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

Joe Touch <touch@ISI.EDU> Tue, 16 June 2009 23:01 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9705628C0EF for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 16:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAElKPLyqW9b for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 16:01:46 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 420833A6C6B for <tcpm@ietf.org>; Tue, 16 Jun 2009 16:01:46 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GN1Sqh021796; Tue, 16 Jun 2009 16:01:30 -0700 (PDT)
Message-ID: <4A382448.7080705@isi.edu>
Date: Tue, 16 Jun 2009 16:01:28 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <4A30BED6.3050308@gont.com.ar> <4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu> <4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu> <4A38191D.4010604@gont.com.ar>
In-Reply-To: <4A38191D.4010604@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2009 23:01:47 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>>> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
>>>>> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
>>>>> to get into the details of how a specific transport protocol (TCP) would
>>>>> react to specific ICMP error messages.
>>>> It does, though, in detail.
>>> Can you quote the text you are referring to, or provide a citation to
>>> the specific Section you are referring to?
>> Section 6.
>>
>> 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?

 >>> As I mentioned, IPsec is by far more general. And thus it sort of makes
>>> sense to avoid being specific about any protocol that it could possibly
>>> encapsulate.
>> As I said above, IPsec is fairly specific about the handling of ICMPs
>> and reasons thereof. Those reasons apply primarily to TCP - including
>> when to both ignore ICMPs and when they should not be ignored.
> 
> Joe, I've just read Section 6, and there's no such a thing. Please quote
> text from that section which assesses ICMP hard errors, and prove me wrong.


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.

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

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

> 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. It is just as sensible to make the same recommendation here
as IPsec does - let the user decide.

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

>>>> This document is not a place where the difference between hard and soft
>>>> ICMPs and TCP opening vs. established should be resolved, since it has
>>>> not been resolved for TCP without authentication, and authentication
>>>> does not apply to the ICMP messages.
>>> Agreed. Easier: ignore ICMP error messages, or "do not abort connections
>>> in response to ICMP error messages".
>> Ignore disables valid PMTUD and valid connection termination
>> indications. 
> 
> I was meaning any ICMP error messages other than "frag needed" in this case.

See above; it's more than just frag needed.

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

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.

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

>>>> There are a few possibilities:
>>>>
>>>> 	- use DF=0
>>> Could be an option. However, considering that the IP ID field is 16-bits
>>> long, I don't think that relying on IP fragmentation should not be
>>> considered a viable option nowadays.
>> 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.

>>>> The security benefits of PLPMTUD are more significant when ICMPs are
>>>> dropped more than when they are spoofed, but it can be noted.
>>> FWIW, if you implement the PMTUD counter-measure described in the ICMP
>>> attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the
>>> security drawback of the traditional PMTUD (check for progress on the
>>> connection before honoring the ICMP error message).
>> That's an *if*. We're not modifying TCP functionality as part of TCP-AO;
>> we're extending it to support security. Changes of the nature you
>> propose may be useful in conjunction once standardized, but until we
>> make that case for TCP we can't add it to TCP-AO, IMO.
> 
> 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, 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?)

Joe

joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKOCRIE5f5cImnZrsRAilRAKD5xXlUT/tXXJH+NL6212IS315bCgCg1TDW
qt7HJY9HF0vr0q5o0ShcHlY=
=If3n
-----END PGP SIGNATURE-----