Re: [tcpm] Q&C regarding tcpsecure-09 recommendations

[Joe Touch <[e-mail]>]

Andre Oppermann wrote:
> Joe Touch wrote:
>> Andre Oppermann wrote:
>> ...
>>>>     2. adding these mitigations complicates the TCP implementation,
>>>>     and makes it less robust to legitimate RSTs, esp. in the
>>>>     presence of reordering; it can increase the time needed to
>>>>     reset a connection by one or more RTTs
>>>
>>> Agreed for the second part about the potential for the time increase.
>>> Not agreed to the first part.  All kinds of mitigations make TCP
>>> implementations more complex.  Port randomization does, TCP-MD5 does,
>>> IPsec does and so on.  You can trust me on this one. ;-)
>>
>> IPsec has nothing to do with the TCP implementation; it may make the 
>> stack more complex, but not TCP. Port randomization is a one-time 
>> event during SYN creation, and should be easy to factor out as a 
>> separate call. TCP MD5 is complex, but already implemented.
> 
> Port randomization is complex to implement.

It's already implemented. See my other reply.

>> The complexity I'm referring to is reflected in the exchange on 
>> details and corner cases you've posted to this list.
> 
> There are just as many corner cases with (true) port randomization.
> Have a look at its CVS history in the BSDs.  Or Linux.  Took a couple
> iterations.

Multiple iterations is not an indication of difficult corner cases.

>>> Repeating myself:
>>>
>>> The extra time it may take in an edge case is not terribly high.  Most
>>> RSTs will match and do their thing. 
>>
>> Actually, you've already indicated cases where that might not be true; 
>> if RSTs are used to shut down typical connections "just in case", if 
>> any of the in-transit data was lost, then these will trigger the ACK 
>> exchange and extra RTT. This costs extra time, extra packets, and 
>> extra processing on both ends - all for a NON MALICIOUS CASE.
> 
> Normally the connection is in an idle state.  It is primarily observed
> with web servers where either the client or server wants to do persistent
> connections and the other end does not.  Or it times out.  There would be
> no extra round-trip for the RST to be come effective.

It's also been observed in web servers that want to reduce the amount of 
TIME_WAIT state they hold - and thus kernel memory they tie up - for 
connections that clients close by normal means.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm