idnits 2.17.1 draft-davies-v6ops-icmpv6-filtering-bcp-00.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 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 860. ** 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 == Line 548 has weird spacing: '...eration and f...' -- 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 (July 11, 2005) is 6857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-ipngwg-icmp-name-lookups-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipngwg-icmp-name-lookups (ref. 'I-D.ietf-ipngwg-icmp-name-lookups') == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-06 -- 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 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 5 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 Expires: January 12, 2006 J. Mohacsi 5 NIIF/HUNGARNET 6 July 11, 2005 8 Best Current Practice for Filtering ICMPv6 Messages in Firewalls 9 draft-davies-v6ops-icmpv6-filtering-bcp-00.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 January 12, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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, and it is desirable to configure site 47 firewalls to intercept inappropriate usages of ICMPv6 which might 48 allow an attacker outside a site to probe or compromise the site 49 network. On the other hand, compared with IPv4 and the corresponding 50 protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather 51 than a useful auxiliary. Hence too aggressive filtering of ICMPv6 52 messages can be detrimental to the establishment of IPv6 53 communications. This means that effective filtering of ICMPv6 54 requires a more complex configuration than was needed for ICMP. This 55 document provides some recommendations for ICMPv6 firewall filter 56 configuration that will allow propagation of ICMPv6 messages that are 57 needed to maintain the functioning of the network but drop messages 58 which are potential security risks. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . 5 64 2.1 Error and Informational ICMPv6 Messages . . . . . . . . . 5 65 2.2 Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6 66 2.3 Network Topology and Address Scopes . . . . . . . . . . . 6 67 2.4 Role in Establishing Communication . . . . . . . . . . . . 6 68 3. Security Concerns for ICMPv6 Controllable by Firewall 69 Configuration . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 7 71 3.2 Probing . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.3 Redirection Attacks . . . . . . . . . . . . . . . . . . . 8 73 3.4 Renumbering Attacks . . . . . . . . . . . . . . . . . . . 8 74 4. Filtering Recommendations . . . . . . . . . . . . . . . . . 8 75 4.1 Common Considerations . . . . . . . . . . . . . . . . . . 8 76 4.2 ICMPv6 Echo Request and Echo Response . . . . . . . . . . 9 77 4.3 Destination Unreachable Error Message . . . . . . . . . . 10 78 4.4 Packet Too Big Error Message . . . . . . . . . . . . . . . 10 79 4.5 Time Exceeded Error Message . . . . . . . . . . . . . . . 11 80 4.6 Parameter Problem Error Message . . . . . . . . . . . . . 12 81 4.7 Neighbor Solicitation and Neighbor Advertisement 82 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.8 Router Solicitation and Router Advertisement Messages . . 14 84 4.9 Redirect Messages . . . . . . . . . . . . . . . . . . . . 14 85 4.10 Multicast Listener Discovery Messages . . . . . . . . . 14 86 4.11 Router Renumbering Messages . . . . . . . . . . . . . . 15 87 4.12 Node Information Query and Reply . . . . . . . . . . . . 15 88 4.13 Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . 16 89 4.14 Unused and Experimental Messages . . . . . . . . . . . . 16 90 4.15 Problems Resulting from ICMPv6 Transparency . . . . . . 17 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.1 Normative References . . . . . . . . . . . . . . . . . . . 17 96 8.2 Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 98 Intellectual Property and Copyright Statements . . . . . . . 20 100 1. Introduction 102 When a network supports IPv6 [RFC2460], the Internet Control Message 103 Protocol version 6 (ICMPv6) [RFC2463], [I-D.ietf-ipngwg-icmp-v3] 104 plays a fundamental role including being an essential component in 105 establishing communications both at the interface level and for 106 sessions to remote nodes. This means that overly aggressive 107 filtering of ICMPv6 may have a detrimental effect on the 108 establishment of IPv6 communications. On the other hand, allowing 109 indiscriminate passage of all ICMPv6 messages can be a major security 110 risk. This document recommends a set of rules which seek to balance 111 effective IPv6 communication against the needs of site security. 112 [Author's note: The new versions of RFC2461, RFC2462 and RFC2463 have 113 been taken into account in this draft, but not necessarily referenced 114 as yet.] 116 ICMPv6 has a large number of functions defined in a number of sub- 117 protocols, and there are a correspondingly large number of messages 118 and options within these messages. The functions currently defined 119 are: 120 o Returning error messages to the source if a packet could not be 121 delivered. Four different error messages are specified in 122 [RFC2463]. 123 o Simple monitoring of connectivity through echo requests and 124 responses used by the ping and traceroute utilities. The Echo 125 Request and Echo Response messages are specified in [RFC2463]. 126 o Finding neighbors (both routers and hosts) connected to the same 127 link and determining their IP and link layer addresses. These 128 messages are also used to check the uniqueness of any addresses 129 that an interface proposes to use (Duplicate Address Detection - 130 DAD)) - DAD can be turned off if the network administrator 131 believes that the configuration method used is bound to generate 132 unique addresses. Four messages - Neighbor Solicitation (NS), 133 Neighbor Advertisement (NA), Router Solicitation (RS) and Router 134 Advertisement (RA) - are specified in [RFC2461]. 135 o Ensuring that neighbors remain reachable using the same IP and 136 link layer addresses after initial discovery (Neighbor 137 Unreachability Discovery - NUD) and notifying neighbors of changes 138 to link layer addresses. Uses NS and NA [RFC2461]. 139 o Finding routers and determining how to obtain IP addresses to join 140 the subnets supported by the routers. Uses RS and RA [RFC2461]. 141 o If stateless auto-configuration of hosts is enabled, communicating 142 prefixes and other configuration information (including the link 143 MTU and suggested hop count default) from routers to hosts. Uses 144 RS and RA [RFC2462]. 145 o Redirecting packets to a more appropriate router on the local link 146 for the destination address or pointing out that a destination is 147 actually on the local link even if it is not obvious from the IP 148 address (where a link supports multiple subnets). This facility 149 could be used by a malicious sender to divert packets and nodes 150 should provide configuration options to prevent the messages being 151 sent by routers and acted on by hosts. The redirect message is 152 specified in [RFC2461]. 153 o Supporting renumbering of networks by allowing the prefixes 154 advertised by routers to be altered. Uses NS, NA, RS and RA 155 together with the Router Renumbering message specified in 156 [RFC2894]. 157 o Determining the Maximum Transmission Unit (MTU) along a path. The 158 Packet Too Big error message is essential to this function 159 [RFC1981]. 160 o Communicating which multicast groups have listeners on a link to 161 the multicast capable routers connected to the link. Uses 162 messages Multicast Listener Query, Multicast Listener Report (two 163 versions) and Multicast Listener Done (version 1 only) as 164 specified in Multicast Listener Discovery MLDv1 [RFC2710] and 165 MLDv2[RFC3810]. 166 o Providing support for some aspects of Mobile IPv6 especially 167 dealing with the IPv6 Mobile Home Agent functionality provided in 168 routers and needed to support a Mobile node homed on the link. 169 The Home Agent Address Discovery Request and reply; and Mobile 170 Prefix Solicitation and Advertisement messages are specified in 171 [RFC3775] 172 o ICMPv6 can provide some basic information about nodes to 173 interested parties [I-D.ietf-ipngwg-icmp-name-lookups]. 175 Many of these messages should only be used in a link-local context 176 rather than end-to-end, and filters need to be concerned with the 177 type of addresses in ICMPv6 packets as well as the specific source 178 and destination addresses. 180 Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be 181 treated as an auxiliary function with packets that can be dropped in 182 most cases without damaging the functionality of the network. This 183 means that firewall filters for ICMPv6 have to be more carefully 184 configured than was the case for ICMP, where typically a small set of 185 blanket rules could be applied. 187 2. Classifying ICMPv6 Messages 189 2.1 Error and Informational ICMPv6 Messages 191 ICMPv6 messages contain an eight bit Type field interpreted as an 192 integer between 0 and 255. Messages with Type values less than or 193 equal to 127 are Error Messages. The remainder are Informational 194 Messages. In general terms, Error Messages with well-known 195 (standardized) Type values would normally be expected to be allowed 196 to be sent to or pass through firewalls, and may be essential to the 197 establishment of communications (see Section 2.4 whereas 198 Informational Messages will generally be the subject of policy rules, 199 and those passing through firewalls can, in many but by no means all 200 cases, be dropped without damaging IPv6 communications. 202 2.2 Addressing of ICMPv6 204 ICMPv6 messages are sent using various kinds of source and 205 destination address types. The source address is usually a unicast 206 address, but during address autoconfiguration message exchanges, the 207 unspecified address :: is also used as a source address [RFC2462]. 208 The destination address can be either a well-known multicast address, 209 a generated multicast address such as the solicited-node multicast 210 address, an anycast address or a unicast address. While many ICMPv6 211 messages use multicast addresses most of the time, some also use 212 unicast addresses sometimes. For instance, the Router Advertisement 213 messages are sent to the all-nodes multicast address when 214 unsolicited, but can also be sent to a unicast address in response to 215 a specific Router Solicitation. 217 2.3 Network Topology and Address Scopes 219 ICMPv6 messages can be classified according to whether they are meant 220 for end-to-end communications or communications within a link. There 221 are also messages that we can classify as 'any-to-end', which can be 222 sent from any point within a path back to the source; typically these 223 are used to announce an error in processing the original packet. For 224 instance, the address resolution messages are solely for local 225 communications [RFC2461], whereas the Destination Unreachable 226 messages are any-to-end in nature. Generally end-to-end and any-to- 227 end messages might be expected to pass through firewalls depending on 228 policies but local communications must not 230 Local communications will use link-local addresses in many cases but 231 may also use global unicast addresses for example when configuring 232 global addresses. Also some ICMPv6 messages in local communications 233 may contravene the usual rules requiring compatible scopes for source 234 and destination addresses. 236 2.4 Role in Establishing Communication 238 Many ICMPv6 messages have a role in establishing communications to 239 and from the firewall and such messages have to be accepted by 240 firewalls for local delivery. Which messages need to be accepted 241 depend on whether the firewall is also acting as a router. This type 242 of communication establishment messages should not be passed through 243 a firewall as they are normally intended for use within a link. 245 On the other hand, some ICMPv6 error messages, which are sent either 246 end-to-end or any-to-end. are essential to the establishment of 247 communications. For example the Packet Too Big error message is 248 needed to establish the MTU along a path. These messages must be 249 passed through firewalls and might also be sent to and from firewalls 250 to assist with establishment of communications. 252 The remaining ICMPv6 messages which are not associated with 253 communication establishment will normally be legitimately attempting 254 to pass through a firewall from inside to out or vice versa, but 255 decisions as to whether to allow them to pass or not can be made on 256 the basis of local policy without interfering with the establishment 257 of IPv6 communications. 259 The filtering rules for the various message roles will generally be 260 different. 262 3. Security Concerns for ICMPv6 Controllable by Firewall Configuration 264 A major concern with most ICMPv6 messages is that it is generally not 265 possible to use IPsec or other means to authenticate the sender and 266 validate the contents of some ICMPv6 messages. To a large extent 267 this is because a site can legitimately expect to receive certain 268 error and other messages from almost any location in the wider 269 Internet, and these messages may occur as a result of the first 270 message sent to a destination. Establishing security associations 271 with all possible sources of ICMPv6 messages is therefore impossible. 273 The inability to establish security associations to protect some 274 messages that are needed to establish communications means that 275 alternative means have to used to reduce the vulnerability of sites 276 to ICMPv6 based attacks. The most common way of doing this is to 277 establish strict filtering policies in site firewalls to limit the 278 unauthenticated ICMPv6 messages that can pass between the site and 279 the wider Internet. This makes control of ICMPv6 filtering a 280 delicate balance between protecting the site by dropping most of the 281 ICMPv6 traffic passing through the firewall and allowing enough of 282 the traffic through to make sure that efficient communication can be 283 established. 285 Firewalls will normally be concerned to monitor ICMPv6 to control the 286 following security concerns: 288 3.1 Denial of Service Attacks 290 ICMPv6 can be used to cause a Denial of Service(DoS) in a number of 291 ways, including simply sending excessive number sof ICMPv6 packets to 292 destinations in the site and sending error messages which disrupt 293 established commnuications by causing sessions to be dropped. Also 294 if spurious communication establishment messages can be passed on to 295 link it might be possible to disrupt established communications. 297 3.2 Probing 299 A major security consideration is preventing attackers probing the 300 site to determine the topology and identify hosts that might be 301 vulnerable to attack. Carefully crafted but, often, malformed 302 messages can be used to provoke ICMPv6 responses from hosts thereby 303 informing attackers of potential targets for future attacks. 305 3.3 Redirection Attacks 307 These attacks would normally have to be carried out locally on a 308 link, but it is important to ensure that Redirect messages are not 309 allowed through the firewall. Redirection could be used simply for 310 DoS as well as endeavouring to redirect traffic to a compromised 311 node. 313 3.4 Renumbering Attacks 315 Spurious Renumbering messages could lead to the disruption of a site 316 and should not be allowed through a firewall in general. 318 4. Filtering Recommendations 320 4.1 Common Considerations 322 Depending on the classification of the message to be fitered (see 323 Section 2), ICMPv6 messages should be filtered based on the ICMPv6 324 type of the message and the type (unicast, multicast, etc.) and scope 325 (link-local, global unicast, etc) of source and destination 326 addresses. In some cases, where deeper packet inspection is 327 possible, it may be desirable to filter on, for example, the Code 328 field of ICMPv6 error messages. 330 Messages that are authenticated by means of an IPsec AH or ESP header 331 may be subject to less strict policies than unauthenticated messages. 332 In the remainder of this section, we are generally considering what 333 should be configured for unauthenticated messages. In many cases it 334 is not realistic to expect more than a tiny fraction of the messages 335 to be authenticated. 337 Where messages are not essential to the establishment of 338 communications, local policy can be used to determine whether a 339 message should be allowed or dropped. 341 Depending on the capabilities of the firewall being configured, it 342 may be possible for the firewall to maintain state about packets that 343 may result in error messages being returned or about ICMPv6 packets 344 (e.g., Echo Requests) that are expected to receive a specific 345 response. This state may allow the firewall to perform more precise 346 checks based on this state, and to apply limits on the number of 347 ICMPv6 packets accepted incoming or outgoing as a result of a packet 348 travelling in the opposite direction. The capabilities of firewalls 349 to perform such stateful packet inspection vary from model to model, 350 and it is not assumed that firewalls are uniformly capable in this 351 respect. 353 Unless otherwise specified, the scopes of source and destination 354 addresses of ICMPv6 messages should be matched, and packets with 355 mismatched addresses should be dropped. 357 4.2 ICMPv6 Echo Request and Echo Response 359 Echo Request (Type 128) uses unicast addresses as source addresses, 360 but may be sent to any legal IPv6 address, even multicast and anycast 361 addresses [RFC2463]. Echo Requests travel end-to-end but never have 362 a role in establishing communications. Similarly Echo Responses 363 (Type 129) travel end-to-end and would have a unicast address as 364 destination and either a unicast or anycast address as source. They 365 are used in combination for monitoring and debugging connectivity. 366 o It is desirable that Echo Requests are allowed to pass outwards 367 through firewalls. 368 o Echo Requests may be allowed to pass inwards only towards selected 369 hosts which are providing well-known services to the rest of the 370 Internet. 371 o If possible, it is desirable to maintain state about Echo Requests 372 passing through the firewall which can be used to limit the 373 possible corresponding Echo Responses that may be returned. 374 o If policy requires, the possible source addresses for Echo 375 Requests can be limited to certain machines, but in any case the 376 source address should be an address owned by the site. 377 o If state is maintained, only one response should be allowed 378 corresponding to each request. Echo Responses should only be 379 passed outwards from machines to which Echo Requests can be sent, 380 and should only be passed inwards towards hosts which are allowed 381 to originate Echo Requests. 382 o Both Echo Requets and Echo Responses should be rate limited in 383 line with [RFC2463] and, if possible, the overall incoming rate 384 from all sources destined for any given host should be limited to 385 a value that the host is known to be able to handle. 386 o Messages with link local addresses in either source or destination 387 should be dropped, except for messages coming from the inside 388 directed to the firewall itself. 390 o Echo Response messages must have a unicast address as destination 391 and may have a unicast, or anycast address as source. 393 4.3 Destination Unreachable Error Message 395 Destination Unreachable (Type 1) error messages [RFC2463] are sent 396 any-to-end between unicast addresses. The message can be generated 397 from any node which a packet traverses on the path when the node is 398 unable to forward the packet for any reason except congestion. 399 o Incoming ICMPv6 Destination Unreachable messages may be passed 400 through the firewall for debugging purposes where they relate to 401 outgoing IPv6 packets that have previously been sent out through 402 the firewall. For preference, this should be implemented by means 403 of a stateful packet inspection mechanism. These messages should 404 not be sent if the outgoing message was sent to a multicast 405 address: if possible any error message that is returned from a 406 multicast address should be discarded. 407 o Outgoing ICMPv6 Destination Unreachable messages may be generated 408 and passed out for all packets that have been allowed through the 409 firewall. 410 o At most one Destination Unreachable message should be passed 411 through the firewall in response to each packet that might result 412 in an error if the firewall is able to manage this. 414 Destination Unreachable messages are useful for debugging but are 415 also important to speed up cycling through possible addresses, as 416 they can avoid the need to wait through timeouts and hence can be 417 part of the process of establishing communications. It is a common 418 practice in IPv4, to refrain from generating ICMP Destination 419 Unreachable messages to attempt to hide the networking topology 420 and/or service structure. The same rule can be applied to IPv6 but 421 this can slow down connection if a host has multiple addresses some 422 of which are deprecated as when using privacy addresses [RFC3041]. 423 If policy allows the generation of ICMPv6 Destination Unreachable 424 messages, it is important to provide the correct reason code, one of: 425 no route to destination, administratively prohibited, beyond scope of 426 source address, address unreachable, port unreachable, source address 427 failed ingress/egress policy, reject route to destination. 429 4.4 Packet Too Big Error Message 431 Packet Too Big (Type 2) error messages [RFC2463] are sent any-to-end 432 between unicast addresses. The message can be generated from any 433 node which a packet traverses on the path when the node is unable to 434 forward the packet because the packet is too large for the MTU of the 435 next link. This message is vital to the correct functioning of Path 436 MTU Discovery and hence is part of the establishment of 437 communications. Since routers are not allowed to fragment packets, 438 informing sources of the need to fragment large packets is more 439 important than for IPv4. If these messages are not generated when 440 appropriate, hosts will continue to send packets which are too large 441 or may assume that the route is congested. Effectively parts of the 442 Internet will become inaccessible. 443 o It is essential to allow incoming ICMPv6 Packet Too Big messages 444 as responses to outgoing IPv6 packets so that Path MTU Discovery 445 will operate properly. 446 o If possible, stateful packet inspection should be used to limit 447 incoming Packet Too Big messages to legitimate responses to 448 outgoing packets and to limit error messages to at most one per 449 outgoing packet. Note that this message can be geenrated as a 450 result of messages sent to multicast addresses. 451 o It is essential to allow outgoing ICMPv6 Packet Too Big messages 452 to be generated and passed through the firewall if the MTU is 453 smaller on any link anywhere within the network protected by the 454 firewall than the MTU on the link between the firewall and the ISP 455 which connects the site to the rest of the Internet. In transit 456 networks, it will be necessary to pass Packet Too Big messages 457 through the network. 459 If a network chooses to generate packets that are no larger than the 460 Guaranteed Minimum MTU (1280 octets) and the site's links to the 461 wider internet have corresponding MTUs, Packet Too Big messages 462 should not be expected at the firewall and can be dropped if they 463 arrive. 465 4.5 Time Exceeded Error Message 467 Time Exceeded (Type 3) error messages [RFC2463] can occur in two 468 contexts: 469 o Code 0 are generated at any node on the path being taken by the 470 packet and sent any-to-end between unicast addresses if the Hop 471 Limit value is decremented to zero at any point on the path. 472 o Code 1 messages are generated at the destination node and sent 473 end-to-end between unicast addresses if all the segments of a 474 fragmented message are not received within the reassembly time 475 limit 477 Code 0 messages can be needed as part of the establishment of 478 communications if the path to a particular destination requires an 479 unusually large number of hops. It is therefore essential to 480 generate and forward Code 0 Time Exceeded messages for effective 481 operation of IPv6 networks. 483 Code 1 messages will generally only result from congestion in the 484 network and it is less essential to propagate these messages. 486 o It is essential to allow incoming ICMPv6 Time Exceeded Code 0 487 messages to be able discover destination systems not reachable due 488 to a low Hop Limit value in the outgoing packets, so that the Hop 489 Limit can be selectively increased for these packets. 490 o Incoming ICMPv6 Time Exceeded Code 1 messages may be enabled by 491 policy if desired. 492 o If possible, stateful packet inspection should be used to limit 493 incoming Time Exceeded messages to legitimate responses to 494 outgoing packets and to limit error messages to at most one per 495 outgoing packet. 496 o It is essential to generate and allow outgoing ICMPv6 Time 497 Exceeded Code 0 messages to ensure that communications can be 498 established to sites which generate packets with small hop limits 499 or are traversing very long paths. 500 o Generation of outgoing ICMPv6 Time Exceeded Code 1 messages and 501 allowing them through the firewall may be enabled by policy if 502 desired. 504 4.6 Parameter Problem Error Message 506 The great majority of Parameter Problem (Type 4) error messages will 507 be generated by the destination node when processing destination 508 options and other extension headers, and hence are sent end-to-end 509 between unicast addresses. Exceptionally, these messages might be 510 generated by any node on the path if a faulty or unrecognized hop-by- 511 hop option is included or from any routing waypoint if there are 512 faulty or unrecognized destination options associated with a Type 0 513 routing header. In these cases the message will be sent any-to-end 514 using unicast source and destination addresses. 516 Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 517 (Unrecognized IPv6 Option) messages may result if a node on the path 518 (usually the destination) is unable to process a correctly formed 519 extension header or option. If these messages are not returned to 520 the source communication cannot be established, as the source would 521 need to adapt its choice of options probably because the destination 522 does not implement these capabilities. Hence these messages need to 523 be generated and allowed for effective IPv6 communications. 525 Code 0 (Erroneous Header) messages indicate a malformed extension 526 header generally as a result of incorrectly generated packets. Hence 527 these messages are useful for debugging purposes but it is unlikely 528 that a node generating such packets could establish communications 529 without human intervention to correct the problem. 531 Code 2 messages, only, can be generated for packets with multicast 532 destinatio addresses. 534 o It is essential that incoming ICMPv6 Parameter Problem messages 535 with Code 1 or Code 2 are allowed as responses to outgoing IPv6 536 packets to allow establishment of communications to sites which do 537 not support unusual options. 538 o Incoming ICMPv6 Parameter Problem messages with Code 1 may be 539 allowed by policy if desired. 540 o If possible, stateful packet inspection should be used to limit 541 incoming Parameter Problem messages to legitimate responses to 542 outgoing packets and to limit error messages to at most one per 543 outgoing packet. 544 o It is essential to generate and allow outgoing ICMPv6 Parameter 545 Problem Code 1 and Code 2 messages to ensure that communications 546 can be established if it is known that nodes are not able to 547 support certain options or extension headers. Some risks 548 associated with blanket generation and forwarding of responses of 549 this type are discussed at the end of this section. 550 o Generation of outgoing ICMPv6 Parameter Problem Code 0 messages 551 and allowing them through the firewall may be enabled by policy if 552 desired. 554 It is possible that attackers may seek to probe or scan a network by 555 deliberately generating packets with unknown extension headers or 556 options, or faulty headers. If nodes generate Parameter Problem 557 error messages in all cases and these outgoing messages are allowed 558 through firewalls, the attacker may be able to identify active 559 addresses that can be probed further or learn about the network 560 topology. The vulnerability could be mitigated whilst helping to 561 establish communications if the firewall was able to examine such 562 error messages in depth and was configured to only allow Parameter 563 Problem messages for headers which had been standardized but were not 564 supported in the protected network. If the network administrator 565 believes that all nodes in the network support all legitimate 566 extension headers then it would be reasonable to drop all outgoing 567 Parameter Problem messages. 569 4.7 Neighbor Solicitation and Neighbor Advertisement Messages 571 ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 572 136) messages are essential to establishment of communications on the 573 local link. Firewalls need to generate and accept these messages to 574 allow them to establish interfaces onto their connected links. 575 o Firewalls must accept and generate ICMPv6 neighbor Solicitation 576 and Neighbor Advertisement messages for local delivery on all 577 interfaces as described in [RFC2461] and [RFC2462]. 578 o Firewalls must not allow any Neighbor Solicitation or Neighbor 579 Advertisement messages to pass through the firewall, either 580 incoming or outgoing. 582 Note that the address scopes of the source and destination addresses 583 on Neighbor Solicitations and Neighbor Advertisements may not match. 584 The exact functions which these messages will be carrying out depends 585 on the mechanism being used to configure IPv6 addresses on the link 586 (Stateless, Stateful or Static configuration). 588 4.8 Router Solicitation and Router Advertisement Messages 590 ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134) 591 messages are essential to establishment of communications on the 592 local link. Firewalls need to generate (since the firewall will 593 generally be behaving as a router) and accept these messages to allow 594 them to establish interfaces onto their connected links. 595 o Firewalls must accept and generate ICMPv6 Router Solicitation and 596 Router Advertisement messages for local delivery on all interfaces 597 as described in [RFC2461] and [RFC2462]. 598 o Firewalls must not allow any Router Solicitation or Router 599 Advertisement messages to pass through the firewall, either 600 incoming or outgoing. 602 4.9 Redirect Messages 604 ICMPv6 Redirect Messages(Type 137) are used on the local link to 605 indicate that nodes are actually link-local and communications need 606 not go via a router, or to indicate a more appropriate first hop 607 router. Although they can be used to make communications more 608 efficient, they are not essential to the establishment of 609 communications and may be a security vulnerability. 610 o Firewalls should generally implement a policy of not generating or 611 accepting ICMPv6 Redirect messages for local delivery on any 612 interface. 613 o Firewalls must not allow ICMPv6 Redirect messages to pass through 614 the firewall, either incoming or outgoing. 616 4.10 Multicast Listener Discovery Messages 618 Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener 619 Query, Listener Report and Listener Done - Types 130, 131 and 132) 620 and version 2 [RFC3810] (Listener Query and Listener Report Version 2 621 - Types 130 and 143) messages are sent on the local link to 622 communicate between multicast capable routers and nodes which wish to 623 join or leave specific multicast groups. 624 o Firewalls must be able to generate ICMPv6 Listener Report messages 625 on their interfaces for Solicited Node Multicast Groups as part of 626 the address configuration process. They may also have to generate 627 ICMPv6 Listener Report version 2 messages and Listener Done 628 messages for the same reason [Author's Note: The current versions 629 of the standards are not specific about this.]. 631 o Firewalls which are also acting as multicast routers need to be 632 able to receive both types of ICMPv6 Listener Report and Listener 633 Done messages, and generate ICMPv6 Listener Query messages on 634 relevant interfaces. 635 o Firewalls must not allow any of the MLD messages to pass throigh 636 the firewall, wither incoming or outgoing. 638 4.11 Router Renumbering Messages 640 ICMPv6 Router Renumbering (Type 138) command messages can be received 641 and results messages sent by routers to change the prefixes which 642 they advertise as part of Stateless Address Configuration [RFC2461], 643 [RFC2462]. These messages are sent end-to-end to either the all- 644 routers multicast address (site or local scope) or specific unicast 645 addresses from a unicast address. 647 Router Renumbering messages are required to be protected by IPsec 648 authentication since they could be readily misused by attackers to 649 disrupt or divert site communications. Renumbering messages should 650 be confined to sites for this reason. 651 o Firewalls which are acting as routers on sites which implement 652 router renumbering functionality must accept for local delivery 653 and generate appropriate ICMPv6 Router Renumbering messages on 654 inward facing interfaces. Such messages must be protected by 655 IPsec authentication as described in [RFC2894]. 656 o Firewalls must not accept ICMPv6 Router Renumbering messages on 657 outward facing interfaces. 658 o Firewalls must not allow any Router Renumbering messages to pass 659 through the firewall, either incoming or outgoing. 661 4.12 Node Information Query and Reply 663 ICMPv6 Node Information Query and Reply (Type 139 and 140) messages 664 are sent end-to-end between unicast addresses. They can, in theory, 665 be sent from any node to any other but it would generally not be 666 desirable for nodes outside the local site to be able to send queries 667 to nodes within the site. Also these messages are not required to be 668 authenticated. 669 o Firewall policy may allow ICMPv6 Node Information Query messages 670 to be accepted for local delivery on inward facing interfaces and 671 allow generation of corresponding Node Information reply messages 672 on these interfaces. 673 o Firewalls must not accept or generate ICMPv6 Node Information 674 messages on outward facing interfaces. 675 o Firewalls must not allow any ICMPv6 Node Information messages to 676 pass through the firewall, either incoming or outgoing. 678 4.13 Mobile IPv6 Messages 680 Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to 681 support mobile operations: Home Agent Address Discovery Request, Home 682 Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP 683 Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. 684 These messages are sent end-to-end between unicast addresses of a 685 mobile node and its home agent. They must be expected to be sent 686 from outside a site. The two Mobile prefix messages should be 687 protected by the use of IPsec authentication. 688 o If the site provides home agents for mobile nodes, the firewall 689 must allow incoming Home Agent Address Discovery Request and 690 Mobile Prefix Solicitation messages., and outgoing Home Agent 691 Address Discovery Reply and ICMP Mobile Prefix Advertisement 692 messages. It may be desirable to limit the destination addresses 693 for the incoming messages to links that are known to support home 694 agents. 695 o If the site is prepared to host roaming mobile nodes, the firewall 696 must allow outgoing Home Agent Address Discovery Request and 697 Mobile Prefix Solicitation messages., and incoming Home Agent 698 Address Discovery Reply and ICMP Mobile Prefix Advertisement 699 messages. Administrators may find it desirable to prevent fixed 700 nodes which are normally resident on the site from behaving as 701 mobile nodes by dropping outgoing messages from these nodes. 702 o If possible, stateful packet inspection should be used to match 703 incoming and outgoing messages. 705 4.14 Unused and Experimental Messages 707 A large number of ICMPv6 Type values are currently unused. These 708 values have not had a specific function registered with IANA. This 709 section describes how to treat messages which attempt to use these 710 Type values in a way of which the network administrator (and hence 711 the firewall) is not aware. 713 [I-D.ietf-ipngwg-icmp-v3] defines a number of experimental Type 714 values for ICMPv6 Error and Informational messages, which could be 715 used in site specific ways. These values should be treated in the 716 same way as values which are not registered by IANA unless the 717 network administrator is explicitly made aware of usage. 719 Any ICMPv6 Informational messages of which the firewall is not aware 720 should not be allowed to pass through the firewall or be accepted for 721 local delivery on any of its interfaces. 723 Any incoming ICMPv6 Error messages of which the firewall is not aware 724 may be allowed through the firewall in line with the specification in 725 [RFC2463], which requests delivery of unknown error messages to 726 higher layer protocol processes. However, administrators may wish to 727 disallow forwarding of these incoming messages as a potential 728 security risk. Unknown outgoing Error messages must be dropped as 729 the administrator should be aware of all messages that could be 730 generated on the site. 732 4.15 Problems Resulting from ICMPv6 Transparency 734 Because some ICMPv6 error packets need to be passed through a 735 firewall in both directions. This means that the ICMPv6 error 736 packets can be exchanged between inside and outside without any 737 filtering. 739 Using this feature, malicious users can communicate between the 740 inside and outside of a firewall bypassing the administrator's 741 inspection (proxy, firewall etc.). For example in might be possible 742 to carry out a covert conversation through the payload of ICMPv6 743 error messages or tunnel inappropriate encapsulated IP packets in 744 ICMPv6 error messages. This problem can be alleviated by filtering 745 ICMPv6 errors using a stateful packet inspection mechanism to ensure 746 that the packet carried as a payload is associated with legitimate 747 traffic to or from the protected network. 749 5. IANA Considerations 751 There are no IANA considerations defined in this document. 753 6. Acknowledgements 755 Pekka Savola created the original IPv6 Security Overview document 756 which contained suggestions for ICMPv6 filter setups. This 757 information has been incorporated into this document. Some analysis 758 of the classification of ICMPv6 messages and the term 'any-to-end' 759 were used by Jari Arkko in a draft relating to ICMPv6 and IKE. 761 7. Security Considerations 763 This memo recommends filtering configurations for firewalls designed 764 to minimize the security vulnerabilities that can arise in using the 765 many different sub-protocols of ICMPv6 in support of IPv6 766 communication. 768 8. References 770 8.1 Normative References 772 [I-D.ietf-ipngwg-icmp-name-lookups] 773 Crawford, M. and B. Haberman, "IPv6 Node Information 774 Queries", draft-ietf-ipngwg-icmp-name-lookups-11 (work in 775 progress), May 2005. 777 [I-D.ietf-ipngwg-icmp-v3] 778 Conta, A., "Internet Control Message Protocol (ICMPv6)for 779 the Internet Protocol Version 6 (IPv6) Specification", 780 draft-ietf-ipngwg-icmp-v3-06 (work in progress), 781 November 2004. 783 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 784 for IP version 6", RFC 1981, August 1996. 786 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 787 (IPv6) Specification", RFC 2460, December 1998. 789 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 790 Discovery for IP Version 6 (IPv6)", RFC 2461, 791 December 1998. 793 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 794 Autoconfiguration", RFC 2462, December 1998. 796 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 797 Protocol (ICMPv6) for the Internet Protocol Version 6 798 (IPv6) Specification", RFC 2463, December 1998. 800 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 801 Listener Discovery (MLD) for IPv6", RFC 2710, 802 October 1999. 804 [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, 805 August 2000. 807 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 808 in IPv6", RFC 3775, June 2004. 810 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 811 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 813 8.2 Informative References 815 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 816 Stateless Address Autoconfiguration in IPv6", RFC 3041, 817 January 2001. 819 Authors' Addresses 821 Elwyn B. Davies 822 Consultant 823 Soham, Cambs 824 UK 826 Phone: +44 7889 488 335 827 Email: elwynd@dial.pipex.com 829 Janos Mohacsi 830 NIIF/HUNGARNET 831 Victor Hugo u. 18-22 832 Budapest, H-1132 833 Hungary 835 Phone: +36 1 4503070 836 Email: mohacsi@niif.hu 838 Intellectual Property Statement 840 The IETF takes no position regarding the validity or scope of any 841 Intellectual Property Rights or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; nor does it represent that it has 845 made any independent effort to identify any such rights. Information 846 on the procedures with respect to rights in RFC documents can be 847 found in BCP 78 and BCP 79. 849 Copies of IPR disclosures made to the IETF Secretariat and any 850 assurances of licenses to be made available, or the result of an 851 attempt made to obtain a general license or permission for the use of 852 such proprietary rights by implementers or users of this 853 specification can be obtained from the IETF on-line IPR repository at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at 860 ietf-ipr@ietf.org. 862 Disclaimer of Validity 864 This document and the information contained herein are provided on an 865 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 866 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 867 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 868 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 869 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 870 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 872 Copyright Statement 874 Copyright (C) The Internet Society (2005). This document is subject 875 to the rights, licenses and restrictions contained in BCP 78, and 876 except as set forth therein, the authors retain all their rights. 878 Acknowledgment 880 Funding for the RFC Editor function is currently provided by the 881 Internet Society.