Subject: [Tsvwg] ISN regeneration in the Stateless SYN cookie approach

From: "gangadharan annapurna" <[email-masked]>
Date: Fri, 19 Oct 2001 05:14:07 +0530

Hi folks,

I had a question about the Stateless SYN
cookie approach to solve the Denial of Service attack.
The linux kernel has implemented this for quite some
time now.

So basically when we get an incoming SYN we send back a
SYN+ACK with the ISN generated as

ISN = f(t) + MD5(Sport,Saddress,Dport,Daddress,secret1)

where
f(t) is a monotonically increasing function of time
Secret1 is a boot time generated secret number

However lets assume the SYN+ACk that we sent back got
delayed and the client sends a new SYN request.  And
the server sends back a new SYN+ACK and regenerates the
a new ISN.  Note that we are not preserving any state
so the ISN we sent back the first time cannot be regenerated
again.

In the meantime the client gets the OLD SYN and it accepts
it and the connection goes to established state. A  TCB is
created.

Now when the new SYN+ACK arrives and if the new ISN falls
within the Receive window of the client, then the packet
is wrongly accepted.  How  do we handle this issue ?

thanks
Naren

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Neil Spring <[email-masked]>
Date: Thu, 18 Oct 2001 18:15:36 -0700

Your scenario expects that the first syn/ack gets delayed
by between 3 seconds and 3+rtt seconds so that it arrives
before the second syn/ack.  This is unlikely.

Your scenario then assumes it's a bad thing that the
syn/ack is "accepted" in the middle of an established
connection.  Although strange, I'd be surprised if this is
bad:
- The ack part of the syn/ack isn't a problem because both
  client transmissions of the initial syn contain the same 
  sequence number.  

- The syn part of the ("new") syn ack doesn't seem to be
  a problem because the connection is already established.

- There's no data to be placed in the window.

There are many denial of service attacks; the attack this
scheme protects against is called "SYN flooding".

You mentioned window scaling on your messages to
end2end-interest.  Note that these cookies are not used
with window scaling, and that window scaling does not
apply to the initial handshake.  Note also that the
initial receive window advertised on new connections by
linux clients is small (around 5k).  

forgive me if I misunderstood the question.  a diagram
might help describe your scenario better.

-neil

---

From: Murali Bashyam <[email-masked]>
Date: Thu, 18 Oct 2001 18:17:11 -0700

> so the ISN we sent back the first time cannot be regenerated

Isn't this a violation of the protocol? The retransmitted SYN has to be sent
with
the original sequence number i.e it is exactly like any retransmitted packet.

Murali