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

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.

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

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

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

I'm all ears on your magic RST/SYN burst filter.

-- 
Andre

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm