Subject: WGLC: draft-ietf-v6ops-icmpv6-filtering-recs-02

From: Fred Baker <[email-masked]>
Date: Wed, 12 Jul 2006 19:03:39 -0400

We are now in a position to open WGLC on the ICMP Filtering  
Recommendations. The document passed WGLC some time back and there  
were initial comments from the IESG that led to an early update. The  
changes comprised a fair amount of text, so we agreed today to run a  
short WGLC on the result.

Please read the document and comment to the list. This WGLC will  
close a week from Friday, on 21 July. If there are substantive  
comments, we will ask the authors to update it again. If not, we will  
simply advise the AD to continue his review of the updated document.

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Jul 2006 20:42:22 -0700

David:

The WGLC on the recent icmp recommendations draft has commpleted  
without comment, either public or (Elwyn tells me) private. I think  
you're in a position to continue your review.

Fred

On Jul 12, 2006, at 4:03 PM, Fred Baker wrote:

> were initial comments from the IESG that led to an early update.  
> The changes comprised a fair amount of text, so we agreed today to  
> run a short WGLC on the result.
>
> comments, we will ask the authors to update it again. If not, we  
> will simply advise the AD to continue his review of the updated  
> document.

---

From: Tim Chown <[email-masked]>
Date: Tue, 25 Jul 2006 16:29:11 +0100

> you're in a position to continue your review.

Hi,

I have a handful of minor comments.  In general I think the document
is very usefukl and should be published.   I have not rechecked 
Appendix A or B.

Abstract

   In networks supporting IPv6 the Internet Control Message Protocol
   version 6 (ICMPv6) plays a fundamental role with a large number of
   functions, and a correspondingly large number of message types and
   options.  ICMPv6 is essential to the functioning of IPv6 but there
   are a number of security risks associated with uncontrolled
   forwarding of ICMPv6 messages.  Filtering strategies designed for the
   corresponding protocol, ICMP, in IPv4 networks are not directly

>> I'd add something here like you state in the main text to catch a
   reader's attention as to why IPv4-like ICMP filtering practice is
   not good for IPv6.

>> The audience should certainly be firewall vendors as well as site admins.

>> Maybe also emphasise it's INformational, seeking feedback to go BCP?

1.  Introduction

   When a network supports IPv6 [RFC2460], the Internet Control Message
   Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3]

>> The I.D reference is redundant now and can be deleted?

   Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be
   treated as an auxiliary function with packets that can be dropped in
   most cases without damaging the functionality of the network.  This
   means that firewall filters for ICMPv6 have to be more carefully
   configured than was the case for ICMP, where typically a small set of
   blanket rules could be applied.

>> So a bit of this text would be good in the abstract, if it can fit.

2.3.  Network Topology and Address Scopes

   Local communications will use link-local addresses in many cases but
   may also use global unicast addresses when configuring global
   addresses, for example. 

>> Or ULAs when configuring ULA addresses.  Though they are global scope now.

   Also some ICMPv6 messages used in local
   communications may contravene the usual rules requiring compatible
   scopes for source and destination addresses.

>> Maybe add an example?

3.  Security Considerations

   Firewalls will normally be used to monitor ICMPv6 to control the
   following security concerns:

>> Firewalls and/or IDS systems?   Often combined, but not always.

>> RFC4443 has a security considerations section.  It might be helpful to
   a reader of that document and this if the subsections were congruent, or
   is that not possible?

3.3.  Redirection Attacks

   A redirection attack could be used by a malicious sender to perform
   man-in-the-middle attacks or divert packets either to a malicious
   monitor or to cause DoS by blackholing the packets.  These attacks
   would normally have to be carried out locally on a link using the
   Redirect message.  Administrators need to decide if the improvement
   in efficiency from using Redirect messages is worth the risk of
   malicious use.  Factors to consider include the physical security of
   the link and the complexity of addressing on the link.  For example,
   on a wireless link, redirection would be a serious hazard due to the
   lack of physical security.  On the other hand, with a wired link in a
   secure building with complex addressing and redundant routers, the
   efficiency gains might well outweigh the small risk of a rogue node
   being connected.

>> Can the firewall do anything about this - more of an IDS example?

3.4.  Renumbering Attacks

   Spurious Renumbering messages can lead to the disruption of a site.
   Although Renumbering messages are required to be authenticated with
   IPsec, so that it is difficult to carry out such attacks in practice,
   they should not be allowed through a firewall.

>> So how do I renumber a network with Router Renumbering where subnets
   have their own firewalls?   Today a 'firewall' can be applied per port
   on a reasonable switch-router unit.   Is this document focused on 
   purely the classic one-firewall-at-site-border model?
   Also clarify here you mean Router Renumbering protocol.
   (Of course, Router Renumbering protocol has its own issues, but that's
    another story)

4.1.  Common Considerations

   Depending on the classification of the message to be filtered (see
   Section 2), ICMPv6 messages should be filtered based on the ICMPv6
   type of the message and the type (unicast, multicast, etc.) and scope
   (link-local, global unicast, etc) of source and destination

>> Add ULA, though they are now defined as global?  Then there's no 'etc'.

   Where messages are not essential to the establishment of
   communications, local policy can be used to determine whether a
   message should be allowed or dropped.

>> Well, the previous section talked in more detail about must/should/etc
   than this - this is superfluous?

   Depending on the capabilities of the firewall being configured, it
   may be possible for the firewall to maintain state about packets that
   may result in error messages being returned or about ICMPv6 packets
   (e.g., Echo Requests) that are expected to receive a specific
   response.  This state may allow the firewall to perform more precise
   checks based on this state, and to apply limits on the number of
   ICMPv6 packets accepted incoming or outgoing as a result of a packet
   traveling in the opposite direction.  The capabilities of firewalls
   to perform such stateful packet inspection vary from model to model,
   and it is not assumed that firewalls are uniformly capable in this
   respect.

>> RFC4443 talks about ideas for rate-limits for forwarding ICMPv6.

   In general, the scopes of source and destination addresses of ICMPv6
   messages should be matched, and packets with mismatched addresses
   should be dropped if they attempt to transit a router.  However some
   of the address configuration messages carried locally on a link may
   legitimately have mismatched addresses.  Node implementations must
   accept these messages delivered locally on a link and administrators
   should be aware that they can exist.

>> An example?

4.3.  Recommendations for ICMPv6 Transit Traffic

   This section recommends rules that should be applied to ICMPv6
   traffic attempting to transit a firewall.

Davies & Mohacsi        Expires January 10, 2007               [Page 12]

Internet-Draft      ICMPv6 Filtering Recommendations           July 2006

4.3.1.  Traffic that Must Not be Dropped

   For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be
   possible, it is essential that the connectivity checking messages are
   allowed through the firewall.  It has been common practice in IPv4
   networks to drop Echo Request messages in firewalls to minimize the
   risk of scanning attacks on the protected network.  As discussed in
   Section 3.2, the risks from port scanning in an IPv6 network are much
   less severe and it is not necessary to filter IPv6 Echo Request
   messages.

>> not as necessary?

4.3.5.  Traffic which Should be Dropped Unless a Good Case can be Made

   Router Renumbering messages should not be forwarded across site
   boundaries.  As originally specified, these messages may use a site

>> This is better than the text above which said 'must always be firewalled';
   it depends where your firewalls are.

   scope multicast address or a site local unicast address.  They should
   be caught by standard rules that are intended to stop any packet with
   a multicast site scope or site local destination being forwarded
   across a site boundary provided these are correctly configured.
   Since site local addresses have now been deprecated it seems likely
   that changes may be made to allow the use of unique local addresses
   or global unicast addresses.  Should this happen, it will be
   essential to explicitly filter these messages:
   o  Router Renumbering (Type 139)

>> So I guess one question is what to recommend for observed use of the now
   deprecated old site local prefix?

4.4.  Recommendations for ICMPv6 Local Configuration Traffic

   This section recommends filtering rules for ICMPv6 traffic addressed
   to an interface on a firewall.  For a small number of messages, the
   desired behavior may differ between interfaces on the site or private
   side of the firewall and the those on the public Internet side of the
   firewall.

4.4.1.  Traffic that Must Not be Dropped

   As discussed in Section 4.3.1, dropping connectivity checking
   messages will prevent the firewall being the destination of a Teredo
   tunnel and it is not considered necessary to disable connectivity
   checking in IPv6 networks because port scanning is less of a security
   risk.

>> Is a firewall likely to be such a destination?

   Link-local multicast receiver notification messages:
   o  Listener Query (Type 130)
   o  Listener Report (Type 131)
   o  Listener Done (Type 132)
   o  Listener Report v2 (Type 143)

>> I guess for this and for other types you might want to note that whether
   you expect to see those types depends on if the interface is point to
   point to another router or has hosts on link.

-- 
Tim/::1