[ipv6hackers] Operational ICMPv6 Filtering

[daniel.bartram at bt.com]

So this prompted me to do a bit of research into ICMPv6 Type 4, which I probably should have done earlier.

RFC4443:
If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing the packet, it MUST discard the packet and SHOULD originate an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem.

Now interesting points here. The router must discard a problematic packet after realising it can't process it, fair enough. But it SHOULD originate an ICMPv6 type 4 message - it doesn't necessarily have to. So by RFC4890 stating it MUST not be dropped, is not entirely correct. In fact, I'd prefer it not to generate a message. Say a rouge user is sending randomly constructed ICMPv6 packets into a network, and they finally send one that a node returns a type 4 packet. Now the rouge user knows they've found a packet structure the node cannot process so not only can they now flood this router with this type of packet (that it has to process to figure out it's not valid), it now also creates additional network bandwidth by constantly sending these type 4's back - almost like a self-inflicted DoS. 

So must I still allow ICMPv6 type 4's through?

Dan.


-----Original Message-----
From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-bounces at lists.si6networks.com] On Behalf Of Simon Perreault
Sent: 31 May 2012 15:06
To: ipv6hackers at lists.si6networks.com
Subject: Re: [ipv6hackers] Operational ICMPv6 Filtering

On 2012-05-31 09:52, daniel.bartram at bt.com wrote:
> Granted, but hackers don't work within what the RFC's say, or on the 
> converse can work within exactly what they say to find 
> vulnerabilities. If I don't know or need what type 4 does then I will 
> block it until a time where I do need it or I find it did in fact 
> break something. Why leave it open just because something tells you 
> to? I'd expect an even better network engineer to make their own 
> rules.

Change "type 4" with "type 2" and the above turns into the usual reasoning for breaking PMTUD.

This is why we can't have nice things.

If you don't know why the RFC tell you you MUST NOT block something, then you better follow the RFC and not block it.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers