idnits 2.17.1 draft-arkko-icmpv6-ike-effects-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 3, 2003) is 7717 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) == Unused Reference: '3' is defined on line 606, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 628, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 633, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 637, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 645, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (ref. '1') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '7') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '8') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (ref. '10') (Obsoleted by RFC 4941) == Outdated reference: A later version (-01) exists of draft-ietf-send-ipsec-00 == Outdated reference: A later version (-04) exists of draft-ietf-send-psreq-00 == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-01 Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Expires: September 1, 2003 March 3, 2003 6 Effects of ICMPv6 on IKE 7 draft-arkko-icmpv6-ike-effects-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on September 1, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The ICMPv6 protocol provides many functions which in IPv4 were either 39 non-existent or provided by lower layers. IPv6 architecture also 40 makes it possible to secure all IP packets using IPsec, even ICMPv6 41 messages. IPsec architecture has a Security Policy Database that 42 specifies which traffic is protected, and how. It turns out that the 43 specification of policies in the presence of ICMPv6 traffic is hard, 44 particularly with ICMPv6 packets related to Neighbor Discovery. 45 Sound looking policies may easily lead to loops: The establishment of 46 security requires Neighbor Discovery messages which can not be sent 47 since security has not been established yet. The purpose of this 48 draft is to inform system administrators and IPsec implementors in 49 which manner they can handle the ICMPv6 messages. Common 50 understanding of the way that these messages are handled is also 51 necessary for interoperability, in case vendors hardcode such rules 52 in to products. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Neighbor Discovery and ICMPv6 Tasks . . . . . . . . . . . . 5 59 3.1 Path MTU Discovery . . . . . . . . . . . . . . . . . . . 5 60 3.2 Error Notification . . . . . . . . . . . . . . . . . . . 5 61 3.3 Informational Notifications . . . . . . . . . . . . . . 5 62 3.4 Router and Prefix Discovery . . . . . . . . . . . . . . 5 63 3.5 Address Autoconfiguration . . . . . . . . . . . . . . . 6 64 3.6 Duplicate Address Detection . . . . . . . . . . . . . . 6 65 3.7 Address Resolution . . . . . . . . . . . . . . . . . . . 6 66 3.8 Neighbor Reachability Detection . . . . . . . . . . . . 6 67 3.9 Redirect . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.10 Router Renumbering . . . . . . . . . . . . . . . . . . . 7 69 4. Factors Affecting the Policy Rules . . . . . . . . . . . . . 8 70 4.1 Nature of the Addresses . . . . . . . . . . . . . . . . 8 71 4.2 Network Topology . . . . . . . . . . . . . . . . . . . . 8 72 4.3 Role in Estaliblishing Communications . . . . . . . . . 9 73 4.4 Protecting the Infrastructure versus Communications . .10 74 5. Analysis of the ICMPv6 Messages . . . . . . . . . . . . . . 11 75 5.1 Destination Unreachable . . . . . . . . . . . . . . . .11 76 5.2 Packet Too Big . . . . . . . . . . . . . . . . . . . . .11 77 5.3 Time Exceeded . . . . . . . . . . . . . . . . . . . . .11 78 5.4 Parameter Problem . . . . . . . . . . . . . . . . . . .11 79 5.5 Echo Request . . . . . . . . . . . . . . . . . . . . . .11 80 5.6 Echo Reply . . . . . . . . . . . . . . . . . . . . . . .12 81 5.7 Redirect . . . . . . . . . . . . . . . . . . . . . . . .12 82 5.8 Router Solicitation . . . . . . . . . . . . . . . . . .12 83 5.9 Router Advertisement . . . . . . . . . . . . . . . . . .12 84 5.10 Neighbour Solicitation . . . . . . . . . . . . . . . . .12 85 5.11 Neighbour Advertisement . . . . . . . . . . . . . . . .12 86 5.12 Router Renumbering . . . . . . . . . . . . . . . . . . .13 87 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Normative References . . . . . . . . . . . . . . . . . . . . 17 90 Informative References . . . . . . . . . . . . . . . . . . . 18 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 92 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 Intellectual Property and Copyright Statements . . . . . . . 20 95 1. Introduction 97 The ICMPv6 [8] and IPv6 Neighbor Discovery [6] protocols provide many 98 functions which in IPv4 were either non-existent or provided by lower 99 layers. For instance, IPv6 implements address resolution using an IP 100 packet, ICMPv6 Neighbour Solicitation message. In contrast, IPv4 101 uses an ARP message at a lower layer. 103 IPv6 architecture makes it possible to secure all IP packets using 104 IPsec [4], even ICMPv6 and Neighbor Discovery messages and even to 105 multicast addresses. IPsec architecture has a Security Policy 106 Database that specifies which traffic is protected, and how. It 107 turns out that the specification of policies in the presence of 108 Neighbor Discovery traffic is not easy. For instance, a simple 109 policy of protecting all traffic between two hosts on the same 110 network would trap even address resolution messages, leading to a 111 situation where IKE ca not establish a Security Association since in 112 order to send the IKE UDP packets one would have had to send the 113 Neighbour Solicitation Message, which would have required an SA. 115 The purpose of this draft is to inform system administrators and 116 IPsec implementors in which manner they can handle the Neighbor 117 Discovery messages. System administrators do not want to study the 118 IPv6 specifications in order to understand how they shall configure 119 their routers. IPsec implementors want to understand what kind of 120 policies they can offer with respect to the Neighbor Discovery 121 messages. 123 Common understanding of the way that these messages are handled is 124 also very much necessary for interoperability, as some vendors may be 125 hardcoding some of the low-level policy operations in their products. 126 If the rules between two vendors' products are incompatible for a 127 particular message we may end with the sender sending cleartext and 128 the receiver requiring IPsec, causing the packet to be dropped and 129 possibly all connectivity between the two nodes lost. 131 This document does not imply any changes to the ICMPv6, Neighbor 132 Discovery, IPsec, or IKE specifications. It is merely provided for 133 configuration guidance. 135 2. Terminology 137 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [2]. 141 3. Neighbor Discovery and ICMPv6 Tasks 143 In IPv6, ICMP has several tasks, and many of these tasks are 144 overloaded on a few central message types such as the Neighbour 145 Discovery message. In this chapter we explain the tasks and their 146 effects in order to understand better how the messages should be 147 treated. 149 3.1 Path MTU Discovery 151 Path MTUs are dynamically determined by IPv6 in order to optimize the 152 size of the packets sent to a particular destination [1]. 154 The ICMPv6 Packet Too Big messages [8] are used as a part of the Path 155 MTU Discovery procedure. 157 3.2 Error Notification 159 ICMPv6 handles basic error situations of the IP layer, such as 160 finding out that a particular destination is not available. 162 The Destination Unreachable, Packet Too Big, Parameter Problem, and 163 Time Exceeded messages are a part of the error handling procedure 164 [8]. Note that the Packet Too Big message also plays a role in the 165 Path MTU Discovery procedure. 167 3.3 Informational Notifications 169 For debugging and network analysis purposes, ICMPv6 includes 170 informational messages [8]. These message are necessary also in 171 IPsec contexts and over IPsec tunnels due to the complex nature of 172 some tunnel setups. 174 The Echo Request and Echo Reply messages are used solely for this 175 purpose. 177 3.4 Router and Prefix Discovery 179 Router and prefix discovery is a part of the Neighbour Discovery 180 protocol [6], which in turn is a part of the ICMPv6. The main 181 purpose of the router discovery is to find neighboring routers that 182 are willing to forward packets on the behalf of hosts. Prefix 183 discovery involves determining which destinations are local for an 184 attached link. This information is used both by the address 185 autoconfiguration process, and routing. Typically, address 186 autoconfiguration and other tasks can not proceed at all until the 187 router discovery process has run. 189 The Router Solicitation and Router Advertisement messages are used 190 for this and only this purpose. 192 3.5 Address Autoconfiguration 194 Address autoconfiguration is another part of the Neighbour Discovery 195 protocol [6]. It's purpose is to automatically assign addresses to 196 interfaces. It comes in two variants, stateless and statefull. In 197 this document we consider only the stateless autoconfiguration 198 aspects. Obviously, no higher layer traffic can be sent until all 199 participating nodes have addresses. This includes also IKE UDP 200 traffic. 202 The Neighbour Solicitation and Advertisement messages are used for 203 this purpose, among other things. Furthermore, Router and Prefix 204 Discovery and Duplicate Address Detection have an effect to the 205 Address Autoconfiguration tasks. 207 3.6 Duplicate Address Detection 209 As a part of the stateless address autoconfiguration procedure, nodes 210 check for duplicate addresses prior to assigning an address to an 211 interface [7]. This procedure uses the same messages as the 212 Neighbour Discovery protocol. Since the rules outlined in RFC 2462 213 [7] forbid the use of an address for both sending and receiving 214 packets until it has been found unique, no higher layer traffic is 215 possible until this procedure has completed. 217 The Neighbour Solicitation and Advertisement messages are used also 218 for this purpose. 220 3.7 Address Resolution 222 In address resolution, nodes determine the link-layer address of a 223 local destination given only the destination's IP address [6]. 224 Again, no higher level traffic can proceed until the sender knows the 225 hardware address of the destination or the next hop router. 227 The Neighbour Solicitation and Advertisement messages are used also 228 for this purpose. 230 3.8 Neighbor Reachability Detection 232 Hosts monitor the reachability of local destinations and routers in 233 the Neighbour Unreachability procedure, which is a part of the 234 Neighbour Discovery protocol [6]. No higher level traffic can 235 proceed if this procedure flushes out neighbour cache entries after 236 (perhaps incorrectly) determining that the peer is not reachable. 238 The Neighbour Solicitation and Advertisement messages are used also 239 for this purpose. 241 3.9 Redirect 243 In the Redirect procedure, a router informs a host of a better 244 first-hop node to reach a particular destination [6]. It is a part 245 of the Neighbour Discovery protocol. As routers forward packets 246 regardless of them being sent first to the wrong place, 247 communications can still be established without the ability to 248 process Redirect messages. 250 The Redirect message is used solely for the Redirect procedure. 252 3.10 Router Renumbering 254 This procedure [9] allows address prefixes on routers to be 255 configured and reconfigured in the similar manner as Neighbor 256 Discovery and Address Autoconfiguration works for hosts. Incorrect 257 processing or blocking of messages related to this procedure may 258 render a node's address sets invalid, thereby preventing further 259 communications. 261 The Router Renumbering message is used solely for the Router 262 Renumbering procedure. 264 4. Factors Affecting the Policy Rules 266 4.1 Nature of the Addresses 268 Neighbor Discovery messages are sent using various kinds of source 269 and destination address types. The nature of the destination address 270 is of relevance here, as the destination address is used to find the 271 right security association. The destination address can be either a 272 well known multicast address, a computed multicast address, such as 273 the solicited-node multicast address, or a unicast address. Many 274 Neighbor Discovery messages use multicast addresses in most cases. 275 Some messages can also be sent to unicast addresses in certain 276 situations. For instance, the Neighbor Solicitation messages are 277 usually sent to multicast addresses, but the Neighbor Advertisement 278 messages are also sent to unicast addresses when sent as a response 279 to a node that has an address. 281 ICMPv6 messages are sent using various kinds of source and 282 destination address types. The source address is usually a unicast 283 address, but during address autoconfiguration message exchanges, the 284 unspecified address :: is also used as a source address [7]. The 285 destination address can be either a well known multicast address, a 286 generated multicast address such as the solicited-node multicast 287 address, or a unicast address. While many ICMPv6 messages use 288 multicast addresses most of the time, some also use unicast addresses 289 sometimes. For instance, the Neighbour Solicitation messages are 290 usually sent to multicast addresses, but the Neighbour Advertisement 291 messages are also sent to unicast addresses when sent as a response 292 to a node that has an address. 294 IPsec [4] can be used for the protection of both unicast and 295 multicast traffic. However, in order to automatically negotiate 296 mutually acceptable security associations and to refresh keys, IKE 297 [5] needs to be used. IKE is only capable of negotiating SAs for 298 unicast communications. 300 Obviously, policies MUST be configured so that multicast traffic does 301 not require dynamic SAs. However, while this is a necessary 302 condition it is not sufficient to make sure that that IKE works. The 303 policies MUST also exclude unicast traffic which is contains ICMPv6 304 messages required before UDP can work between the two nodes. 306 4.2 Network Topology 308 ICMP traffic has different implications for hosts and security 309 gateways. In general, security gateways SHOULD carry all ICMP 310 traffic related to the protected traffic in the same tunnel as the 311 traffic itself. For instance, when an ICMPv6 Packet Too Big message 312 is generated on the unprotected segment of a packet's path, that 313 message should relayed through the tunnel to ensure that the sender 314 recognizes the MTU problem. 316 Between hosts similar rules apply. However, messages related to the 317 establishment of communication between the hosts - such as for 318 address resolution - MUST NOT be passed through the tunnel at least 319 when the tunnel does not exist yet and IKE would be needed to 320 establish it. 322 Note that the distinctions in network topology are more due to the 323 actual network architecture than the selected IPsec mode, be it 324 tunnel or transport. 326 ICMPv6 messages can be classified according to whether they are meant 327 for end-to-end communications or communications within a link. There 328 are also messages that we classify as 'any-to-end', which can be sent 329 from any point within a path back to the source, typically to 330 announce an error in processing the original packet. For instance, 331 the address resolution messages are solely for local communications 332 [6], whereas the Destination Unreachable messages are any-to-end in 333 nature. End-to-end and any-to-end messages MUST always be passed 334 through tunnels. Local messages may be passed through IPsec process 335 under certain conditions. 337 4.3 Role in Estaliblishing Communications 339 ICMPv6 messages can also be classified according to their role for 340 establishing communications between two nodes. For the purposes of 341 this discussion, the relevant issue is whether or not the messages 342 must be passed through before IKE can use UDP packets to negotiate 343 SAs. For instance, address autoconfiguration, duplicate address 344 detection, and address resolution obviously MUST be completed before 345 UDP packets can be passed. 347 Neighbour reachability detection is also capable of disrupting IKE 348 communications. The reference [6] states the following: 350 In some cases (e.g., UDP-based protocols and routers 351 forwarding packets to hosts) such reachability information 352 may not be readily available from upper-layer protocols. 353 When no hints are available and a node is sending packets 354 to a neighbor, the node actively probes the neighbor using 355 unicast Neighbor Solicitation messages to verify that the 356 forward path is still working. 358 This means that unless the IKE implementation explicitly handles 359 forward progress notifications towards the IPv6 stack, the stack can 360 not know about the reachability towards the other host. Since the 361 hosts may be using tunnel mode and other address in the inner packets 362 than the regular addresses on the hosts, the stack can not learn of 363 forward progress through regular IPsec AH or ESP packets. 365 Therefore, neighbour reachability MUST also be allowed to work 366 independent of IKE SA establishment. 368 As IKE messages may contain certificates, it is quite possible that 369 an MTU limit may be exceeded somewhere within the network. If this 370 is possible in a given network, the policies MUST allow ICMP Packet 371 Too Big messages to be received. Note that these messages may well 372 be received either in the clear, on manually configured SAs, or on 373 dynamic SAs. If the router generating the Packet Too Big message 374 does not yet have an SA with the original host, it can initiate IKE 375 negotiations to create one. In case that this new negotiation fails 376 due to reaching another MTU limit, other routers may be involved 377 along the way. But ultimately the process reaches the closest router 378 to which the MTU is known and will not cause any ICMP error messages. 380 4.4 Protecting the Infrastructure versus Communications 382 IPsec can be used to protect the end-to-end communications or the 383 underlying control messages (such as ICMPv6). It can even be used to 384 protect both. Since many of the control messages are sent to 385 multicast addresses, if IPsec is used then manual SA configuration 386 MUST be performed instead of IKE-based SA negotiation. 388 As we have talked about some messages in some situations having to be 389 independent of IKE, it does not necessarily imply that they have to 390 passed through in the clear. Instead, systems MAY use manually 391 configured IPsec SAs to protect e.g. all ICMPv6 communications 392 within one network. (Note that setting these manual SAs up requires 393 some care as discussed in [13].) 395 A plausible security policy configuration could therefore be one 396 where all ICMPv6 messages within the local network must be protected 397 by manual SAs, and all other communications must be protected by 398 IKE-negotiated SAs. 400 5. Analysis of the ICMPv6 Messages 402 5.1 Destination Unreachable 404 This message is always sent between unicast addresses [8]. It is an 405 end-to-end message Destination Unreachable is never a relevant 406 message for establishing dynamic SAs, unless advanced failover 407 schemes rely on the knowledge to quickly determine unreachable IKE 408 peers. 410 5.2 Packet Too Big 412 This message is also always sent between unicast addresses [8] even 413 if might be sent as a response to a multicast message. It is an 414 end-to-end message. 416 Packet Too Big has, however, a role in establishing communications. 417 End-to-end communications, that is. In order to pass through long 418 IKE packets, Packet Too Big responses from the network MUST be 419 considered. Therefore, it MUST be possible for policies to be 420 configured so that such messages can be received. Note that as 421 dicussed previously, the Packet Too Big messages themselves can be 422 protected in various ways. 424 5.3 Time Exceeded 426 This message is also always sent between unicast addresses [8] and is 427 an end-to-end message. Like Packet Too Big, it too has a role in 428 establishing end-to-end communications under certain special 429 situations. 431 5.4 Parameter Problem 433 This message is similar to Packet Too Big in the sense that it uses 434 only unicast messages even if it could be sent as a response to a 435 multicast packet. It's role is also end-to-end. While in theory its 436 role in establishing communications is similar to Packet Too Big and 437 Time Exceeded, in practise it is hard to see the kind of IKE and IPv6 438 stack version problem that could result in this message being sent. 440 5.5 Echo Request 442 Echo Request uses unicast addresses as source addresses, but may be 443 sent to any legal IPv6 address, even multicast and anycast addresses 444 [8]. Echo Requests run end-to-end but never have a role in 445 establishing communications. 447 5.6 Echo Reply 449 Echo Reply is similar to Echo Request in other respects, but uses 450 only unicast addresses. 452 5.7 Redirect 454 The Redirect message is always sent between unicast addresses [6]. 455 It is only used for local purposes, not for end-to-end 456 communications. It is not strictly necessary in order to establish 457 communications. Nevertheless, it can be viewed as a logical add-on 458 to the Neighbour Discovery messages such as Router Advertisement, and 459 as such SHOULD be treated in a similar manner. 461 5.8 Router Solicitation 463 This message uses either the unspecified address or an unicast 464 address as a source address. The destination address is typically a 465 multicast address. This message is always used only local. Since 466 address autoconfiguration and routing depend on the ability of the 467 routers and address prefixes to be found, this message is required 468 before any communications can be established. Therefore, this 469 message MUST be allowed to work independent of IKE SA establishment. 471 5.9 Router Advertisement 473 This message has always a unicast source address, but the destination 474 address can be either a unicast or a multicast address. Like the 475 solicitation message, the advertisement is also link local only and 476 required for establishing any communications. Therefore, this 477 message MUST be allowed to work independent of IKE SA establishment. 479 5.10 Neighbour Solicitation 481 The source address of this message is either a unicast address or (if 482 Duplicate Address Detection is in progress) the unspecified address 483 [6, 8]. The destination is either a multicast address, unicast 484 address, or an anycast address. Neighbour Solicitation and 485 Advertisement messages are used for multiple purposes: address 486 autoconfiguration, duplicate address detection, and reachability 487 detection. In all these roles they act only locally on the link, and 488 getting them through is required before any communications can be 489 established. Therefore, this message MUST be allowed to work 490 independent of IKE SA establishment. 492 5.11 Neighbour Advertisement 494 The source address of this message is a unicast address, and the 495 destination is either a unicast or a multicast address. Like the 496 solication message, this message is link local only and is required 497 before any communications can be established. Therefore, this 498 message MUST be allowed to work independent of IKE SA establishment. 500 5.12 Router Renumbering 502 These messages are sent from a unicast address to either a multicast 503 or a unicast address. The message are not solely link local, they 504 are used for end-to-end purposes such as having a central management 505 station renumber all routers in a corporate network. As a result of 506 the RR procedure, automatically configured addresses and prefixes may 507 be changed. However, it is expected that a transition period exists 508 where both addresses are still acceptable, making it possible to 509 still proceed with IKE negotiations to create SAs for the RR 510 procedure. We can therefore assume that the procedure MAY use manual 511 or dynamic SAs as desired by the system administrators. 513 6. Summary 515 Based on the above, the ICMPv6 messages can be classified as follows: 517 +-------------------+------------+-----------------+ 518 | MESSAGE | ROLE | USE IKE? | 519 +-------------------+------------+-----------------+ 520 | Dest Unreachable | Any-to-End | MAY(1,2) | 521 +-------------------+------------+-----------------+ 522 | Packet Too Big | Any-to-End | MAY(1,3) | 523 +-------------------+------------+-----------------+ 524 | Time Exceeded | Any-to-End | MAY(1,3) | 525 +-------------------+------------+-----------------+ 526 | Parameter Problem | End-to-End | MAY(4) | 527 +-------------------+------------+-----------------+ 528 | Echo Request | End-to-End | MAY(4) | 529 +-------------------+------------+-----------------+ 530 | Echo Reply | End-to-End | MAY(4) | 531 +-------------------+------------+-----------------+ 532 | Redirect | Link Local | SHOULD NOT(5) | 533 +-------------------+------------+-----------------+ 534 | Router Solicit | Link Local | MUST NOT(6) | 535 +-------------------+------------+-----------------+ 536 | Router Advert | Link Local | MUST NOT(6) | 537 +-------------------+------------+-----------------+ 538 | Neighbour Solicit | Link Local | MUST NOT(6) | 539 +-------------------+------------+-----------------+ 540 | Neighbour Advert | Link Local | MUST NOT(6) | 541 +-------------------+------------+-----------------+ 542 | Router Renumbering| End-to-End | MAY(4) | 543 +-------------------+------------+-----------------+ 545 Explanations: 547 (1) These error messages have an end-to-end nature but may be 548 generated by intermediate routers as well. 550 (2) This MAY have to be considered by implementations that wish to 551 base failover decisions on the Unreachable message. 553 (3) These messages have an impact on the success of IKE messages e.g. 554 when certificates are passed in IKE packets. It MUST be possible 555 for policies to be configured so that these messages can be 556 received while the IKE negotiations are still ongoing. Different 557 security policy configurations MUST be supported, including 558 trusting cleartext messages or protecting the messages from 559 intermediate nodes using other, new dynamic SA negotiations. 561 (4) These messages MAY be treated using regular IPsec and/or IKE 562 processing. 564 (5) This message SHOULD NOT use IKE in order to make their treatment 565 equal with the rest of the link local messages, but in theory 566 Redirect MAY be handled differently, e.g. using dynamic SAs. 568 (6) These messages MUST NOT use dynamic SAs. 570 These policy rules may be expressed in various ways on a particular 571 host or a router. It is necessary to use the ICMPv6 type in making 572 the policy decisions. As [9] states, "This is consistent with, 573 although not mentioned by, the Security Architecture specification". 574 Only the following requirement for all implementations is stated 575 here. Products that provide hardcoded security policies for ICMPv6 576 messages SHOULD enable user specified policies to be expressed at a 577 higher priority level so that a possibility is still retained for 578 modifying the rules due to e.g. interoperability problems. 580 7. Further Work 582 This draft discusses the use of IPsec on ICMPv6 messages on a 583 principle level. It does not take a stand on how the policies are 584 expressed, for instance whether IPsec products need to have hardcoded 585 rules for handling these messages, or whether the Security Policy 586 Databases should be general enough to make it possible to express the 587 policies in them even for the ICMPv6 messages. 589 This draft does not address stateful address autoconfiguration 590 aspects of IPv6. 592 This draft does not address the use of dynamic security associations 593 in the context of multicast traffic. Now that the multicast key 594 management working group has been founded in the IETF, a question 595 eventually arises whether or not the results of that work can be used 596 to protect the infrastructure multicast messages. 598 Normative References 600 [1] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 601 IP version 6", RFC 1981, August 1996. 603 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 604 Levels", BCP 14, RFC 2119, March 1997. 606 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 607 Architecture", RFC 2373, July 1998. 609 [4] Kent, S. and R. Atkinson, "Security Architecture for the 610 Internet Protocol", RFC 2401, November 1998. 612 [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 613 RFC 2409, November 1998. 615 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 616 for IP Version 6 (IPv6)", RFC 2461, December 1998. 618 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 619 Autoconfiguration", RFC 2462, December 1998. 621 [8] Conta, A. and S. Deering, "Internet Control Message Protocol 622 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 623 Specification", RFC 2463, December 1998. 625 [9] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 626 2000. 628 [10] Narten, T. and R. Draves, "Privacy Extensions for Stateless 629 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 631 Informative References 633 [11] Arkko, J., Kempf, J., Sommerfeld, B. and B. Zill, "SEcure 634 Neighbor Discovery (SEND) Protocol", 635 draft-ietf-send-ipsec-00.txt (work in progress), February 2003. 637 [12] Nikander, P., "IPv6 Neighbor Discovery trust models and 638 threats", draft-ietf-send-psreq-00 (work in progress), October 639 2002. 641 [13] Arkko, J., "Manual SA Configuration for IPv6 Link Local 642 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 643 June 2002. 645 [14] Nikander, P., "Denial-of-Service, Address Ownership, and Early 646 Authentication in the IPv6 World", Proceedings of the Cambridge 647 Security Protocols Workshop, April 2001. 649 Author's Address 651 Jari Arkko 652 Ericsson 653 Jorvas 02420 654 Finland 656 EMail: jari.arkko@ericsson.com 658 Appendix A. Acknowledgements 660 The author would like to thank Pekka Nikander, Markku Rossi, Tero 661 Kivinen, Michael Richardson, Erik Nordmark, and James Kempf for 662 interesting discussions in this problem space. 664 Intellectual Property Statement 666 The IETF takes no position regarding the validity or scope of any 667 intellectual property or other rights that might be claimed to 668 pertain to the implementation or use of the technology described in 669 this document or the extent to which any license under such rights 670 might or might not be available; neither does it represent that it 671 has made any effort to identify any such rights. Information on the 672 IETF's procedures with respect to rights in standards-track and 673 standards-related documentation can be found in BCP-11. Copies of 674 claims of rights made available for publication and any assurances of 675 licenses to be made available, or the result of an attempt made to 676 obtain a general license or permission for the use of such 677 proprietary rights by implementors or users of this specification can 678 be obtained from the IETF Secretariat. 680 The IETF invites any interested party to bring to its attention any 681 copyrights, patents or patent applications, or other proprietary 682 rights which may cover technology that may be required to practice 683 this standard. Please address the information to the IETF Executive 684 Director. 686 Full Copyright Statement 688 Copyright (C) The Internet Society (2003). All Rights Reserved. 690 This document and translations of it may be copied and furnished to 691 others, and derivative works that comment on or otherwise explain it 692 or assist in its implementation may be prepared, copied, published 693 and distributed, in whole or in part, without restriction of any 694 kind, provided that the above copyright notice and this paragraph are 695 included on all such copies and derivative works. However, this 696 document itself may not be modified in any way, such as by removing 697 the copyright notice or references to the Internet Society or other 698 Internet organizations, except as needed for the purpose of 699 developing Internet standards in which case the procedures for 700 copyrights defined in the Internet Standards process must be 701 followed, or as required to translate it into languages other than 702 English. 704 The limited permissions granted above are perpetual and will not be 705 revoked by the Internet Society or its successors or assignees. 707 This document and the information contained herein is provided on an 708 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 709 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 710 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 711 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 712 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 714 Acknowledgement 716 Funding for the RFC Editor function is currently provided by the 717 Internet Society.