Draft: draft-ietf-v6ops-icmpv6-filtering-recs-01.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Thursday 6/29/2006 1:34 PM CST IETF LC Date: 7/3/2006 Summary: This document is almost ready for publication as an Informational RFC. I did find a small number of questions, tagged as "Spencer/More-than-Editorial", which appear below, that I'd like you to consider along with any other Last Call comments you may receive. There are also editorial notes tagged as "Spencer/Editorial". Thanks, Spencer Dawkins Throughout the document - weasel-wording about "site local" appears in a number of places. Do we have a sense whether this is still necessary? If not, would be nice to delete; if still necessary, might be nice to collect the guidance on site-locals into one place, to ensure that it's consistent. Throughout the document - there are many recommendations that point out IPv6 resistence to scanning attacks as part of the recommendation. I'm wondering if some of these could be removed (since there is an explicit section on resistance to scanning attacks in the document). 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. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. Spencer/Editorial: I struggled with the wording of the last two sentences, just because it's so central to the point of the document. I'd suggest something like "While a number of security risks are associated with uncontrolled forwarding of ICMPv6 messages, ICMPv6 is essential to the functioning of IPv6. This indicates that current filtering strategies designed for the corresponding protocol ICMP in IPv4 networks should be revisited, because these strategies are accommodating a useful auxiliary protocol that may not be required for correct functioning." But this paragraph doesn't seem as clear as the corresponding text in Section 1. 1. Introduction ICMPv6 has a large number of functions defined in a number of sub- protocols, and there are a correspondingly large number of messages and options within these messages. The functions currently defined are: Spencer/Editorial: The following text is really dense. Is it possible to provide any hiearchy/abstraction, even if it's only a list of the 15 or so functions, without message detail, followed by the full version of the list appearing below? If it's possible to combine functions (for example, grouping all of the discovery functions into one category, followed by all end-to-end signaling functions, followed by MIPv6 ...), that would be better. A table would be better. Other proposals would be better. o Returning error messages to the source if a packet could not be delivered. Four different error messages, each with a number of sub-types are specified in [RFC4443]. o Simple monitoring of connectivity through echo requests and responses used by the ping and traceroute utilities. The Echo Request and Echo Response messages are specified in [RFC4443]. o Finding neighbors (both routers and hosts) connected to the same link and determining their IP and link layer addresses. These messages are also used to check the uniqueness of any addresses that an interface proposes to use (Duplicate Address Detection - DAD)). Four messages - Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and Router Advertisement (RA) - are specified in [RFC2461]. o Ensuring that neighbors remain reachable using the same IP and link layer addresses after initial discovery (Neighbor Unreachability Discovery - NUD) and notifying neighbors of changes to link layer addresses. Uses NS and NA [RFC2461]. o Finding routers and determining how to obtain IP addresses to join the subnets supported by the routers. Uses RS and RA [RFC2461].[[anchor2: [RFC Editor: Please update references to RFC2461 when the new version of RFC2461 is published.] --Authors]] o If stateless auto-configuration of hosts is enabled, communicating prefixes and other configuration information (including the link MTU and suggested hop limit default) from routers to hosts. Uses RS and RA [RFC2462]. [[anchor3: [RFC Editor: Please update references to RFC2462 when the new version of RFC2462 is published.] --Authors]] o Using SEcure Neighbor Discovery (SEND) to authenticate a router attached to a link, the Certificate Path Solicitation and Advertisement messages specified in [RFC3971] are used by hosts to retrieve the trust chain between a trust anchor and the router certificate from the router. o Redirecting packets to a more appropriate router on the local link for the destination address or pointing out that a destination is actually on the local link even if it is not obvious from the IP address (where a link supports multiple subnets). The Redirect message is specified in [RFC2461]. o Supporting renumbering of networks by allowing the prefixes advertised by routers to be altered. Uses NS, NA, RS and RA together with the Router Renumbering message specified in [RFC2894]. o Determining the Maximum Transmission Unit (MTU) along a path. The Packet Too Big error message is essential to this function [RFC1981]. o Providing a means to discover the IPv6 addresses associated with the link layer address of an interface (the inverse of Neighbor Discovery, where the link layer address is discovered given an IPv6 address). Two messages, Inverse Neighbor Discovery Solicitation and Advertisement messages are specified in [RFC3122]. o Communicating which multicast groups have listeners on a link to the multicast capable routers connected to the link. Uses messages Multicast Listener Query, Multicast Listener Report (two versions) and Multicast Listener Done (version 1 only) as specified in Multicast Listener Discovery MLDv1 [RFC2710] and MLDv2[RFC3810]. o Discovering multicast routers attached to the local link. Uses messages Multicast Router Advertisement, Multicast Router Solicitation and Multicast Router Termination as specified in Multicast Router Discovery [RFC4286]. o Providing support for some aspects of Mobile IPv6 especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link. The Home Agent Address Discovery Request and Reply; and Mobile Prefix Solicitation and Advertisement messages are specified in [RFC3775] o An experimental extension to ICMPv6 specifies the ICMP Node Information Query and Response messages which can be used to retrieve some basic information about nodes [I-D.ietf-ipngwg-icmp- name-lookups]. o The SEAmless IP MOBility (seamoby) working group specified a pair of experimental protocols which use an ICMPv6 message specified in [RFC4065] to help in locating an access router and moving the attachment point of a mobile node from one access router to another. 2.3. Network Topology and Address Scopes Local communications will use link-local addresses in many cases but may also use global unicast addresses for example when configuring Spencer/Editorial: this sentence may be correct as written but isn't easy to read clearly - suggest "may also use global unicast addresses when configuring global addresses, for example". global addresses. Also some ICMPv6 messages in local communications may contravene the usual rules requiring compatible scopes for source and destination addresses. 2.4. Role in Establishing Communication Many ICMPv6 messages have a role in establishing communications to and from the firewall and such messages have to be accepted by firewalls for local delivery. Generally a firewall will also by Spencer/Editorial: "will also be" acting as a router so that all the messages that might be used in configuring a router interface need to be accepted and generated. This type of communication establishment messages should not be passed through a firewall as they are normally intended for use within a link. 3. Security Considerations Firewalls will normally be concerned to monitor ICMPv6 to control the Spencer/Editorial: "Firewalls will normally be used to monitor" - my firewall seems extremely unconcerned most of the time, even when dropping packets :-) following security concerns: 3.1. Denial of Service Attacks ICMPv6 can be used to cause a Denial of Service(DoS) in a number of ways, including simply sending excessive numbers of ICMPv6 packets to destinations in the site and sending error messages which disrupt established communications by causing sessions to be dropped. Also if spurious communication establishment messages can be passed on to Spencer/Editorial: is this "passed to on-link"? But it seems like odd English usage. "passed onto a specific link", perhaps? link it might be possible to invalidate legitimate addresses or disable interfaces. 3.4. Renumbering Attacks Spurious Renumbering messages could lead to the disruption of a site and should not be allowed through a firewall in general. Renumbering messages are required to be authenticated with IPsec so that it is difficult to carry out such attacks in practice. Spencer/Editorial: Is this saying, roughly, "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."? 3.5. Problems Resulting from ICMPv6 Transparency Because some ICMPv6 error packets need to be passed through a firewall in both directions. This means that the ICMPv6 error packets can be exchanged between inside and outside without any filtering. Spencer/More-than-Editorial: First "sentence" is a fragment - I'm not sure that the paragraph is a complete thought, because I don't understand how the second sentence is related to the first sentence (fragment), so I'm not proposing an editorial change. (Just because you need something to happen doesn't mean "there's no problem when it happens, so go ahead and pass the traffic without filtering.") Someone smart, please provide suggested text :-) Using this feature, malicious users can communicate between the inside and outside of a firewall bypassing the administrator's inspection (proxy, firewall etc.). For example it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages or tunnel inappropriate encapsulated IP packets in ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 errors using a deep packet inspection mechanism to ensure that the packet carried as a payload is associated with legitimate traffic to or from the protected network. Spencer/More-than-Editorial: Forgive my ignorance here, but are most firewalls doing stateful deep inspection tracking for ICMP/ICMPv6 traffic today? If not, this seems to need more discussion about why the additional state is the right way to go. 4. Filtering Recommendations This section suggests some common considerations which should be borne in mind when designing filtering rules and then categorizes the rules for each class. The categories are: o Messages that must not be dropped: usually because establishment of communications will be prevented or severely impacted. Spencer/More-than-Editorial: why "usually"? ("Why would you pass messages you didn't have to pass?") o Messages that should not be dropped: administrators need to have a very good reason for dropping this category o Messages that may be dropped but it is not essential because they would normally be dropped for other reasons (e.g., because they would be using link-local addresses) or the protocol specification would cause them to be rejected if they had passed through a router. Spencer/Editorial: "Messages that may be dropped, although they would normally be dropped for other reasons anyway", and I think the parenthetical should inclide both the e.g. and the "or the protocol specification" clause, if I get the point being made. 4.1. Common Considerations Many of the messages used for establishment of communications on the local link will be sent with link-local addresses for at least one of their source and destination. Routers (and firewalls) conforming to the IPv6 standards will not forward these packets; there is no need to configure additional rules to prevent these packets traversing the firewall/router. Also the specifications of ICMPv6 messages intended for use only on the local link specify various measures which would allow receivers to detect if the message had passed through a firewall/router, including: o Requiring that the hop limit in the IPv6 header is set to 255 on transmission. On reception the hop limit is required to be still 255 which would not be the case if the packet had passed through a firewall/router. Spencer/Editorial: second sentence "Receivers verify that the hop limit is still 255, to ensure that the packet has not passed through a firewall/router."? o Checking that the source address is a link-local unicast address. Accordingly it is not essential to configure firewall rules to drop illegal packets of these types. If they have non-link-local source and destination addresses, allowing them to traverse the firewall, they would be rejected because of the checks performed at the destination. However, firewall administrators may still wish to log or drop such illegal packets. Spencer/Editorial: There really are "illegal packets", but I don't think that's what you're talking about. "wish to drop adminstratively-prohibited packets"? This term is used elsewhere in the specification, too. 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 need to avoid over-zealous filtering of these messages delivered locally on a link. Spencer/More-than-Editorial: I know the specification is targeted as an Informational RFC, but this recommendation seems awefully hand-wavish even for Informational ("you should drop them unless doing so is over-zealous") - is there better guidance than "turn it off and see if the phone rings"? 4.2.3. Traffic that May be Dropped but will be Caught Anyway Spencer/Editorial: this phrase, which appears in several places in the document, seemed odd to me every time I read it. Perhaps "Traffic that will be dropped anyway for other reasons, so no special attention required"? The text describing this is fine - the thing being described just seems odd. 4.2.4. Traffic for which a Dropping Policy Should be Defined The message which the experimental Seamoby protocols are using will Spencer/Editorial: This is actually probably correct and consistent but still looks like a number disagreement "the message are". Maybe "The message type used by the experimental Seamoby protocols will ..."? be expected to have to cross site boundaries. Administrators should Spencer/Editorial: "will be expected to cross site boundaries in normal operation."? determine if they need to support these experiments and otherwise messages of this type should be dropped: o Seamoby Experimental (Type 150) 4.3.1. Traffic that Must NOT be Dropped Spencer/Editorial: "NOT" sure why the "NOT" is emphasized here, and it looks like 2119 language gone bad :-) A.2. Packet Too Big Error Message If a network chooses to generate packets that are no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive. Spencer/More-than-Editorial: Having had experience with wireless links that had a smaller MTU than the "guaranteeed minimum" in IPv4, I'm not entirely comfortable with this guidance ("if you don't care about communicating with people who violate the spec, drop the packets, and hope there's no GOOD reason why someone is violating the spec"). At a minimum, there's a balance between making the network more secure by not passing unnecessary packets and making the path more fragile - maybe that's guidance that would be helpful? A.8. Redirect Messages ICMPv6 Redirect Messages(Type 137) are used on the local link to indicate that nodes are actually link-local and communications need not go via a router, or to indicate a more appropriate first hop router. Although they can be used to make communications more efficient, they are not essential to the establishment of communications and may be a security vulnerability, particularly if a link is not physically secured. Conformant nodes are required to provide configuration controls which suppress the generation of Redirect messages and allow them to be ignored on reception. Using Redirect messages on a wireless link is particularly hazardous because of the lack of physical security. Spencer/More-than-Editorial: should be something like "wireless link with no link-level authentication/encryption is particularly hazardous", I think - the problem isn't that the link is wireless, the problem is that the link is open to eavesdropping and packet injection. A.14. Mobile IPv6 Messages Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to support mobile operations: Home Agent Address Discovery Request, Home Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. These messages are sent end-to-end between unicast addresses of a mobile node and its home agent. They must be expected to be sent from outside a site. The two Mobile prefix messages should be Spencer/Editorial: "They must traverse site-boundary firewalls in order for Mobile IPv6 to function"? protected by the use of IPsec authentication.