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

[Joe Touch <[e-mail]>]

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



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>>> I think that for the sake of the "principle of least surprise", ICMP
>>>>> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.
>>>> Please explain why you think that TCP-AO needs more strict advice in
>>>> this regard than IPsec.
>>> 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.

>>> In the case of TCP-AO, it's TCP specific, and thus I believe it should
>>> provide stricter advice wrt how TCP should react to ICMP error messages
>>> when they are received for connections that employ TCP-AO.
>> It's probably useful to split out the discussion of ICMP to a separate
>> section. However, the advice therein seems like it should still not
>> exceed what is in 4301 for the same reason for the same transport
>> protocol - there are pros and cons of either leaving open or closing
>> ICMP handling.
> 
> 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.

> TCP-AO is TCP-specific. And IMHO it would thus make sense for the
> document to be as specific/detailed as necessary.
> 
> 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. It also means not
turning a functioning PMTUD mechanism into a black hole.

As 4301 notes, there are good reasons for either way of configuring an
endpoint - endpoints it is intended to protect from replays and
connection interruption as well.

>> 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. Do not abort ignores the latter. Again, there is no reason
to *default* to this case.

I believe letting the user configure whether specific ICMPs are passed
or ignored covers the needed functionality.

>>>> We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
>>>> particular recommendations of implementation. We would need to be
>>>> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
>>>> deployment.
>>> I believe it could/should be suggested that PLPMTUD be implemented
>>> without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821
>>> leaves it open as to whether PMTUD should only be implemented for
>>> dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).
>> 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.

>> 	- use DF=1 with PMTUD
>> 		this requires ICMP frag-needed be passed
>> 		which opens a vulnerability on that ICMP type
>> 		however, the attack of additional frag-neededs
>> 		could reduce efficiency but won't shut down TCP
>> 	- use DF=1 with PLPMTUD
>> 		this allows ICMP frag-needed to be dropped
>>
>> 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.

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

iD8DBQFKOAePE5f5cImnZrsRAn0tAKCN+2xduqYoJ4TzBOwN9FZcECqFggCg7gn8
Y5YE3pjk/rAEGeVrwRBCU8s=
=EtH6
-----END PGP SIGNATURE-----