RE: Security considerations of the ICMPv6 draft

["Elwyn davies" <elwynd@dial.pipex.com>]

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: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Fernando Gont
> Sent: 08 April 2005 12:44
> To: ipv6@ietf.org
> Cc: Mukesh.K.Gupta@nokia.com
> Subject: Security considerations of the ICMPv6 draft
> 
> 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: fernando@gont.com.ar || fgont@acm.org
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------