Re: [tcpm] Some comments on tcpsecure

[Fernando Gont <[e-mail]>]

At 02:05 a.m. 07/04/2008, Joe Touch wrote:

>>The TCP SEQ check would help a bit in those scenarios in which an 
>>attacker might be able to spoof an ICMP error message, and cause 
>>the connection to be stuck for a little while (e.g., by means of 
>>causing congestion). That is, it would require more packets on the 
>>side of the attacker.
>
>In those cases, I still see the contents of the ICMP to be moot 
>(w.r.t. window). That info is useful only if:
>         - ICMPs are known to be returned in a timely fashion
>         (and there's no way of knowing)

If anything, isn't this the case for any type of packet? After all, 
any packet can get queued in a router or be delayed whilie transiting 
a link....



>         OR
>         - there's some way to differentiate between legitimate
>         ICMPs and attack ICMPs
>
>Since neither is the case, this is a moot issue. I do not agree that 
>checking the TCP SEQ in the content of an ICMP is ever appropriate.

Well, I do know that you don't like the idea, but the systems I know 
of will not consider a packet legitimate unless there's enough reason 
for that. For ICMPs, the bar for that is the SEQ contained in the 
payload. That's what everybody has been doing for quite some time.



>>However, if TCP waits for USER_TIMEOUT to check whether the 
>>connection is making forward progress, then this is basically the 
>>"hard errors should be considered to indicate soft errors when 
>>received for connections in any of the synchronized states" 
>>behavior, and thus an attacker could not exploit the so-called ICMP 
>>hard errors to perform reset attacks.
>
>Waiting that long defeats the purpose of the errors - to terminate 
>connections more rapidly than TCP would otherwise. That is, IMO, too far.

Well, that's just a matter of policy. In any case, Clark's RFC on 
"Fault Isolation and Recovery" and even "The Design of the DARPA..." 
seem to support this idea: data transfers should work when there is 
at least a working path to do the transfer.
As I have seen you have mentioned a number of times, TCP is not 
supposed to be optimized for any scenario (e.g., multi-path 
scenarios). So if there's a working path, I think that for robustness 
sake the connection should not be aborted.

In any case, I don't think we'd even have to stick to any particular 
timeout. Particularly, given that we can accommodate existing 
implementations (hard errors -> soft errors) as a degenerate case of the above.


>>(i.e., the "hard errors should be considered to indicate soft 
>>errors when received for connections in any of the synchronized 
>>states" becomes a degenerate case of the "checking for progress on 
>>the TCP connection" when TCP waits for USER_TIMEOUT seconds before 
>>concluding whether the connection is making progress or not).
>>(FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as 
>>during what I called 'Initial Path-MTU Discovery', you probably 
>>don't want to wait, so that you get a good convergence time for the PMTUD).
>
>I'd have to think further to see if this appropriate - i.e., if done 
>only once during a connection, before a wrap, then the SEQ might be 
>appropriate to check, but only within that period.

Most of all, the check is needed once at the beginning of the connection.
Then, it might be nice to do it after the 10-minute PMTUD timeout 
when you want to discover the PMTU again. Although at that point 
(t>10 minutes) it wouldn't be much of a problem to just check for 
progress on the connection (what's most important is to avoid delays 
at he beginning of the connection, as that would hurt interactive applications)

Kind regards,

--
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




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