TCP/BGP vulnerability - easier than you think

Tue Apr 27 16:24:07 UTC 2004

I didn't have it quite right though because I said the host that sends the 
ACK could keep sending and then that would trigger a RST. But the ACK 
triggers an immediate RST from the host that sent the original RST. This 
time the RST has the right sequence number (derived from the ACK).

Maybe I would have gotten more responses if I hadn't admitted this was for 
my students. :-) I wear many hats and do work as a network operator too 
(but for a small network).

Cheers,

Priscilla Oppenheimer

At 09:14 AM 4/27/04, Iljitsch van Beijnum wrote:
>On 27-apr-04, at 5:03, Priscilla Oppenheimer wrote:
>
>>    C) If the RST bit is set and the sequence number does not exactly
>>       match the next expected sequence value, yet is within the
>>       acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an
>>       acknowledgment.
>
>>So, per item C, does the recipient of a RST with a sequence number that 
>>does not exactly match the next expected sequence value not reset the 
>>connection? It sends an ACK but keeps the connection open?
>
>Looks that way to me.
>
>>The ACK will go to the correct TCP partner, not the attacker presumably. 
>>So then that partner resets. But where does this leave the other partner 
>>(the recipient of the RST)? Is the assumption that this side may continue 
>>sending, which would cause the other side to RST (since it closed the 
>>session) and this RST would have the correct sequence number so the 
>>connection would get reset from both partners' points of view?
>
>Yes. I think the idea is that if A has the session open and B has it 
>closed, then the only real RSTs will be those that B sends for packets it 
>receives from A. If those packets have and acknowledgement number in them 
>(which should always  be the case for established sessions) then this will 
>be the RST's sequence number so there will be a perfect match between what 
>A expects from an RST and what B sends.
>
>The situation where B legitimately sends a sequence number that isn't an 
>exact match is hard to imagine, as the ACKs A sends depend on the sequence 
>numbers B sent and if the session is dead at B's end presumably B isn't 
>burning up too many sequence numbers. But if this happens for some reason 
>and A sends a dataless ACK packet obviously B will respond with an RST so 
>we're back to the situation where B is sending an RST with the sequence 
>number that A expects.

_______________________________

Priscilla Oppenheimer
www.priscilla.com

When your Daemon is in charge, do not try to think consciously. Drift, 
wait, and obey. -- Kipling.