TCP and syncache question

[Rui Paulo]

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