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

[Fernando Gont <[e-mail]>]

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?



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

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.



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



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



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

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