[ipv6hackers] Operational ICMPv6 Filtering

[Simon Perreault]

On 2012-06-01 06:13, Marksteiner, Stefan wrote:
> I'm more with Daniel, Marc and Romain (more strict filtering), here's why:
>
> 1.) Marc stated correctly that these recommendations aren't written from a security perspective, so filtering tends to be too openly.
>
> 2.) Simon wrote (31/05/2012 16:44): "Sometimes I wish the situation for network engineers was the same as for
> doctors: follow the BCPs or be sued for malpractice..." RFC4890 is informational and neither a standard nor a BCP, that might probably be the case, because the IETF doesn't want to dictate operators how to secure their networks but giving just glues instead.
>
> 3.) Simon wrote (31/05/2012 16:44): " The reason it's a SHOULD is to account for ICMP error generation rate limiting. Not personal preference."
> Because of 2.), the document avoids "SHOULD" and "MUST"  (or "NOT", respectively) in the sense of RFC2119 (it's neither used this way in the document, nor  is the reference to RFC2119 included, which is usual for standards and BCPs), instead it uses merely "should not" and "must not". That might make a difference, as the recommendations aren't set in stone.
>
> 4.) I totally agree with the "Not personal preference" part, though. There are a bunch of recommendations which present guidelines (of which RFC4890 is just one, another is, though yet only a draft, [1, p.15] or in a classic white paper [2, p.24]. These are more restrictive ones, but recommend to adapt to your own policy by using your IPv4 policy as base work (which, of course, is often "Deny all inbound ICMP"). The recommendations posted by Romain deem me also to be very reasonable.
>
> The goal seems to me to take these recommendations and build up a chain of logical conclusions based on them which lead to a strategy suitable for one's individual needs. Recommendations should definitely be used as a glue but probably  aren't meant to replace reason.
>
> 5.)  At the end of the day it comes down to the *ancient* battle functionality vs. security. And to what your security needs are. So for *my purposes*, *I*'d prefer a more strict filtering policy, but I wouldn't exclude that to change if circumstances do (i.e. performance is so crucial, that you just have to take attacking risks, or the risks are decreasing like by M$'s blind spoofing bulletin and bugfix [3] - although for me a bugfix from a single vendor isn't reason enough to change a filtering policy). Bottom line, in my opinion is, carefully select from existing (trusted) recommendations and adapt them individually.

You can present this analysis to the judge when you get sued for 
malpractice. ;)

Seriously though, I totally agree with you. My point is when you don't 
know, you should follow the guidelines. If you do your homework (you 
clearly have) and you have good technical reasons to do otherwise, then 
go ahead.

But changing the guidelines is another issue. And the above doesn't 
justify doing it IMHO.

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