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

[Fernando Gont <[e-mail]>]

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.


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



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

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.



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



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



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



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



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


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

Thanks!

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