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

From: Elwyn Davies <[email-masked]>
Date: Tue, 13 Jun 2006 14:00:49 +0100

Apologies for the long delay in answering:
Comments below - updates in new -01 version appearing shortly.

/Elwyn

Rémi Denis-Courmont wrote:
> Le Mercredi 26 Avril 2006 21:58, vous avez écrit :
>   
>> 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"
>>     
>
> 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.
>   
RFC2463 explicitly requires that undefined informational messages are 
silently dropped.  Responding to error messages with an error message 
would not be clever.  There are a couple of other cases where it might 
be possible, but on due consideration, I think that, on security 
grounds, dropping is the right answer
>
> 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.
>   
Done.
> 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).
>   
I don't think this requires any action.  The draft recommends never 
dropping Echo Requests or Echo Responses.

/Elwyn
> Regards,