Re: [tcpm] Some comments on tcpsecure

[Fernando Gont <[e-mail]>]

At 12:40 p.m. 07/04/2008, Joe Touch wrote:

>>>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....
>
>Routers are supposed to forward packets in a timely fashion, but are 
>encouraged to delay control plane event processing when loaded - 
>both are in RFC 1812.
>
>I.e., for forwarding this is required, but for ICMP the contrary us 
>allowed and encouraged if needed.

I'd bet that it is more likely that packets get delayed longer for 
congestion probems or while transiting a link (e.g., a satellite 
link) than for that of delaying control plane event processing when loaded.



>>>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.
>
>Again, known implementation bugs aren't the issue - and since seq 
>checking isn't required, dropping packets due to that check 
>qualifies IMO as an implementation bug.

Well, I guess we have to agree to disagree. :-)



>But this is still somewhat off topic if there's a way to get 95% of 
>the way there without doing a seq check, which is what I'm 
>suggesting. That would correct the *intent* of the current code 
>without *needing to change the current specs* (which is the only way 
>to *require* timely ICMPs).

ICMP code has been for a long time (>20+ years, in some cases) to do 
"hard errors -> soft errors". The TCP SEQ check was originally 
implemented in Linux as a general validation check. Then applied in 
virtually all stacks for the same reason.
The TCP SEQ check is particularly useful as a mitigation against 
PMTUD attacks... and some have seen as something quicker/easier to 
implement than the mechanism proposed in my draft (although FWIW, I 
implemented the mechanism myself for OpenBSD, and it wasn't what pne 
would call "complex" at all...)



>>>>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.
>
>Robustness also allows signalled connection faults to recover 
>quickly, rather than on the same timescale as a 'no message' 
>timeout. Yes, though, the devil is in the detail of what that timeout would be.

You say it allows a connection to recover quickly, but... why would 
it actually recover, if you are not affecting the path that packets follow?



>>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.
>
>That's assuming the worst timeout, IMO, which is a particular 
>timeout value I disagree with.

That's how the Internet has worked during the last 20+ years. 
BSD-derived and Mentat-derived implementations have always done this.



>>>>(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)
>
>The first one can easily have a seq num check, since the connection 
>isn't open long enough for a legitimate delay. However, the 
>subesquent ones don't seem to have that luxury, IMO.

Well, that wouldn't be a big deal. After all, the delay I'm more 
concerned about would be the one when the connection has just been 
established (as it would affect interactive applications). Although 
one might argue that with http persistent-connections, connections 
could be affected by the delay made after the 10-minute PMTUD-timeout.....

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