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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
