--- 1/draft-ietf-v6ops-icmpv6-filtering-recs-01.txt 2006-07-12 22:12:52.000000000 +0200 +++ 2/draft-ietf-v6ops-icmpv6-filtering-recs-02.txt 2006-07-12 22:12:52.000000000 +0200 @@ -1,19 +1,19 @@ IPv6 Operations E. Davies Internet-Draft Consultant -Expires: December 15, 2006 J. Mohacsi +Expires: January 10, 2007 J. Mohacsi NIIF/HUNGARNET - June 13, 2006 + July 9, 2006 Recommendations for Filtering ICMPv6 Messages in Firewalls - draft-ietf-v6ops-icmpv6-filtering-recs-01.txt + draft-ietf-v6ops-icmpv6-filtering-recs-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,100 +24,105 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 15, 2006. + This Internet-Draft will expire on January 10, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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. + 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 + applicable, because these strategies are intended to accommodate a + useful auxiliary protocol that may not be required for correct + functioning. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6 2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6 2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6 2.3. Network Topology and Address Scopes . . . . . . . . . . . 7 2.4. Role in Establishing Communication . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 8 + 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9 3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 9 3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 9 - 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 9 + 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10 4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10 - 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 10 - 4.2. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12 - 4.2.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 12 - 4.2.2. Traffic that Normally Should Not be Dropped . . . . . 12 - 4.2.3. Traffic that May be Dropped but will be Caught - Anyway . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2.4. Traffic for which a Dropping Policy Should be - Defined . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.2.5. Traffic which Should be Dropped Unless a Good Case - can be Made . . . . . . . . . . . . . . . . . . . . . 14 - 4.3. Recommendations for ICMPv6 Local Configuration Traffic . . 15 - 4.3.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 15 - 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 16 - 4.3.3. Traffic that May be Dropped but will be Caught - Anyway . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 + 4.2. Interaction of Link Local Messages with + Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12 + 4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12 + 4.3.1. Traffic that Must Not be Dropped . . . . . . . . . . . 13 + 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 13 + 4.3.3. Traffic that will be Dropped Anyway - No Special + Attention Needed . . . . . . . . . . . . . . . . . . . 13 4.3.4. Traffic for which a Dropping Policy Should be - Defined . . . . . . . . . . . . . . . . . . . . . . . 17 + Defined . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.5. Traffic which Should be Dropped Unless a Good Case - can be Made . . . . . . . . . . . . . . . . . . . . . 17 + can be Made . . . . . . . . . . . . . . . . . . . . . 15 + 4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 16 + 4.4.1. Traffic that Must Not be Dropped . . . . . . . . . . . 16 + 4.4.2. Traffic that Normally Should Not be Dropped . . . . . 17 + 4.4.3. Traffic that will be Dropped Anyway - No Special + Attention Needed . . . . . . . . . . . . . . . . . . . 17 + 4.4.4. Traffic for which a Dropping Policy Should be + Defined . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.4.5. Traffic which Should be Dropped Unless a Good Case + can be Made . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 20 - A.1. Destination Unreachable Error Message . . . . . . . . . . 20 - A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 20 - A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 21 - A.4. Parameter Problem Error Message . . . . . . . . . . . . . 21 - A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 22 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 21 + A.1. Destination Unreachable Error Message . . . . . . . . . . 21 + A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 21 + A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 22 + A.4. Parameter Problem Error Message . . . . . . . . . . . . . 22 + A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 23 A.6. Neighbor Solicitation and Neighbor Advertisement Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23 - A.7. Router Solicitation and Router Advertisement Messages . . 23 - A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23 - A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23 + A.7. Router Solicitation and Router Advertisement Messages . . 24 + A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 24 + A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 24 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 24 - A.11. Multicast Router Discovery Messages . . . . . . . . . . . 24 - A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 24 - A.13. Node Information Query and Reply . . . . . . . . . . . . . 24 + A.11. Multicast Router Discovery Messages . . . . . . . . . . . 25 + A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 25 + A.13. Node Information Query and Reply . . . . . . . . . . . . . 25 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25 - A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25 - Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 - Intellectual Property and Copyright Statements . . . . . . . . . . 35 + A.15. Unused and Experimental Messages . . . . . . . . . . . . . 26 + Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . . . . . 36 1. Introduction When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3] plays a fundamental role including being an essential component in establishing communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 may have a detrimental effect on the establishment of IPv6 communications. On the other hand, allowing @@ -125,96 +130,106 @@ risk. This document recommends a set of rules which seek to balance effective IPv6 communication against the needs of site security. Readers familiar with ICMPv6 can skip to the recommended filtering rules in Section 4 and an example configuration script for Linux netfilter in Appendix B. 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: - 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 + fall into a number of categories: + Returning Error Messages + * 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]. + Connection Checking + * 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]. + Discovery Functions + * 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]. + * 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]. + * 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 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 + * 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]] + * 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. + * Determining the Maximum Transmission Unit (MTU) along a + path. The Packet Too Big error message is essential to this + function [RFC1981]. + * 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]. + * 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]. + * 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]. + Reconfiguration Functions + * 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]. + * 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 + Mobile IPv6 Support + * 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] + Experimental Extensions + * 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. + retrieve some basic information about nodes [I-D.ietf- + ipngwg-icmp-name-lookups]. + * 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. Many of these messages should only be used in a link-local context rather than end-to-end, and filters need to be concerned with the type of addresses in ICMPv6 packets as well as the specific source and destination addresses. 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 @@ -268,38 +283,39 @@ are also messages that we can classify as 'any-to-end', which can be sent from any point within a path back to the source; typically these are used to announce an error in processing the original packet. For instance, the address resolution messages are solely for local communications [RFC2461], whereas the Destination Unreachable messages are any-to-end in nature. Generally end-to-end and any-to- end messages might be expected to pass through firewalls depending on policies but local communications must not. Local communications will use link-local addresses in many cases but - may also use global unicast addresses for example when configuring - global addresses. Also some ICMPv6 messages in local communications - may contravene the usual rules requiring compatible scopes for source - and destination addresses. + may also use global unicast addresses when configuring global + addresses, for example. Also some ICMPv6 messages used 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 + firewalls for local delivery. Generally a firewall 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. On the other hand, most ICMPv6 error messages traveling end-to-end or any-to-end are essential to the establishment of communications. + These messages must be passed through firewalls and might also be sent to and from firewalls to assist with establishment of communications. For example the Packet Too Big error message is needed to establish the MTU along a path. The remaining ICMPv6 messages which are not associated with communication establishment will normally be legitimately attempting to pass through a firewall from inside to out or vice versa, but in most cases decisions as to whether to allow them to pass or not can be made on the basis of local policy without interfering with the @@ -336,104 +352,102 @@ the traffic through to make sure that efficient communication can be established. SEND [RFC3971] has been specified as a means to improve the security of local ICMPv6 communications. SEND sidesteps security association bootstrapping problems that would result if IPsec was used. SEND affects only link local messages and does not limit the filtering which firewalls can apply and its role in security is therefore not discussed further in this document. - Firewalls will normally be concerned to monitor ICMPv6 to control the + Firewalls will normally be used to monitor ICMPv6 to control the 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 - link it might be possible to invalidate legitimate addresses or - disable interfaces. + if spurious communication establishment messages can be infiltrated + on to a link it might be possible to invalidate legitimate addresses + or disable interfaces. 3.2. Probing A major security consideration is preventing attackers probing the site to determine the topology and identify hosts that might be vulnerable to attack. Carefully crafted but, often, malformed messages can be used to provoke ICMPv6 responses from hosts thereby informing attackers of potential targets for future attacks. However the very large address space of IPv6 makes probing a less effective weapon as compared with IPv4 provided that addresses are not allocated in an easily guessable fashion. This subject is explored - in more depth in [I-D.chown-v6ops-port-scanning-implications]. + in more depth in [I-D.ietf-v6ops-scanning-implications]. 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. 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. + 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. - - 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. + firewall in both directions, malicious users can potentially use + these messages to communicate between inside and outside, bypassing + administrative inspection. 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. 4. Filtering Recommendations When designing firewall filtering rules for ICMPv6, the rules can be divided into two classes: o Rules for ICMPv6 traffic transiting the firewall o Rules for ICMPv6 directed to interfaces on the firewall 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. 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. + o Messages that may be dropped in firewall/routers 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. Special considerations apply to transit + traffic if the firewall is not a router as discussed in + Section 4.2. o Messages that administrators may or may not want to drop depending on local policy. o Messages that administrators should consider dropping (e.g., ICMP node information name lookup queries) More detailed analysis of each of the message types can be found in Appendix A. 4.1. Common Considerations @@ -448,41 +462,20 @@ may be subject to less strict policies than unauthenticated messages. In the remainder of this section, we are generally considering what should be configured for unauthenticated messages. In many cases it is not realistic to expect more than a tiny fraction of the messages to be authenticated. 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. - 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. - 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. - 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 @@ -495,30 +488,71 @@ error message the packet can be dropped. This provides a partial defense against some possible attacks on TCP that use spoofed ICMPv6 error messages, but the checks can also be carried out at the destination. For further information on these attacks see [I-D.gont- tcpm-icmp-attacks]. 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. + legitimately have mismatched addresses. Node implementations must + accept these messages delivered locally on a link and administrators + should be aware that they can exist. -4.2. Recommendations for ICMPv6 Transit Traffic +4.2. Interaction of Link Local Messages with Firewall/Routers and + Firewall/Bridges + + Firewalls can be implemented both as IP routers (firewall/routers) + and as link layer bridges (e.g., Ethernet bridges) that are + transparent to the IP layer although they will actually be inspecting + the IP packets as they pass through (firewall/bridges). + + 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 conforming to the IPv6 + standards will not forward these packets; there is no need to + configure additional rules to prevent these packets traversing a + firewall/router, although administrators may wish to configure rules + that would drop these packets for insurance and as a means of + monitoring for attacks. 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 router, including: + o Requiring that the hop limit in the IPv6 header is set to 255 on + transmission. Receivers verify that the hop limit is still 255, + to ensure that the packet has not passed through a router. + o Checking that the source address is a link-local unicast address. + Accordingly it is not essential to configure firewall/router rules to + drop out-of-specification packets of these types. If they have non- + link-local source and destination addresses, allowing them to + traverse the firewall/router, they would be rejected because of the + checks performed at the destination. Again, firewall administrators + may still wish to configure rules to log or drop such out-of- + specification packets. + + For firewall/bridges, slightly different considerations apply. The + physical links on either side of the firewall/bridge are treated as a + single logical link for the purposes of IP. Hence the link local + messages used for discovery functions on the link must be allowed to + transit the transparent bridge. Administrators should assure for + themselves that routers and hosts attached to the link containing the + firewall/bridge are built to the correct specifications so that out- + of-specification packets are actually dropped as described in the + earlier part of this section. + +4.3. Recommendations for ICMPv6 Transit Traffic This section recommends rules that should be applied to ICMPv6 traffic attempting to transit a firewall. -4.2.1. Traffic that Must NOT be Dropped +4.3.1. Traffic that Must Not be Dropped Error messages that are essential to the establishment of communications: o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the necessary packet inspection capabilities. @@ -528,53 +562,60 @@ o Echo Response (Type 129) 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. -4.2.2. Traffic that Normally Should Not be Dropped +4.3.2. Traffic that Normally Should Not be Dropped - Error messages other than those listed in Section 4.2.1 + Error messages other than those listed in Section 4.3.1 o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0 Mobile IPv6 messages that are needed to assist mobility: - o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement(Type 147) Administrators may wish to apply more selective rules as described in Appendix A.14 depending on whether the site is catering for mobile nodes which would normally be at home on the site and/or foreign mobile nodes roaming onto the site. -4.2.3. Traffic that May be Dropped but will be Caught Anyway +4.3.3. Traffic that will be Dropped Anyway - No Special Attention + Needed The messages listed in this section are all involved with local - management of nodes connected to the link on which they were + management of nodes connected to the logical link on which they were initially transmitted. All these messages should never be propagated - beyond the link on which they were initially transmitted. During - normal operations these messages will have destination addresses, - mostly link local but in some cases global unicast addresses, of - interfaces on the local link. No special action is needed to filter - messages with link-local addresses. As discussed in Section 4.1 - these messages are specified so that either the receiver is able to - check that the message has not passed through a firewall/router or it - will be dropped at the first router it encounters. Administrators - may wish to consider providing rules to catch illegal packets sent - with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being - generated for these packets. + beyond the link on which they were initially transmitted. If the + firewall is a firewall/bridge rather than a firewall/router, these + messages should be allowed to transit the firewall as they would be + intended for establishing communications between the two physical + parts of the link that are bridged into a single logical link. + + During normal operations these messages will have destination + addresses, mostly link local but in some cases global unicast + addresses, of interfaces on the local link. No special action is + needed to filter messages with link-local addresses in a firewall/ + router. As discussed in Section 4.1 these messages are specified so + that either the receiver is able to check that the message has not + passed through a router or it will be dropped at the first router it + encounters. + + Administrators may also wish to consider providing rules in firewall/ + routers to catch illegal packets sent with hop limit = 1 to avoid + ICMPv6 Time Exceeded messages being generated for these packets. Address Configuration and Router Selection messages (must be received with hop limit = 255): o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Redirect (Type 137) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142) @@ -590,40 +631,41 @@ hop limit = 255): o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (type 149) Multicast Router Discovery messages (must have link-local source address and hop limit = 1): o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153) -4.2.4. Traffic for which a Dropping Policy Should be Defined +4.3.4. Traffic for which a Dropping Policy Should be Defined - The message which the experimental Seamoby protocols are using will - be expected to have to cross site boundaries. Administrators should - determine if they need to support these experiments and otherwise - messages of this type should be dropped: + The message type that the experimental Seamoby protocols are using + will be expected to have to cross site boundaries in normal + operation. Administrators should determine if they need to support + these experiments and otherwise messages of this type should be + dropped: o Seamoby Experimental (Type 150) Error messages not currently defined by IANA: o Unallocated Error messages (Types 5-99 and 102-126, inclusive) The base ICMPv6 specification suggests that error messages which are not explicitly known to a node should be forwarded and passed to any higher level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators should be aware of this and determine whether they wish to allow these messages through the firewall. -4.2.5. Traffic which Should be Dropped Unless a Good Case can be Made +4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made Node Information enquiry messages should generally not be forwarded across site boundaries. Some of these messages will be using non- link-local unicast addresses so that they will not necessarily be dropped by address scope limiting rules: o Node Information Query (Type 139) o Node Information Response (Type 140) Router Renumbering messages should not be forwarded across site boundaries. As originally specified, these messages may use a site @@ -640,57 +681,58 @@ Messages with types in the experimental allocations: o Types 100, 101, 200 and 201. Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions: o Types 127 and 255. All informational messages with types not explicitly assigned by IANA, currently: + o Types 154 - 199 inclusive and 202 - 254 inclusive. Note that the base ICMPv6 specification requires that informational messages with unknown types must be silently discarded. -4.3. Recommendations for ICMPv6 Local Configuration Traffic +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.3.1. Traffic that Must NOT be Dropped +4.4.1. Traffic that Must Not be Dropped Error messages that are essential to the establishment of communications: o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only Connectivity checking messages: o Echo Request (Type 128) o Echo Response (Type 129) - As discussed in Section 4.2.1, dropping connectivity checking + 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. There are a number of other sets of messages which play a role in configuring the node and maintaining unicast and multicast communications through the interfaces of a node. These messages must not be dropped if the node is to successfully participate in an IPv6 network. The exception to this is the Redirect message for which an - explicit policy decision should be taken (see Section 4.3.4). + explicit policy decision should be taken (see Section 4.4.4). Address Configuration and Router Selection messages: o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142) Link-local multicast receiver notification messages: @@ -701,31 +744,32 @@ SEND Certificate Path notification messages: o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (type 149) Multicast Router Discovery messages : o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153) -4.3.2. Traffic that Normally Should Not be Dropped +4.4.2. Traffic that Normally Should Not be Dropped - Error messages other than those listed in Section 4.3.1: + Error messages other than those listed in Section 4.4.1: o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0 -4.3.3. Traffic that May be Dropped but will be Caught Anyway +4.4.3. Traffic that will be Dropped Anyway - No Special Attention + Needed Router Renumbering messages must be authenticated using IPsec, so it is not essential to filter these messages even if they are not - allowed at the firewall: + allowed at the firewall/router: o Router Renumbering (Type 139) Mobile IPv6 messages that are needed to assist mobility: o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement(Type 147) It may be desirable to drop these messages, especially on public interfaces, if the firewall is not also providing mobile Home Agent services, but they will be ignored otherwise. @@ -725,28 +769,28 @@ o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement(Type 147) It may be desirable to drop these messages, especially on public interfaces, if the firewall is not also providing mobile Home Agent services, but they will be ignored otherwise. The message used by the experimental Seamoby protocols may be dropped but will be ignored if the service is not implemented: - o Seamoby Experimental (Type 150) -4.3.4. Traffic for which a Dropping Policy Should be Defined +4.4.4. Traffic for which a Dropping Policy Should be Defined Redirect messages provide a significant security risk and administrators should take a case-by-case view of whether firewalls, routers in general and other nodes should accept these messages: + o Redirect (Type 137) Conformant nodes must provide configuration controls which allow nodes to control their behavior with respect to Redirect messages so that it should only be necessary to install specific filtering rules under special circumstances, such as if Redirect messages are accepted on private interfaces but not public ones. If a node implements the experimental Node Information service, the administrator needs to make an explicit decision as to whether the node should respond to or accept Node Information messages on each @@ -761,21 +805,21 @@ o Unallocated Error messages (Types 5-99 and 102-126, inclusive) The base ICMPv6 specification suggests that error messages which are not explicitly known to a node should be forwarded and passed to any higher level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators should be aware of this and determine whether they wish to allow these messages to be sent to the firewall. -4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made +4.4.5. Traffic which Should be Dropped Unless a Good Case can be Made Messages with types in the experimental allocations: o Types 100, 101, 200 and 201. Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions: o Types 127 and 255. All informational messages with types not explicitly assigned by IANA, currently: @@ -857,30 +900,30 @@ [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 7.2. Informative References - [I-D.chown-v6ops-port-scanning-implications] - Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", - draft-chown-v6ops-port-scanning-implications-02 (work in - progress), October 2005. - [I-D.gont-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm-icmp-attacks-05 (work in progress), October 2005. + [I-D.ietf-v6ops-scanning-implications] + Chown, T., "IPv6 Implications for Network Scanning", + draft-ietf-v6ops-scanning-implications-00 (work in + progress), June 2006. + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [netfilter] netfilter.org, "The netfilter.org project", Firewalling, @@ -1040,22 +1083,23 @@ 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. + Redirect messages on, for example, a wireless link without link level + encryption/authentication is particularly hazardous because the link + is open to eavesdroppring and packet injection. A.9. SEND Certificate Path Messages SEND [RFC3971] uses two messages (Certificate Path Solicitation and Advertisement - Types 148 and 149) sent from nodes to supposed routers on the same local link to obtain a certificate path which will allow the node to authenticate the router's claim to provide routing services for certain prefixes. If a link connected to a firewall/router is using SEND, the firewall must be able to exchange these messages with nodes on the link that will use its routing @@ -1108,22 +1152,25 @@ authenticated. 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 - protected by the use of IPsec authentication. + from outside a site and must traverse site-boundary firewalls toreach + the home agent in order for Mobile IPv6 to function. The two Mobile + prefix messages should be protected by the use of IPsec + authentication. + o If the site provides home agents for mobile nodes, the firewall must allow incoming Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and outgoing Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages. It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents. o If the site is prepared to host roaming mobile nodes, the firewall must allow outgoing Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and incoming Home Agent @@ -1179,20 +1226,25 @@ site that may or may not support Mobile IPv6. #!/bin/bash # Set of prefixes on the trusted ("inner") side of the firewall export INNER_PREFIXES="2001:DB8:85::/60" # Set of hosts providing services so that they can be made pingable export PINGABLE_HOSTS="2001:DB8:85::/64" # Configuration option: Change this to 1 if errors allowed only for # existing sessions export STATE_ENABLED=0 + # Configuration option: Change this to 1 if messages to/from link + # local addresses should be filtered. + # Do not use this if the firewall is a bridge. + # Optional for firewalls that are routers. + export FILTER_LINK_LOCAL_ADDRS=0 # Configuration option: Change this to 0 if the site does not support # Mobile IPv6 Home Agents - see Appendix A.14 export HOME_AGENTS_PRESENT=1 # Configuration option: Change this to 0 if the site does not support # Mobile IPv6 mobile nodes being present on the site - # see Appendix A.14 export MOBILE_NODES_PRESENT=1 ip6tables -N icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter @@ -1194,32 +1246,33 @@ # see Appendix A.14 export MOBILE_NODES_PRESENT=1 ip6tables -N icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter # Match scope of src and dest else deny # This capability is not provided for in base ip6tables functionality # An extension (agr) exists which may support it. #@TODO@ + # ECHO REQUESTS AND RESPONSES # =========================== # Allow outbound echo requests from prefixes which belong to the site - # for inner_prefix in $INNER_PREFIXES + for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type echo-request -j ACCEPT done # Allow inbound echo requests towards only predetermined hosts - # for pingable_host in $PINGABLE_HOSTS + for pingable_host in $PINGABLE_HOSTS do ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ --icmpv6-type echo-request -j ACCEPT done if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming and outgoing echo reply messages # only for existing sessions ip6tables -A icmpv6-filter -m state -p icmpv6 \ @@ -1235,24 +1288,29 @@ done # Incoming echo replies to prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type echo-reply -j ACCEPT done fi # Deny icmps to/from link local addresses + # If the firewall is a router: # These rules should be redundant as routers should not forward # link local addresses but to be sure... + # DO NOT ENABLE these rules if the firewall is a bridge + if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ] + then ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP + fi # Drop echo replies which have a multicast address as a # destination ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ --icmpv6-type echo-reply -j DROP # DESTINATION UNREACHABLE ERROR MESSAGES # ====================================== if [ "$STATE_ENABLED" -eq "1" ]