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.

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

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.

>>> What to do with "frag needed" might vary. Although one could argue that
>>> you SHOULD implement PLPMTUD.
>> ---
>>
>> We could add that TCP-AO, like IPsec (text copied from 4301):
>>
>>    ...A compliant TCP-AO
>>    implementation MUST permit a local administrator to configure an
>>    IPsec implementation to accept or reject unauthenticated ICMP
>>    traffic.  This control MUST be at the granularity of ICMP type and
>>    MAY be at the granularity of ICMP type and code.  Additionally, an
>>    implementation SHOULD incorporate mechanisms and parameters for
>>    dealing with such traffic.  For example, there could be the ability
>>    to establish a minimum PMTU for traffic (on a per destination basis),
>>    to prevent receipt of an unauthenticated ICMP from setting the PMTU
>>    to a trivial size.
> 
> Makes sense to me. Although, again, I believe there should be (safe)
> defaults for this.

Defaults have generally been removed from the document for various reasons.

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

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

iEYEARECAAYFAko341sACgkQE5f5cImnZruR3gCgvJVChK96Gf8moejptPAu4RP7
1CgAnipyWxdfj+pzb4MN7RSv7ON3HmIx
=ynAC
-----END PGP SIGNATURE-----