idnits 2.17.1 draft-ietf-v6ops-icmpv6-filtering-recs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1542. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 13, 2006) is 6526 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipngwg-icmp-name-lookups' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-tcpm-icmp-attacks' is defined on line 873, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-ipngwg-icmp-name-lookups (ref. 'I-D.ietf-ipngwg-icmp-name-lookups') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipngwg-icmp-v3' ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4065 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Davies 3 Internet-Draft Consultant 4 Expires: December 15, 2006 J. Mohacsi 5 NIIF/HUNGARNET 6 June 13, 2006 8 Recommendations for Filtering ICMPv6 Messages in Firewalls 9 draft-ietf-v6ops-icmpv6-filtering-recs-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 15, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 In networks supporting IPv6 the Internet Control Message Protocol 43 version 6 (ICMPv6) plays a fundamental role with a large number of 44 functions, and a correspondingly large number of message types and 45 options. A number of security risks are associated with uncontrolled 46 forwarding of ICMPv6 messages. On the other hand, compared with IPv4 47 and the corresponding protocol ICMP, ICMPv6 is essential to the 48 functioning of IPv6 rather than a useful auxiliary. 50 This document provides some recommendations for ICMPv6 firewall 51 filter configuration that will allow propagation of ICMPv6 messages 52 that are needed to maintain the functioning of the network but drop 53 messages which are potential security risks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6 59 2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6 60 2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6 61 2.3. Network Topology and Address Scopes . . . . . . . . . . . 7 62 2.4. Role in Establishing Communication . . . . . . . . . . . . 7 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 8 65 3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 9 67 3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 9 68 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 9 69 4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10 70 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 10 71 4.2. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12 72 4.2.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 12 73 4.2.2. Traffic that Normally Should Not be Dropped . . . . . 12 74 4.2.3. Traffic that May be Dropped but will be Caught 75 Anyway . . . . . . . . . . . . . . . . . . . . . . . . 13 76 4.2.4. Traffic for which a Dropping Policy Should be 77 Defined . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.2.5. Traffic which Should be Dropped Unless a Good Case 79 can be Made . . . . . . . . . . . . . . . . . . . . . 14 80 4.3. Recommendations for ICMPv6 Local Configuration Traffic . . 15 81 4.3.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 15 82 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 16 83 4.3.3. Traffic that May be Dropped but will be Caught 84 Anyway . . . . . . . . . . . . . . . . . . . . . . . . 16 85 4.3.4. Traffic for which a Dropping Policy Should be 86 Defined . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.3.5. Traffic which Should be Dropped Unless a Good Case 88 can be Made . . . . . . . . . . . . . . . . . . . . . 17 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 94 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 20 95 A.1. Destination Unreachable Error Message . . . . . . . . . . 20 96 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 20 97 A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 21 98 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 21 99 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 22 100 A.6. Neighbor Solicitation and Neighbor Advertisement 101 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 A.7. Router Solicitation and Router Advertisement Messages . . 23 103 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23 104 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23 105 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 24 106 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 24 107 A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 24 108 A.13. Node Information Query and Reply . . . . . . . . . . . . . 24 109 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25 110 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25 111 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 26 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 113 Intellectual Property and Copyright Statements . . . . . . . . . . 35 115 1. Introduction 117 When a network supports IPv6 [RFC2460], the Internet Control Message 118 Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3] 119 plays a fundamental role including being an essential component in 120 establishing communications both at the interface level and for 121 sessions to remote nodes. This means that overly aggressive 122 filtering of ICMPv6 may have a detrimental effect on the 123 establishment of IPv6 communications. On the other hand, allowing 124 indiscriminate passage of all ICMPv6 messages can be a major security 125 risk. This document recommends a set of rules which seek to balance 126 effective IPv6 communication against the needs of site security. 128 Readers familiar with ICMPv6 can skip to the recommended filtering 129 rules in Section 4 and an example configuration script for Linux 130 netfilter in Appendix B. 132 ICMPv6 has a large number of functions defined in a number of sub- 133 protocols, and there are a correspondingly large number of messages 134 and options within these messages. The functions currently defined 135 are: 136 o Returning error messages to the source if a packet could not be 137 delivered. Four different error messages, each with a number of 138 sub-types are specified in [RFC4443]. 139 o Simple monitoring of connectivity through echo requests and 140 responses used by the ping and traceroute utilities. The Echo 141 Request and Echo Response messages are specified in [RFC4443]. 142 o Finding neighbors (both routers and hosts) connected to the same 143 link and determining their IP and link layer addresses. These 144 messages are also used to check the uniqueness of any addresses 145 that an interface proposes to use (Duplicate Address Detection - 146 DAD)). Four messages - Neighbor Solicitation (NS), Neighbor 147 Advertisement (NA), Router Solicitation (RS) and Router 148 Advertisement (RA) - are specified in [RFC2461]. 149 o Ensuring that neighbors remain reachable using the same IP and 150 link layer addresses after initial discovery (Neighbor 151 Unreachability Discovery - NUD) and notifying neighbors of changes 152 to link layer addresses. Uses NS and NA [RFC2461]. 153 o Finding routers and determining how to obtain IP addresses to join 154 the subnets supported by the routers. Uses RS and RA 155 [RFC2461].[[anchor2: [RFC Editor: Please update references to 156 RFC2461 when the new version of RFC2461 is published.] --Authors]] 157 o If stateless auto-configuration of hosts is enabled, communicating 158 prefixes and other configuration information (including the link 159 MTU and suggested hop limit default) from routers to hosts. Uses 160 RS and RA [RFC2462]. [[anchor3: [RFC Editor: Please update 161 references to RFC2462 when the new version of RFC2462 is 162 published.] --Authors]] 164 o Using SEcure Neighbor Discovery (SEND) to authenticate a router 165 attached to a link, the Certificate Path Solicitation and 166 Advertisement messages specified in [RFC3971] are used by hosts to 167 retrieve the trust chain between a trust anchor and the router 168 certificate from the router. 169 o Redirecting packets to a more appropriate router on the local link 170 for the destination address or pointing out that a destination is 171 actually on the local link even if it is not obvious from the IP 172 address (where a link supports multiple subnets). The Redirect 173 message is specified in [RFC2461]. 174 o Supporting renumbering of networks by allowing the prefixes 175 advertised by routers to be altered. Uses NS, NA, RS and RA 176 together with the Router Renumbering message specified in 177 [RFC2894]. 178 o Determining the Maximum Transmission Unit (MTU) along a path. The 179 Packet Too Big error message is essential to this function 180 [RFC1981]. 181 o Providing a means to discover the IPv6 addresses associated with 182 the link layer address of an interface (the inverse of Neighbor 183 Discovery, where the link layer address is discovered given an 184 IPv6 address). Two messages, Inverse Neighbor Discovery 185 Solicitation and Advertisement messages are specified in 186 [RFC3122]. 187 o Communicating which multicast groups have listeners on a link to 188 the multicast capable routers connected to the link. Uses 189 messages Multicast Listener Query, Multicast Listener Report (two 190 versions) and Multicast Listener Done (version 1 only) as 191 specified in Multicast Listener Discovery MLDv1 [RFC2710] and 192 MLDv2[RFC3810]. 193 o Discovering multicast routers attached to the local link. Uses 194 messages Multicast Router Advertisement, Multicast Router 195 Solicitation and Multicast Router Termination as specified in 196 Multicast Router Discovery [RFC4286]. 197 o Providing support for some aspects of Mobile IPv6 especially 198 dealing with the IPv6 Mobile Home Agent functionality provided in 199 routers and needed to support a Mobile node homed on the link. 200 The Home Agent Address Discovery Request and Reply; and Mobile 201 Prefix Solicitation and Advertisement messages are specified in 202 [RFC3775] 203 o An experimental extension to ICMPv6 specifies the ICMP Node 204 Information Query and Response messages which can be used to 205 retrieve some basic information about nodes [I-D.ietf-ipngwg-icmp- 206 name-lookups]. 207 o The SEAmless IP MOBility (seamoby) working group specified a pair 208 of experimental protocols which use an ICMPv6 message specified in 209 [RFC4065] to help in locating an access router and moving the 210 attachment point of a mobile node from one access router to 211 another. 213 Many of these messages should only be used in a link-local context 214 rather than end-to-end, and filters need to be concerned with the 215 type of addresses in ICMPv6 packets as well as the specific source 216 and destination addresses. 218 Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be 219 treated as an auxiliary function with packets that can be dropped in 220 most cases without damaging the functionality of the network. This 221 means that firewall filters for ICMPv6 have to be more carefully 222 configured than was the case for ICMP, where typically a small set of 223 blanket rules could be applied. 225 2. Classifying ICMPv6 Messages 227 2.1. Error and Informational ICMPv6 Messages 229 ICMPv6 messages contain an eight bit Type field interpreted as an 230 integer between 0 and 255. Messages with Type values less than or 231 equal to 127 are Error Messages. The remainder are Informational 232 Messages. In general terms, Error Messages with well-known 233 (standardized) Type values would normally be expected to be allowed 234 to be sent to or pass through firewalls, and may be essential to the 235 establishment of communications (see Section 2.4) whereas 236 Informational Messages will generally be the subject of policy rules, 237 and those passing through firewalls can, in many but by no means all 238 cases, be dropped without damaging IPv6 communications. 240 2.2. Addressing of ICMPv6 242 ICMPv6 messages are sent using various kinds of source and 243 destination address types. The source address is usually a unicast 244 address, but during address autoconfiguration message exchanges, the 245 unspecified address :: is also used as a source address [RFC2462]. 247 Multicast Listener Discovery (MLD) Report and Done messages are sent 248 with a link-local address as the IPv6 source address, if a valid 249 address is available on the interface. If a valid link-local address 250 is not available (e.g., one has not been configured), the message is 251 sent with the unspecified address (::) as the IPv6 source address. 252 Subsequently the node will generate new MLD Report messages with 253 proper link-local source address once it has been configured 254 [RFC3590]. 256 The destination address can be either a well-known multicast address, 257 a generated multicast address such as the solicited-node multicast 258 address, an anycast address or a unicast address. While many ICMPv6 259 messages use multicast addresses most of the time, some also use 260 unicast addresses. For instance, the Router Advertisement messages 261 are sent to the all-nodes multicast address when unsolicited, but can 262 also be sent to a unicast address in response to a specific Router 263 Solicitation. 265 2.3. Network Topology and Address Scopes 267 ICMPv6 messages can be classified according to whether they are meant 268 for end-to-end communications or communications within a link. There 269 are also messages that we can classify as 'any-to-end', which can be 270 sent from any point within a path back to the source; typically these 271 are used to announce an error in processing the original packet. For 272 instance, the address resolution messages are solely for local 273 communications [RFC2461], whereas the Destination Unreachable 274 messages are any-to-end in nature. Generally end-to-end and any-to- 275 end messages might be expected to pass through firewalls depending on 276 policies but local communications must not. 278 Local communications will use link-local addresses in many cases but 279 may also use global unicast addresses for example when configuring 280 global addresses. Also some ICMPv6 messages in local communications 281 may contravene the usual rules requiring compatible scopes for source 282 and destination addresses. 284 2.4. Role in Establishing Communication 286 Many ICMPv6 messages have a role in establishing communications to 287 and from the firewall and such messages have to be accepted by 288 firewalls for local delivery. Generally a firewall will also by 289 acting as a router so that all the messages that might be used in 290 configuring a router interface need to be accepted and generated. 291 This type of communication establishment messages should not be 292 passed through a firewall as they are normally intended for use 293 within a link. 295 On the other hand, most ICMPv6 error messages traveling end-to-end or 296 any-to-end are essential to the establishment of communications. 297 These messages must be passed through firewalls and might also be 298 sent to and from firewalls to assist with establishment of 299 communications. For example the Packet Too Big error message is 300 needed to establish the MTU along a path. 302 The remaining ICMPv6 messages which are not associated with 303 communication establishment will normally be legitimately attempting 304 to pass through a firewall from inside to out or vice versa, but in 305 most cases decisions as to whether to allow them to pass or not can 306 be made on the basis of local policy without interfering with the 307 establishment of IPv6 communications. 309 The filtering rules for the various message roles will generally be 310 different. 312 3. Security Considerations 314 This memo recommends filtering configurations for firewalls designed 315 to minimize the security vulnerabilities that can arise in using the 316 many different sub-protocols of ICMPv6 in support of IPv6 317 communication. 319 A major concern is that it is generally not possible to use IPsec or 320 other means to authenticate the sender and validate the contents of 321 many ICMPv6 messages. To a large extent this is because a site can 322 legitimately expect to receive certain error and other messages from 323 almost any location in the wider Internet, and these messages may 324 occur as a result of the first message sent to a destination. 325 Establishing security associations with all possible sources of 326 ICMPv6 messages is therefore impossible. 328 The inability to establish security associations to protect some 329 messages that are needed to establish communications means that 330 alternative means have to used to reduce the vulnerability of sites 331 to ICMPv6 based attacks. The most common way of doing this is to 332 establish strict filtering policies in site firewalls to limit the 333 unauthenticated ICMPv6 messages that can pass between the site and 334 the wider Internet. This makes control of ICMPv6 filtering a 335 delicate balance between protecting the site by dropping some of the 336 ICMPv6 traffic passing through the firewall and allowing enough of 337 the traffic through to make sure that efficient communication can be 338 established. 340 SEND [RFC3971] has been specified as a means to improve the security 341 of local ICMPv6 communications. SEND sidesteps security association 342 bootstrapping problems that would result if IPsec was used. SEND 343 affects only link local messages and does not limit the filtering 344 which firewalls can apply and its role in security is therefore not 345 discussed further in this document. 347 Firewalls will normally be concerned to monitor ICMPv6 to control the 348 following security concerns: 350 3.1. Denial of Service Attacks 352 ICMPv6 can be used to cause a Denial of Service(DoS) in a number of 353 ways, including simply sending excessive numbers of ICMPv6 packets to 354 destinations in the site and sending error messages which disrupt 355 established communications by causing sessions to be dropped. Also 356 if spurious communication establishment messages can be passed on to 357 link it might be possible to invalidate legitimate addresses or 358 disable interfaces. 360 3.2. Probing 362 A major security consideration is preventing attackers probing the 363 site to determine the topology and identify hosts that might be 364 vulnerable to attack. Carefully crafted but, often, malformed 365 messages can be used to provoke ICMPv6 responses from hosts thereby 366 informing attackers of potential targets for future attacks. However 367 the very large address space of IPv6 makes probing a less effective 368 weapon as compared with IPv4 provided that addresses are not 369 allocated in an easily guessable fashion. This subject is explored 370 in more depth in [I-D.chown-v6ops-port-scanning-implications]. 372 3.3. Redirection Attacks 374 A redirection attack could be used by a malicious sender to perform 375 man-in-the-middle attacks or divert packets either to a malicious 376 monitor or to cause DoS by blackholing the packets. These attacks 377 would normally have to be carried out locally on a link using the 378 Redirect message. Administrators need to decide if the improvement 379 in efficiency from using Redirect messages is worth the risk of 380 malicious use. Factors to consider include the physical security of 381 the link and the complexity of addressing on the link. For example, 382 on a wireless link, redirection would be a serious hazard due to the 383 lack of physical security. On the other hand, with a wired link in a 384 secure building with complex addressing and redundant routers, the 385 efficiency gains might well outweigh the small risk of a rogue node 386 being connected. 388 3.4. Renumbering Attacks 390 Spurious Renumbering messages could lead to the disruption of a site 391 and should not be allowed through a firewall in general. Renumbering 392 messages are required to be authenticated with IPsec so that it is 393 difficult to carry out such attacks in practice. 395 3.5. Problems Resulting from ICMPv6 Transparency 397 Because some ICMPv6 error packets need to be passed through a 398 firewall in both directions. This means that the ICMPv6 error 399 packets can be exchanged between inside and outside without any 400 filtering. 402 Using this feature, malicious users can communicate between the 403 inside and outside of a firewall bypassing the administrator's 404 inspection (proxy, firewall etc.). For example it might be possible 405 to carry out a covert conversation through the payload of ICMPv6 406 error messages or tunnel inappropriate encapsulated IP packets in 407 ICMPv6 error messages. This problem can be alleviated by filtering 408 ICMPv6 errors using a deep packet inspection mechanism to ensure that 409 the packet carried as a payload is associated with legitimate traffic 410 to or from the protected network. 412 4. Filtering Recommendations 414 When designing firewall filtering rules for ICMPv6, the rules can be 415 divided into two classes: 416 o Rules for ICMPv6 traffic transiting the firewall 417 o Rules for ICMPv6 directed to interfaces on the firewall 419 This section suggests some common considerations which should be 420 borne in mind when designing filtering rules and then categorizes the 421 rules for each class. The categories are: 422 o Messages that must not be dropped: usually because establishment 423 of communications will be prevented or severely impacted. 424 o Messages that should not be dropped: administrators need to have a 425 very good reason for dropping this category 426 o Messages that may be dropped but it is not essential because they 427 would normally be dropped for other reasons (e.g., because they 428 would be using link-local addresses) or the protocol specification 429 would cause them to be rejected if they had passed through a 430 router. 431 o Messages that administrators may or may not want to drop depending 432 on local policy. 433 o Messages that administrators should consider dropping (e.g., ICMP 434 node information name lookup queries) 436 More detailed analysis of each of the message types can be found in 437 Appendix A. 439 4.1. Common Considerations 441 Depending on the classification of the message to be filtered (see 442 Section 2), ICMPv6 messages should be filtered based on the ICMPv6 443 type of the message and the type (unicast, multicast, etc.) and scope 444 (link-local, global unicast, etc) of source and destination 445 addresses. In some cases it may be desirable to filter on the Code 446 field of ICMPv6 error messages. 448 Messages that are authenticated by means of an IPsec AH or ESP header 449 may be subject to less strict policies than unauthenticated messages. 450 In the remainder of this section, we are generally considering what 451 should be configured for unauthenticated messages. In many cases it 452 is not realistic to expect more than a tiny fraction of the messages 453 to be authenticated. 455 Where messages are not essential to the establishment of 456 communications, local policy can be used to determine whether a 457 message should be allowed or dropped. 459 Many of the messages used for establishment of communications on the 460 local link will be sent with link-local addresses for at least one of 461 their source and destination. Routers (and firewalls) conforming to 462 the IPv6 standards will not forward these packets; there is no need 463 to configure additional rules to prevent these packets traversing the 464 firewall/router. Also the specifications of ICMPv6 messages intended 465 for use only on the local link specify various measures which would 466 allow receivers to detect if the message had passed through a 467 firewall/router, including: 468 o Requiring that the hop limit in the IPv6 header is set to 255 on 469 transmission. On reception the hop limit is required to be still 470 255 which would not be the case if the packet had passed through a 471 firewall/router. 472 o Checking that the source address is a link-local unicast address. 473 Accordingly it is not essential to configure firewall rules to drop 474 illegal packets of these types. If they have non-link-local source 475 and destination addresses, allowing them to traverse the firewall, 476 they would be rejected because of the checks performed at the 477 destination. However, firewall administrators may still wish to log 478 or drop such illegal packets. 480 Depending on the capabilities of the firewall being configured, it 481 may be possible for the firewall to maintain state about packets that 482 may result in error messages being returned or about ICMPv6 packets 483 (e.g., Echo Requests) that are expected to receive a specific 484 response. This state may allow the firewall to perform more precise 485 checks based on this state, and to apply limits on the number of 486 ICMPv6 packets accepted incoming or outgoing as a result of a packet 487 traveling in the opposite direction. The capabilities of firewalls 488 to perform such stateful packet inspection vary from model to model, 489 and it is not assumed that firewalls are uniformly capable in this 490 respect. 492 Firewalls which are able to perform deep packet inspection may be 493 able to check the header fields in the start of the errored packet 494 which is carried by ICMPv6 error messages. If the embedded packet 495 has a source address which does not match the destination of the 496 error message the packet can be dropped. This provides a partial 497 defense against some possible attacks on TCP that use spoofed ICMPv6 498 error messages, but the checks can also be carried out at the 499 destination. For further information on these attacks see [I-D.gont- 500 tcpm-icmp-attacks]. 502 In general, the scopes of source and destination addresses of ICMPv6 503 messages should be matched, and packets with mismatched addresses 504 should be dropped if they attempt to transit a router. However some 505 of the address configuration messages carried locally on a link may 506 legitimately have mismatched addresses. Node implementations need to 507 avoid over-zealous filtering of these messages delivered locally on a 508 link. 510 4.2. Recommendations for ICMPv6 Transit Traffic 512 This section recommends rules that should be applied to ICMPv6 513 traffic attempting to transit a firewall. 515 4.2.1. Traffic that Must NOT be Dropped 517 Error messages that are essential to the establishment of 518 communications: 519 o Destination Unreachable (Type 1) - All codes 520 o Packet Too Big (Type 2) 521 o Time Exceeded (Type 3) - Code 0 only 522 o Parameter Problem (Type 4) - Codes 1 and 2 only 523 Appendix A.4 suggests some more specific checks that could be 524 performed on Parameter Problem messages if a firewall has the 525 necessary packet inspection capabilities. 527 Connectivity checking messages: 528 o Echo Request (Type 128) 529 o Echo Response (Type 129) 530 For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be 531 possible, it is essential that the connectivity checking messages are 532 allowed through the firewall. It has been common practice in IPv4 533 networks to drop Echo Request messages in firewalls to minimize the 534 risk of scanning attacks on the protected network. As discussed in 535 Section 3.2, the risks from port scanning in an IPv6 network are much 536 less severe and it is not necessary to filter IPv6 Echo Request 537 messages. 539 4.2.2. Traffic that Normally Should Not be Dropped 541 Error messages other than those listed in Section 4.2.1 542 o Time Exceeded (Type 3) - Code 1 543 o Parameter Problem (Type 4) - Code 0 545 Mobile IPv6 messages that are needed to assist mobility: 547 o Home Agent Address Discovery Request (Type 144) 548 o Home Agent Address Discovery Reply (Type 145) 549 o Mobile Prefix Solicitation (Type 146) 550 o Mobile Prefix Advertisement(Type 147) 551 Administrators may wish to apply more selective rules as described in 552 Appendix A.14 depending on whether the site is catering for mobile 553 nodes which would normally be at home on the site and/or foreign 554 mobile nodes roaming onto the site. 556 4.2.3. Traffic that May be Dropped but will be Caught Anyway 558 The messages listed in this section are all involved with local 559 management of nodes connected to the link on which they were 560 initially transmitted. All these messages should never be propagated 561 beyond the link on which they were initially transmitted. During 562 normal operations these messages will have destination addresses, 563 mostly link local but in some cases global unicast addresses, of 564 interfaces on the local link. No special action is needed to filter 565 messages with link-local addresses. As discussed in Section 4.1 566 these messages are specified so that either the receiver is able to 567 check that the message has not passed through a firewall/router or it 568 will be dropped at the first router it encounters. Administrators 569 may wish to consider providing rules to catch illegal packets sent 570 with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being 571 generated for these packets. 573 Address Configuration and Router Selection messages (must be received 574 with hop limit = 255): 575 o Router Solicitation (Type 133) 576 o Router Advertisement (Type 134) 577 o Neighbor Solicitation (Type 135) 578 o Neighbor Advertisement (Type 136) 579 o Redirect (Type 137) 580 o Inverse Neighbor Discovery Solicitation (Type 141) 581 o Inverse Neighbor Discovery Advertisement (Type 142) 583 Link-local multicast receiver notification messages (must have link- 584 local source address): 585 o Listener Query (Type 130) 586 o Listener Report (Type 131) 587 o Listener Done (Type 132) 588 o Listener Report v2 (Type 143) 590 SEND Certificate Path notification messages (must be received with 591 hop limit = 255): 592 o Certificate Path Solicitation (Type 148) 593 o Certificate Path Advertisement (type 149) 595 Multicast Router Discovery messages (must have link-local source 596 address and hop limit = 1): 597 o Multicast Router Advertisement (Type 151) 598 o Multicast Router Solicitation (Type 152) 599 o Multicast Router Termination (Type 153) 601 4.2.4. Traffic for which a Dropping Policy Should be Defined 603 The message which the experimental Seamoby protocols are using will 604 be expected to have to cross site boundaries. Administrators should 605 determine if they need to support these experiments and otherwise 606 messages of this type should be dropped: 607 o Seamoby Experimental (Type 150) 609 Error messages not currently defined by IANA: 610 o Unallocated Error messages (Types 5-99 and 102-126, inclusive) 612 The base ICMPv6 specification suggests that error messages which are 613 not explicitly known to a node should be forwarded and passed to any 614 higher level protocol that might be able to interpret them. There is 615 a small risk that such messages could be used to provide a covert 616 channel or form part of a DoS attack. Administrators should be aware 617 of this and determine whether they wish to allow these messages 618 through the firewall. 620 4.2.5. Traffic which Should be Dropped Unless a Good Case can be Made 622 Node Information enquiry messages should generally not be forwarded 623 across site boundaries. Some of these messages will be using non- 624 link-local unicast addresses so that they will not necessarily be 625 dropped by address scope limiting rules: 626 o Node Information Query (Type 139) 627 o Node Information Response (Type 140) 629 Router Renumbering messages should not be forwarded across site 630 boundaries. As originally specified, these messages may use a site 631 scope multicast address or a site local unicast address. They should 632 be caught by standard rules that are intended to stop any packet with 633 a multicast site scope or site local destination being forwarded 634 across a site boundary provided these are correctly configured. 635 Since site local addresses have now been deprecated it seems likely 636 that changes may be made to allow the use of unique local addresses 637 or global unicast addresses. Should this happen, it will be 638 essential to explicitly filter these messages: 640 o Router Renumbering (Type 139) 642 Messages with types in the experimental allocations: 643 o Types 100, 101, 200 and 201. 645 Messages using the extension type numbers until such time as ICMPv6 646 needs to use such extensions: 647 o Types 127 and 255. 649 All informational messages with types not explicitly assigned by 650 IANA, currently: 651 o Types 154 - 199 inclusive and 202 - 254 inclusive. 653 Note that the base ICMPv6 specification requires that informational 654 messages with unknown types must be silently discarded. 656 4.3. Recommendations for ICMPv6 Local Configuration Traffic 658 This section recommends filtering rules for ICMPv6 traffic addressed 659 to an interface on a firewall. For a small number of messages, the 660 desired behavior may differ between interfaces on the site or private 661 side of the firewall and the those on the public Internet side of the 662 firewall. 664 4.3.1. Traffic that Must NOT be Dropped 666 Error messages that are essential to the establishment of 667 communications: 668 o Destination Unreachable (Type 1) - All codes 669 o Packet Too Big (Type 2) 670 o Time Exceeded (Type 3) - Code 0 only 671 o Parameter Problem (Type 4) - Codes 1 and 2 only 673 Connectivity checking messages: 674 o Echo Request (Type 128) 675 o Echo Response (Type 129) 676 As discussed in Section 4.2.1, dropping connectivity checking 677 messages will prevent the firewall being the destination of a Teredo 678 tunnel and it is not considered necessary to disable connectivity 679 checking in IPv6 networks because port scanning is less of a security 680 risk. 682 There are a number of other sets of messages which play a role in 683 configuring the node and maintaining unicast and multicast 684 communications through the interfaces of a node. These messages must 685 not be dropped if the node is to successfully participate in an IPv6 686 network. The exception to this is the Redirect message for which an 687 explicit policy decision should be taken (see Section 4.3.4). 689 Address Configuration and Router Selection messages: 690 o Router Solicitation (Type 133) 691 o Router Advertisement (Type 134) 692 o Neighbor Solicitation (Type 135) 693 o Neighbor Advertisement (Type 136) 694 o Inverse Neighbor Discovery Solicitation (Type 141) 695 o Inverse Neighbor Discovery Advertisement (Type 142) 697 Link-local multicast receiver notification messages: 698 o Listener Query (Type 130) 699 o Listener Report (Type 131) 700 o Listener Done (Type 132) 701 o Listener Report v2 (Type 143) 703 SEND Certificate Path notification messages: 704 o Certificate Path Solicitation (Type 148) 705 o Certificate Path Advertisement (type 149) 707 Multicast Router Discovery messages : 708 o Multicast Router Advertisement (Type 151) 709 o Multicast Router Solicitation (Type 152) 710 o Multicast Router Termination (Type 153) 712 4.3.2. Traffic that Normally Should Not be Dropped 714 Error messages other than those listed in Section 4.3.1: 715 o Time Exceeded (Type 3) - Code 1 716 o Parameter Problem (Type 4) - Code 0 718 4.3.3. Traffic that May be Dropped but will be Caught Anyway 720 Router Renumbering messages must be authenticated using IPsec, so it 721 is not essential to filter these messages even if they are not 722 allowed at the firewall: 723 o Router Renumbering (Type 139) 725 Mobile IPv6 messages that are needed to assist mobility: 726 o Home Agent Address Discovery Request (Type 144) 727 o Home Agent Address Discovery Reply (Type 145) 728 o Mobile Prefix Solicitation (Type 146) 729 o Mobile Prefix Advertisement(Type 147) 730 It may be desirable to drop these messages, especially on public 731 interfaces, if the firewall is not also providing mobile Home Agent 732 services, but they will be ignored otherwise. 734 The message used by the experimental Seamoby protocols may be dropped 735 but will be ignored if the service is not implemented: 737 o Seamoby Experimental (Type 150) 739 4.3.4. Traffic for which a Dropping Policy Should be Defined 741 Redirect messages provide a significant security risk and 742 administrators should take a case-by-case view of whether firewalls, 743 routers in general and other nodes should accept these messages: 744 o Redirect (Type 137) 745 Conformant nodes must provide configuration controls which allow 746 nodes to control their behavior with respect to Redirect messages so 747 that it should only be necessary to install specific filtering rules 748 under special circumstances, such as if Redirect messages are 749 accepted on private interfaces but not public ones. 751 If a node implements the experimental Node Information service, the 752 administrator needs to make an explicit decision as to whether the 753 node should respond to or accept Node Information messages on each 754 interface: 755 o Node Information Query (Type 139) 756 o Node Information Response (Type 140) 757 It may be possible to disable the service on the node if it is not 758 wanted in which case these messages will ignored and no filtering is 759 necessary. 761 Error messages not currently defined by IANA: 762 o Unallocated Error messages (Types 5-99 and 102-126, inclusive) 764 The base ICMPv6 specification suggests that error messages which are 765 not explicitly known to a node should be forwarded and passed to any 766 higher level protocol that might be able to interpret them. There is 767 a small risk that such messages could be used to provide a covert 768 channel or form part of a DoS attack. Administrators should be aware 769 of this and determine whether they wish to allow these messages to be 770 sent to the firewall. 772 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made 774 Messages with types in the experimental allocations: 775 o Types 100, 101, 200 and 201. 777 Messages using the extension type numbers until such time as ICMPv6 778 needs to use such extensions: 779 o Types 127 and 255. 781 All informational messages with types not explicitly assigned by 782 IANA, currently: 784 o Types 154 - 199 inclusive and 202 - 254 inclusive. 786 Note that the base ICMPv6 specification requires that informational 787 messages with unknown types must be silently discarded. 789 5. IANA Considerations 791 There are no IANA considerations defined in this document. 793 6. Acknowledgements 795 Pekka Savola created the original IPv6 Security Overview document 796 which contained suggestions for ICMPv6 filter setups. This 797 information has been incorporated into this document. He has also 798 provided important comments. Some analysis of the classification of 799 ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in 800 a draft relating to ICMPv6 and IKE. 802 The Netfilter configuration script in Appendix C was contributed by 803 Suresh Krishnan. 805 7. References 807 7.1. Normative References 809 [I-D.ietf-ipngwg-icmp-name-lookups] 810 Crawford, M. and B. Haberman, "IPv6 Node Information 811 Queries", draft-ietf-ipngwg-icmp-name-lookups-15 (work in 812 progress), February 2006. 814 [I-D.ietf-ipngwg-icmp-v3] 815 Conta, A., "Internet Control Message Protocol (ICMPv6) for 816 the Internet Protocol Version 6 (IPv6) Specification", 817 draft-ietf-ipngwg-icmp-v3-07 (work in progress), 818 July 2005. 820 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 821 for IP version 6", RFC 1981, August 1996. 823 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 824 (IPv6) Specification", RFC 2460, December 1998. 826 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 827 Discovery for IP Version 6 (IPv6)", RFC 2461, 828 December 1998. 830 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 831 Autoconfiguration", RFC 2462, December 1998. 833 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 834 Listener Discovery (MLD) for IPv6", RFC 2710, 835 October 1999. 837 [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, 838 August 2000. 840 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 841 Inverse Discovery Specification", RFC 3122, June 2001. 843 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 844 Listener Discovery (MLD) Protocol", RFC 3590, 845 September 2003. 847 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 848 in IPv6", RFC 3775, June 2004. 850 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 851 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 853 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 854 Neighbor Discovery (SEND)", RFC 3971, March 2005. 856 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 857 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 859 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 860 RFC 4286, December 2005. 862 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 863 Message Protocol (ICMPv6) for the Internet Protocol 864 Version 6 (IPv6) Specification", RFC 4443, March 2006. 866 7.2. Informative References 868 [I-D.chown-v6ops-port-scanning-implications] 869 Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 870 draft-chown-v6ops-port-scanning-implications-02 (work in 871 progress), October 2005. 873 [I-D.gont-tcpm-icmp-attacks] 874 Gont, F., "ICMP attacks against TCP", 875 draft-gont-tcpm-icmp-attacks-05 (work in progress), 876 October 2005. 878 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 879 Stateless Address Autoconfiguration in IPv6", RFC 3041, 880 January 2001. 882 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 883 Network Address Translations (NATs)", RFC 4380, 884 February 2006. 886 [netfilter] 887 netfilter.org, "The netfilter.org project", Firewalling, 888 NAT and Packet Mangling for Linux , 2006, 889 . 891 Appendix A. Notes on Individual ICMPv6 Messages 893 A.1. Destination Unreachable Error Message 895 Destination Unreachable (Type 1) error messages [RFC4443] are sent 896 any-to-end between unicast addresses. The message can be generated 897 from any node which a packet traverses when the node is unable to 898 forward the packet for any reason except congestion. 900 Destination Unreachable messages are useful for debugging but are 901 also important to speed up cycling through possible addresses, as 902 they can avoid the need to wait through timeouts and hence can be 903 part of the process of establishing communications. It is a common 904 practice in IPv4 to refrain from generating ICMP Destination 905 Unreachable messages in an attempt to hide the networking topology 906 and/or service structure. The same idea could be applied to IPv6 but 907 this can slow down connection if a host has multiple addresses, some 908 of which are deprecated, as they may be when using privacy addresses 909 [RFC3041]. If policy allows the generation of ICMPv6 Destination 910 Unreachable messages, it is important that nodes provide the correct 911 reason code, one of: no route to destination, administratively 912 prohibited, beyond scope of source address, address unreachable, port 913 unreachable, source address failed ingress/egress policy, reject 914 route to destination. 916 A.2. Packet Too Big Error Message 918 Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end 919 between unicast addresses. The message can be generated from any 920 node which a packet traverses on the path when the node is unable to 921 forward the packet because the packet is too large for the MTU of the 922 next link. This message is vital to the correct functioning of Path 923 MTU Discovery and hence is part of the establishment of 924 communications. Since routers are not allowed to fragment packets, 925 informing sources of the need to fragment large packets is more 926 important than for IPv4. If these messages are not generated when 927 appropriate, hosts will continue to send packets which are too large 928 or may assume that the route is congested. Effectively parts of the 929 Internet will become inaccessible. 931 If a network chooses to generate packets that are no larger than the 932 Guaranteed Minimum MTU (1280 octets) and the site's links to the 933 wider internet have corresponding MTUs, Packet Too Big messages 934 should not be expected at the firewall and could be dropped if they 935 arrive. 937 A.3. Time Exceeded Error Message 939 Time Exceeded (Type 3) error messages [RFC4443] can occur in two 940 contexts: 941 o Code 0 are generated at any node on the path being taken by the 942 packet and sent, any-to-end between unicast addresses, if the Hop 943 Limit value is decremented to zero at that node. 944 o Code 1 messages are generated at the destination node and sent 945 end-to-end between unicast addresses if all the segments of a 946 fragmented message are not received within the reassembly time 947 limit 949 Code 0 messages can be needed as part of the establishment of 950 communications if the path to a particular destination requires an 951 unusually large number of hops. 953 Code 1 messages will generally only result from congestion in the 954 network and it is less essential to propagate these messages. 956 A.4. Parameter Problem Error Message 958 The great majority of Parameter Problem (Type 4) error messages will 959 be generated by the destination node when processing destination 960 options and other extension headers, and hence are sent end-to-end 961 between unicast addresses. Exceptionally, these messages might be 962 generated by any node on the path if a faulty or unrecognized hop-by- 963 hop option is included or from any routing waypoint if there are 964 faulty or unrecognized destination options associated with a Type 0 965 routing header. In these cases the message will be sent any-to-end 966 using unicast source and destination addresses. 968 Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 969 (Unrecognized IPv6 Option) messages may result if a node on the path 970 (usually the destination) is unable to process a correctly formed 971 extension header or option. If these messages are not returned to 972 the source communication cannot be established, as the source would 973 need to adapt its choice of options probably because the destination 974 does not implement these capabilities. Hence these messages need to 975 be generated and allowed for effective IPv6 communications. 977 Code 0 (Erroneous Header) messages indicate a malformed extension 978 header generally as a result of incorrectly generated packets. Hence 979 these messages are useful for debugging purposes but it is unlikely 980 that a node generating such packets could establish communications 981 without human intervention to correct the problem. 983 Code 2 messages, only, can be generated for packets with multicast 984 destination addresses. 986 It is possible that attackers may seek to probe or scan a network by 987 deliberately generating packets with unknown extension headers or 988 options, or faulty headers. If nodes generate Parameter Problem 989 error messages in all cases and these outgoing messages are allowed 990 through firewalls, the attacker may be able to identify active 991 addresses that can be probed further or learn about the network 992 topology. The vulnerability could be mitigated whilst helping to 993 establish communications if the firewall was able to examine such 994 error messages in depth and was configured to only allow Parameter 995 Problem messages for headers which had been standardized but were not 996 supported in the protected network. If the network administrator 997 believes that all nodes in the network support all legitimate 998 extension headers then it would be reasonable to drop all outgoing 999 Parameter Problem messages. Note that this is not a major 1000 vulnerability in a well-designed IPv6 network because of the 1001 difficulties of performing scanning attacks (see Section 3.2). 1003 A.5. ICMPv6 Echo Request and Echo Response 1005 Echo Request (Type 128) uses unicast addresses as source addresses, 1006 but may be sent to any legal IPv6 address, including multicast and 1007 anycast addresses [RFC4443]. Echo Requests travel end-to-end. 1008 Similarly Echo Responses (Type 129) travel end-to-end and would have 1009 a unicast address as destination and either a unicast or anycast 1010 address as source. They are mainly used in combination for 1011 monitoring and debugging connectivity. Their only role in 1012 establishing communication is that they are required when verifying 1013 connectivity through Teredo tunnels[RFC4380]: Teredo tunneling to 1014 IPv6 nodes on the site will not be possible if these messages are 1015 blocked. It is not thought that there is a significant risk from 1016 scanning attacks on a well-designed IPv6 network (see Section 3.2) 1017 and so connectivity checks should be allowed by default. 1019 A.6. Neighbor Solicitation and Neighbor Advertisement Messages 1021 ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 1022 136) messages are essential to the establishment of communications on 1023 the local link. Firewalls need to generate and accept these messages 1024 to allow them to establish interfaces onto their connected links. 1026 Note that the address scopes of the source and destination addresses 1027 on Neighbor Solicitations and Neighbor Advertisements may not match. 1028 The exact functions which these messages will be carrying out depends 1029 on the mechanism being used to configure IPv6 addresses on the link 1030 (Stateless, Stateful or Static configuration). 1032 A.7. Router Solicitation and Router Advertisement Messages 1034 ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134) 1035 messages are essential to the establishment of communications on the 1036 local link. Firewalls need to generate (since the firewall will 1037 generally be behaving as a router) and accept these messages to allow 1038 them to establish interfaces onto their connected links. 1040 A.8. Redirect Messages 1042 ICMPv6 Redirect Messages(Type 137) are used on the local link to 1043 indicate that nodes are actually link-local and communications need 1044 not go via a router, or to indicate a more appropriate first hop 1045 router. Although they can be used to make communications more 1046 efficient, they are not essential to the establishment of 1047 communications and may be a security vulnerability, particularly if a 1048 link is not physically secured. Conformant nodes are required to 1049 provide configuration controls which suppress the generation of 1050 Redirect messages and allow them to be ignored on reception. Using 1051 Redirect messages on a wireless link is particularly hazardous 1052 because of the lack of physical security. 1054 A.9. SEND Certificate Path Messages 1056 SEND [RFC3971] uses two messages (Certificate Path Solicitation and 1057 Advertisement - Types 148 and 149) sent from nodes to supposed 1058 routers on the same local link to obtain a certificate path which 1059 will allow the node to authenticate the router's claim to provide 1060 routing services for certain prefixes. If a link connected to a 1061 firewall/router is using SEND, the firewall must be able to exchange 1062 these messages with nodes on the link that will use its routing 1063 services. 1065 A.10. Multicast Listener Discovery Messages 1067 Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener 1068 Query, Listener Report and Listener Done - Types 130, 131 and 132) 1069 and version 2 [RFC3810] (Listener Query and Listener Report Version 2 1070 - Types 130 and 143) messages are sent on the local link to 1071 communicate between multicast capable routers and nodes which wish to 1072 join or leave specific multicast groups. Firewalls need to be able 1073 to generate Listener messages in order to establish communications 1074 and may generate all the messages if they also provide multicast 1075 routing services. 1077 A.11. Multicast Router Discovery Messages 1079 Multicast Router Discovery [RFC4286] (Router Advertisement, Router 1080 Solicitation and Router Termination - Types 151, 152 and 153) 1081 messages are sent by nodes on the local link to discover multicast 1082 capable routers on the link, and by multicast capable routers to 1083 notify other nodes of their existence or change of state. Firewalls 1084 which also act as multicast routers need to process these messages on 1085 their interfaces. 1087 A.12. Router Renumbering Messages 1089 ICMPv6 Router Renumbering (Type 138) command messages can be received 1090 and results messages sent by routers to change the prefixes which 1091 they advertise as part of Stateless Address Configuration [RFC2461], 1092 [RFC2462]. These messages are sent end-to-end to either the all- 1093 routers multicast address (site or local scope) or specific unicast 1094 addresses from a unicast address. 1096 Router Renumbering messages are required to be protected by IPsec 1097 authentication since they could be readily misused by attackers to 1098 disrupt or divert site communications. Renumbering messages should 1099 generally be confined to sites for this reason. 1101 A.13. Node Information Query and Reply 1103 ICMPv6 Node Information Query and Reply (Type 139 and 140) messages 1104 are sent end-to-end between unicast addresses, and can also be sent 1105 to link-local multicast addresses. They can, in theory, be sent from 1106 any node to any other but it would generally not be desirable for 1107 nodes outside the local site to be able to send queries to nodes 1108 within the site. Also these messages are not required to be 1109 authenticated. 1111 A.14. Mobile IPv6 Messages 1113 Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to 1114 support mobile operations: Home Agent Address Discovery Request, Home 1115 Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP 1116 Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. 1117 These messages are sent end-to-end between unicast addresses of a 1118 mobile node and its home agent. They must be expected to be sent 1119 from outside a site. The two Mobile prefix messages should be 1120 protected by the use of IPsec authentication. 1121 o If the site provides home agents for mobile nodes, the firewall 1122 must allow incoming Home Agent Address Discovery Request and 1123 Mobile Prefix Solicitation messages, and outgoing Home Agent 1124 Address Discovery Reply and ICMP Mobile Prefix Advertisement 1125 messages. It may be desirable to limit the destination addresses 1126 for the incoming messages to links that are known to support home 1127 agents. 1128 o If the site is prepared to host roaming mobile nodes, the firewall 1129 must allow outgoing Home Agent Address Discovery Request and 1130 Mobile Prefix Solicitation messages, and incoming Home Agent 1131 Address Discovery Reply and ICMP Mobile Prefix Advertisement 1132 messages. 1133 o Administrators may find it desirable to prevent static nodes which 1134 are normally resident on the site from behaving as mobile nodes by 1135 dropping Mobile IPv6 messages from these nodes. 1137 A.15. Unused and Experimental Messages 1139 A large number of ICMPv6 Type values are currently unused. These 1140 values have not had a specific function registered with IANA. This 1141 section describes how to treat messages which attempt to use these 1142 Type values in a way of which the network administrator (and hence 1143 the firewall) is not aware. 1145 [I-D.ietf-ipngwg-icmp-v3] defines a number of experimental Type 1146 values for ICMPv6 Error and Informational messages, which could be 1147 used in site specific ways. These values should be treated in the 1148 same way as values which are not registered by IANA unless the 1149 network administrator is explicitly made aware of usage. 1151 The codes reserved for future extension of the ICMPv6 Type space 1152 should currently be dropped as this functionality is as yet 1153 undefined. 1155 Any ICMPv6 Informational messages of which the firewall is not aware 1156 should not be allowed to pass through the firewall or be accepted for 1157 local delivery on any of its interfaces. 1159 Any incoming ICMPv6 Error messages of which the firewall is not aware 1160 may be allowed through the firewall in line with the specification in 1161 [RFC4443], which requests delivery of unknown error messages to 1162 higher layer protocol processes. However, administrators may wish to 1163 disallow forwarding of these incoming messages as a potential 1164 security risk. Unknown outgoing Error messages should be dropped as 1165 the administrator should be aware of all messages that could be 1166 generated on the site. 1168 Also the Seamoby working group has had an ICMPv6 message (Type 150) 1169 allocated for experimental use in two protocols. This message is 1170 sent end-to-end and may need to pass through firewalls on sites that 1171 are supporting the experimental protocols. 1173 Appendix B. Example Script to Configure ICMPv6 Firewall Rules 1175 This appendix contains an example script to implement most of the 1176 rules suggested in this document when using the Netfilter packet 1177 filtering system for Linux [netfilter]. When used with IPv6, the 1178 'ip6tables' command is used to configure packet filtering rules for 1179 the Netfilter system. The script is targeted at a simple enterprise 1180 site that may or may not support Mobile IPv6. 1182 #!/bin/bash 1183 # Set of prefixes on the trusted ("inner") side of the firewall 1184 export INNER_PREFIXES="2001:DB8:85::/60" 1185 # Set of hosts providing services so that they can be made pingable 1186 export PINGABLE_HOSTS="2001:DB8:85::/64" 1187 # Configuration option: Change this to 1 if errors allowed only for 1188 # existing sessions 1189 export STATE_ENABLED=0 1190 # Configuration option: Change this to 0 if the site does not support 1191 # Mobile IPv6 Home Agents - see Appendix A.14 1192 export HOME_AGENTS_PRESENT=1 1193 # Configuration option: Change this to 0 if the site does not support 1194 # Mobile IPv6 mobile nodes being present on the site - 1195 # see Appendix A.14 1196 export MOBILE_NODES_PRESENT=1 1198 ip6tables -N icmpv6-filter 1199 ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter 1201 # Match scope of src and dest else deny 1202 # This capability is not provided for in base ip6tables functionality 1203 # An extension (agr) exists which may support it. 1204 #@TODO@ 1205 # ECHO REQUESTS AND RESPONSES 1206 # =========================== 1208 # Allow outbound echo requests from prefixes which belong to the site 1209 # for inner_prefix in $INNER_PREFIXES 1210 do 1211 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1212 --icmpv6-type echo-request -j ACCEPT 1213 done 1215 # Allow inbound echo requests towards only predetermined hosts 1216 # for pingable_host in $PINGABLE_HOSTS 1217 do 1218 ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ 1219 --icmpv6-type echo-request -j ACCEPT 1220 done 1222 if [ "$STATE_ENABLED" -eq "1" ] 1223 then 1224 # Allow incoming and outgoing echo reply messages 1225 # only for existing sessions 1226 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1227 --state ESTABLISHED,RELATED --icmpv6-type \ 1228 echo-reply -j ACCEPT 1229 else 1230 # Allow both incoming and outgoing echo replies 1231 for pingable_host in $PINGABLE_HOSTS 1232 do 1233 # Outgoing echo replies from pingable hosts 1234 ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ 1235 --icmpv6-type echo-reply -j ACCEPT 1236 done 1237 # Incoming echo replies to prefixes which belong to the site 1238 for inner_prefix in $INNER_PREFIXES 1239 do 1240 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1241 --icmpv6-type echo-reply -j ACCEPT 1242 done 1243 fi 1245 # Deny icmps to/from link local addresses 1246 # These rules should be redundant as routers should not forward 1247 # link local addresses but to be sure... 1248 ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP 1249 ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP 1251 # Drop echo replies which have a multicast address as a 1252 # destination 1253 ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ 1254 --icmpv6-type echo-reply -j DROP 1256 # DESTINATION UNREACHABLE ERROR MESSAGES 1257 # ====================================== 1259 if [ "$STATE_ENABLED" -eq "1" ] 1260 then 1261 # Allow incoming destination unreachable messages 1262 # only for existing sessions 1263 for inner_prefix in $INNER_PREFIXES 1264 do 1265 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1266 -d $inner_prefix \ 1267 --state ESTABLISHED,RELATED --icmpv6-type \ 1268 destination-unreachable -j ACCEPT 1269 done 1270 else 1271 # Allow incoming destination unreachable messages 1272 for inner_prefix in $INNER_PREFIXES 1273 do 1274 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1275 --icmpv6-type destination-unreachable -j ACCEPT 1276 done 1277 fi 1279 # Allow outgoing destination unreachable messages 1280 for inner_prefix in $INNER_PREFIXES 1281 do 1282 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1283 --icmpv6-type destination-unreachable -j ACCEPT 1284 done 1286 # PACKET TOO BIG ERROR MESSAGES 1287 # ============================= 1289 if [ "$STATE_ENABLED" -eq "1" ] 1290 then 1291 # Allow incoming Packet Too Big messages 1292 # only for existing sessions 1293 for inner_prefix in $INNER_PREFIXES 1294 do 1295 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1296 -d $inner_prefix \ 1297 --state ESTABLISHED,RELATED \ 1298 --icmpv6-type packet-too-big \ 1299 -j ACCEPT 1300 done 1302 else 1303 # Allow incoming Packet Too Big messages 1304 for inner_prefix in $INNER_PREFIXES 1305 do 1306 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1307 --icmpv6-type packet-too-big -j ACCEPT 1308 done 1309 fi 1311 # Allow outgoing Packet Too Big messages 1312 for inner_prefix in $INNER_PREFIXES 1313 do 1314 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1315 --icmpv6-type packet-too-big -j ACCEPT 1316 done 1318 # TIME EXCEEDED ERROR MESSAGES 1319 # ============================ 1321 if [ "$STATE_ENABLED" -eq "1" ] 1322 then 1323 # Allow incoming time exceeded code 0 messages 1324 # only for existing sessions 1325 for inner_prefix in $INNER_PREFIXES 1326 do 1327 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1328 -d $inner_prefix \ 1329 --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ 1330 -j ACCEPT 1331 done 1332 else 1333 # Allow incoming time exceeded code 0 messages 1334 for inner_prefix in $INNER_PREFIXES 1335 do 1336 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1337 --icmpv6-type ttl-zero-during-transit -j ACCEPT 1338 done 1339 fi 1341 #@POLICY@ 1342 # Allow incoming time exceeded code 1 messages 1343 for inner_prefix in $INNER_PREFIXES 1344 do 1345 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1346 --icmpv6-type ttl-zero-during-reassembly -j ACCEPT 1347 done 1349 # Allow outgoing time exceeded code 0 messages 1350 for inner_prefix in $INNER_PREFIXES 1351 do 1352 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1353 --icmpv6-type ttl-zero-during-transit -j ACCEPT 1354 done 1356 #@POLICY@ 1357 # Allow outgoing time exceeded code 1 messages 1358 for inner_prefix in $INNER_PREFIXES 1359 do 1360 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1361 --icmpv6-type ttl-zero-during-reassembly -j ACCEPT 1362 done 1364 # PARAMETER PROBLEM ERROR MESSAGES 1365 # ================================ 1367 if [ "$STATE_ENABLED" -eq "1" ] 1368 then 1369 # Allow incoming parameter problem code 1 and 2 messages 1370 # for an existing session 1371 for inner_prefix in $INNER_PREFIXES 1372 do 1373 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1374 -d $inner_prefix \ 1375 --state ESTABLISHED,RELATED --icmpv6-type \ 1376 unknown-header-type \ 1377 -j ACCEPT 1378 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1379 -d $inner_prefix \ 1380 --state ESTABLISHED,RELATED \ 1381 --icmpv6-type unknown-option \ 1382 -j ACCEPT 1383 done 1384 fi 1386 # Allow outgoing parameter problem code 1 and code 2 messages 1387 for inner_prefix in $INNER_PREFIXES 1388 do 1389 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1390 --icmpv6-type unknown-header-type -j ACCEPT 1391 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1392 --icmpv6-type unknown-option -j ACCEPT 1393 done 1395 #@POLICY@ 1396 # Allow incoming and outgoing parameter 1397 # problem code 0 messages 1398 for inner_prefix in $INNER_PREFIXES 1399 do 1400 ip6tables -A icmpv6-filter -p icmpv6 \ 1401 --icmpv6-type bad-header \ 1402 -j ACCEPT 1403 done 1405 # NEIGHBOR DISCOVERY MESSAGES 1406 # =========================== 1408 # Drop NS/NA messages both incoming and outgoing 1409 ip6tables -A icmpv6-filter -p icmpv6 \ 1410 --icmpv6-type neighbor-solicitation -j DROP 1411 ip6tables -A icmpv6-filter -p icmpv6 \ 1412 --icmpv6-type neighbor-advertisement -j DROP 1414 # Drop RS/RA messages both incoming and outgoing 1415 ip6tables -A icmpv6-filter -p icmpv6 \ 1416 --icmpv6-type router-solicitation -j DROP 1417 ip6tables -A icmpv6-filter -p icmpv6 \ 1418 --icmpv6-type router-advertisement -j DROP 1420 # Drop Redirect messages both incoming and outgoing 1421 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP 1423 # MLD MESSAGES 1424 # ============ 1426 # Drop incoming and outgoing 1427 # Multicast Listener queries (MLDv1 and MLDv2) 1428 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP 1430 # Drop incoming and outgoing Multicast Listener reports (MLDv1) 1431 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP 1433 # Drop incoming and outgoing Multicast Listener Done messages (MLDv1) 1434 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP 1436 # Drop incoming and outgoing Multicast Listener reports (MLDv2) 1437 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP 1439 # ROUTER RENUMBERING MESSAGES 1440 # =========================== 1442 # Drop router renumbering messages 1443 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP 1444 # NODE INFORMATION QUERIES 1445 # ======================== 1447 # Drop node information queries (139) and replies (140) 1448 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP 1449 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP 1451 # MOBILE IPv6 MESSAGES 1452 # ==================== 1454 # If there are mobile ipv6 home agents present on the 1455 # trusted side allow 1456 if [ "$HOME_AGENTS_PRESENT" -eq "1" ] 1457 then 1458 for inner_prefix in $INNER_PREFIXES 1459 do 1460 #incoming Home Agent address discovery request 1461 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1462 --icmpv6-type 144 -j ACCEPT 1463 #outgoing Home Agent address discovery reply 1464 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1465 --icmpv6-type 145 -j ACCEPT 1466 #incoming Mobile prefix solicitation 1467 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1468 --icmpv6-type 146 -j ACCEPT 1469 #outgoing Mobile prefix advertisement 1470 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1471 --icmpv6-type 147 -j ACCEPT 1472 done 1473 fi 1475 # If there are roaming mobile nodes present on the 1476 # trusted side allow 1477 if [ "$MOBILE_NODES_PRESENT" -eq "1" ] 1478 then 1479 for inner_prefix in $INNER_PREFIXES 1480 do 1481 #outgoing Home Agent address discovery request 1482 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1483 --icmpv6-type 144 -j ACCEPT 1484 #incoming Home Agent address discovery reply 1485 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1486 --icmpv6-type 145 -j ACCEPT 1487 #outgoing Mobile prefix solicitation 1488 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1489 --icmpv6-type 146 -j ACCEPT 1490 #incoming Mobile prefix advertisement 1491 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1492 --icmpv6-type 147 -j ACCEPT 1493 done 1494 fi 1496 # DROP EVERYTHING ELSE 1497 # ==================== 1499 ip6tables -A icmpv6-filter -p icmpv6 -j DROP 1501 Authors' Addresses 1503 Elwyn B. Davies 1504 Consultant 1505 Soham, Cambs 1506 UK 1508 Phone: +44 7889 488 335 1509 Email: elwynd@dial.pipex.com 1511 Janos Mohacsi 1512 NIIF/HUNGARNET 1513 Victor Hugo u. 18-22 1514 Budapest, H-1132 1515 Hungary 1517 Phone: +36 1 4503070 1518 Email: mohacsi@niif.hu 1520 Intellectual Property Statement 1522 The IETF takes no position regarding the validity or scope of any 1523 Intellectual Property Rights or other rights that might be claimed to 1524 pertain to the implementation or use of the technology described in 1525 this document or the extent to which any license under such rights 1526 might or might not be available; nor does it represent that it has 1527 made any independent effort to identify any such rights. Information 1528 on the procedures with respect to rights in RFC documents can be 1529 found in BCP 78 and BCP 79. 1531 Copies of IPR disclosures made to the IETF Secretariat and any 1532 assurances of licenses to be made available, or the result of an 1533 attempt made to obtain a general license or permission for the use of 1534 such proprietary rights by implementers or users of this 1535 specification can be obtained from the IETF on-line IPR repository at 1536 http://www.ietf.org/ipr. 1538 The IETF invites any interested party to bring to its attention any 1539 copyrights, patents or patent applications, or other proprietary 1540 rights that may cover technology that may be required to implement 1541 this standard. Please address the information to the IETF at 1542 ietf-ipr@ietf.org. 1544 Disclaimer of Validity 1546 This document and the information contained herein are provided on an 1547 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1548 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1549 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1550 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1551 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1552 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1554 Copyright Statement 1556 Copyright (C) The Internet Society (2006). This document is subject 1557 to the rights, licenses and restrictions contained in BCP 78, and 1558 except as set forth therein, the authors retain all their rights. 1560 Acknowledgment 1562 Funding for the RFC Editor function is currently provided by the 1563 Internet Society.