idnits 2.17.1 draft-arkko-icmpv6-ike-effects-01.txt: -(13): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(15): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(38): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(39): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(40): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(42): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(52): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(74): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(83): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(85): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(90): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(115): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(116): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(120): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(125): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(147): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(168): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(203): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(213): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(214): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(229): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(231): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(286): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(293): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(302): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(313): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(324): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(325): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(335): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(396): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(397): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(407): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(409): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(430): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(431): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(442): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(443): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(456): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(460): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(498): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(507): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(512): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(533): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(544): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(557): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(574): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(580): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 59 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 175 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 227 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 228: '...iously, policies MUST be configured ...' RFC 2119 keyword, line 231: '... cies MUST also exclude unicast ...' RFC 2119 keyword, line 237: '...urity gateways SHOULD carry all ICMP...' RFC 2119 keyword, line 246: '... resolution - MUST NOT be passed th...' RFC 2119 keyword, line 260: '...-to-end messages MUST always be pass...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '... ments of t...' == Line 15 has weird spacing: '...tribute work...' == Line 19 has weird spacing: '...y other docum...' == Line 20 has weird spacing: '... any time....' == Line 23 has weird spacing: '... The list...' == (170 more instances...) -- 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 (23 June 2002) is 7977 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) ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '3') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 1981 (ref. '5') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-00 -- Possible downref: Normative reference to a draft: ref. '8' Summary: 18 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Ericsson 4 Category: Standards Track 5 6 23 June 2002 8 Effects of ICMPv6 on IKE and IPsec Policies 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working docu� 14 ments of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute work� 16 ing documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or made obsolete by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts may be found at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories may be found at 27 http://www.ietf.org/shadow.html. 29 The distribution of this memo is unlimited. It is filed as , and expires July 9, 2001. Please 31 send comments to the author or to IPsec and/or IPNG working group 32 mailing lists. 34 2. Abstract 36 The ICMPv6 protocol provides many functions which in IPv4 were either 37 non-existent or provided by lower layers. IPv6 architecture also makes 38 it possible to secure all IP packets using IPsec, even ICMPv6 mes� 39 sages. IPsec architecture has a Security Policy Database that speci� 40 fies which traffic is protected, and how. It turns out that the speci� 41 fication of policies in the presence of ICMPv6 traffic is hard. Sound 42 looking policies may easily lead to loops: The establishment of secu� 43 rity requires ICMPv6 messages which can't be sent since security 44 hasn't been established yet. The purpose of this draft is to inform 45 system administrators and IPsec implementors in which manner they can 46 handle the ICMPv6 messages. Common understanding of the way that these 47 messages are handled is also necessary for interoperability, in case 48 vendors hardcode such rules in to products. 50 3. Introduction 52 This draft is a re-submission of an earlier Internet Draft from Febru� 53 ary 2001. It is intended as an input paper for the Secure Neighbor 54 Discovery (SEND) BOF. 56 The ICMPv6 protocol [3] provides many functions which in IPv4 were 57 either non-existent or provided by lower layers. For instance, IPv6 58 implements address resolution using an IP packet, ICMPv6 Neighbour 59 Solicitation message [1]. In contrast, IPv4 uses an ARP message at a 60 lower layer. 62 IPv6 architecture makes it possible to secure all IP packets using 63 IPsec [6], even ICMPv6 messages and even to multicast addresses. 64 IPsec architecture has a Security Policy Database that specifies which 65 traffic is protected, and how. It turns out that the specification of 66 policies in the presence of ICMPv6 traffic is not easy. For instance, 67 a simple policy of protecting all traffic between two hosts on the 68 same network would trap even address resolution messages, leading to a 69 situation where IKE can't establish a Security Association since in 70 order to send the IKE UDP packets one would have had to send the 71 Neighbour Solicitation Message, which would have required an SA. 73 The purpose of this draft is to inform system administrators and IPsec 74 implementors in which manner they can handle the ICMPv6 messages. Sys� 75 tem administrators do not want to study the IPv6 specifications in 76 order to understand how they shall configure their routers. IPsec 77 implementors want to understand what kind of policies they can offer 78 with respect to the ICMPv6 messages. 80 Common understanding of the way that these messages are handled is 81 also very much necessary for interoperability, as some vendors may be 82 hardcoding some of the low-level policy operations in their products. 83 If the rules between two vendors' products are incompatible for a par� 84 ticular message we may end with the sender sending cleartext and the 85 receiver requiring IPsec, causing the packet to be dropped and possi� 86 bly all connectivity between the two nodes lost. 88 4. ICMPv6 Tasks 90 In IPv6, ICMP has several tasks, and many of these tasks are over� 91 loaded on a few central message types such as the Neighbour Discovery 92 message. In this chapter we explain the tasks and their effects in 93 order to understand better how the messages should be treated. 95 4.1. Path MTU Discovery 97 Path MTUs are dynamically determined by IPv6 in order to optimize the 98 size of the packets sent to a particular destination [5]. 100 The ICMPv6 Packet Too Big messages are used as a part of the Path MTU 101 Discovery procedure [3]. 103 4.2. Error Notification 105 ICMPv6 handles basic error situations of the IP layer, such as finding 106 out that a particular destination isn't available. 108 The Destination Unreachable, Packet Too Big, Parameter Problem, and 109 Time Exceeded messages are a part of the error handling procedure [3]. 110 Note that the Packet Too Big message also plays a role in the Path MTU 111 Discovery procedure. 113 4.3. Informational Notifications 115 For debugging and network analysis purposes, ICMPv6 includes informa� 116 tional messages [3]. These message are necessary also in IPsec con� 117 texts and over IPsec tunnels due to the complex nature of some tunnel 118 setups. 120 The Echo Request and Echo Reply messages are used solely for this pur� 121 pose. 123 4.4. Router and Prefix Discovery 125 Router and prefix discovery is a part of the Neighbour Discovery pro� 126 tocol [1], which in turn is a part of the ICMPv6. The main purpose of 127 the router discovery is to find neighboring routers that are willing 128 to forward packets on the behalf of hosts. Prefix discovery involves 129 determining which destinations are local for an attached link. This 130 information is used both by the address autoconfiguration process, and 131 routing. Typically, address autoconfiguration and other tasks can't 132 proceed at all until the router discovery process has run. 134 The Router Solicitation and Router Advertisement messages are used for 135 this and only this purpose. 137 4.5. Address Autoconfiguration 139 Address autoconfiguration is another part of the Neighbour Discovery 140 protocol [1]. It's purpose is to automatically assign addresses to 141 interfaces. It comes in two variants, stateless and statefull. In this 142 document we consider only the stateless autoconfiguration aspects. 143 Obviously, no higher layer traffic can be sent until all participating 144 nodes have addresses. This includes also IKE UDP traffic. 146 The Neighbour Solicitation and Advertisement messages are used for 147 this purpose, among other things. Furthermore, Router and Prefix Dis� 148 covery and Duplicate Address Detection have an effect to the Address 149 Autoconfiguration tasks. 151 4.6. Duplicate Address Detection 153 As a part of the stateless address autoconfiguration procedure, nodes 154 check for duplicate addresses prior to assigning an address to an 155 interface [2]. This procedure uses the same messages as the Neighbour 156 Discovery protocol [1]. Since the rules outlined in [2] forbid the use 157 of an address for both sending and receiving packets until it has been 158 found unique, no higher layer traffic is possible until this procedure 159 has completed. 161 The Neighbour Solicitation and Advertisement messages are used also 162 for this purpose. 164 4.7. Address Resolution 166 In address resolution, nodes determine the link-layer address of a 167 local destination given only the destination's IP address [1]. Again, 168 no higher level traffic can proceed until the sender knows the hard� 169 ware address of the destination or the next hop router. 171 The Neighbour Solicitation and Advertisement messages are used also 172 for this purpose. 174 4.8. Neighbor Reachability Detection 176 Hosts monitor the reachability of local destinations and routers in 177 the Neighbour Unreachability procedure, which is a part of the Neigh� 178 bour Discovery protocol [1]. No higher level traffic can proceed if 179 this procedure flushes out neighbour cache entries after (perhaps 180 incorrectly) determining that the peer is not reachable. 182 The Neighbour Solicitation and Advertisement messages are used also 183 for this purpose. 185 4.9. Redirect 187 In the Redirect procedure, a router informs a host of a better first- 188 hop node to reach a particular destination [1]. It is a part of the 189 Neighbour Discovery protocol. As routers forward packets regardless of 190 them being sent first to the wrong place, communications can still be 191 established without the ability to process Redirect messages. 193 The Redirect message is used solely for the Redirect procedure. 195 4.10. Router Renumbering 197 This procedure [4] allows address prefixes on routers to be configured 198 and reconfigured in the similar manner as Neighbor Discovery and 199 Address Autoconfiguration works for hosts. Incorrect processing or 200 blocking of messages related to this procedure may render a node's 201 address sets invalid, thereby preventing further communications. 203 The Router Renumbering message is used solely for the Router Renumber� 204 ing procedure. 206 5. Factors Affecting the Policy Rules 207 5.1. Nature of the Addresses 209 ICMPv6 messages are sent using various kinds of source and destination 210 address types. The source address is usually a unicast address, but 211 during address autoconfiguration message exchanges, the unspecified 212 address :: is also used as a source address [2]. The destination 213 address can be either a well known multicast address, a generated mul� 214 ticast address such as the solicited-node multicast address, or a uni� 215 cast address. While many ICMPv6 messages use multicast addresses most 216 of the time, some also use unicast addresses sometimes. For instance, 217 the Neighbour Solicitation messages are usually sent to multicast 218 addresses, but the Neighbour Advertisement messages are also sent to 219 unicast addresses when sent as a response to a node that has an 220 address. 222 IPsec [6] can be used for the protection of both unicast and multicast 223 traffic. However, in order to automatically negotiate mutually accept� 224 able security associations and to refresh keys, IKE [7] needs to be 225 used. IKE is only capable of negotiating SAs for unicast communica� 226 tions. 228 Obviously, policies MUST be configured so that multicast traffic 229 doesn't require dynamic SAs. However, while this is a necessary condi� 230 tion it is not sufficient to make sure that that IKE works. The poli� 231 cies MUST also exclude unicast traffic which is contains ICMPv6 mes� 232 sages required before UDP can work between the two nodes. 234 5.2. Network Topology 236 ICMP traffic has different implications for hosts and security gate� 237 ways. In general, security gateways SHOULD carry all ICMP traffic 238 related to the protected traffic in the same tunnel as the traffic 239 itself. For instance, when an ICMPv6 Packet Too Big message is gener� 240 ated on the unprotected segment of a packet's path, that message 241 should relayed through the tunnel to ensure that the sender recognizes 242 the MTU problem. 244 Between hosts similar rules apply. However, messages related to the 245 establishment of communication between the hosts - such as for address 246 resolution - MUST NOT be passed through the tunnel at least when the 247 tunnel does not exist yet and IKE would be needed to establish it. 249 Note that the distinctions in network topology are more due to the 250 actual network architecture than the selected IPsec mode, be it tunnel 251 or transport. 253 ICMPv6 messages can be classified according to whether they are meant 254 for end-to-end communications or communications within a link. There 255 are also messages that we classify as 'any-to-end', which can be sent 256 from any point within a path back to the source, typically to announce 257 an error in processing the original packet. For instance, the address 258 resolution messages are solely for local communications [1], whereas 259 the Destination Unreachable messages are any-to-end in nature. End-to- 260 end and any-to-end messages MUST always be passed through tunnels. 262 Local messages may be passed through IPsec process under certain con� 263 ditions. 265 5.3. Role in Estaliblishing Communications 267 ICMPv6 messages can also be classified according to their role for 268 establishing communications between two nodes. For the purposes of 269 this discussion, the relevant issue is whether or not the messages 270 must be passed through before IKE can use UDP packets to negotiate 271 SAs. For instance, address autoconfiguration, duplicate address detec� 272 tion, and address resolution obviously MUST be completed before UDP 273 packets can be passed. 275 Neighbour reachability detection is also capable of disrupting IKE 276 communications. The reference [1] states the following: 278 In some cases (e.g., UDP-based protocols and routers 279 forwarding packets to hosts) such reachability information 280 may not be readily available from upper-layer protocols. 281 When no hints are available and a node is sending packets 282 to a neighbor, the node actively probes the neighbor using 283 unicast Neighbor Solicitation messages to verify that the 284 forward path is still working. 286 This means that unless the IKE implementation explicitly handles for� 287 ward progress notifications towards the IPv6 stack, the stack can not 288 know about the reachability towards the other host. Since the hosts 289 may be using tunnel mode and other address in the inner packets than 290 the regular addresses on the hosts, the stack can not learn of forward 291 progress through regular IPsec AH or ESP packets. 293 Therefore, neighbour reachability MUST also be allowed to work inde� 294 pendent of IKE SA establishment. 296 As IKE messages may contain certificates, it is quite possible that an 297 MTU limit may be exceeded somewhere within the network. If this is 298 possible in a given network, the policies MUST allow ICMP Packet Too 299 Big messages to be received. Note that these messages may well be 300 received either in the clear, on manually configured SAs, or on 301 dynamic SAs. If the router generating the Packet Too Big message does 302 not yet have an SA with the original host, it can initiate IKE negoti� 303 ations to create one. In case that this new negotiation fails due to 304 reaching another MTU limit, other routers may be involved along the 305 way. But ultimately the process reaches the closest router to which 306 the MTU is known and will not cause any ICMP error messages. 308 5.4. Protecting the Infrastructure versus Communications 310 IPsec can be used to protect the end-to-end communications or the 311 underlying control messages (such as ICMPv6). It can even be used to 312 protect both. Since many of the control messages are sent to multicast 313 addresses, if IPsec is used then manual SA configuration MUST be per� 314 formed instead of IKE-based SA negotiation. 316 As we have talked about some messages in some situations having to be 317 independent of IKE, it does not necessarily imply that they have to 318 passed through in the clear. Instead, systems MAY use manually config� 319 ured IPsec SAs to protect e.g. all ICMPv6 communications within one 320 network. (Note that setting these manual SAs up requires some care as 321 discussed in [8].) 323 A plausible security policy configuration could therefore be one where 324 all ICMPv6 messages within the local network must be protected by man� 325 ual SAs, and all other communications must be protected by IKE-negoti� 326 ated SAs. 328 6. Analysis of the ICMPv6 Messages 330 6.1. Destination Unreachable 332 The ICMPv6 type of this message is 1. 334 This message is always sent between unicast addresses [3]. It is an 335 end-to-end message Destination Unreachable is never a relevant mes� 336 sage for establishing dynamic SAs, unless advanced failover schemes 337 rely on the knowledge to quickly determine unreachable IKE peers. 339 6.2. Packet Too Big 341 The ICMPv6 type of this message is 2. 343 This message is also always sent between unicast addresses [3] even if 344 might be sent as a response to a multicast message. It is an end-to- 345 end message. 347 Packet Too Big has, however, a role in establishing communications. 348 End-to-end communications, that is. In order to pass through long IKE 349 packets, Packet Too Big responses from the network MUST be considered. 350 Therefore, it MUST be possible for policies to be configured so that 351 such messages can be received. Note that as dicussed previously, the 352 Packet Too Big messages themselves can be protected in various ways. 354 6.3. Time Exceeded 356 The ICMPv6 type of this message is 3. 358 This message is also always sent between unicast addresses [3] and is 359 an end-to-end message. Like Packet Too Big, it too has a role in 360 establishing end-to-end communications under certain special situa� 361 tions. 363 6.4. Parameter Problem 365 The ICMPv6 type of this message is 4. 367 This message is similar to Packet Too Big in the sense that it uses 368 only unicast messages even if it could be sent as a response to a 369 multicast packet. It's role is also end-to-end. While in theory its 370 role in establishing communications is similar to Packet Too Big and 371 Time Exceeded, in practise it is hard to see the kind of IKE and IPv6 372 stack version problem that could result in this message being sent. 374 6.5. Echo Request 376 The ICMPv6 type of this message is 128. 378 Echo Request uses unicast addresses as source addresses, but may be 379 sent to any legal IPv6 address, even multicast and anycast addresses 380 [3]. Echo Requests run end-to-end but never have a role in establish� 381 ing communications. 383 6.6. Echo Reply 385 The ICMPv6 type of this message is 129. 387 Echo Reply is similar to Echo Request in other respects, but uses only 388 unicast addresses. 390 6.7. Redirect 392 The ICMPv6 type of this message is 137. 394 The Redirect message is always sent between unicast addresses [1]. It 395 is only used for local purposes, not for end-to-end communications. It 396 isn't strictly necessary in order to establish communications. Never� 397 theless, it can be viewed as a logical add-on to the Neighbour Discov� 398 ery messages such as Router Advertisement, and as such SHOULD be 399 treated in a similar manner. 401 6.8. Router Solicitation 403 The ICMPv6 type of this message is 133. 405 This message uses either the unspecified address or an unicast address 406 as a source address. The destination address is typically a multicast 407 address. This message is always used only local. Since address auto� 408 configuration and routing depend on the ability of the routers and 409 address prefixes to be found, this message is required before any com� 410 munications can be established. Therefore, this message MUST be 411 allowed to work independent of IKE SA establishment. 413 6.9. Router Advertisement 415 The ICMPv6 type of this message is 134. 417 This message has always a unicast source address, but the destination 418 address can be either a unicast or a multicast address. Like the 419 solicitation message, the advertisement is also link local only and 420 required for establishing any communications. Therefore, this message 421 MUST be allowed to work independent of IKE SA establishment. 423 6.10. Neighbour Solicitation 425 The ICMPv6 type of this message is 135. 427 The source address of this message is either a unicast address or (if 428 Duplicate Address Detection is in progress) the unspecified address 429 [1, 3]. The destination is either a multicast address, unicast 430 address, or an anycast address. Neighbour Solicitation and Advertise� 431 ment messages are used for multiple purposes: address autoconfigura� 432 tion, duplicate address detection, and reachability detection. In all 433 these roles they act only locally on the link, and getting them 434 through is required before any communications can be established. 435 Therefore, this message MUST be allowed to work independent of IKE SA 436 establishment. 438 6.11. Neighbour Advertisement 440 The ICMPv6 type of this message is 136. 442 The source address of this message is a unicast address, and the des� 443 tination is either a unicast or a multicast address. Like the solica� 444 tion message, this message is link local only and is required before 445 any communications can be established. Therefore, this message MUST 446 be allowed to work independent of IKE SA establishment. 448 6.12. Router Renumbering 450 The ICMPv6 type of this message is 138. The code is 0 for a Router 451 Renumbering Command, 1 for a Router Renumbering Result, and 255 for a 452 Sequence Number Reset [4]. 454 These messages are sent from a unicast address to either a multicast 455 or a unicast address. The message are not solely link local, they are 456 used for end-to-end purposes such as having a central management sta� 457 tion renumber all routers in a corporate network. As a result of the 458 RR procedure, automatically configured addresses and prefixes may be 459 changed. However, it is expected that a transition period exists where 460 both addresses are still acceptable, making it possible to still pro� 461 ceed with IKE negotiations to create SAs for the RR procedure. We can 462 therefore assume that the procedure MAY use manual or dynamic SAs as 463 desired by the system administrators. 465 7. Summary 467 Based on the above, the ICMPv6 messages can be classified as follows: 468 +-------------------+------------+-----------------+ 469 | MESSAGE | ROLE | USE IKE? | 470 +-------------------+------------+-----------------+ 471 | Dest Unreachable | Any-to-End | MAY(1,2) | 472 +-------------------+------------+-----------------+ 473 | Packet Too Big | Any-to-End | MAY(1,3) | 474 +-------------------+------------+-----------------+ 475 | Time Exceeded | Any-to-End | MAY(1,3) | 476 +-------------------+------------+-----------------+ 477 | Parameter Problem | End-to-End | MAY(4) | 478 +-------------------+------------+-----------------+ 479 | Echo Request | End-to-End | MAY(4) | 480 +-------------------+------------+-----------------+ 481 | Echo Reply | End-to-End | MAY(4) | 482 +-------------------+------------+-----------------+ 483 | Redirect | Link Local | SHOULD NOT(5) | 484 +-------------------+------------+-----------------+ 485 | Router Solicit | Link Local | MUST NOT(6) | 486 +-------------------+------------+-----------------+ 487 | Router Advert | Link Local | MUST NOT(6) | 488 +-------------------+------------+-----------------+ 489 | Neighbour Solicit | Link Local | MUST NOT(6) | 490 +-------------------+------------+-----------------+ 491 | Neighbour Advert | Link Local | MUST NOT(6) | 492 +-------------------+------------+-----------------+ 493 | Router Renumbering| End-to-End | MAY(4) | 494 +-------------------+------------+-----------------+ 496 Explanations: 498 (1) These error messages have an end-to-end nature but may be gener� 499 ated by intermediate routers as well. 501 (2) This MAY have to be considered by implementations that wish to 502 base failover decisions on the Unreachable message. 504 (3) These messages have an impact on the success of IKE messages e.g. 505 when certificates are passed in IKE packets. It MUST be possible for 506 policies to be configured so that these messages can be received while 507 the IKE negotiations are still ongoing. Different security policy con� 508 figurations MUST be supported, including trusting cleartext messages 509 or protecting the messages from intermediate nodes using other, new 510 dynamic SA negotiations. 512 (4) These messages MAY be treated using regular IPsec and/or IKE pro� 513 cessing. 515 (5) This message SHOULD NOT use IKE in order to make their treatment 516 equal with the rest of the link local messages, but in theory Redirect 517 MAY be handled differently, e.g. using dynamic SAs. 519 (6) These messages MUST NOT use dynamic SAs. 521 These policy rules may be expressed in various ways on a particular 522 host or a router. It is necessary to use the ICMPv6 type in making the 523 policy decisions. As [4] states, "This is consistent with, although 524 not mentioned by, the Security Architecture specification". Only the 525 following requirement for all implementations is stated here. Products 526 that provide hardcoded security policies for ICMPv6 messages SHOULD 527 enable user specified policies to be expressed at a higher priority 528 level so that a possibility is still retained for modifying the rules 529 due to e.g. interoperability problems. 531 8. Further Work 533 This draft discusses the use of IPsec on ICMPv6 messages on a princi� 534 ple level. It does not take a stand on how the policies are expressed, 535 for instance whether IPsec products need to have hardcoded rules for 536 handling these messages, or whether the Security Policy Databases 537 should be general enough to make it possible to express the policies 538 in them even for the ICMPv6 messages. 540 This draft does not address stateful address autoconfiguration aspects 541 of IPv6. 543 This draft does not address the use of dynamic security associations 544 in the context of multicast traffic. Now that the multicast key man� 545 agement working group has been founded in the IETF, a question eventu� 546 ally arises whether or not the results of that work can be used to 547 protect the infrastructure multicast messages. 549 9. Acknowledgements 551 The author would like to thank Pekka Nikander, Markku Rossi, Tero 552 Kivinen, and Michael Richardson for interesting discussions in this 553 problem space. 555 10. References 557 [1] T. Narten, E. Nordmark, W. Simpson "Neighbor Discovery for IP Ver� 558 sion 6 (IPv6)" RFC 2461, IBM, Sun Microsystems, Daydreamer, December 559 1998. 561 [2] S. Thomson, T. Narten "IPv6 Stateless Address Autoconfiguration" 562 RFC 2462, Bellcore, IBM, December 1998. 564 [3] A. Conta, S. Deering "Internet Control Message Protocol (ICMPv6) 565 for the Internet Protocol Version 6 (IPv6) Specification" RFC 2463, 566 Lucent, Cisco Systems, December 1998. 568 [4] M. Crawford "Router Renumbering for IPv6" RFC 2894, Fermilab, 569 August 2000. 571 [5] J. McCann, S. Deering, J. Mogul "Path MTU Discovery for IP version 572 6" RFC 1981, Digital Equipment Corporation, Xerox PARC, August 1996. 574 [6] S. Kent, R. Atkinson "Security Architecture for the Internet Pro� 575 tocol" RFC 2401, BBN Corp, @Home Network, November 1998. 577 [7] D. Harkins and D. Carrel "The Internet Key Exchange", RFC 2409, 578 Cisco Systems, November 1998. 580 [8] J. Arkko, P. Nikander, T. Kivinen, M. Rossi "Manual SA Configura� 581 tion for IPv6 Link Local Messages", draft-arkko-manual- 582 icmpv6-sas-00.txt, Work In Progress, IETF, February 2001. 584 11. Author's Address 586 Jari Arkko 587 Oy LM Ericsson Ab 588 02420 Jorvas 589 Finland 591 Phone: +358 40 5079256 (hand) 592 +358 9 2992480 (desk) 593 EMail: Jari.Arkko@ericsson.com