Date: Mon, 17 Nov 2008 00:01:52 +0000 From: Rui Paulo <rpaulo@freebsd.org> To: Hartmut Brandt <hartmut.brandt@dlr.de> Cc: freebsd-net@freebsd.org Subject: Re: TCP and syncache question Message-ID: <27C5037E-25AB-4EA5-B4DA-445A4B4218F1@freebsd.org> In-Reply-To: <49201859.2080605@dlr.de> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Nov 2008, at 12:55, Hartmut Brandt wrote: > Rui Paulo wrote: >> >> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >> >>> Hi, >>> >>> in tcp_syncache.c:syncache_expand() there is a test that the >>> acknowledgement number and the sequence number of an incoming ACK >>> segment are in the expected range. If they are not, >>> syncache_expand() returns 0 and tcp_input drops the segment and >>> sets a reset. So far so good. But syncache_expand() also deletes >>> the syncache entry, and so destroys the connection. I cannot see >>> why it does it. It seems to me that such a wrong segment should be >>> interpreted as to be from another connection and as such the >>> segment should be ignored (but a reset sent). When the correct ACK >>> comes, the connection could still be established. As it is now, >>> the establishment of incoming connections can seriously be >>> disturbed by someone sending fake ACK packets. >>> >>> The same test (for the ack number, not for the sequence number) is >>> also further down in tcp_input.c:tcp_do_segment() (just after the >>> header prediction stuff) and here the handling is correct: the >>> goto dropwithreset just sends a reset and drops the segment but >>> leaves the connection in the SYN-RECEIVED state. This test is >>> probably never reached now, because of syncache_expand(), though. >>> >>> Maybe I fail to see something obvious, though... >> >> >> Well, if the RST is sent, why should we keep the syncache entry? > > Because this effectively destroys the connection in SYN-RECEIVED > which is wrong according to RFC793. On page 69 the handling of > incoming segments for connections in SYN-RECEIVED is described: > first you check the sequence number and, if it is wrong, you send an > RST (unless the RST bit is set in the incoming segment), but > otherwise ignore the segment. > > A segment with a bad sequence number in SYN-RECEIVED is either > forged or from an old connection. In both cases you don't want to > destroy the embryonic connection, because the correct ACK from the > correct peer may still arrive. That clarifies your initial email. You're probably right, I'll try to find out when the bug was introduced. Thanks, -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27C5037E-25AB-4EA5-B4DA-445A4B4218F1>