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

> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU] 
> Sent: Monday, July 17, 2006 7:31 AM
> To: Anantha Ramaiah (ananth)
> Cc: Fernando Gont; tcpm@ietf.org
> 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.

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

> 
> > 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. 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
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm