Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)

[Fernando Gont <[e-mail]>]

Joe Touch wrote:

[talking about RFC 4301]
>>> It discusses PMTU and unreachables, neither of which have much impact on
>>> protocols that don't establish connections. UDP passes ICMPs up, and
>>> generates them when the port isn't listening, but otherwise does not
>>> interact with ICMP.
>> That's your assessment. And while I may agree with it, that's not what
>> the spec says. The only ICMP unreachable about which the spec talks with
>> some level of detail is "frag needed". For instance, it never mentions
>> the possibility of ICMP unreachables of being used for connection reset
>> attacks.
> 
> 6.  ICMP Processing
> 
>    ...There are two
>    categories of ICMP traffic: error messages (e.g., type = destination
>    unreachable) and non-error messages (e.g., type = echo).  This
>    section applies exclusively to error messages.
> 
> then further...
> 
> 6.1.1.  ICMP Error Messages Received on the Unprotected Side of the
>         Boundary
> 
>    Figure 3 in Section 5.2 shows a distinct ICMP processing module on
>    the unprotected side of the IPsec boundary, for processing ICMP
>    messages (error or otherwise) that are addressed to the IPsec device
>    and that are not protected via AH or ESP.  An ICMP message of this
>    sort is unauthenticated, and its processing may result in denial or
>    degradation of service.
> 
> How do you interpret denial or degradation w.r.t. destination unreachables?

Again, that's your personal assessment, not what the spec says.
What service does TCP provide? - Data transfer. Is it degraded for not
reacting to ICMP errors? No. For instance, nobody resets established
connections in response to ICMP error messages. So if you consider that
a "degraded service", we all use scuh a degraded service.

And, btw, in this quoted para, it's "its *processing*" (i.e., *honoring*
the ICMPs) that may lead to denial or degradation of service.



> 6.0 says that this section is exclusively about error messages of type
> dest unreachable:
> 
>    ... There are two
>    categories of ICMP traffic: error messages (e.g., type = destination
>    unreachable) and non-error messages (e.g., type = echo).  This
>    section applies exclusively to error messages.
> 
> Sec 6.1.1. says that these can result in denial of service:
> 
>    ...An ICMP message of this
>    sort is unauthenticated, and its processing may result in denial or
>    degradation of service.  This suggests that, in general, it would be
>    desirable to ignore such messages.
> 
> TCP and other connection oriented protocols are a primary user of such
> error messages; UDP sends port unreachable, but otherwise does not
> itself react to ICMPs.

But the spec is not talking about the transport protocol reacting to
these messages, but about the processing of them. In the case of UDP,
that would be the processing of ICMP errors by the app layer.



>    ...However, many ICMP messages will
>    be received by hosts or security gateways from unauthenticated
>    sources, e.g., routers in the public Internet.  Ignoring these ICMP
>    messages can degrade service, e.g., because of a failure to process
>    PMTU message and redirection messages.  Thus, there is also a
>    motivation for accepting and acting upon unauthenticated ICMP
>    messages.
> 
> TCP and other connection oriented protocols are the primary users of
> PMTU messages.

In the case of UDP, the app would be the user of those messages.
Actually, in the case of TCP the app could also be a user of those
messages (RFC 1122 about relaying ICMP errors to apps).



>>>> I guess you could come up with some scenario in which it makes sense to
>>>> process ICMP messages for connections that employ TCP-AO. However,
>>>> principle of least surprise: one of the main drivers for TCP MD5 was to
>>>> mitigate connection-reset attacks. Thus, by default, you should close
>>>> the avenue of ICMP-based attacks, too. IMO, that is the safe default.
>>> Principle of least surprise also means not making a TCP-AO connection
>>> need to wait for a full timeout even when an endpoint cannot be reached,
>>> whether during a connection or during establishment. 
>> We have debated RFC 5461 for years (literally), and you know care about
>> long delays in connection establishment attempts? That said, if you were
>> able to establish the connection in the first place, chances are that
>> you will receive soft errors, not hard errors. Therefore you wouldn't be
>> aborting the connection, anyway. For connection establishment, you may
>> be right... but RFC 5461 seemed controversial for connections that
>> didn't employ authentication, and you now consider it acceptable for
>> "authenticated" connections?
> 
> I am NOT in favor of changing TCPs reaction to ICMPs in TCP-AO, any more
> than I was in RFC5461.

You are concerned that ignoring ICMPs may lead to long timeouts. What's
the difference?



>> That said, TCP-AO/MD5 are meant for security, not performance. If you
>> enable it, you expect security, not performance. Having TCP-AO and then
>> being spec-wise vulnerable (by default) to trivial ICMP attacks would be
>> non-sensical.
> 
> IPsec has exactly the same tradeoff, yet fails to come to the same
> conclusion. 

We're not here to rehash the past for the sake of it. The fact that some
spec does something doesn't mean that we have to repeat the same thing
in new work.

FWIW, from that perspective, you could have ignored the ICMP attacks
issue altogether, as RFC 2385 does not even talk about it. -- No need to
say that I'm happy that the TCP-AO I-D is different in this respect.



>>> It also means not
>>> turning a functioning PMTUD mechanism into a black hole.
>> Agreed. That's why I said "frag needed" are a different issue.
> 
> The same thing happens when redirects are ignored - black hole.

No. Redirects are an optimization. honoring redirects without something
like GTSM (which you cannot really enforce) would be dumb nowadays.



>>> Do not abort ignores the latter. Again, there is no reason
>>> to *default* to this case.
>> Yes. I enable TCP-AO to protect my connections against reset attacks.
>> Why would I bother doing it if you don't close the even-easier ICMP
>> vector????
> 
> There are cases where, e.g., replays are possible but it is much more
> difficult to generate packets. There are also cases where some IP
> addresses can be spoofed but not others (e.g., where reverse path
> validation is done).

>From the Intro of RFC 2385:

"   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets."

Again, I believe TCP-AO should default to ignoring ICMP hard errors, at
least for the established states.



> Regardless, it's up to the user to decide. I'm not saying they would
> never decide to block ICMPs, but I don't agree that we can disable ICMP
> by default.

Does the *user* really need to know about TCP internals such as how TCP
reacts to those error messages?



>>> I believe letting the user configure whether specific ICMPs are passed
>>> or ignored covers the needed functionality.
>> You expect the user to know too much. Pick a safe default, and then let
>> the knowledgeable user override that default (if needed).
> 
> TCP-AO isn't enabled by default either. And systems that have
> unpredictable behavior (e.g., won't work - not just won't be fast -
> because valid ICMPs won't get through) get turned OFF.
> 
> I expect a user to either disable or enable ICMPs. An implementation can
> do what it wants regarding defaults.

Do you really expect the user to go and play with the switches for each
message type/code? I don't, and wouldn't want the general TCP-AO user to
do so.


>>> It is both viable and currently in widespread use. Discussion of that
>>> field should happen on the INTAREA list, not here, but as I noted the
>>> proposed update to 791 makes that ID field useful so long as DF=0 or the
>>> packet has already been fragmented, and the ID is unique over some
>>> multiple of the expected reordering - not just unique within 2MSL as is
>>> the current requirement.
>> I had read your proposal in the past, but do not recall the details
>> right now. However, the problems of fragmentation has been beaten to
>> death. (e.g., the Matthis/Heffner RFC).
> 
> Matthis/Heffner describes some problems. My draft proposes a change to
> the standard, and was written with Mathis FWIW. If you want to discuss
> it further, again, please do so on the INTAREA list.

FWIW, I'm not against your proposal. Actually, IIRC, I was in general
agreement with it.



>> Ignoring ICMP errors is sort of the same thing: you're not complying
>> with the specs. At that point (i.e., once you have decided not to comply
>> with the standard), whether you simply ignore the ICMP errors or you
>> ignore them based on connection progress, is a minor detail.
> 
> The WG did not think so, 

I was talking about the PMTUD mitigation in the ICMP attacks I-D, and
not about RFC 5461.


> which is why 5461 was limited to describing
> what had been implemented and is Informational rather than making a
> recommendation and being BCP or Standards Track (BTW, any idea who did
> the implementation you were documenting?)

The soft errors implementation? I don't know which developer, but it was
implemented in Linux and a number of other systems, well before I
started working on RFC 5461.

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