idnits 2.17.1 draft-rja-ilnp-intro-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 948. -- Found old boilerplate from RFC 3978, Section 5.3 on line 950. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 945. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 63 has weird spacing: '...fferent class...' -- 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 (10 December 2008) is 5615 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CA-1995-01' is mentioned on line 648, but not defined == Missing Reference: 'BCP-38' is mentioned on line 666, but not defined == Missing Reference: 'RFC-3971' is mentioned on line 749, but not defined == Unused Reference: 'RFC-2119' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'MILCOM08' is defined on line 835, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-rja-ilnp-nonce-01 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-dns-01 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-icmp-00 -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 draft-rja-ilnp-intro-02.txt Extreme Networks 4 Expires: 10 JUN 2009 10 December 2008 5 Category: Experimental 7 ILNP Concept of Operations 8 draft-rja-ilnp-intro-02.txt 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-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 material 26 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/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This document is a contribution to the IRTF Routing Research Group. 35 It is NOT a contribution to the IETF or to any IETF Working Group 36 or to any IETF Area. 38 Abstract 40 This documents the Concept of Operations for an experimental 41 extension to IPv6 which is known as the Identifier Locator 42 Network Protocol (ILNP). 44 Table of Contents 46 1. Introduction ...............................................2 47 2. Transport Protocols.........................................4 48 3. Multi-Homing................................................5 49 4. Mobility....................................................6 50 5. Localised Addressing........................................7 51 6. IP Security Enhancements....................................8 52 7. DNS Enhancements............................................9 53 8. Backwards Compatibility....................................10 54 9. Incremental Deployment.....................................11 55 10. Security Considerations ...................................12 56 11. IANA Considerations .......................................16 57 12. References ................................................16 59 1. Introduction 61 At present, the IRTF Routing Research Group is studying different 62 approaches to evolving the Internet Architecture. Several 63 different classes of evolution are being considered. One class 64 is often called "Map and Encapsulate", where traffic would be 65 mapped and then tunnelled through the inter-domain core of the 66 Internet. Another class being considered is sometimes known as 67 "Identifier/Locator Split". This document relates to a proposal 68 that is in the latter class of evoluationary approaches. 70 There has been substantial research relating to naming in the 71 Internet through the years.[IEN-1][IEN-19][IEN-23][IEN-31][RFC-814] 72 [RFC-1498] More recently, and mindful of that important prior work, 73 the author has been examining enhancements to certain naming aspects 74 of the Internet Architecture.[MobiArch07][MobiWAC07] 76 This architectural concept derives originally from a note by Dave 77 Clark to the IETF mailing list suggesting that the IPv6 address 78 be split into separate Identifier and Locator fields. Afterwards, 79 Mike O'Dell persued this concept in Internet-Drafts describing "GSE" 80 or "8+8".[8+8][GSE] More recently, the IRTF Namespace Research Group 81 (NSRG) studied this matter. Unusually for an IRTF RG, the NSRG 82 operated on the principle that unanimity was required for the NSRG 83 to make a recommendation. The author was a member of the IRTF NSRG. 84 At least one other proposal, the Host Identity Protocol (HIP), also 85 derives in part from the IRTF NSRG studies (and related antecedant 86 work). This current proposal differs from O'Dell's work in various 87 ways. 89 The crux of this proposal is to split each 128-bit IPv6 address 90 into two separate fields, with crisp semantics for each. It is 91 worth remembering here that an IPv6 address names a specific 92 interface on a node, since the new scheme will be different in 93 that regard. 95 1 1 2 3 96 0 4 8 2 6 4 1 97 +---------------+-----------------+----------------+---------------+ 98 | Version| Traffic Class | Flow Label | 99 +---------------+-----------------+----------------+---------------+ 100 | Payload Length | Next Header | Hop Limit | 101 +---------------+-----------------+--------------------------------+ 102 | Source Address | 103 + + 104 | | 105 + + 106 | | 107 + + 108 | | 109 +---------------+-----------------+----------------+---------------+ 110 | Destination Address | 111 + + 112 | | 113 + + 114 | | 115 + + 116 | | 117 +---------------+-----------------+----------------+---------------+ 119 Figure 1: Existing ("Classic") IPv6 Header 121 The high-order 64-bits of the IPv6 address become the Locator. 122 The Locator indicates the subnetwork point of attachment for 123 a node. In essence, the Locator names a subnetwork. Locators 124 are also known as Routing Prefixes. 126 The low-order 64-bits of the IPv6 address become the Identifier. 127 The Identifier provides a fixed-length identity for a node, 128 rather than an identity for a specific interface of a node. 129 Identifiers are bound to nodes, not to interfaces, and are 130 in the same modified EUI-64 syntax already specified for 131 IPv6.[RFC-2460][RFC-4219][IEEE-EUI] 133 Identifiers are unique within the context of a given Locator; in many 134 cases, Identifiers might happen to be globally unique, but that is 135 not a functional requirement for this proposal. 137 1 1 2 3 139 0 4 8 2 6 4 1 140 +---------------+-----------------+----------------+---------------+ 141 | Version| Traffic Class | Flow Label | 142 +---------------+-----------------+----------------+---------------+ 143 | Payload Length | Next Header | Hop Limit | 144 +---------------+-----------------+----------------+---------------+ 145 | Source Locator | 146 + + 147 | | 148 +---------------+-----------------+----------------+---------------+ 149 | Source Identifier | 150 + + 151 | | 152 +---------------+-----------------+----------------+---------------+ 153 | Destination Locator | 154 + + 155 | | 156 +---------------+-----------------+----------------+---------------+ 157 | Destination Identifier | 158 + + 159 | | 160 +---------------+-----------------+----------------+---------------+ 162 Figure 2: Enhanced IPv6 Header 164 Most commonly, a node's set of Identifiers are derived from the 165 IEEE 802 or IEEE 1394 MAC addresses associated with that node. 166 This use of MAC addresses to generate Identifiers is convenient 167 and is not required. Other methods also might be used to generate 168 Identifiers. For example, one might derive Identifiers using 169 cryptographic-generation or using methods specified in the IPv6 170 Privacy Extensions to State-Less Address Auto-Configuration 171 (SLAAC). [RFC-3972, RFC-4941] 173 This proposal enhances the Internet Architecture by adding crisp 174 and clear semantics for the Identifier and for the Locator, 175 removing the semantically-muddled concept of the IP address, 176 and updating end system protocols slightly, without requiring 177 router changes. 179 With these naming enhancements, we have improved the architectural 180 support not only for multi-homing, but also for mobility, 181 localised addressing (e.g. NAT/NAPT), and IP Security. 183 2. Transport Protocols 185 At present, commonly deployed transport protocols include a 186 pseudo-header checksum that includes certain network-layer 187 fields, the IP addresses used for the session, in its 188 calculation. This inclusion of network-layer information 189 within the transport-layer session state creates issues for 190 multi-homing, mobility, IP Security, and localised 191 addressing (e.g. using Network Address Translation). 192 [RFC-1631][RFC-3022] 194 This unfortunate aspect of the TCP pseudo-header checksum 195 has been understood to be an architectural problem at least 196 since 1977, well before the transition from NCP to 197 IPv4.[IEN-1][IEN-19][IEN-23][IEN-31][RFC-1498] 199 With this proposal, transport protocols include only the 200 Identifier in their pseudo-header calculations, but do not 201 include the Locator in their pseudo-header calculations. 203 To minimise the changes required within transport protocol 204 implementations, when this proposal is in use for an IP 205 session, the Locator fields are zeroed before use by the 206 transport protocols. 208 Later in this document, methods for incremental deployment 209 of this change and backwards compatibility with non-upgraded 210 nodes are described. 212 3. Multi-Homing 214 Conceptually, there are two kinds of multi-homing. Site 215 multi-homing is when all nodes at a site are multi-homed at 216 the same time. This is what most people mean when they talk 217 about multi-homing. However, there is also a separate 218 concept of node multi-homing, where only a single node is 219 multi-homed. 221 At present, site multi-homing is common in the deployed 222 Internet. This is primarily achieved by advertising the 223 site's routing prefix(es) to more than upstream Internet 224 service provider at a given time. In turn, this requires 225 de-aggregation of routing prefixes within the inter-domain 226 routing system. In turn, this increases the entropy of the 227 inter-omain routing system (e.g. RIB/FIB size increases 228 beyond the minimal RIB/FIB size that would be required to 229 reach all sites). 231 At present, node multi-homing is not uncommon. When TCP 232 or UDP are in use for a session, node multi-homing cannot 233 provide session reslience, because the transport 234 pseudo-header checksum binds the session to a single 235 interface of the multi-homed node. It must be noted that 236 SCTP has a protocol-specific mechanism to support node 237 multi-homing; SCTP can support session resilience both at 238 present and also without change in the proposed approach. 240 In the new scheme, when a node is multi-homed, it has more 241 than one valid Locator value. When one upstream connection 242 fails, the node sends an ICMP Locator Update message to each 243 existing correspondent node to remove the no-longer-valid 244 Locator from the set of valid Locators. [ILNP-ICMP] Also, 245 the node will use Secure Dynamic DNS Update to alter the set 246 of currently valid L records associated with that node. 247 [RFC-3007] This second step ensures that any new 248 correspondents can reach the node. 250 In the new scheme, site multi-homing works in a similar 251 manner, with nodes having one Locator for each upstream 252 connection to the Internet. To avoid a DNS Update burst 253 when a site or subnetwork moves location, a DNS record 254 optimisation is possible. This would change the number of 255 DNS Updates required from Order(number of nodes at the 256 site/subnetwork that moved) to Order(1).[ILNP-DNS] 258 Additionally, since the transport-protocol session state 259 no longer includes the Locators, a site could choose to 260 perform Locator rewriting at its site border routers, 261 possibly in combination with applying site traffic engineering 262 policy on which upstream link to use for which packets. 263 Since the site border router(s) are in the middle of any 264 exterior packet flow, they also can send proxy Locator 265 Update messages on behalf of nodes inside that site, 266 and can even include the appropriate Nonce value in such 267 proxy Locator Updates, if desired by that site's 268 administration. 270 4. Mobility 272 First, note well that mobiity and multi-homing actually present 273 the same set of issues. In each case, the set of Locators 274 associated with a node or site changes. The reason for the 275 change might be different, but the effects on the network and 276 on correspondents is identical. 278 There are no standardised mechanisms to update most transport 279 protocols with new IP addresses in use for the session. 280 Exceptionally, the Stream Control Transport Protocol (SCTP) 281 recently added this capability.[RFC-5061] 283 This creates various issues for mobility. For example, there is 284 no method at present to update the IP addresses associated with 285 a transport layer session when one of the nodes in that session 286 moves (i.e. changes one of its points of network attachment). 288 So, the several approaches to IP mobility seek to hide the change 289 in location (and corresponding change in IP addresses) via 290 tunnelling, home agents, foreign agents, and so forth.[RFC-3775] 291 All of this can add substantial complexity to IP mobility 292 approaches, both in the initial deployment and also in ongoing 293 operation. 295 By contrast, this ILNP proposal hides each node's location 296 information from the transport layer protocols at all times, 297 by removing location information from the transport session 298 state (e.g. pseudo-header checksum calculations). 300 In this proposal, mobility is supported using the same 301 mechanisms as multihoming. Both cases use Locator values to 302 identify different IP subnetworks. To handle the move of a 303 node, we add a new ICMP control message. The ICMP Locator 304 Update message is used by a node to inform its existing 305 correspondents that the set of valid Locators for the node 306 has changed. This mechanism can be used to add newly valid 307 Locators, to remove no longer valid Locators, or to do both 308 at the same time. Further, the node uses Secure Dynamic DNS 309 Update to correct the set of L records in the DNS for that 310 node. This enables any new correspondents to correctly 311 initiate a new session with the node at its new location. 312 This use of DNS for initial rendezvous with mobile node was 313 independently proposed by others [PHG02] and then separately 314 by the current author later on. 316 Note that we can (and do) treat network mobility (as well as 317 node mobility) as a special case of multihoming. That is, 318 when a network moves, it uses a new Locator value for all of 319 its communications sessions. So, the same mechanism, using 320 a new or additional Locator value, also supports network 321 mobility. 323 So in ILNP, when a connectivity change affects the set of 324 valid Locators, the affected node(s) actively update their 325 correspondents with the updated information and also update 326 their DNS entries. This combination eliminates the need for 327 network probing to discover how to reach an existing 328 correspondent that has moved (or whose connectivity has developed 329 a fault). Middleboxes do not need to participate for this 330 to succeed. 332 5. Localised Addressing 334 As the Locator value no longer forms part of the node session state 335 (e.g. TCP pseudo-header), it is easier to implement localised 336 addressing based on the use of local values of the Locator. This 337 would be either in place of, or to supplement, existing NAT-based 338 schemes.[RFC-1631] [RFC-3022] For example, some form of IPv6 Unique 339 Local Addressing (ULA) might be used for localised addressing along 340 with some form of IPv6 network address translation at a site border 341 gateway.[ID-ULA][RFC-4193] 343 In the simplest case, an ILNP capable NAT only would need to change 344 the value of the Source Locator in an outbound packet, and the 345 value of the Destination Locator for an inbound packet. Identifier 346 values would not need to change, so a true end-to-end session 347 could be maintained. 349 If a site using localised addressing chooses to deploy a 350 split-horizon DNS server, then all internal nodes would advertise 351 the global-scope Locator(s) of the site border routers outside 352 the site and would advertise the local-scope Locator(s) specific 353 to that internal node inside the site. Such deployments of 354 split-horizon DNS servers are not unusual in the IPv4 Internet 355 today. 357 If a site using localised addressing chooses not to deploy 358 a split-horizon DNS server, then all internal nodes would advertise 359 the global-scope Locator(s) of the site border routers. To deliver 360 packets from one internal node to another internal node, the site 361 would either choose to use layer-2 bridging (e.g. IEEE Spanning Tree, 362 IEEE Rapid Spanning Tree, or a link-state layer-2 algorithm such as 363 the IETF TRILL group or IEEE 802.1 are developing), or the interior 364 routers would forward packets up to the nearest site border router, 365 which in turn would then rewrite the Locators to appropriate 366 local-scope values, and forward the packet towards the interior 367 destination node. 369 Please note that with this proposal, localised addressing 370 (e.g. using Network Address Translation on the Locator bits) 371 would work in harmony with multihoming, mobility, and IP 372 Security.[MobiWAC07] 374 6. IP Security Enhancements 375 A current issue is that the IP Security protocols, AH and ESP, 376 have Security Associations that include the IP addresses of 377 the secure session endpoints. This was understood to be a 378 problem when AH and ESP were originally defined, however the 379 limited set of namespaces in the Internet Architecture did not 380 provide any better choices at that time. 382 Operationally, this binding causes problems for the use of 383 the IPsec protocols through Network Address Translation 384 devices, with mobile nodes (because the mobile node's IP 385 address changes at each network-layer handoff), and with 386 multi-homed nodes (because the session is bound to a 387 particular interface of the multi-homed node, rather than 388 being bound to the node itself).[RFC-3027][RFC-3715] 390 To resolve the issue of IPsec interoperability through 391 a NAT deployment, UDP encapsulation of IPsec is commonly 392 used today.[RFC-3948] 394 With this proposal, the IP Security protocols, AH and ESP, 395 are enhanced to bind Security Associations only to 396 Identifier values and never to Locator values (and also not 397 to an entire 128-bit IPv6 address). 399 Similarly, key management protocols used with IPsec would be 400 enhanced to deprecate use of IP addresses as identifiers and 401 to substitute the use of the new Identifier for that 402 purpose. 404 This small change enables IPsec to work in harmony with 405 multihoming, mobility, and localised addressing. Further, 406 it would obviate the need for specialised IPsec NAT 407 Traversal mechanisms, thus simplifying IPsec implementations 408 while enhancing deployability and interoperability. 409 [RFC-3948] 411 This change does not reduce the security provided by the IP 412 Security protocols. 414 7. DNS Enhancements 416 As part of this proposal, additional DNS Resource Records have 417 been proposed in a separate document. [ILNP-DNS] These new 418 records store the Identifier and Locator values for nodes that 419 have been upgraded to support the Identifier-Locator Split Mode. 421 With this proposal, mobile or multi-homed nodes and sites are 422 expected to use the existing widely implemented "Secure Dynamic 423 DNS Update" protocol to keep their Identifier and Locator records 424 correct in its authoritative DNS server(s). [RFC-3007] 426 Reverse DNS lookups, to find a node's Fully Qualified Domain Name 427 from the combination of a Locator and related Identifier value, 428 can be performed as at present. 430 Previous research by others indicates that DNS caching is largely 431 ineffective, with the exception of NS records and the addresses 432 of DNS servers referred to by NS records.[SBK2002] This means DNS 433 caching performance will not be adversely affected by assigning 434 very short time-to-live (TTL) values to the Locator records of 435 typical nodes. It also means that it is preferable to deploy the 436 DNS server function on nodes that have longer TTL values, rather 437 than on nodes that have shorter TTL values. 439 Identifier values might be very long-lived (e.g. days) when they 440 have been generated from an IEEE MAC Address on the system or 441 are cryptographically-generated, or they might have a moderate 442 lifetime (e.g. hours) when they have been created by the 443 IPv6 Privacy Extensions or some other method that regularly 444 generates new Identifier values over time. 446 Existing DNS specifications require that DNS clients and DNS 447 resolvers obey the TTL values provided by the DNS servers. In 448 the context of this proposal, short DNS TTL values are assigned 449 to particular DNS records to ensure that the ubiquitous DNS 450 caching resolvers do not cache volatile values (e.g. Locator 451 records of a mobile node) and consequently return stale 452 information to new requestors. 454 As a practical matter, it is not sensible to flush all Locator 455 values associated with an existing session's remote node from the 456 local node's I/L Session Cache. Instead, Locator values should 457 be marked as "aged" when their TTL has expired until the next 458 Locator Update message is received or there is other indication 459 that a given Locator is not working any longer. 461 During a long transition period, a node that is I/L-enabled 462 should have not only I and L records present in its 463 authoritative DNS server, but also should have AAAA records 464 for the benefit of non-upgraded nodes. This capability might 465 be implemented strictly inside a DNS server, whereby the DNS 466 server synthesised a set of AAAA records to advertise from 467 the I and L values that the node has kept updated in that 468 DNS server. 470 Existing DNS specifications require that a DNS resolver or DNS 471 client ignore unrecognised DNS record types. So gratuitously 472 appending I and L records as "additional data" in DNS responses 473 to AAAA queries is not expected to create any operational issues. 475 8. Backwards Compatibility 477 First, if one comapres Figure 1 and Figure 2, one can see 478 that IPv6 with the Identifier/Locator Split enhancement is 479 fully backwards compatible with existing IPv6. This means 480 that no router software or silicon changes are necessary to 481 support the proposed enhancements. A router would be 482 unaware whether the packet being forwarded were classic IPv6 483 or the proposed enhanced version of IPv6. So no changes to 484 IPv6 routers is required to deploy this proposal. 486 Further, IPv6 Neighbour Discovery should work fine without 487 any significant protocol changes. 489 If a node that has been enhanced to support the Identifier/ 490 Locator Split mode initiates an IP session with another 491 node, normally it will first perform a DNS lookup on the 492 responding node's DNS name. If the inititator node does not 493 find any new I and L DNS resource records for the responder 494 node, then the initiator uses the Classical IPv6 mode of 495 operation for the new session with the responder, rather 496 than trying to use the I/L Split mode for that session. 498 If the responder node for a new IP session has not been 499 enhanced to support the I/L Split mode and receives initial 500 packet(s) containing the Nonce Destination Option, the 501 responder will drop the packet and send an ICMP Parameter 502 Problem error message back to the initiator. 504 If the initiator node does not receive a response from the 505 responder in a timely manner (e.g. within TCP timeout for a 506 TCP session) and also does not receive an ICMP Unreachable 507 error message for that packet, OR if the initiator receives 508 an ICMP Parameter Problem error message for that packet, 509 then the initiator knows that the responder is not able to 510 support the I/L Split Operating mode. In this case, the 511 initiator node should try again to create the new IP session 512 but this time OMITTING the Nonce Destination Option, and 513 this time operating in Classic IPv6 mode, rather than I/L 514 Split mode. 516 The existing BSD Sockets API can continue to be used. That 517 API can be implemented in a manner that hides the underlying 518 protocol changes from the applications. So it is believed 519 that existing IP address referrals can continue to work 520 properly in most cases. For a rapidly moving target 521 node, referrals might break in at least some cases. 522 The potential for referral breakage is necessarily 523 dependent upon the specific application and implementation 524 being considered. 526 (We note, however, that a more architecturally sensible 527 approach to referrals would be to use Fully-Qualified Domain 528 Names (FQDNs), as is commonly done today with web URLs. 529 This is true even with the deployed IPv4 or IPv6 Internet.) 531 It is suggested, however, that a new, optional, more 532 abstract, API be created so that new applications do not 533 have to delve needlessly into low-level details of the 534 underlying network protocols. 536 9. Incremental Deployment 538 If a node has been enhanced to support the Identifier/ 539 Locator Split operating mode, that node's fully-qualified 540 domain name will normally have one or more I records and one 541 or more L records associated with it in the DNS. 543 When a host ("initiator") initiates a new IP session with a 544 correspondent ("responder"), it normally will perform a DNS 545 lookup to determine the address(es) of the responder. A 546 host that has been enhanced to support the Identifier/ 547 Locator Split operating mode normally will look for 548 Identifier ("I") and Locator ("L") records in any received 549 DNS replies. DNS servers that support I and L records 550 should include them (when they exist) as additional data in 551 all DNS replies to queries for DNS AAAA records.[ILNP-DNS] 553 If the initiator supports the I/L Split mode and from DNS 554 information learns that the responder also supports the I/L 555 Split mode, then the initiator will generate an unpredictable 556 nonce value, store that value in a local Correspondent Cache, 557 and will include the Nonce Destination Option in its initial 558 packet(s) to the responder.[ILNP-Nonce] 560 If the responder supports the I/L Split mode and receives 561 initial packet(s) containing the Nonce Destination Option, 562 the responder will thereby know that the initiator supports 563 the I/L Split mode and the responder will also operate in 564 I/L Split mode for this new IP session. 566 If the responder supports the I/L Split mode and receives 567 initial packet(s) NOT containing the Nonce Destination Option, 568 the responder will thereby know that the initiator does NOT 569 support the I/L Split mode and the responder will operate 570 in classic IPv6 mode for this new IP session. 572 The previous section described how interoperability between 573 enhanced nodes and non-enhanced nodes is retained even if a 574 non-enhanced node erroneously has I and L DNS resource 575 records in place (e.g. due to some accident). 577 10. Security Considerations 579 This proposal outlines a proposed evolution for the 580 Internet Architecture to provide improved capabilities. 581 This section discusses security considerations for 582 this proposal. 584 10.1 Authentication of Locator Updates 586 A separate document [ILNP-Nonce] proposed a new IPv6 587 Destination Option that can be used to carry a session nonce 588 end-to-end between communicating nodes. That nonce provides 589 protection against off-path attacks on an Identifier/Locator 590 session. The Nonce Destination Option is used ONLY for IP 591 sessions in the Identifier/Locator Split mode. 593 Ordinary IPv6 is vulnerable to on-path attacks unless 594 the IP Authentication Header or IP Encapsulating Security 595 Payload is in use. So the Nonce Destination Option 596 only seeks to provide protection against off-path attacks 597 on an IP session -- equivalent to ordinary IPv6 when 598 not using IP Security. 600 When the Identifier/Locator split mode is in use for an 601 existing IP session, the Nonce Destination Option must be 602 included in any ICMP control messages (e.g. ICMP Unreachable, 603 ICMP Locator Update) sent with regard to that IP session. 605 It is common to have non-symmetric paths between 606 two nodes on the Internet. To reduce the number 607 of on-path nodes that know the Nonce value for 608 a given session when the I/L split mode is in use, 609 separate nonce values are used in each direction. 610 For example, for a session between two nodes A and B, 611 one nonce value is used from A to B and a different 612 nonce value is used from B to A. 614 When in the I/L Split operating mode for an existing IP 615 session, ICMP control messages received without a Nonce 616 Destination Option must be discarded as forgeries. This 617 security event should be logged. 619 When in the I/L Split operating mode for an existing IP 620 session, ICMP control messages received without a correct 621 nonce value inside the Nonce Destination Option must be 622 discarded as forgeries. This security event should be logged. 624 When in the I/L Split operating mode for an existing IP 625 session, and a node changes its Locator set, it should 626 include the Nonce Destination Option in the first few 627 data packets sent using a new Locator value, so that 628 the recipient can validate the received data packets 629 as valid (despite having an unexpected Source Locator 630 value). 632 For ID/Locator Split mode sessions operating in higher risk 633 environments, the use of the cryptographic authentication 634 provided by IP Authentication Header is recommended 635 *in addition* to concurrent use of the Nonce Destination 636 Option. 638 It is important to note that at present an IPv6 session 639 is entirely vulnerable to on-path attacks unless IPsec 640 is in use for that particular IPv6 session, so the security 641 properties of the new proposal are never worse than 642 for existing IPv6. 644 10.2 Forged Identifier Attacks 646 In the deployed Internet, active attacks using packets with a 647 forged Source IP Address have been publicly known at least since 648 early 1995.[CA-1995-01] While these exist in the deployed 649 Internet, they have not been widespread. This is equivalent to 650 the issue of a forged Identifier value and demonstrates that this 651 is not a new threat created by the Identifier/Locator-split mode 652 of operation. 654 One mitigation for these attacks has been to deploy Source IP 655 Address Filtering.[BCP-38] Jun Bi at U. Tsinghua cites Arbor 656 Networks as reporting that this mechanism has less than 50% 657 deployment and cites an MIT analysis indicating that at least 25% 658 of the deployed Internet permits forged source IP addresses. 660 Other parts of this document discuss the probability of an 661 accidental duplicate Identifier being used on the Internet. 662 However, this sub-section instead focuses on methods for 663 mitigating attacks based on packets containing deliberately 664 forged Source Identifier values. 666 First, the recommendations of [BCP-38] remain. Packets that 667 have a forged Locator value can be easily filtered using 668 existing widely available mechanisms. 670 Second, the receiving node does not blindly accept any packet 671 with the proper Source Identifier and proper Destination 672 Identifier as an authentic packet. Instead, each node operating 673 the I/L-split mode maintains a session cache for each of its 674 correspondents. This cache contains two unidirectional nonce 675 values (one used in control messages sent by this node, a 676 different one used to authenticate messages from the other node). 677 The cache also contains the currently valid set of Locators 678 and set of Identifiers for each correspondent node. If a 679 received packet contains valid Identifier values and a valid 680 Destination Locator, but contains a Source Locator value that 681 is not present in the session cache, the packet is dropped 682 without further processing as an invalid packet, unless the 683 packet also contains a Nonce Destination Option with the 684 correct value used for packets from the node with that 685 Source Identifier to this node. This prevents an off-path 686 attacker from stealing an existing session. 688 Third, any node can distinguish different nodes using the same 689 Identifier value by other properties of their sessions. IPv6 690 Neighbor Discovery prevents more than one node from using the 691 same source (Locator + Identifier) pair at the same time. So 692 cases of different nodes using the same Identifier value will 693 involve nodes that have different sets of valid Locator values. 694 A node can thus demux based on the combination of Source Locator 695 and Source Identifier if necessary. If IP Security is in use, 696 the combination of the Source Identifier and the SPI value would 697 be sufficient to demux two different sessions. 699 Finally, deployments in high threat environments also should use 700 the IP Authentication Header to authenticate control traffic and 701 data traffic. Because in the I/L-split mode, IP Security binds 702 only to the Identifier values, and never to the Locator values, 703 this enables a mobile or multi-homed node to use IPsec even when 704 its Locator value(s) have just changed. 706 10.3 IP Security Enhancements 708 The IP Security standards are enhanced here by binding IPsec 709 Security Associations to the Identifiers of the session 710 endpoints, rather than binding IPsec Security Associations 711 to the IP Addresses as at present. This change enhances the 712 deployability and interoperability of the IP Security 713 standards, but does not decrease the security provided by 714 those protocols. 716 10.4 DNS Security 718 The DNS enhancements proposed here are entirely compatible 719 with, and can be protected using, the existing IETF 720 standards for DNS Security.[RFC-4033] The Secure DNS Dynamic 721 Update mechanism used here is also used unchanged.[RFC-3007] 722 So there is no change to the security properties of the 723 Domain Name System. 725 10.5 Firewall Considerations 727 In the proposed new scheme, firewalls are able to 728 authenticate ICMP control messages arriving on the external 729 interface. This enables more thoughtful handling of ICMP 730 messages by firewalls than is commonly the case at present. 731 As the firewall is along the path between the communicating 732 nodes, the firewall can snoop on any Session Nonce being 733 carried in the initial packets of an I/L Split mode session. 734 The firewall can verify that nonce is present on incoming 735 control packets, dropping any control packets that lack the 736 correct nonce value. 738 By always including the nonce, even when IP Security is also in 739 use, the firewall can filter out all off-path attacks. In this 740 case, a forged packet from an on-path attacker will still be 741 detected when the IPsec input processing occurs in the receiving 742 node; this will cause that forged packet to be dropped rather 743 than acted upon. 745 10.6 Neighbor Discovery Authentication 747 Nothing in this proposal prevents sites from using 748 the Secure Neighbor Discovery (SEND) proposal for 749 authenticating IPv6 Neighbor Discovery. [RFC-3971] 751 11. IANA Considerations 753 This document has no IANA considerations. 755 12. References 757 This section provides both normative and informative 758 references relating to this note. 760 12.1. Normative References 762 [RFC-2119] Bradner, S., "Key words for use in RFCs to 763 Indicate Requirement Levels", BCP 14, RFC 2119, 764 March 1997. 766 [RFC-2460] S. Deering & R. Hinden, "Internet Protocol 767 Version 6 Specification", RFC-2460, 768 December 1998. 770 [RFC-3007] B. Wellington, "Secure Domain Name System 771 Dynamic Update", RFC-3007, November 2000. 773 [RFC-4033] R. Arends, et alia, "DNS Security Introduction 774 and Requirements", RFC-4033, March 2005. 776 [RFC-4219] R. Hinden & S. Deering, "IP Version 6 777 Addressing Architecture", RFC-4219, February 778 2006. 780 12.2. Informative References 782 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 783 Architecture for IPv6", Internet-Draft, 784 October 1996. 786 [GSE] M. O'Dell, "GSE - An Alternate Addressing 787 Architecture for IPv6", Internet-Draft, 788 February 1997. 790 [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally 791 Assigned Unique Local IPv6 Unicast Addresses", 792 draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. 794 [IEEE-EUI] IEEE Standards Association, "Guidelines for 795 64-bit Global Identifier (EUI-64)", IEEE, 796 2007. 798 [IEN-1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, 799 "Issues in the Interconnection of Datagram 800 Networks", Internet Experiment Note (IEN) 1, 801 INDRA Note 637, PSPWN 76, University College 802 London, 29 July 1977. 803 http://www.postel.org/ien/ien001.pdf 805 [IEN-19] J. F. Shoch, "Inter-Network Naming, Addressing, 806 and Routing", IEN-19, January 1978. 808 [IEN-23] J. F. Shoch, "On Names, Addresses, and 809 Routings", IEN-23, January 1978. 811 [IEN-31] D. Cohen, "On Names, Addresses, and Routings 812 (II)", IEN-31, April 1978. 814 [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", 815 draft-rja-ilnp-nonce-01.txt, December 2008. 817 [ILNP-DNS] R. Atkinson, "Additional DNS Resource Records", 818 draft-rja-ilnp-dns-01.txt, December 2008. 820 [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" 821 draft-rja-ilnp-icmp-00.txt, December 2008. 823 [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes, 824 "Mobility as an Integrated Service Through 825 the Use of Naming", Proceedings of 826 ACM MobiArch 2007, August 2007, 827 Kyoto, Japan. 829 [MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes, 830 "A Proposal for Unifying Mobility with 831 Multi-Homing, NAT, & Security", 832 Proceedings of ACM MobiWAC 2007, Chania, 833 Crete. ACM, October 2007. 835 [MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes, 836 "Harmonised Resilience, Security, and Mobility 837 Capability for IP", Proceedings of IEEE 838 Military Communications Conference, 839 San Diego, CA, USA, November 2008. 841 [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, 842 "Mobile Host Location Tracking through DNS", 843 Proceedings of IEEE London Communications 844 Symposium, IEEE, September 2002, London, 845 England, UK. 847 [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 848 Kaashoek, "Reconsidering Internet Mobility", 849 Proceedings of 8th Workshop on Hot Topics in 850 Operating Systems, 2002. 852 [RFC-814] D.D. Clark, "Names, Addresses, Ports, and 853 Routes", RFC-814, July 1982. 855 [RFC-1498] J.H. Saltzer, "On the Naming and Binding of 856 Network Destinations", RFC-1498, August 1993. 858 [RFC-1631] K. Egevang & P. Francis, "The IP Network 859 Address Translator (NAT)", RFC-1631, May 1994. 861 [RFC-3022] P. Srisuresh & K. Egevang, "Traditional IP 862 Network Address Translator", RFC-3022, 863 January 2001. 865 [RFC-3027] M. Holdrege and P Srisuresh, "Protocol 866 Complications of the IP Network Address 867 Translator", RFC-3027, January 2001. 869 [RFC-3715] B. Aboba and W. Dixon, "IPsec-Network Address 870 Translation (NAT) Compatibility Requirements", 871 RFC-3715, March 2004. 873 [RFC-3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility 874 Support in IPv6", RFC-3775, June 2004. 876 [RFC-3948] A. Huttunen, et alia, "UDP Encapsulation of 877 IPsec ESP Packets", RFC-3948, January 2005. 879 [RFC-3972] T. Aura, "Cryptographically Generated Addresses 880 (CGAs)", RFC-3972, March 2005. 882 [RFC-4193] R. Hinden & B. Haberman, "Unique Local IPv6 883 Unicast Addresses, RFC-4193, October 2005. 885 [RFC-4941] T. Narten, R. Draves, & S. Krishnan, "Privacy 886 Extensions for Stateless Address Autoconfiguration 887 in IPv6", RFC-4941, September 2007. 889 [RFC-5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & 890 M. Kozuka, "Stream Control Transmission Protocol 891 (SCTP) Dynamic Address Reconfiguration", RFC-5061, 892 September 2007. 894 (Additional references to be added later.) 896 Author's Address 898 R. Atkinson 899 Extreme Networks 900 3585 Monroe Street 901 Santa Clara, CA 902 95051 USA 903 Telephone: +1 (408)579-2800 904 Email: rja@extremenetworks.com 906 Full Copyright Statement 908 Copyright (C) The IETF Trust (2008). 910 This document is subject to the rights, licenses and restrictions 911 contained in BCP 78, and except as set forth therein, the authors 912 retain all their rights. 914 This document and the information contained herein are provided 915 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 916 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 917 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 918 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 919 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 920 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 921 OR FITNESS FOR A PARTICULAR PURPOSE. 923 Intellectual Property 925 The IETF takes no position regarding the validity or scope of any 926 Intellectual Property Rights or other rights that might be claimed 927 to pertain to the implementation or use of the technology 928 described in this document or the extent to which any license 929 under such rights might or might not be available; nor does it 930 represent that it has made any independent effort to identify any 931 such rights. Information on the procedures with respect to 932 rights in RFC documents can be found in BCP 78 and BCP 79. 934 Copies of IPR disclosures made to the IETF Secretariat and any 935 assurances of licenses to be made available, or the result of an 936 attempt made to obtain a general license or permission for the use 937 of such proprietary rights by implementers or users of this 938 specification can be obtained from the IETF on-line IPR repository 939 at http://www.ietf.org/ipr. 941 The IETF invites any interested party to bring to its attention 942 any copyrights, patents or patent applications, or other 943 proprietary rights that may cover technology that may be required 944 to implement this standard. Please address the information to the 945 IETF at ietf-ipr@ietf.org. 947 This document may not be modified, and derivative works of it 948 may not be created. 950 This document may only be posted in an Internet-Draft. 952 Expires: 10 June 2009