idnits 2.17.1 draft-ietf-v6ops-icmpv6-filtering-recs-03.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, updated by RFC 4748 on line 1641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1665. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 13, 2007) is 6244 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: Informational ---------------------------------------------------------------------------- ** 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) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-scanning-implications-01 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 Intended status: Informational J. Mohacsi 5 Expires: August 17, 2007 NIIF/HUNGARNET 6 February 13, 2007 8 Recommendations for Filtering ICMPv6 Messages in Firewalls 9 draft-ietf-v6ops-icmpv6-filtering-recs-03.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 August 17, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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. ICMPv6 is essential to the functioning of IPv6 but there 46 are a number of security risks associated with uncontrolled 47 forwarding of ICMPv6 messages. Filtering strategies designed for the 48 corresponding protocol, ICMP, in IPv4 networks are not directly 49 applicable, because these strategies are intended to accommodate a 50 useful auxiliary protocol that may not be required for correct 51 functioning. 53 This document provides some recommendations for ICMPv6 firewall 54 filter configuration that will allow propagation of ICMPv6 messages 55 that are needed to maintain the functioning of the network but drop 56 messages which are potential security risks. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6 62 2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6 63 2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 7 64 2.3. Network Topology and Address Scopes . . . . . . . . . . . 7 65 2.4. Role in Establishing and Maintaining Communication . . . . 8 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9 68 3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 10 70 3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 10 71 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10 72 4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10 73 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 74 4.2. Interaction of Link Local Messages with 75 Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12 76 4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13 77 4.3.1. Traffic that Must Not be Dropped . . . . . . . . . . . 13 78 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 14 79 4.3.3. Traffic that will be Dropped Anyway - No Special 80 Attention Needed . . . . . . . . . . . . . . . . . . . 14 81 4.3.4. Traffic for which a Policy Should be Defined . . . . . 15 82 4.3.5. Traffic which Should be Dropped Unless a Good Case 83 can be Made . . . . . . . . . . . . . . . . . . . . . 16 84 4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 17 85 4.4.1. Traffic that Must Not be Dropped . . . . . . . . . . . 17 86 4.4.2. Traffic that Normally Should Not be Dropped . . . . . 18 87 4.4.3. Traffic that will be Dropped Anyway - No Special 88 Attention Needed . . . . . . . . . . . . . . . . . . . 18 89 4.4.4. Traffic for which a Policy Should be Defined . . . . . 19 90 4.4.5. Traffic which Should be Dropped Unless a Good Case 91 can be Made . . . . . . . . . . . . . . . . . . . . . 19 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 93 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 96 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 97 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 22 98 A.1. Destination Unreachable Error Message . . . . . . . . . . 22 99 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 22 100 A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 23 101 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 23 102 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 24 103 A.6. Neighbor Solicitation and Neighbor Advertisement 104 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 A.7. Router Solicitation and Router Advertisement Messages . . 25 106 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 25 107 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 25 108 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 25 109 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 26 110 A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 26 111 A.13. Node Information Query and Reply . . . . . . . . . . . . . 26 112 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 26 113 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 27 114 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 28 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 116 Intellectual Property and Copyright Statements . . . . . . . . . . 36 118 1. Introduction 120 When a network supports IPv6 [RFC2460], the Internet Control Message 121 Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role 122 including being an essential component in establishing and 123 maintaining communications both at the interface level and for 124 sessions to remote nodes. This means that overly aggressive 125 filtering of ICMPv6 by firewalls may have a detrimental effect on the 126 establishment and maintenance of IPv6 communications. On the other 127 hand, allowing indiscriminate passage of all ICMPv6 messages can be a 128 major security risk. This document recommends a set of rules which 129 seek to balance effective IPv6 communication against the needs of 130 site security. 132 In a few cases the appropriate rules will depend on whether the 133 firewall is protecting 134 o an individual host, 135 o an end site where all ICMPv6 messages originate or terminate 136 within the site, or 137 o a transit site such as an Internet Service Provider's site where 138 some ICMPv6 messages will be passing through. 139 The document suggests alternative rules appropriate to each situation 140 where it is relevant. It also notes some situations where 141 alternative rules could be adopted according to the nature of the 142 work being carried out on the site and consequent security policies. 143 In general Internet Service Providers should not filter ICMPv6 144 messages transiting their sites so that all the necessary 145 communication elements are available to their customers to decide and 146 filter according to their policy. 148 Readers familiar with ICMPv6 can skip to the recommended filtering 149 rules in Section 4 and an example configuration script for Linux 150 netfilter in Appendix B. 152 ICMPv6 has a large number of functions defined in a number of sub- 153 protocols, and there are a correspondingly large number of messages 154 and options within these messages. The functions currently defined 155 fall into a number of categories: 156 Returning Error Messages 157 * Returning error messages to the source if a packet could not 158 be delivered. Four different error messages, each with a 159 number of sub-types are specified in [RFC4443]. 160 Connection Checking 161 * Simple monitoring of connectivity through echo requests and 162 responses used by the ping and traceroute utilities. The 163 Echo Request and Echo Response messages are specified in 164 [RFC4443]. 166 Discovery Functions 167 * Finding neighbors (both routers and hosts) connected to the 168 same link and determining their IP and link layer addresses. 169 These messages are also used to check the uniqueness of any 170 addresses that an interface proposes to use (Duplicate 171 Address Detection - DAD). Four messages - Neighbor 172 Solicitation (NS), Neighbor Advertisement (NA), Router 173 Solicitation (RS) and Router Advertisement (RA) - are 174 specified in [RFC2461]. 175 * Ensuring that neighbors remain reachable using the same IP 176 and link layer addresses after initial discovery (Neighbor 177 Unreachability Discovery - NUD) and notifying neighbors of 178 changes to link layer addresses. Uses NS and NA [RFC2461]. 179 * Finding routers and determining how to obtain IP addresses 180 to join the subnets supported by the routers. Uses RS and 181 RA [RFC2461]. 182 * If stateless auto-configuration of hosts is enabled, 183 communicating prefixes and other configuration information 184 (including the link Maximum Transfer Unit (MTU) and 185 suggested hop limit default) from routers to hosts. Uses RS 186 and RA [RFC2462]. 187 * Using SEcure Neighbor Discovery (SEND) to authenticate a 188 router attached to a link, the Certificate Path Solicitation 189 and Advertisement messages specified in [RFC3971] are used 190 by hosts to retrieve the trust chain between a trust anchor 191 and the router certificate from the router. 192 * Determining the Maximum Transmission Unit (MTU) along a 193 path. The Packet Too Big error message is essential to this 194 function [RFC1981]. 195 * Providing a means to discover the IPv6 addresses associated 196 with the link layer address of an interface (the inverse of 197 Neighbor Discovery, where the link layer address is 198 discovered given an IPv6 address). Two messages, Inverse 199 Neighbor Discovery Solicitation and Advertisement messages 200 are specified in [RFC3122]. 201 * Communicating which multicast groups have listeners on a 202 link to the multicast capable routers connected to the link. 203 Uses messages Multicast Listener Query, Multicast Listener 204 Report (two versions) and Multicast Listener Done (version 1 205 only) as specified in Multicast Listener Discovery MLDv1 206 [RFC2710] and MLDv2[RFC3810]. 207 * Discovering multicast routers attached to the local link. 208 Uses messages Multicast Router Advertisement, Multicast 209 Router Solicitation and Multicast Router Termination as 210 specified in Multicast Router Discovery [RFC4286]. 212 Reconfiguration Functions 213 * Redirecting packets to a more appropriate router on the 214 local link for the destination address or pointing out that 215 a destination is actually on the local link even if it is 216 not obvious from the IP address (where a link supports 217 multiple subnets). The Redirect message is specified in 218 [RFC2461]. 219 * Supporting renumbering of networks by allowing the prefixes 220 advertised by routers to be altered. Uses NS, NA, RS and RA 221 together with the Router Renumbering message specified in 222 [RFC2894]. 223 Mobile IPv6 Support 224 * Providing support for some aspects of Mobile IPv6 especially 225 dealing with the IPv6 Mobile Home Agent functionality 226 provided in routers and needed to support a Mobile node 227 homed on the link. The Home Agent Address Discovery Request 228 and Reply; and Mobile Prefix Solicitation and Advertisement 229 messages are specified in [RFC3775] 230 Experimental Extensions 231 * An experimental extension to ICMPv6 specifies the ICMP Node 232 Information Query and Response messages which can be used to 233 retrieve some basic information about nodes [RFC4620]. 234 * The SEAmless IP MOBility (seamoby) working group specified a 235 pair of experimental protocols which use an ICMPv6 message 236 specified in [RFC4065] to help in locating an access router 237 and moving the attachment point of a mobile node from one 238 access router to another. 240 Many of these messages should only be used in a link-local context 241 rather than end-to-end, and filters need to be concerned with the 242 type of addresses in ICMPv6 packets as well as the specific source 243 and destination addresses. 245 Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be 246 treated as an auxiliary function with packets that can be dropped in 247 most cases without damaging the functionality of the network. This 248 means that firewall filters for ICMPv6 have to be more carefully 249 configured than was the case for ICMP, where typically a small set of 250 blanket rules could be applied. 252 2. Classifying ICMPv6 Messages 254 2.1. Error and Informational ICMPv6 Messages 256 ICMPv6 messages contain an eight bit Type field interpreted as an 257 integer between 0 and 255. Messages with Type values less than or 258 equal to 127 are Error Messages. The remainder are Informational 259 Messages. In general terms, Error Messages with well-known 260 (standardized) Type values would normally be expected to be allowed 261 to be sent to or pass through firewalls, and may be essential to the 262 establishment and maintenance of communications (see Section 2.4) 263 whereas Informational Messages will generally be the subject of 264 policy rules, and those passing through end site firewalls can, in 265 many but by no means all cases, be dropped without damaging IPv6 266 communications. 268 2.2. Addressing of ICMPv6 270 ICMPv6 messages are sent using various kinds of source and 271 destination address types. The source address is usually a unicast 272 address, but during address autoconfiguration message exchanges, the 273 unspecified address :: is also used as a source address [RFC2462]. 275 Multicast Listener Discovery (MLD) Report and Done messages are sent 276 with a link-local address as the IPv6 source address, if a valid 277 address is available on the interface. If a valid link-local address 278 is not available (e.g., one has not been configured), the message is 279 sent with the unspecified address (::) as the IPv6 source address. 280 Subsequently the node will generate new MLD Report messages with 281 proper link-local source address once it has been configured 282 [RFC3590]. 284 The destination address can be either a well-known multicast address, 285 a generated multicast address such as the solicited-node multicast 286 address, an anycast address or a unicast address. While many ICMPv6 287 messages use multicast addresses most of the time, some also use 288 unicast addresses. For instance, the Router Advertisement messages 289 are sent to the all-nodes multicast address when unsolicited, but can 290 also be sent to a unicast address in response to a specific Router 291 Solicitation, although this is rarely seen in current 292 implementations. 294 2.3. Network Topology and Address Scopes 296 ICMPv6 messages can be classified according to whether they are meant 297 for end-to-end communications or communications within a link. There 298 are also messages that we can classify as 'any-to-end', which can be 299 sent from any point within a path back to the source; typically these 300 are used to announce an error in processing the original packet. For 301 instance, the address resolution messages are solely for local 302 communications [RFC2461], whereas the Destination Unreachable 303 messages are any-to-end in nature. Generally end-to-end and any-to- 304 end messages might be expected to pass through firewalls depending on 305 policies but local communications must not. 307 Local communications will use link-local addresses in many cases but 308 may also use global unicast addresses when configuring global 309 addresses, for example. Also some ICMPv6 messages used in local 310 communications may contravene the usual rules requiring compatible 311 scopes for source and destination addresses. 313 2.4. Role in Establishing and Maintaining Communication 315 Many ICMPv6 messages have a role in establishing or maintaining 316 communications to and from the firewall and such messages have to be 317 accepted by firewalls for local delivery. Generally a firewall will 318 also be acting as a router so that all the messages that might be 319 used in configuring a router interface need to be accepted and 320 generated. These messages should not transit through a firewall that 321 is also acting as a router as they are normally intended for use 322 within a link. 324 On the other hand, most ICMPv6 error messages traveling end-to-end or 325 any-to-end are essential to the establishment and maintenance of 326 communications. These messages must be passed through firewalls and 327 might also be sent to and from firewalls to assist with establishment 328 and maintenance of communications. For example the Packet Too Big 329 error message is needed to determine the MTU along a path both when a 330 communication session is established initially and later if the path 331 is rerouted during the session. 333 The remaining ICMPv6 messages which are not associated with 334 communication establishment or maintenance will normally be 335 legitimately attempting to pass through a firewall from inside to out 336 or vice versa, but in most cases decisions as to whether to allow 337 them to pass or not can be made on the basis of local policy without 338 interfering with IPv6 communications. 340 The filtering rules for the various message roles will generally be 341 different. 343 3. Security Considerations 345 This memo recommends filtering configurations for firewalls designed 346 to minimize the security vulnerabilities that can arise in using the 347 many different sub-protocols of ICMPv6 in support of IPv6 348 communication. 350 A major concern is that it is generally not possible to use IPsec or 351 other means to authenticate the sender and validate the contents of 352 many ICMPv6 messages. To a large extent this is because a site can 353 legitimately expect to receive certain error and other messages from 354 almost any location in the wider Internet, and these messages may 355 occur as a result of the first message sent to a destination. 356 Establishing security associations with all possible sources of 357 ICMPv6 messages is therefore impossible. 359 The inability to establish security associations to protect some 360 messages that are needed to establish and maintain communications 361 means that alternative means have to used to reduce the vulnerability 362 of sites to ICMPv6 based attacks. The most common way of doing this 363 is to establish strict filtering policies in site firewalls to limit 364 the unauthenticated ICMPv6 messages that can pass between the site 365 and the wider Internet. This makes control of ICMPv6 filtering a 366 delicate balance between protecting the site by dropping some of the 367 ICMPv6 traffic passing through the firewall and allowing enough of 368 the traffic through to make sure that efficient communication can be 369 established. 371 SEND [RFC3971] has been specified as a means to improve the security 372 of local ICMPv6 communications. SEND sidesteps security association 373 bootstrapping problems that would result if IPsec was used. SEND 374 affects only link local messages and does not limit the filtering 375 which firewalls can apply and its role in security is therefore not 376 discussed further in this document. 378 Firewalls will normally be used to monitor ICMPv6 to control the 379 following security concerns: 381 3.1. Denial of Service Attacks 383 ICMPv6 can be used to cause a Denial of Service(DoS) in a number of 384 ways, including simply sending excessive numbers of ICMPv6 packets to 385 destinations in the site and sending error messages which disrupt 386 established communications by causing sessions to be dropped. Also 387 if spurious communication establishment or maintenance messages can 388 be infiltrated on to a link it might be possible to invalidate 389 legitimate addresses or disable interfaces. 391 3.2. Probing 393 A major security consideration is preventing attackers probing the 394 site to determine the topology and identify hosts that might be 395 vulnerable to attack. Carefully crafted but, often, malformed 396 messages can be used to provoke ICMPv6 responses from hosts thereby 397 informing attackers of potential targets for future attacks. However 398 the very large address space of IPv6 makes probing a less effective 399 weapon as compared with IPv4 provided that addresses are not 400 allocated in an easily guessable fashion. This subject is explored 401 in more depth in [I-D.ietf-v6ops-scanning-implications]. 403 3.3. Redirection Attacks 405 A redirection attack could be used by a malicious sender to perform 406 man-in-the-middle attacks or divert packets either to a malicious 407 monitor or to cause DoS by blackholing the packets. These attacks 408 would normally have to be carried out locally on a link using the 409 Redirect message. Administrators need to decide if the improvement 410 in efficiency from using Redirect messages is worth the risk of 411 malicious use. Factors to consider include the physical security of 412 the link and the complexity of addressing on the link. For example, 413 on an open wireless link, redirection would be a serious hazard due 414 to the lack of physical security. On the other hand, with a wired 415 link in a secure building with complex addressing and redundant 416 routers, the efficiency gains might well outweigh the small risk of a 417 rogue node being connected. 419 3.4. Renumbering Attacks 421 Spurious Renumbering messages can lead to the disruption of a site. 422 Although Renumbering messages are required to be authenticated with 423 IPsec, so that it is difficult to carry out such attacks in practice, 424 they should not be allowed through a site boundary firewall. On the 425 other hand a site may employ multiple "layers" of firewall. In this 426 case Renumbering messages might be expected to be allowed to transit 427 interior firewalls but not pass across the outer boundary. 429 3.5. Problems Resulting from ICMPv6 Transparency 431 Because some ICMPv6 error packets need to be passed through a 432 firewall in both directions, malicious users can potentially use 433 these messages to communicate between inside and outside, bypassing 434 administrative inspection. For example it might be possible to carry 435 out a covert conversation through the payload of ICMPv6 error 436 messages or tunnel inappropriate encapsulated IP packets in ICMPv6 437 error messages. This problem can be alleviated by filtering ICMPv6 438 errors using a deep packet inspection mechanism to ensure that the 439 packet carried as a payload is associated with legitimate traffic to 440 or from the protected network. 442 4. Filtering Recommendations 444 When designing firewall filtering rules for ICMPv6, the rules can be 445 divided into two classes: 446 o Rules for ICMPv6 traffic transiting the firewall, with some minor 447 variations for 448 * firewalls protecting end sites or individual hosts, and 449 * firewalls protecting transit sites 450 o Rules for ICMPv6 directed to interfaces on the firewall 451 Firewalls integrated with an individual host ("end host firewalls") 452 can be treated as end site firewalls but the special considerations 453 discussed in Section 4.2 may be relevant because the firewall is not 454 a router. 456 This section suggests some common considerations which should be 457 borne in mind when designing filtering rules and then categorizes the 458 rules for each class. The categories are: 459 o Messages that must not be dropped: usually because establishment 460 or maintenance of communications will be prevented or severely 461 impacted. 462 o Messages that should not be dropped: administrators need to have a 463 very good reason for dropping this category 464 o Messages that may be dropped in firewall/routers, but these 465 messages may already be targeted to drop for other reasons, (e.g., 466 because they are using link-local addresses), or because the 467 protocol specification would cause the messages to be rejected if 468 they had passed through a router. Special considerations apply to 469 transit traffic if the firewall is not a router as discussed in 470 Section 4.2. 471 o Messages that administrators may or may not want to drop depending 472 on local policy. 473 o Messages that administrators should consider dropping (e.g., ICMP 474 node information name lookup queries) 476 More detailed analysis of each of the message types can be found in 477 Appendix A. 479 4.1. Common Considerations 481 Depending on the classification of the message to be filtered (see 482 Section 2), ICMPv6 messages should be filtered based on the ICMPv6 483 type of the message and the type (unicast, multicast, etc.) and scope 484 (link-local, global unicast, etc) of source and destination 485 addresses. In some cases it may be desirable to filter on the Code 486 field of ICMPv6 error messages. 488 Messages that can be authenticated on delivery, probably because they 489 contain an IPsec AH header or ESP header with authentication, may be 490 subject to less strict policies than messages that cannot be 491 authenticated. In the remainder of this section, we are generally 492 considering what should be configured for unauthenticated messages. 493 In many cases it is not realistic to expect more than a tiny fraction 494 of the messages to be authenticated. 496 Where messages are not essential to the establishment or maintenance 497 of communications, local policy can be used to determine whether a 498 message should be allowed or dropped. 500 Depending on the capabilities of the firewall being configured, it 501 may be possible for the firewall to maintain state about packets that 502 may result in error messages being returned or about ICMPv6 packets 503 (e.g., Echo Requests) that are expected to receive a specific 504 response. This state may allow the firewall to perform more precise 505 checks based on this state, and to apply limits on the number of 506 ICMPv6 packets accepted incoming or outgoing as a result of a packet 507 traveling in the opposite direction. The capabilities of firewalls 508 to perform such stateful packet inspection vary from model to model, 509 and it is not assumed that firewalls are uniformly capable in this 510 respect. 512 Firewalls which are able to perform deep packet inspection may be 513 able to check the header fields in the start of the errored packet 514 which is carried by ICMPv6 error messages. If the embedded packet 515 has a source address which does not match the destination of the 516 error message the packet can be dropped. This provides a partial 517 defense against some possible attacks on TCP that use spoofed ICMPv6 518 error messages, but the checks can also be carried out at the 519 destination. For further information on these attacks see 520 [I-D.ietf-tcpm-icmp-attacks]. 522 In general, the scopes of source and destination addresses of ICMPv6 523 messages should be matched, and packets with mismatched addresses 524 should be dropped if they attempt to transit a router. However some 525 of the address configuration messages carried locally on a link may 526 legitimately have mismatched addresses. Node implementations must 527 accept these messages delivered locally on a link and administrators 528 should be aware that they can exist. 530 ICMPv6 messages transiting firewalls inbound to a site may be treated 531 differently depending on whether they addressed to a node on the site 532 or to some other node. For end sites packets addressed to nodes not 533 on the site should be dropped but would generally be forwarded by 534 firewalls on transit sites. 536 4.2. Interaction of Link Local Messages with Firewall/Routers and 537 Firewall/Bridges 539 Firewalls can be implemented both as IP routers (firewall/routers) 540 and as link layer bridges (e.g., Ethernet bridges) that are 541 transparent to the IP layer although they will actually be inspecting 542 the IP packets as they pass through (firewall/bridges). 544 Many of the messages used for establishment and maintenance of 545 communications on the local link will be sent with link-local 546 addresses for at least one of their source and destination. Routers 547 conforming to the IPv6 standards will not forward these packets; 548 there is no need to configure additional rules to prevent these 549 packets traversing a firewall/router, although administrators may 550 wish to configure rules that would drop these packets for insurance 551 and as a means of monitoring for attacks. Also the specifications of 552 ICMPv6 messages intended for use only on the local link specify 553 various measures which would allow receivers to detect if the message 554 had passed through a router, including: 555 o Requiring that the hop limit in the IPv6 header is set to 255 on 556 transmission. Receivers verify that the hop limit is still 255, 557 to ensure that the packet has not passed through a router. 558 o Checking that the source address is a link-local unicast address. 559 Accordingly it is not essential to configure firewall/router rules to 560 drop out-of-specification packets of these types. If they have non- 561 link-local source and destination addresses, allowing them to 562 traverse the firewall/router, they would be rejected because of the 563 checks performed at the destination. Again, firewall administrators 564 may still wish to configure rules to log or drop such out-of- 565 specification packets. 567 For firewall/bridges, slightly different considerations apply. The 568 physical links on either side of the firewall/bridge are treated as a 569 single logical link for the purposes of IP. Hence the link local 570 messages used for discovery functions on the link must be allowed to 571 transit the transparent bridge. Administrators should assure for 572 themselves that routers and hosts attached to the link containing the 573 firewall/bridge are built to the correct specifications so that out- 574 of-specification packets are actually dropped as described in the 575 earlier part of this section. 577 An end host firewall can generally be thought of as a special case of 578 a firewall/bridge but the only link local messages that need to be 579 allowed through are those directed to the host's interface. 581 4.3. Recommendations for ICMPv6 Transit Traffic 583 This section recommends rules that should be applied to ICMPv6 584 traffic attempting to transit a firewall. 586 4.3.1. Traffic that Must Not be Dropped 588 Error messages that are essential to the establishment and 589 maintenance of communications: 591 o Destination Unreachable (Type 1) - All codes 592 o Packet Too Big (Type 2) 593 o Time Exceeded (Type 3) - Code 0 only 594 o Parameter Problem (Type 4) - Codes 1 and 2 only 595 Appendix A.4 suggests some more specific checks that could be 596 performed on Parameter Problem messages if a firewall has the 597 necessary packet inspection capabilities. 599 Connectivity checking messages: 600 o Echo Request (Type 128) 601 o Echo Response (Type 129) 602 For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be 603 possible, it is essential that the connectivity checking messages are 604 allowed through the firewall. It has been common practice in IPv4 605 networks to drop Echo Request messages in firewalls to minimize the 606 risk of scanning attacks on the protected network. As discussed in 607 Section 3.2, the risks from port scanning in an IPv6 network are much 608 less severe and it is not necessary to filter IPv6 Echo Request 609 messages. 611 4.3.2. Traffic that Normally Should Not be Dropped 613 Error messages other than those listed in Section 4.3.1 614 o Time Exceeded (Type 3) - Code 1 615 o Parameter Problem (Type 4) - Code 0 617 Mobile IPv6 messages that are needed to assist mobility: 618 o Home Agent Address Discovery Request (Type 144) 619 o Home Agent Address Discovery Reply (Type 145) 620 o Mobile Prefix Solicitation (Type 146) 621 o Mobile Prefix Advertisement(Type 147) 622 Administrators may wish to apply more selective rules as described in 623 Appendix A.14 depending on whether the site is catering for mobile 624 nodes which would normally be at home on the site and/or foreign 625 mobile nodes roaming onto the site. 627 4.3.3. Traffic that will be Dropped Anyway - No Special Attention 628 Needed 630 The messages listed in this section are all involved with local 631 management of nodes connected to the logical link on which they were 632 initially transmitted. All these messages should never be propagated 633 beyond the link on which they were initially transmitted. If the 634 firewall is a firewall/bridge rather than a firewall/router, these 635 messages should be allowed to transit the firewall as they would be 636 intended for establishing communications between the two physical 637 parts of the link that are bridged into a single logical link. 639 During normal operations these messages will have destination 640 addresses, mostly link local but in some cases global unicast 641 addresses, of interfaces on the local link. No special action is 642 needed to filter messages with link-local addresses in a firewall/ 643 router. As discussed in Section 4.1 these messages are specified so 644 that either the receiver is able to check that the message has not 645 passed through a router or it will be dropped at the first router it 646 encounters. 648 Administrators may also wish to consider providing rules in firewall/ 649 routers to catch illegal packets sent with hop limit = 1 to avoid 650 ICMPv6 Time Exceeded messages being generated for these packets. 652 Address Configuration and Router Selection messages (must be received 653 with hop limit = 255): 654 o Router Solicitation (Type 133) 655 o Router Advertisement (Type 134) 656 o Neighbor Solicitation (Type 135) 657 o Neighbor Advertisement (Type 136) 658 o Redirect (Type 137) 659 o Inverse Neighbor Discovery Solicitation (Type 141) 660 o Inverse Neighbor Discovery Advertisement (Type 142) 662 Link-local multicast receiver notification messages (must have link- 663 local source address): 664 o Listener Query (Type 130) 665 o Listener Report (Type 131) 666 o Listener Done (Type 132) 667 o Listener Report v2 (Type 143) 669 SEND Certificate Path notification messages (must be received with 670 hop limit = 255): 671 o Certificate Path Solicitation (Type 148) 672 o Certificate Path Advertisement (type 149) 674 Multicast Router Discovery messages (must have link-local source 675 address and hop limit = 1): 676 o Multicast Router Advertisement (Type 151) 677 o Multicast Router Solicitation (Type 152) 678 o Multicast Router Termination (Type 153) 680 4.3.4. Traffic for which a Policy Should be Defined 682 The message type that the experimental Seamoby protocols are using 683 will be expected to have to cross site boundaries in normal 684 operation. Transit sites must allow these messages to transit the 685 site. End site administrators should determine if they need to 686 support these experiments and otherwise messages of this type should 687 be dropped: 688 o Seamoby Experimental (Type 150) 690 Error messages not currently defined by IANA: 691 o Unallocated Error messages (Types 5-99 and 102-126, inclusive) 693 The base ICMPv6 specification suggests that error messages which are 694 not explicitly known to a node should be forwarded and passed to any 695 higher level protocol that might be able to interpret them. There is 696 a small risk that such messages could be used to provide a covert 697 channel or form part of a DoS attack. Administrators of end sites 698 should be aware of this and determine whether they wish to allow 699 these messages through the firewall. Firewalls protecting transit 700 sites must allow all types of error messages to transit the site but 701 may adopt different policies for error messages addressed to nodes 702 within the site. 704 All informational messages with types not explicitly assigned by 705 IANA, currently: 706 o Unallocated Informational messages (Types 154 - 199 inclusive and 707 202 - 254 inclusive). 709 Note that the base ICMPv6 specification requires that received 710 informational messages with unknown types must be silently discarded. 711 Transit sites must allow these messages to transit the site. End 712 site administrators can either adopt a policy of allowing all these 713 messages through the firewall, relying on end hosts to drop 714 unrecognized messages, or drop all such messages at the firewall. 715 Different policies could be adopted for inbound and outbound 716 messages. 718 If administrators choose to implement policies that drop currently 719 unallocated error or informational messages, it is important to 720 review the set of messages affected in case new message types are 721 assigned by IANA. 723 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made 725 Node Information enquiry messages should generally not be forwarded 726 across site boundaries. Some of these messages will be using non- 727 link-local unicast addresses so that they will not necessarily be 728 dropped by address scope limiting rules: 729 o Node Information Query (Type 139) 730 o Node Information Response (Type 140) 732 Router Renumbering messages should not be forwarded across site 733 boundaries. As originally specified, these messages may use a site 734 scope multicast address or a site local unicast address. They should 735 be caught by standard rules that are intended to stop any packet with 736 a multicast site scope or site local destination being forwarded 737 across a site boundary provided these are correctly configured. 738 Since site local addresses have now been deprecated it seems likely 739 that changes may be made to allow the use of unique local addresses 740 or global unicast addresses. Should this happen, it will be 741 essential to explicitly filter these messages at site boundaries. If 742 a site has internal as well as boundary firewalls, individual 743 policies should be established for the internal firewalls depending 744 on whether the site wishes to use Router Renumbering or not: 745 o Router Renumbering (Type 138) 747 Messages with types in the experimental allocations: 748 o Types 100, 101, 200 and 201. 750 Messages using the extension type numbers until such time as ICMPv6 751 needs to use such extensions: 752 o Types 127 and 255. 754 4.4. Recommendations for ICMPv6 Local Configuration Traffic 756 This section recommends filtering rules for ICMPv6 traffic addressed 757 to an interface on a firewall. For a small number of messages, the 758 desired behavior may differ between interfaces on the site or private 759 side of the firewall and the those on the public Internet side of the 760 firewall. 762 4.4.1. Traffic that Must Not be Dropped 764 Error messages that are essential to the establishment and 765 maintenance of communications: 766 o Destination Unreachable (Type 1) - All codes 767 o Packet Too Big (Type 2) 768 o Time Exceeded (Type 3) - Code 0 only 769 o Parameter Problem (Type 4) - Codes 1 and 2 only 771 Connectivity checking messages: 772 o Echo Request (Type 128) 773 o Echo Response (Type 129) 774 As discussed in Section 4.3.1, dropping connectivity checking 775 messages will prevent the firewall being the destination of a Teredo 776 tunnel and it is not considered necessary to disable connectivity 777 checking in IPv6 networks because port scanning is less of a security 778 risk. 780 There are a number of other sets of messages which play a role in 781 configuring the node and maintaining unicast and multicast 782 communications through the interfaces of a node. These messages must 783 not be dropped if the node is to successfully participate in an IPv6 784 network. The exception to this is the Redirect message for which an 785 explicit policy decision should be taken (see Section 4.4.4). 787 Address Configuration and Router Selection messages: 788 o Router Solicitation (Type 133) 789 o Router Advertisement (Type 134) 790 o Neighbor Solicitation (Type 135) 791 o Neighbor Advertisement (Type 136) 792 o Inverse Neighbor Discovery Solicitation (Type 141) 793 o Inverse Neighbor Discovery Advertisement (Type 142) 795 Link-local multicast receiver notification messages: 796 o Listener Query (Type 130) 797 o Listener Report (Type 131) 798 o Listener Done (Type 132) 799 o Listener Report v2 (Type 143) 801 SEND Certificate Path notification messages: 802 o Certificate Path Solicitation (Type 148) 803 o Certificate Path Advertisement (type 149) 805 Multicast Router Discovery messages : 806 o Multicast Router Advertisement (Type 151) 807 o Multicast Router Solicitation (Type 152) 808 o Multicast Router Termination (Type 153) 810 4.4.2. Traffic that Normally Should Not be Dropped 812 Error messages other than those listed in Section 4.4.1: 813 o Time Exceeded (Type 3) - Code 1 814 o Parameter Problem (Type 4) - Code 0 816 4.4.3. Traffic that will be Dropped Anyway - No Special Attention 817 Needed 819 Router Renumbering messages must be authenticated using IPsec, so it 820 is not essential to filter these messages even if they are not 821 allowed at the firewall/router: 822 o Router Renumbering (Type 138) 824 Mobile IPv6 messages that are needed to assist mobility: 825 o Home Agent Address Discovery Request (Type 144) 826 o Home Agent Address Discovery Reply (Type 145) 827 o Mobile Prefix Solicitation (Type 146) 828 o Mobile Prefix Advertisement(Type 147) 829 It may be desirable to drop these messages, especially on public 830 interfaces, if the firewall is not also providing mobile Home Agent 831 services, but they will be ignored otherwise. 833 The message used by the experimental Seamoby protocols may be dropped 834 but will be ignored if the service is not implemented: 835 o Seamoby Experimental (Type 150) 837 4.4.4. Traffic for which a Policy Should be Defined 839 Redirect messages provide a significant security risk and 840 administrators should take a case-by-case view of whether firewalls, 841 routers in general and other nodes should accept these messages: 842 o Redirect (Type 137) 843 Conformant nodes must provide configuration controls which allow 844 nodes to control their behavior with respect to Redirect messages so 845 that it should only be necessary to install specific filtering rules 846 under special circumstances, such as if Redirect messages are 847 accepted on private interfaces but not public ones. 849 If a node implements the experimental Node Information service, the 850 administrator needs to make an explicit decision as to whether the 851 node should respond to or accept Node Information messages on each 852 interface: 853 o Node Information Query (Type 139) 854 o Node Information Response (Type 140) 855 It may be possible to disable the service on the node if it is not 856 wanted in which case these messages will be ignored and no filtering 857 is necessary. 859 Error messages not currently defined by IANA: 860 o Unallocated Error messages (Types 5-99 and 102-126, inclusive) 862 The base ICMPv6 specification suggests that error messages which are 863 not explicitly known to a node should be forwarded and passed to any 864 higher level protocol that might be able to interpret them. There is 865 a small risk that such messages could be used to provide a covert 866 channel or form part of a DoS attack. Administrators should be aware 867 of this and determine whether they wish to allow these messages to be 868 sent to the firewall. 870 4.4.5. Traffic which Should be Dropped Unless a Good Case can be Made 872 Messages with types in the experimental allocations: 873 o Types 100, 101, 200 and 201. 875 Messages using the extension type numbers until such time as ICMPv6 876 needs to use such extensions: 878 o Types 127 and 255. 880 All informational messages with types not explicitly assigned by 881 IANA, currently: 882 o Types 154 - 199 inclusive and 202 - 254 inclusive. 884 Note that the base ICMPv6 specification requires that received 885 informational messages with unknown types must be silently discarded. 887 5. IANA Considerations 889 There are no IANA considerations defined in this document. 891 6. Acknowledgements 893 Pekka Savola created the original IPv6 Security Overview document 894 which contained suggestions for ICMPv6 filter setups. This 895 information has been incorporated into this document. He has also 896 provided important comments. Some analysis of the classification of 897 ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in 898 a draft relating to ICMPv6 and IKE. 900 The Netfilter configuration script in Appendix C was contributed by 901 Suresh Krishnan. 903 7. References 905 7.1. Normative References 907 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 908 for IP version 6", RFC 1981, August 1996. 910 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 911 (IPv6) Specification", RFC 2460, December 1998. 913 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 914 Discovery for IP Version 6 (IPv6)", RFC 2461, 915 December 1998. 917 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 918 Autoconfiguration", RFC 2462, December 1998. 920 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 921 Listener Discovery (MLD) for IPv6", RFC 2710, 922 October 1999. 924 [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, 925 August 2000. 927 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 928 Inverse Discovery Specification", RFC 3122, June 2001. 930 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 931 Listener Discovery (MLD) Protocol", RFC 3590, 932 September 2003. 934 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 935 in IPv6", RFC 3775, June 2004. 937 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 938 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 940 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 941 Neighbor Discovery (SEND)", RFC 3971, March 2005. 943 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 944 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 946 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 947 RFC 4286, December 2005. 949 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 950 Message Protocol (ICMPv6) for the Internet Protocol 951 Version 6 (IPv6) Specification", RFC 4443, March 2006. 953 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 954 Queries", RFC 4620, August 2006. 956 7.2. Informative References 958 [I-D.ietf-tcpm-icmp-attacks] 959 Gont, F., "ICMP attacks against TCP", 960 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 961 October 2006. 963 [I-D.ietf-v6ops-scanning-implications] 964 Chown, T., "IPv6 Implications for Network Scanning", 965 draft-ietf-v6ops-scanning-implications-01 (work in 966 progress), October 2006. 968 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 969 Stateless Address Autoconfiguration in IPv6", RFC 3041, 970 January 2001. 972 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 973 Network Address Translations (NATs)", RFC 4380, 974 February 2006. 976 [netfilter] 977 netfilter.org, "The netfilter.org project", Firewalling, 978 NAT and Packet Mangling for Linux , 2006, 979 . 981 Appendix A. Notes on Individual ICMPv6 Messages 983 A.1. Destination Unreachable Error Message 985 Destination Unreachable (Type 1) error messages [RFC4443] are sent 986 any-to-end between unicast addresses. The message can be generated 987 from any node which a packet traverses when the node is unable to 988 forward the packet for any reason except congestion. 990 Destination Unreachable messages are useful for debugging but are 991 also important to speed up cycling through possible addresses, as 992 they can avoid the need to wait through timeouts and hence can be 993 part of the process of establishing or maintaining communications. 994 It is a common practice in IPv4 to refrain from generating ICMP 995 Destination Unreachable messages in an attempt to hide the networking 996 topology and/or service structure. The same idea could be applied to 997 IPv6 but this can slow down connection if a host has multiple 998 addresses, some of which are deprecated, as they may be when using 999 privacy addresses [RFC3041]. If policy allows the generation of 1000 ICMPv6 Destination Unreachable messages, it is important that nodes 1001 provide the correct reason code, one of: no route to destination, 1002 administratively prohibited, beyond scope of source address, address 1003 unreachable, port unreachable, source address failed ingress/egress 1004 policy, reject route to destination. 1006 A.2. Packet Too Big Error Message 1008 Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end 1009 between unicast addresses. The message can be generated from any 1010 node which a packet traverses on the path when the node is unable to 1011 forward the packet because the packet is too large for the MTU of the 1012 next link. This message is vital to the correct functioning of Path 1013 MTU Discovery and hence is part of the establishment and maintenance 1014 of communications. Since routers are not allowed to fragment 1015 packets, informing sources of the need to fragment large packets is 1016 more important than for IPv4. If these messages are not generated 1017 when appropriate, hosts will continue to send packets which are too 1018 large or may assume that the route is congested. Effectively parts 1019 of the Internet will become inaccessible. 1021 If a network chooses to generate packets that are no larger than the 1022 Guaranteed Minimum MTU (1280 octets) and the site's links to the 1023 wider internet have corresponding MTUs, Packet Too Big messages 1024 should not be expected at the firewall and could be dropped if they 1025 arrive. 1027 A.3. Time Exceeded Error Message 1029 Time Exceeded (Type 3) error messages [RFC4443] can occur in two 1030 contexts: 1031 o Code 0 are generated at any node on the path being taken by the 1032 packet and sent, any-to-end between unicast addresses, if the Hop 1033 Limit value is decremented to zero at that node. 1034 o Code 1 messages are generated at the destination node and sent 1035 end-to-end between unicast addresses if all the segments of a 1036 fragmented message are not received within the reassembly time 1037 limit 1039 Code 0 messages can be needed as part of the establishment of 1040 communications if the path to a particular destination requires an 1041 unusually large number of hops. 1043 Code 1 messages will generally only result from congestion in the 1044 network and it is less essential to propagate these messages. 1046 A.4. Parameter Problem Error Message 1048 The great majority of Parameter Problem (Type 4) error messages will 1049 be generated by the destination node when processing destination 1050 options and other extension headers, and hence are sent end-to-end 1051 between unicast addresses. Exceptionally, these messages might be 1052 generated by any node on the path if a faulty or unrecognized hop-by- 1053 hop option is included or from any routing waypoint if there are 1054 faulty or unrecognized destination options associated with a Type 0 1055 routing header. In these cases the message will be sent any-to-end 1056 using unicast source and destination addresses. 1058 Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 1059 (Unrecognized IPv6 Option) messages may result if a node on the path 1060 (usually the destination) is unable to process a correctly formed 1061 extension header or option. If these messages are not returned to 1062 the source communication cannot be established, as the source would 1063 need to adapt its choice of options probably because the destination 1064 does not implement these capabilities. Hence these messages need to 1065 be generated and allowed for effective IPv6 communications. 1067 Code 0 (Erroneous Header) messages indicate a malformed extension 1068 header generally as a result of incorrectly generated packets. Hence 1069 these messages are useful for debugging purposes but it is unlikely 1070 that a node generating such packets could establish communications 1071 without human intervention to correct the problem. 1073 Code 2 messages, only, can be generated for packets with multicast 1074 destination addresses. 1076 It is possible that attackers may seek to probe or scan a network by 1077 deliberately generating packets with unknown extension headers or 1078 options, or faulty headers. If nodes generate Parameter Problem 1079 error messages in all cases and these outgoing messages are allowed 1080 through firewalls, the attacker may be able to identify active 1081 addresses that can be probed further or learn about the network 1082 topology. The vulnerability could be mitigated whilst helping to 1083 establish communications if the firewall was able to examine such 1084 error messages in depth and was configured to only allow Parameter 1085 Problem messages for headers which had been standardized but were not 1086 supported in the protected network. If the network administrator 1087 believes that all nodes in the network support all legitimate 1088 extension headers then it would be reasonable to drop all outgoing 1089 Parameter Problem messages. Note that this is not a major 1090 vulnerability in a well-designed IPv6 network because of the 1091 difficulties of performing scanning attacks (see Section 3.2). 1093 A.5. ICMPv6 Echo Request and Echo Response 1095 Echo Request (Type 128) uses unicast addresses as source addresses, 1096 but may be sent to any legal IPv6 address, including multicast and 1097 anycast addresses [RFC4443]. Echo Requests travel end-to-end. 1098 Similarly Echo Responses (Type 129) travel end-to-end and would have 1099 a unicast address as destination and either a unicast or anycast 1100 address as source. They are mainly used in combination for 1101 monitoring and debugging connectivity. Their only role in 1102 establishing communication is that they are required when verifying 1103 connectivity through Teredo tunnels[RFC4380]: Teredo tunneling to 1104 IPv6 nodes on the site will not be possible if these messages are 1105 blocked. It is not thought that there is a significant risk from 1106 scanning attacks on a well-designed IPv6 network (see Section 3.2) 1107 and so connectivity checks should be allowed by default. 1109 A.6. Neighbor Solicitation and Neighbor Advertisement Messages 1111 ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 1112 136) messages are essential to the establishment and maintenance of 1113 communications on the local link. Firewalls need to generate and 1114 accept these messages to allow them to establish and maintain 1115 interfaces onto their connected links. 1117 Note that the address scopes of the source and destination addresses 1118 on Neighbor Solicitations and Neighbor Advertisements may not match. 1119 The exact functions which these messages will be carrying out depends 1120 on the mechanism being used to configure IPv6 addresses on the link 1121 (Stateless, Stateful or Static configuration). 1123 A.7. Router Solicitation and Router Advertisement Messages 1125 ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134) 1126 messages are essential to the establishment and maintenance of 1127 communications on the local link. Firewalls need to generate (since 1128 the firewall will generally be behaving as a router) and accept these 1129 messages to allow them to establish and maintain interfaces onto 1130 their connected links. 1132 A.8. Redirect Messages 1134 ICMPv6 Redirect Messages(Type 137) are used on the local link to 1135 indicate that nodes are actually link-local and communications need 1136 not go via a router, or to indicate a more appropriate first hop 1137 router. Although they can be used to make communications more 1138 efficient, they are not essential to the establishment of 1139 communications and may be a security vulnerability, particularly if a 1140 link is not physically secured. Conformant nodes are required to 1141 provide configuration controls which suppress the generation of 1142 Redirect messages and allow them to be ignored on reception. Using 1143 Redirect messages on, for example, a wireless link without link level 1144 encryption/authentication is particularly hazardous because the link 1145 is open to eavesdropping and packet injection. 1147 A.9. SEND Certificate Path Messages 1149 SEND [RFC3971] uses two messages (Certificate Path Solicitation and 1150 Advertisement - Types 148 and 149) sent from nodes to supposed 1151 routers on the same local link to obtain a certificate path which 1152 will allow the node to authenticate the router's claim to provide 1153 routing services for certain prefixes. If a link connected to a 1154 firewall/router is using SEND, the firewall must be able to exchange 1155 these messages with nodes on the link that will use its routing 1156 services. 1158 A.10. Multicast Listener Discovery Messages 1160 Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener 1161 Query, Listener Report and Listener Done - Types 130, 131 and 132) 1162 and version 2 [RFC3810] (Listener Query and Listener Report Version 2 1163 - Types 130 and 143) messages are sent on the local link to 1164 communicate between multicast capable routers and nodes which wish to 1165 join or leave specific multicast groups. Firewalls need to be able 1166 to generate Listener messages in order to establish communications 1167 and may generate all the messages if they also provide multicast 1168 routing services. 1170 A.11. Multicast Router Discovery Messages 1172 Multicast Router Discovery [RFC4286] (Router Advertisement, Router 1173 Solicitation and Router Termination - Types 151, 152 and 153) 1174 messages are sent by nodes on the local link to discover multicast 1175 capable routers on the link, and by multicast capable routers to 1176 notify other nodes of their existence or change of state. Firewalls 1177 which also act as multicast routers need to process these messages on 1178 their interfaces. 1180 A.12. Router Renumbering Messages 1182 ICMPv6 Router Renumbering (Type 138) command messages can be received 1183 and results messages sent by routers to change the prefixes which 1184 they advertise as part of Stateless Address Configuration [RFC2461], 1185 [RFC2462]. These messages are sent end-to-end to either the all- 1186 routers multicast address (site or local scope) or specific unicast 1187 addresses from a unicast address. 1189 Router Renumbering messages are required to be protected by IPsec 1190 authentication since they could be readily misused by attackers to 1191 disrupt or divert site communications. Renumbering messages should 1192 generally be confined to sites for this reason. 1194 A.13. Node Information Query and Reply 1196 ICMPv6 Node Information Query and Reply (Type 139 and 140) messages 1197 defined in [RFC4620] are sent end-to-end between unicast addresses, 1198 and can also be sent to link-local multicast addresses. They can, in 1199 theory, be sent from any node to any other but it would generally not 1200 be desirable for nodes outside the local site to be able to send 1201 queries to nodes within the site. Also these messages are not 1202 required to be authenticated. 1204 A.14. Mobile IPv6 Messages 1206 Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to 1207 support mobile operations: Home Agent Address Discovery Request, Home 1208 Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP 1209 Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. 1210 These messages are sent end-to-end between unicast addresses of a 1211 mobile node and its home agent. They must be expected to be sent 1212 from outside a site and must traverse site-boundary firewalls to 1213 reach the home agent in order for Mobile IPv6 to function. The two 1214 Mobile prefix messages should be protected by the use of IPsec 1215 authentication. 1216 o If the site provides home agents for mobile nodes, the firewall 1217 must allow incoming Home Agent Address Discovery Request and 1218 Mobile Prefix Solicitation messages, and outgoing Home Agent 1219 Address Discovery Reply and ICMP Mobile Prefix Advertisement 1220 messages. It may be desirable to limit the destination addresses 1221 for the incoming messages to links that are known to support home 1222 agents. 1223 o If the site is prepared to host roaming mobile nodes, the firewall 1224 must allow outgoing Home Agent Address Discovery Request and 1225 Mobile Prefix Solicitation messages, and incoming Home Agent 1226 Address Discovery Reply and ICMP Mobile Prefix Advertisement 1227 messages. 1228 o Administrators may find it desirable to prevent static nodes which 1229 are normally resident on the site from behaving as mobile nodes by 1230 dropping Mobile IPv6 messages from these nodes. 1232 A.15. Unused and Experimental Messages 1234 A large number of ICMPv6 Type values are currently unused. These 1235 values have not had a specific function registered with IANA. This 1236 section describes how to treat messages which attempt to use these 1237 Type values in a way of which the network administrator (and hence 1238 the firewall) is not aware. 1240 [RFC4443] defines a number of experimental Type values for ICMPv6 1241 Error and Informational messages, which could be used in site 1242 specific ways. These values should be treated in the same way as 1243 values which are not registered by IANA unless the network 1244 administrator is explicitly made aware of usage. 1246 The codes reserved for future extension of the ICMPv6 Type space 1247 should currently be dropped as this functionality is as yet 1248 undefined. 1250 Any ICMPv6 Informational messages of which the firewall is not aware 1251 should not be allowed to pass through the firewall or be accepted for 1252 local delivery on any of its interfaces. 1254 Any incoming ICMPv6 Error messages of which the firewall is not aware 1255 may be allowed through the firewall in line with the specification in 1256 [RFC4443], which requests delivery of unknown error messages to 1257 higher layer protocol processes. However, administrators may wish to 1258 disallow forwarding of these incoming messages as a potential 1259 security risk. Unknown outgoing Error messages should be dropped as 1260 the administrator should be aware of all messages that could be 1261 generated on the site. 1263 Also the Seamoby working group has had an ICMPv6 message (Type 150) 1264 allocated for experimental use in two protocols. This message is 1265 sent end-to-end and may need to pass through firewalls on sites that 1266 are supporting the experimental protocols. 1268 Appendix B. Example Script to Configure ICMPv6 Firewall Rules 1270 This appendix contains an example script to implement most of the 1271 rules suggested in this document when using the Netfilter packet 1272 filtering system for Linux [netfilter]. When used with IPv6, the 1273 'ip6tables' command is used to configure packet filtering rules for 1274 the Netfilter system. The script is targeted at a simple enterprise 1275 site that may or may not support Mobile IPv6. 1277 #!/bin/bash 1278 # Set of prefixes on the trusted ("inner") side of the firewall 1279 export INNER_PREFIXES="2001:DB8:85::/60" 1280 # Set of hosts providing services so that they can be made pingable 1281 export PINGABLE_HOSTS="2001:DB8:85::/64" 1282 # Configuration option: Change this to 1 if errors allowed only for 1283 # existing sessions 1284 export STATE_ENABLED=0 1285 # Configuration option: Change this to 1 if messages to/from link 1286 # local addresses should be filtered. 1287 # Do not use this if the firewall is a bridge. 1288 # Optional for firewalls that are routers. 1289 export FILTER_LINK_LOCAL_ADDRS=0 1290 # Configuration option: Change this to 0 if the site does not support 1291 # Mobile IPv6 Home Agents - see Appendix A.14 1292 export HOME_AGENTS_PRESENT=1 1293 # Configuration option: Change this to 0 if the site does not support 1294 # Mobile IPv6 mobile nodes being present on the site - 1295 # see Appendix A.14 1296 export MOBILE_NODES_PRESENT=1 1298 ip6tables -N icmpv6-filter 1299 ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter 1301 # Match scope of src and dest else deny 1302 # This capability is not provided for in base ip6tables functionality 1303 # An extension (agr) exists which may support it. 1304 #@TODO@ 1305 # ECHO REQUESTS AND RESPONSES 1306 # =========================== 1308 # Allow outbound echo requests from prefixes which belong to the site 1309 for inner_prefix in $INNER_PREFIXES 1310 do 1311 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1312 --icmpv6-type echo-request -j ACCEPT 1313 done 1315 # Allow inbound echo requests towards only predetermined hosts 1316 for pingable_host in $PINGABLE_HOSTS 1317 do 1318 ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ 1319 --icmpv6-type echo-request -j ACCEPT 1320 done 1322 if [ "$STATE_ENABLED" -eq "1" ] 1323 then 1324 # Allow incoming and outgoing echo reply messages 1325 # only for existing sessions 1326 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1327 --state ESTABLISHED,RELATED --icmpv6-type \ 1328 echo-reply -j ACCEPT 1329 else 1330 # Allow both incoming and outgoing echo replies 1331 for pingable_host in $PINGABLE_HOSTS 1332 do 1333 # Outgoing echo replies from pingable hosts 1334 ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ 1335 --icmpv6-type echo-reply -j ACCEPT 1336 done 1337 # Incoming echo replies to prefixes which belong to the site 1338 for inner_prefix in $INNER_PREFIXES 1339 do 1340 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1341 --icmpv6-type echo-reply -j ACCEPT 1342 done 1343 fi 1345 # Deny icmps to/from link local addresses 1346 # If the firewall is a router: 1347 # These rules should be redundant as routers should not forward 1348 # link local addresses but to be sure... 1349 # DO NOT ENABLE these rules if the firewall is a bridge 1350 if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ] 1351 then 1352 ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP 1353 ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP 1354 fi 1356 # Drop echo replies which have a multicast address as a 1357 # destination 1358 ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ 1359 --icmpv6-type echo-reply -j DROP 1361 # DESTINATION UNREACHABLE ERROR MESSAGES 1362 # ====================================== 1364 if [ "$STATE_ENABLED" -eq "1" ] 1365 then 1366 # Allow incoming destination unreachable messages 1367 # only for existing sessions 1368 for inner_prefix in $INNER_PREFIXES 1369 do 1370 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1371 -d $inner_prefix \ 1372 --state ESTABLISHED,RELATED --icmpv6-type \ 1373 destination-unreachable -j ACCEPT 1374 done 1375 else 1376 # Allow incoming destination unreachable messages 1377 for inner_prefix in $INNER_PREFIXES 1378 do 1379 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1380 --icmpv6-type destination-unreachable -j ACCEPT 1381 done 1382 fi 1384 # Allow outgoing destination unreachable messages 1385 for inner_prefix in $INNER_PREFIXES 1386 do 1387 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1388 --icmpv6-type destination-unreachable -j ACCEPT 1389 done 1391 # PACKET TOO BIG ERROR MESSAGES 1392 # ============================= 1394 if [ "$STATE_ENABLED" -eq "1" ] 1395 then 1396 # Allow incoming Packet Too Big messages 1397 # only for existing sessions 1398 for inner_prefix in $INNER_PREFIXES 1399 do 1400 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1401 -d $inner_prefix \ 1402 --state ESTABLISHED,RELATED \ 1403 --icmpv6-type packet-too-big \ 1404 -j ACCEPT 1405 done 1406 else 1407 # Allow incoming Packet Too Big messages 1408 for inner_prefix in $INNER_PREFIXES 1409 do 1410 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1411 --icmpv6-type packet-too-big -j ACCEPT 1412 done 1413 fi 1415 # Allow outgoing Packet Too Big messages 1416 for inner_prefix in $INNER_PREFIXES 1417 do 1418 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1419 --icmpv6-type packet-too-big -j ACCEPT 1420 done 1422 # TIME EXCEEDED ERROR MESSAGES 1423 # ============================ 1425 if [ "$STATE_ENABLED" -eq "1" ] 1426 then 1427 # Allow incoming time exceeded code 0 messages 1428 # only for existing sessions 1429 for inner_prefix in $INNER_PREFIXES 1430 do 1431 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1432 -d $inner_prefix \ 1433 --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ 1434 -j ACCEPT 1435 done 1436 else 1437 # Allow incoming time exceeded code 0 messages 1438 for inner_prefix in $INNER_PREFIXES 1439 do 1440 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1441 --icmpv6-type ttl-zero-during-transit -j ACCEPT 1442 done 1443 fi 1445 #@POLICY@ 1446 # Allow incoming time exceeded code 1 messages 1447 for inner_prefix in $INNER_PREFIXES 1448 do 1449 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1450 --icmpv6-type ttl-zero-during-reassembly -j ACCEPT 1451 done 1453 # Allow outgoing time exceeded code 0 messages 1454 for inner_prefix in $INNER_PREFIXES 1455 do 1456 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1457 --icmpv6-type ttl-zero-during-transit -j ACCEPT 1458 done 1460 #@POLICY@ 1461 # Allow outgoing time exceeded code 1 messages 1462 for inner_prefix in $INNER_PREFIXES 1463 do 1464 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1465 --icmpv6-type ttl-zero-during-reassembly -j ACCEPT 1466 done 1468 # PARAMETER PROBLEM ERROR MESSAGES 1469 # ================================ 1471 if [ "$STATE_ENABLED" -eq "1" ] 1472 then 1473 # Allow incoming parameter problem code 1 and 2 messages 1474 # for an existing session 1475 for inner_prefix in $INNER_PREFIXES 1476 do 1477 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1478 -d $inner_prefix \ 1479 --state ESTABLISHED,RELATED --icmpv6-type \ 1480 unknown-header-type \ 1481 -j ACCEPT 1482 ip6tables -A icmpv6-filter -m state -p icmpv6 \ 1483 -d $inner_prefix \ 1484 --state ESTABLISHED,RELATED \ 1485 --icmpv6-type unknown-option \ 1486 -j ACCEPT 1487 done 1488 fi 1490 # Allow outgoing parameter problem code 1 and code 2 messages 1491 for inner_prefix in $INNER_PREFIXES 1492 do 1493 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1494 --icmpv6-type unknown-header-type -j ACCEPT 1495 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1496 --icmpv6-type unknown-option -j ACCEPT 1497 done 1499 #@POLICY@ 1500 # Allow incoming and outgoing parameter 1501 # problem code 0 messages 1502 for inner_prefix in $INNER_PREFIXES 1503 do 1504 ip6tables -A icmpv6-filter -p icmpv6 \ 1505 --icmpv6-type bad-header \ 1506 -j ACCEPT 1507 done 1509 # NEIGHBOR DISCOVERY MESSAGES 1510 # =========================== 1512 # Drop NS/NA messages both incoming and outgoing 1513 ip6tables -A icmpv6-filter -p icmpv6 \ 1514 --icmpv6-type neighbor-solicitation -j DROP 1515 ip6tables -A icmpv6-filter -p icmpv6 \ 1516 --icmpv6-type neighbor-advertisement -j DROP 1518 # Drop RS/RA messages both incoming and outgoing 1519 ip6tables -A icmpv6-filter -p icmpv6 \ 1520 --icmpv6-type router-solicitation -j DROP 1521 ip6tables -A icmpv6-filter -p icmpv6 \ 1522 --icmpv6-type router-advertisement -j DROP 1524 # Drop Redirect messages both incoming and outgoing 1525 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP 1527 # MLD MESSAGES 1528 # ============ 1530 # Drop incoming and outgoing 1531 # Multicast Listener queries (MLDv1 and MLDv2) 1532 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP 1534 # Drop incoming and outgoing Multicast Listener reports (MLDv1) 1535 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP 1537 # Drop incoming and outgoing Multicast Listener Done messages (MLDv1) 1538 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP 1540 # Drop incoming and outgoing Multicast Listener reports (MLDv2) 1541 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP 1543 # ROUTER RENUMBERING MESSAGES 1544 # =========================== 1546 # Drop router renumbering messages 1547 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP 1549 # NODE INFORMATION QUERIES 1550 # ======================== 1552 # Drop node information queries (139) and replies (140) 1553 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP 1554 ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP 1556 # MOBILE IPv6 MESSAGES 1557 # ==================== 1559 # If there are mobile ipv6 home agents present on the 1560 # trusted side allow 1561 if [ "$HOME_AGENTS_PRESENT" -eq "1" ] 1562 then 1563 for inner_prefix in $INNER_PREFIXES 1564 do 1565 #incoming Home Agent address discovery request 1566 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1567 --icmpv6-type 144 -j ACCEPT 1568 #outgoing Home Agent address discovery reply 1569 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1570 --icmpv6-type 145 -j ACCEPT 1571 #incoming Mobile prefix solicitation 1572 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1573 --icmpv6-type 146 -j ACCEPT 1574 #outgoing Mobile prefix advertisement 1575 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1576 --icmpv6-type 147 -j ACCEPT 1577 done 1578 fi 1580 # If there are roaming mobile nodes present on the 1581 # trusted side allow 1582 if [ "$MOBILE_NODES_PRESENT" -eq "1" ] 1583 then 1584 for inner_prefix in $INNER_PREFIXES 1585 do 1586 #outgoing Home Agent address discovery request 1587 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1588 --icmpv6-type 144 -j ACCEPT 1589 #incoming Home Agent address discovery reply 1590 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1591 --icmpv6-type 145 -j ACCEPT 1592 #outgoing Mobile prefix solicitation 1593 ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ 1594 --icmpv6-type 146 -j ACCEPT 1595 #incoming Mobile prefix advertisement 1596 ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ 1597 --icmpv6-type 147 -j ACCEPT 1598 done 1599 fi 1601 # DROP EVERYTHING ELSE 1602 # ==================== 1604 ip6tables -A icmpv6-filter -p icmpv6 -j DROP 1606 Example Netfilter Configuration Script for ICMPv6 Filtering 1608 Authors' Addresses 1610 Elwyn B. Davies 1611 Consultant 1612 Soham, Cambs 1613 UK 1615 Phone: +44 7889 488 335 1616 Email: elwynd@dial.pipex.com 1618 Janos Mohacsi 1619 NIIF/HUNGARNET 1620 Victor Hugo u. 18-22 1621 Budapest, H-1132 1622 Hungary 1624 Phone: +36 1 4503070 1625 Email: mohacsi@niif.hu 1627 Full Copyright Statement 1629 Copyright (C) The IETF Trust (2007). 1631 This document is subject to the rights, licenses and restrictions 1632 contained in BCP 78, and except as set forth therein, the authors 1633 retain all their rights. 1635 This document and the information contained herein are provided on an 1636 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1637 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1638 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1639 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1640 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1641 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1643 Intellectual Property 1645 The IETF takes no position regarding the validity or scope of any 1646 Intellectual Property Rights or other rights that might be claimed to 1647 pertain to the implementation or use of the technology described in 1648 this document or the extent to which any license under such rights 1649 might or might not be available; nor does it represent that it has 1650 made any independent effort to identify any such rights. Information 1651 on the procedures with respect to rights in RFC documents can be 1652 found in BCP 78 and BCP 79. 1654 Copies of IPR disclosures made to the IETF Secretariat and any 1655 assurances of licenses to be made available, or the result of an 1656 attempt made to obtain a general license or permission for the use of 1657 such proprietary rights by implementers or users of this 1658 specification can be obtained from the IETF on-line IPR repository at 1659 http://www.ietf.org/ipr. 1661 The IETF invites any interested party to bring to its attention any 1662 copyrights, patents or patent applications, or other proprietary 1663 rights that may cover technology that may be required to implement 1664 this standard. Please address the information to the IETF at 1665 ietf-ipr@ietf.org. 1667 Acknowledgment 1669 Funding for the RFC Editor function is provided by the IETF 1670 Administrative Support Activity (IASA).