Subject: Security considerations of the ICMPv6 draft

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Apr 2005 08:43:37 -0300

Folks,

I sent some comments off-list to Mukesh, and he suggested to raise them on 
the list.

I think the ICMPv6 draft should add some words to raise awareness about 
ICMP-based attacks that can be performed against transport protocols.

For example, the current draft suggest IPsec, or no checks at all on the 
received ICMP error mesasges.

As pointed out by Pekka:

>By the way, one additional ICMP attack that could possibly be included in 5.2:
>
>    6. As the ICMP messages are passed to the upper-layer processes, it
>       is possible to perform attacks on the upper layer protocols
>       (e.g., TCP) with ICMP [TCP-attack].  Protecting the upper layer
>       with IPsec mitigates this problem, though the upper layers may
>       also perform some form of validation of ICMPs on their own.
>
>Where [TCP-attack] is an informative reference to 
>draft-gont-tcpm-icmp-attacks-03.txt.

Another issue that may be worth considering is suggesting that the 
so-called "hard errors" should not necessarily be considered "hard". While 
there's no RFC 1122 for IPv6 (and thus you might say there's no such thing 
as "hard errors" and "soft errors" in v6), I think everyone will 
extrapolate RFC 1122's statements on soft and hard errors to the ICMPv6 
specification.

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Elwyn davies" <[email-masked]>
Date: Fri, 8 Apr 2005 15:59:09 +0100

Hi, Fernando,

Looking back at the ICMPv6 draft, in the light of this, there are a number
of sanity checks that could be performed on returning error messages to
minimise security risks.

For example:
In draft-gont-tcpm-icmp-attacks-03.txt, the 'port unreachable' error is
cited as possibly being classified as a 'hard error' and provoking a reset.
This error message should only be generated by the destination node (not an
intermediate node) so a check could be added to ensure that the ICMPv6
source was equal to the original packet destination, thus requiring address
spoofing (which you suggest is otherwise not necessary because of the rules
in 2.2).  This would slightly cramp the style of would be hackers.

Likewise, getting a spurious 'fragment reassembly time execeeded' message
for a packet which wasn't fragmented in the first place.

And a number of others.

There is also a significant chance that ICMPv6 packets related to TCP coming
from outside a firewall would be junked by the firewall, especially if they
weren't from the destination address (but usually anyway).

Some of this is discussed in the IPv6 Security Overview draft:
draft-savola-v6ops-security-overview-03.txt

It's very late in the day to modify the ICMPv6 draft but we could put some
extra stuff into the security overview as recommendations (I am currently
editing this and could add some thoughts on this stuff).

What is the community view?
- Add some comments and additional sanity checks to the ICMPv6 spec, or
- Update the security overview, or
- Combination, or
- Neither?

Regards,
Elwyn

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: 08 April 2005 12:44
> To: [email-masked]
> Cc: [email-masked]
> Subject: Security considerations of the ICMPv6 draft
> 
> Folks,
>

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Apr 2005 02:24:30 +0300 (EEST)

> ICMP-based attacks that can be performed against transport protocols.

Any text suggestions -- just to have an idea how verbose and explicit 
you're looking at; did you refer to the proposed text below, or 
something more extensive?

>> draft-gont-tcpm-icmp-attacks-03.txt.

Yes, something like this should be added.  I thought it already was 
there, but apparently not...

> Another issue that may be worth considering is suggesting that the so-called 
> "hard errors" should not necessarily be considered "hard". While there's no 
> RFC 1122 for IPv6 (and thus you might say there's no such thing as "hard 
> errors" and "soft errors" in v6), I think everyone will extrapolate RFC 
> 1122's statements on soft and hard errors to the ICMPv6 specification.

Even if I may agree with this sentiment, IMHO it seems to go too much 
on the side of the transport protocols, and doesn't seem to be 
appropriate in this document.  The above already a provides a pointer.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Apr 2005 01:34:51 -0300

At 02:24 09/04/2005 +0300, Pekka Savola wrote:

>you're looking at; did you refer to the proposed text below, or something 
>more extensive?

I referred to the text you had proposed. However, maybe a few additional 
words could be added. With the current specs, you either have IPsec, or no 
counter-measures at all. So I think the ICMP spec should say something like 
"transport protocols SHOULD use the information contained in the ICMP 
payload to validate the received ICMP messages". Probably not in the 
"Security Considerations section", but earlier in the spec.

>Yes, something like this should be added.  I thought it already was there, 
>but apparently not...

Yes, this text has not yet been added.

>>so-called "hard errors" should not necessarily be considered "hard". 
>>While there's no RFC 1122 for IPv6 (and thus you might say there's no 
>>such thing as "hard errors" and "soft errors" in v6), I think everyone 
>>will extrapolate RFC 1122's statements on soft and hard errors to the 
>>ICMPv6 specification.
>
>Even if I may agree with this sentiment, IMHO it seems to go too much on 
>the side of the transport protocols, and doesn't seem to be appropriate in 
>this document.  The above already a provides a pointer.

Note that I'm not saying the ICMPv6 should say whether connections should 
be aborted upon receipt of ICMP errors or not. I'm saying that maybe the 
spec could suggest what the errors being reported "mean". E.g., is a "Port 
unreachable" a soft or a hard error?
With this information, a transport-protocol designer could elaborate the 
policy of reaction to ICMP errors.

I think that part of RFC 1122 that discusses which ICMP errors are soft or 
hard is a complement to the ICMPv4 spec. Then, when RFC 1122 says "TCP 
SHOULD abort...", *that* is the transport-protocol stuff.