Subject: WGLC draft-ietf-v6ops-icmpv6-filtering-recs-00.txt

From: [email-masked]
Date: Wed, 26 Apr 2006 12:58:12 -0700

Per the WG decision in the meeting last month, I am opening a working  
group last call on the filtering document

   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6- 
filtering-recs-00.txt
   "Best Current Practice for Filtering ICMPv6 Messages in Firewalls"

Two weeks from Friday, barring substantive issues, the last call will  
close, Elwyn will post a final update, and we will send the report to  
the AD.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 26 Apr 2006 21:57:39 +0100

Please note that the title in the file has been changed to
"Recommendations for Filtering ICMPv6 Messages in Firewalls"
in line with the file name and the discussion in Dallas.  This is 
necessary, because notwithstanding previous discussions in the wg,
the IESG is unwilling to sanction a BCP for which there is relatively 
little operational experience.

The changes from draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt apart from 
changing the title are editorial plus updating of references to take 
into account the publication of rfc2463bis (RFC4443).

Due to a misreading of the I-D database, I have managed to replace 
RFC2461 with RFC4311 which is *not* rfc2461bis.  Both rfc2461bis and 
rfc2462bis are hung up waiting for resolution of the M/O bits problem - 
hopefully this has been resolved just today so these drafts should go to 
RFC fairly shortly.

/Elwyn

[email-masked] wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt 
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Apr 2006 14:35:30 -0700

On Apr 26, 2006, at 1:57 PM, Elwyn Davies wrote:

> RFC2461 with RFC4311 which is *not* rfc2461bis.  Both rfc2461bis  
> and rfc2462bis are hung up waiting for resolution of the M/O bits  
> problem - hopefully this has been resolved just today so these  
> drafts should go to RFC fairly shortly.

Sorting that out can be a last call comment, or if it is the only  
thing that needs to be done it could be picked up during the sorting  
out of IESG comments or as a note to the RFC Editor.

Let's see what other issues come up.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 27 Apr 2006 21:02:30 +0200

>    "Best Current Practice for Filtering ICMPv6 Messages in Firewalls"

A few minor notes:

1/ The specification does not seem to consider what should be made with 
filtered packets, and seems to assume they will be dropped. In some 
case (such as the _currently_ undefined ICMP codes), it might be nicer, 
so long as the local policy permits, to cause the firewall to craft an 
Administratively prohibited error or something like that (à 
la “ip6tables -j REJECT”), maybe... though I guess some kind of rate 
limiting would obviously be required in that case.

2/ When I see sample rules like these:
“
   # Deny icmps to/from link local addresses
   ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
   ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
”... I'm becoming worried that the forwarding/routing software from 
Linux IPv6 stack actually let this packets through by default 
(particularly the first rule). I'm pretty sure the first one is 
redumdant, and I hope the second one is also. That's not to say 
firewall admin should not use them for the sake of verbosity and/or 
quietness of mind, but it might be worth adding a comment that these 
are already sort of built-in.

By the way, if anyone can confirm that these rules are actually 
redumdant...

3/ I believe filter Echo requests is fairly lame, and I did complain 
that Teredo needs it to work at all. Now Teredo is mentioned and Echo 
requests were promoted from "Should not be blocked" to "Must not be 
blocked" :) Some other yet-to-be-defined protocols/schemes might also 
rely on incoming Echo requests to not be firewalled, and I surely hope 
not so many company and SOHO firewalls will block IPv6 echo requests, 
as IPv4 echo requests.... but as far as Teredo is concerned, only Echo 
requests coming from the Teredo prefix (2001:0::/32) needs to be passed 
(and of course Echo replies, only the other way).

Regards,

-- 
Rémi Denis-Courmont
http://www.simphalempin.com/home/