--- 1/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt 2006-06-14 01:12:37.000000000 +0200 +++ 2/draft-ietf-v6ops-icmpv6-filtering-recs-01.txt 2006-06-14 01:12:37.000000000 +0200 @@ -1,19 +1,19 @@ IPv6 Operations E. Davies Internet-Draft Consultant -Expires: October 14, 2006 J. Mohacsi +Expires: December 15, 2006 J. Mohacsi NIIF/HUNGARNET - April 12, 2006 + June 13, 2006 Recommendations for Filtering ICMPv6 Messages in Firewalls - draft-ietf-v6ops-icmpv6-filtering-recs-00.txt + draft-ietf-v6ops-icmpv6-filtering-recs-01.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,21 +24,21 @@ 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 October 14, 2006. + This Internet-Draft will expire on December 15, 2006. 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 @@ -76,102 +76,107 @@ 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.3.4. Traffic for which a Dropping Policy Should be - Defined . . . . . . . . . . . . . . . . . . . . . . . 16 + Defined . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made . . . . . . . . . . . . . . . . . . . . . 17 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 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 A.6. Neighbor Solicitation and Neighbor Advertisement - Messages . . . . . . . . . . . . . . . . . . . . . . . . . 22 + Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.7. Router Solicitation and Router Advertisement Messages . . 23 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23 - A.10. Multicast Listener Discovery Messages . . . . . . . . . . 23 - A.11. Multicast Router Discovery Messages . . . . . . . . . . . 23 + 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.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 24 + A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25 - Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 - Intellectual Property and Copyright Statements . . . . . . . . . . 34 + Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + Intellectual Property and Copyright Statements . . . . . . . . . . 35 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 indiscriminate passage of all ICMPv6 messages can be a major security 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 [RFC4311]. + 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 [RFC4311]. + 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 [RFC4311]. + 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 count default) from routers to hosts. Uses - RS and RA [RFC2462]. [[anchor2: [RFC Editor: Please update + 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 [RFC4311]. + 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 @@ -257,21 +262,21 @@ Solicitation. 2.3. Network Topology and Address Scopes ICMPv6 messages can be classified according to whether they are meant for end-to-end communications or communications within a link. There 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 [RFC4311], whereas the Destination Unreachable + 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. @@ -452,22 +457,22 @@ 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 count in the IPv6 header is set to 255 on - transmission. On reception the hop count is required to be still + 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. @@ -553,48 +559,47 @@ 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 Count = 1 to avoid ICMPv6 Time Exceeded messages being + 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 Count = 255): + 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) Link-local multicast receiver notification messages (must have link- local source address): o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143) SEND Certificate Path notification messages (must be received with - Hop Count = 255): + 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 Count = 1): - + 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 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: @@ -636,20 +642,23 @@ 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 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 @@ -763,22 +772,26 @@ 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. + 5. IANA Considerations There are no IANA considerations defined in this document. 6. Acknowledgements Pekka Savola created the original IPv6 Security Overview document which contained suggestions for ICMPv6 filter setups. This information has been incorporated into this document. He has also provided important comments. Some analysis of the classification of @@ -802,20 +815,24 @@ the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. + [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, + December 1998. + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. @@ -834,23 +851,20 @@ [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005. [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. - [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load - Sharing", RFC 4311, November 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. @@ -1066,21 +1080,21 @@ messages are sent by nodes on the local link to discover multicast capable routers on the link, and by multicast capable routers to notify other nodes of their existence or change of state. Firewalls which also act as multicast routers need to process these messages on their interfaces. A.12. Router Renumbering Messages ICMPv6 Router Renumbering (Type 138) command messages can be received and results messages sent by routers to change the prefixes which - they advertise as part of Stateless Address Configuration [RFC4311], + they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. These messages are sent end-to-end to either the all- routers multicast address (site or local scope) or specific unicast addresses from a unicast address. Router Renumbering messages are required to be protected by IPsec authentication since they could be readily misused by attackers to disrupt or divert site communications. Renumbering messages should generally be confined to sites for this reason. A.13. Node Information Query and Reply @@ -1221,20 +1235,22 @@ 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 + # These rules should be redundant as routers should not forward + # link local addresses but to be sure... ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP # 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 # ======================================