[ipv6hackers] Operational ICMPv6 Filtering

[Marksteiner, Stefan]

Hi Folks,

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.

Cheers,

Stefan

[1] Howard, L., Chittimaneni, K., Pouffary, Y., Vyncke, E. & Kuarsingh, V. (2012). Internet-Draft: Enterprise Incremental IPv6. (Work in progress). 
Available from http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6-00

[2] Convery, S. & Miller, D. (2004). IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation (v1.0). 
Available from http://www.cisco.com/security_services/ciag/documents/v6-v4-threats.pdf

[3] http://technet.microsoft.com/en-us/security/Bulletin/MS06-064
 

-----Ursprüngliche Nachricht-----
Von: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-bounces at lists.si6networks.com] Im Auftrag von Romain Boissat
Gesendet: Donnerstag, 31. Mai 2012 17:12
An: IPv6 Hackers Mailing List
Betreff: Re: [ipv6hackers] Operational ICMPv6 Filtering

Hi

On Tue, May 29, 2012 at 05:10:42PM +0200, Marksteiner, Stefan wrote:
> Hi,
> 
> in [1] it's stated that most of the ICMPv6 Destination Unreachable 
> messages are to be permitted through intermediate devices (i.e.
> firewalls; on p. 33). On the other hand, [2] describes an ICMPv6 blind 
> connection reset attack based on "hard errors" (p. 12).  I know that 
> this is eventually a stack implementer's issue, as host should 
> basically not accept "hard errors" in an established connection, but 
> my question is: should operators rely on implementers or just block 
> Destination Unreachable and the likes and take the drawback of having 
> their hosts wait for timeouts instead of getting errors?

I use the [1] following set of ip6tables on my gnu/linux routers (personnal appliances only), treating both input and transit icmpv6 traffic. Translating every rule into another syntax may be not possible, though.

These rules have been used for a year now, on several appliances, with success so far. Feel free to comment :)

When I was designing ICMPv6 filtering with ip6tables, I followed the recommendations available on ipv6security.nl [2]

[1] https://n0.pe/p/7yh3k
[2] http://www.ipv6security.nl/?p=233

--
Romain Boissat
chroot-me.in
_______________________________________________
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers