Date: Mon, 01 Jul 2002 20:53:30 -0700 From: Tom Pavel <pavel@networkphysics.com> To: net@FreeBSD.ORG Subject: questions about TCP RST validity Message-ID: <200207020353.g623rUR62985@scout.networkphysics.com>
next in thread | raw e-mail | index | archive | help
Hi. I'm confused about some code dealing with the acceptance of RSTs
in tcp_input.c. I've gleaned what I can about the history of that
code through the CVS repository, but I'm still looking for some more
insight. The code in question requires that a RST have a sequence
number within the current advertised window:
if (thflags & TH_RST) {
if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) &&
SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) {
switch (tp->t_state) {
case TCPS_SYN_RECEIVED:
...
}
}
goto drop;
}
This is all well and good. It follows RFC793 which says:
In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window.
This prevents DoS attacks by requiring an intruder to guess a seqnum
within the current window. (The code appeared with revs 1.81 and
1.98, responding to PR kern/7892 which concerned such DoS attacks.)
However, it seems to ignore the possibility that the RST and an ACK
updating the advertised window might cross in flight. RFC793 also
requires that RSTs set their seqnum from the ACK field of the pkt they
are responding to, even if the sender knows it has sent a seqnum
beyond that ACK (like the FIN below).
Here is a trace to illustrate:
09:05:35.214014 BB.61390 > AA.80: S 2597110672:2597110672(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 3845318 0>
09:05:35.214310 AA.80 > BB.61390: S 3568521185:3568521185(0) ack 2597110673 win 4380 <mss 1460> (DF)
09:05:35.277441 BB.61390 > AA.80: . ack 3568521186 win 65535
09:05:35.278316 BB.61390 > AA.80: P 2597110673:2597111260(587) ack 3568521186 win 65535
09:05:35.302557 AA.80 > BB.61390: P 3568521186:3568522646(1460) ack 2597111260 win 4380 (DF)
09:05:35.302659 AA.80 > BB.61390: P 3568522646:3568524106(1460) ack 2597111260 win 4380 (DF)
09:05:35.302762 AA.80 > BB.61390: P 3568524106:3568525566(1460) ack 2597111260 win 4380 (DF)
09:05:35.380157 BB.61390 > AA.80: . ack 3568524106 win 64240
09:05:35.380211 AA.80 > BB.61390: . 3568525566:3568527026(1460) ack 2597111260 win 4380 (DF)
09:05:35.380231 AA.80 > BB.61390: . 3568527026:3568528486(1460) ack 2597111260 win 4380 (DF)
09:05:35.380248 AA.80 > BB.61390: . 3568528486:3568529946(1460) ack 2597111260 win 4380 (DF)
09:05:35.451495 BB.61390 > AA.80: . ack 3568527026 win 64240
09:05:35.451537 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111260 win 4380 (DF)
09:05:35.451552 AA.80 > BB.61390: . 3568531406:3568532866(1460) ack 2597111260 win 4380 (DF)
09:05:35.451571 AA.80 > BB.61390: . 3568532866:3568534326(1460) ack 2597111260 win 4380 (DF)
09:05:35.453172 BB.61390 > AA.80: . ack 3568529946 win 62780
09:05:35.453206 AA.80 > BB.61390: . 3568534326:3568535786(1460) ack 2597111260 win 4380 (DF)
09:05:35.453221 AA.80 > BB.61390: . 3568535786:3568537246(1460) ack 2597111260 win 4380 (DF)
09:05:35.453976 BB.61390 > AA.80: F 2597111260:2597111260(0) ack 3568529946 win 65535
09:05:35.454002 AA.80 > BB.61390: . 3568537246:3568537538(292) ack 2597111261 win 4380 (DF)
09:05:35.518444 BB.61390 > AA.80: R 2597111260:2597111260(0) win 0
09:05:35.956066 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:05:36.961787 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:05:38.973207 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:05:42.996062 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:05:51.041749 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:06:05.689800 AA.80 > BB.61390: . ack 2597111261 win 4380
09:06:07.133106 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:06:35.861159 AA.80 > BB.61390: . ack 2597111261 win 4380
09:06:39.315883 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:07:06.032500 AA.80 > BB.61390: . ack 2597111261 win 4380
09:07:11.498638 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:07:36.203832 AA.80 > BB.61390: . ack 2597111261 win 4380
09:07:43.681378 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:08:06.375192 AA.80 > BB.61390: . ack 2597111261 win 4380
09:08:15.864135 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:08:36.546533 AA.80 > BB.61390: . ack 2597111261 win 4380
09:08:48.046904 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:09:06.717897 AA.80 > BB.61390: . ack 2597111261 win 4380
09:09:20.229640 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF)
09:09:36.889228 AA.80 > BB.61390: . ack 2597111261 win 4380
09:09:52.412413 AA.80 > BB.61390: R 3568537538:3568537538(0) ack 2597111261 win 4380 (DF)
Now, it seems to me that one could argue that the fault is entirely on
BB, who fails to respond with RST to all the pkts sent after the
initial RST. I imagine that this could be caused by some sort of
stateful firewall, or perhaps by BB hanging up a dialup connection.
This case is alluded to in the tcp_input.c comments:
* If we have multiple segments in flight, the intial reset
* segment sequence numbers will be to the left of last_ack_sent,
* but they will eventually catch up.
In any event, though, it seems to me relatively harmless to have AA
accept seqnums "slightly" to the left of its current advertised window
(say last_ack_sent - rcv_wnd). This would save a bunch of needless
retransmits and it would clean up the control block much sooner than
letting AA timeout on retransmitting.
What collective wisdom do folks have about this?
Tom Pavel
Network Physics
pavel@networkphysics.com / pavel@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207020353.g623rUR62985>