TCP and syncache question
rpaulo at freebsd.org
Sun Nov 16 16:01:58 PST 2008
On 16 Nov 2008, at 12:55, Hartmut Brandt wrote:
> Rui Paulo wrote:
>> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote:
>>> 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.
More information about the freebsd-net