[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using cookies to defeat syn-flooding
Ron,
Actually, this is approximately what i was trying to say in email last week.
Here is how the exchange happens:
B chooses an initial sequence number (ISS-B) and sends a packet to A with the
synchronize bit turned on, the acknowledgement bit turned off, and the
sequence number set to ISS-A (this is the "SYN" packet).
A chooses an initial sequence number (ISS-A) and sends a packet to B with the
synchronize bit turned on, the acknoweldgement bit turned on, the sequence
number set to ISS-A, and the acknowledgement number set to ISS-B+1 (this is
the "SYNACK" packet).
B then sends a packet to A with the synchronize bit turned off (it stays off
for the rest of the conversation), the acknowledgement bit turned on (it stays
on for the rest of the conversation), the sequence number set to ISS-B, and
the acknowledgement number set to ISS-A+1 (this is the first "ACK" packet).
The point is that if ISS-A is "not guessable", and if A refrains from
allocating "much" state until B has replied to A's SYNACK packet, then when A
sees an ACK from B acknowledging ISS-A, then A knows that B has seen A's
SYNACK.
Thus, A knows it can send packets "to" (possibly "past") the system purporting
to be B. Good old "weak security". But, it has the advantage that from
looking at the forwarding tables starting at A one can (more or less) generate
a finite list of places where the system purporting to be B could be located.
This would be a "good thing". Currently, we have no idea where the sources of
the packets might be.
Greg Minshall