Re: [tcpm] feedcback on tcp-secure-05

[Joe Touch <[e-mail]>]

Anantha Ramaiah (ananth) wrote:
>  
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]] 
>> Sent: Monday, July 17, 2006 7:31 AM
>> To: Anantha Ramaiah (ananth)
>> Cc: Fernando Gont; [e-mail]
>> Subject: Re: [tcpm] feedcback on tcp-secure-05
>>
>>
>>
>> Anantha Ramaiah (ananth) wrote:
>> ..
>>> Another point to note is that TCP SHOULD act (not a MUST) on ICMP 
>>> reported hard errors. Also in some cases like "port 
>> unreachable" can 
>>> be ignored since TCP uses the RST for the purpose of port 
>> unreachability.
>>> This is as per RFC 1122. 
>> 1122 actually states exactly the opposite:
>>
>>             A transport protocol
>>             that has its own mechanism for notifying the sender that a
>>             port is unreachable (e.g., TCP, which sends RST segments)
>>             MUST nevertheless accept an ICMP Port Unreachable for the
>>             same purpose.
> 
> Yep, I stand corrected but one of main points above was to point out the
> SHOULD language (which makes sense) instead of MUST.

So you're changing 1122? That needs to be highlighted.

>>> - Some applications would chose to ignore the so called hard errors 
>>> for a TCP connection. In other words the behaviour can be 
>> controlled 
>>> by a CLI and the default would be to ignore this hard 
>> errors. So the 
>>> connection reset wouldn't happen.
>> The default SHOULD be to act on hard errors unless overridden 
>> by the application; to do otherwise would be to redefine 1122 
>> in this regard.
> 
> Going neutral here, since the systems which I have worked do ignore them
> by default and it isn't an RFC voilation.
> 
> As per RFC 2119 :
> 
> "3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course."
> 
> Most of the applications would like to have a say in the treatment of
> ICMP errors by requesting the errors to be passed to it and then
> determine the course of action to take. For the ICMP hard errors
> described, the action generally doesn't result in connection closure and
> also some applications don't even register for some of the hard errors
> and also expect TCP not to close the connection instead silently ignore
> them

1122 fairly directly indicates that ICMP port unreachable MUST be
handled exactly as a RST ("accept for the same purpose").

A SHOULD would be a change to that, and needs to be highlighted as a
change to 1122.

Further, as you note above, negating a should implies that the document
indicate the "particular circumstances" that apply. The doc doesn't
currently discuss interpreting violating messages as an attack and after
a threshold is reached THEN negating the SHOULD. That's key.


> Actually application or TCP level keepalives or retransmission timeouts
> act as a catalyst for the connection closure generally and not ICMP
> errors. But YMMV and I do not intend to argue on this point. Just
> stating my experience.
> 
>> ...
>>> I guess my point is ICMP attacks may be a weakest link, but 
>> wouldn't 
>>> cause connection resets with proper installed workarounds in place. 
>>> Yes, I mean without voilating the current RFC's.
>> Those workarounds MUST be in place, or they ARE the weakest 
>> link. That's the point that this document must discuss at least.
> 
> I don't think that tcpsecure document should discuss these workarounds
> or advise anything of that sort. It is always good to keep the scope of
> the document right and tight.

"right and tight" isn't a justification for not discussing the
"particular circumstances" above.

>>> Also with or without ICMP mitigations in place, one could 
>> still cause 
>>> a TCP connection to RESET, if the mitigations described in 
>> tcp-secure 
>>> isn't present.
>> Without ICMP protection, why bother with a RST when the ICMP 
>> is _easier_ to generate?
> 
> Easier to generate but workarounds can be planted if necessary like I
> have described in earlier emails. On the other hand there aren't any
> known "generic workarounds" available for the issues described in
> tcp-secure. I say generic workarounds since MD5 is used only by a
> handful of applications like BGP, LDP and is a costly workaround and 
> 
> Anyways just to summarize :
> 
> The tcp-secure document, can, at the most state something informative
> like "ICMP attacks aren't covered in this document blah blah..." and
> provide a pointer to the icmp draft if needed.
> 
> To suggest about blocking ICMP etc., calls for stretching too far the
> scope of the doc and also it introduces obvious incompleteness. 

I'm not going to debate this further. I'll be glad to note the omission
to the Security AD; if they think this doc is useful without it, fine.

> What if
> somebody wants to provide some pointer and suggest some
> blocking/mitigation mechanisms for something else..? I see no end to
> this that way..
> 
> Agree/dis-agree ?
> 
> :)
> -Anantha
>> Joe
>>
>>

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