RE: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability)

Hi Gert et al,

While there's not an explicit vulnerability in the protocol which wasn't considered previously, some of the points raised indicate it is not obvious to operators how to provide protection from ND messages (amongst other ICMP) ingressing or egressing your network.

Is it worth providing some guidance steps?

There's been some specific work done with ND-Shield (draft-gont-opsec-ipv6-nd-shield-00) and ND Problems (RFC6583), as well as filtering rules for ICMPv6 (RFC4890)

There is an explicit assumption in RFC 4890 S4.3.3 that the end device will make the right decision and drop packets based on protocol behaviour (i.e. pass ND traffic only with correct hop limits).  I would recommend a change to this behaviour to explicitly control traffic passing a network border.

This would allow systems with bugs and are hard to patch (e.g. IoT) to operate within a safer environment, even if they don't implement full ND checks.

If so, my guess is that sounds more like an operational WG approach rather than 6man.

Sincerely, 

Greg Daley
Solutions Architect
Logicalis Australia Pty Ltd
e gdaley@au.logicalis.com
t +61 3 8532 4042
m +61 401 772 770

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Gert Doering
> Sent: Wednesday, 24 August 2016 7:08 AM
> To: Tore Anderson
> Cc: 6man WG; v6ops-chairs@ietf.org; v6ops list; 6man-chairs@ietf.org
> Subject: Re: [v6ops] Conclusion (was Re: CVE-2016-1409: IPv6 Neighbor
> Discovery Crafted Packet Denial of Service Vulnerability)
> 
> Hi,
> 
> On Tue, Aug 23, 2016 at 10:37:15AM +0200, Tore Anderson wrote:
> > So if all there is to this vulnerability is a simple volumetric DoS
> > attack on the control plane I really wonder what all the fuss is about.
> > Most operators are fully aware that *any* traffic from untrusted
>                  ^^^^^^^^^^^^^^^
> Your optimism on the state of the Internet is amazing :-) - you should be
> reading IXP mailing lists for a reality check on the amazingly low level of
> understanding out there.
> 
> > sources that is being allowed to reach the control plane is a
> > potential DoS vector. Shockingly enough, IPv6 ND is no exception - news at
> 11.
> 
> Seriously - I blatantly assumed that IOS XR LPTS would "do the right thing
> here", namely, protect me from Joe Random's ND packets sent all over the
> Internet to my boxes.  Now, if a peer at the local IXP turns out to be
> malicous or gets hacket, yes, this is an obvious attack angle - but "random
> packets from the Internet drowning out legitimate on-link
> IPv6 ND packets"?
> 
> Well, for me, this came as a surprise.
> 
> (Arguably, the hardware might not be able to look at TTL - but if it's smart
> enough to have a queue for IPv6 ND packets in the first place, why is it not
> smart enough to program proper source address filters there?)
> 
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------