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

[Joe Touch <[e-mail]>]

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.

The complexity I'm referring to is reflected in the exchange on details 
and corner cases you've posted to this list.

> 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.

 > As far as my understanding
> goes TCP is concerned with reliable transport of data, not absolutely
> reliable abortions of the same through RSTs and SYNs.  They do play
> an important role in the functioning of the overall system but they
> are not sensitive to a delay of a couple of milliseconds.

Correct; however, just because an endpoint didn't expect a packet does 
not imply it is an attack either. That's the flaw in this system, IMO - 
and a reason why bursts of RSTs or SYNs to the same addr/port pair are a 
fairly clear indication of a problem, the filtering out of which would 
make these mods completely unnecessary.

Joe

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