[70057] in North American Network Operators' Group
Re: TCP/BGP vulnerability - easier than you think
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Tue Apr 27 03:15:18 2004
In-Reply-To: <5.2.0.9.2.20040426194918.02081540@opendoor.com>
Cc: nanog@merit.edu
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Tue, 27 Apr 2004 09:14:30 +0200
To: Priscilla Oppenheimer <po@priscilla.com>
Errors-To: owner-nanog-outgoing@merit.edu
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.
