idnits 2.17.1 draft-irtf-rrg-ilnp-icmpv4-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 257 has weird spacing: '...of Locs vali...' == Line 260 has weird spacing: '...of Locs rela...' == Line 268 has weird spacing: '...of Locs part...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 July 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4984' is mentioned on line 104, but not defined -- Looks like a reference, but probably isn't: '1' on line 232 -- Looks like a reference, but probably isn't: '2' on line 236 == Unused Reference: 'RFC2780' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC4884' is defined on line 474, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RJ Atkinson 3 draft-irtf-rrg-ilnp-icmpv4-06.txt Consultant 4 Expires: 10 JAN 2013 SN Bhatti 5 Category: Experimental U. St Andrews 6 10 July 2012 8 ICMP Locator Update message for ILNPv4 9 draft-irtf-rrg-ilnp-icmpv4-06.txt 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 Copyright (c) 2012 IETF Trust and the persons identified as the 16 document authors. All rights reserved. 18 This document is subject to BCP 78 and the IETF Trust's Legal 19 Provisions Relating to IETF Documents 20 (http://trustee.ietf.org/license-info) in effect on the date of 21 publication of this document. Please review these documents 22 carefully, as they describe your rights and restrictions with 23 respect to this document. Code Components extracted from this 24 document must include Simplified BSD License text as described in 25 Section 4.e of the Trust Legal Provisions and are provided 26 without warranty as described in the Simplified BSD License. 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 This document may contain material from IETF Documents or 32 IETF Contributions published or made publicly available 33 before November 10, 2008. The person(s) controlling the copyright 34 in some of this material may not have granted the IETF Trust the 35 right to allow modifications of such material outside the IETF 36 Standards Process. Without obtaining an adequate license from 37 the person(s) controlling the copyright in such materials, this 38 document may not be modified outside the IETF Standards Process, 39 and derivative works of it may not be created outside the IETF 40 Standards Process, except to format it for publication as an RFC 41 or to translate it into languages other than English. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as 46 Internet-Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other 50 documents at any time. It is inappropriate to use Internet-Drafts 51 as reference material or to cite them other than as "work in 52 progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/1id-abstracts.html 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 This document is not on the IETF standards-track and does not 61 specify any level of standard. This document merely provides 62 information for the Internet community. 64 This document is part of the ILNP document set, which has had 65 extensive review within the IRTF Routing Research Group. ILNP is 66 one of the recommendations made by the RG Chairs. Separately, 67 various refereed research papers on ILNP have also been published 68 during this decade. So the ideas contained herein have had much 69 broader review than the IRTF Routing RG. The views in this 70 document were considered controversial by the Routing RG, but the 71 RG reached a consensus that the document still should be 72 published. The Routing RG has had remarkably little consensus on 73 anything, so virtually all Routing RG outputs are considered 74 controversial. 76 Abstract 78 This note defines an experimental ICMP message type for IPv4 used 79 with the Identifier-Locator Network Protocol (ILNP). The 80 Identifier-Locator Network Protocol (ILNP) is an experimental, 81 evolutionary enhancement to IP. The ICMP message defined herein 82 is used to dynamically update Identifier/Locator bindings for an 83 existing ILNP session. This is a product of the IRTF Routing RG. 85 Table of Contents 87 1. Introduction.............................2 88 1.1 ILNP Document Roadmap..................3 89 1.2 ICMPv4 Locator Update..................3 90 1.3 Terminology............................3 91 2. ICMP Locator Update message for ILNPv4...4 92 3. Transport Protocol Effects...............5 93 4. Implementation Considerations............6 94 5. Backwards Compatibility..................6 95 6. Security Considerations..................6 96 7. IANA Considerations......................7 97 8. References...............................7 99 1. INTRODUCTION 101 At present, the Internet research and development community are 102 exploring various approaches to evolving the Internet 103 Architecture to solve a variety of issues including, but not 104 limited to, scalability of inter-domain routing [RFC4984]. A wide 105 range of other issues (e.g. site multi-homing, node multi-homing, 106 site/subnet mobility, node mobility) are also active concerns at 107 present. Several different classes of evolution are being 108 considered by the Internet research & development community. One 109 class is often called "Map and Encapsulate", where traffic would 110 be mapped and then tunnelled through the inter-domain core of the 111 Internet. Another class being considered is sometimes known as 112 "Identifier/Locator Split". This document relates to a proposal 113 that is in the latter class of evolutionary approaches. 115 The Identifier Locator Network Protocol (ILNP) is a proposal for 116 evolving the Internet Architecture. It differs from the current 117 Internet Architecture primarily by deprecating the concept of an 118 IP Address, and instead defining two new objects, each having 119 crisp syntax and semantics. The first new object is the Locator, 120 a topology-dependent name for a subnetwork. The other new object 121 is the Identifier, which provides a topology-independent name for 122 a node. 124 1.1 Document roadmap 126 This document describes a new ICMPv4 Locator Update message 127 used by an ILNP node to inform its correspondent nodes 128 of any changes to its set of valid Locators. 130 The ILNP architecture can have more than one engineering 131 instantiation. For example, one can imagine a "clean-slate" 132 engineering design based on the ILNP architecture. In separate 133 documents, we describe two specific engineering instances of 134 ILNP. The term ILNPv6 refers precisely to an instance of ILNP that 135 is based upon, and backwards compatible with, IPv6. The term ILNPv4 136 refers precisely to an instance of ILNP that is based upon, and 137 backwards compatible with, IPv4. 139 Many engineering aspects common to both ILNPv4 and ILNPv6 are 140 described in [ILNP-ENG]. A full engineering specification for 141 either ILNPv6 or ILNPv4 is beyond the scope of this document. 143 Readers are referred to other related ILNP documents for details 144 not described here: 146 a) [ILNP-ARCH] is the main architectural description of ILNP, 147 including the concept of operations. 149 b) [ILNP-ENG] describes engineering and implementation 150 considerations that are common to both ILNPv4 and ILNPv6. 152 c) [ILNP-DNS] defines additional DNS resource records that 153 support ILNP. 155 d) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 156 used by an ILNP node to inform its correspondent nodes 157 of any changes to its set of valid Locators. 159 e) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option 160 used by ILNPv6 nodes (1) to indicate to ILNP correspondent 161 nodes (by inclusion within the initial packets of an ILNP 162 session) that the node is operating in the ILNP mode and 163 (2) to prevent off-path attacks against ILNP ICMP messages. 164 This Nonce is used, for example, with all ILNP ICMPv6 165 Locator Update messages that are exchanged among ILNP 166 correspondent nodes. 168 f) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4 169 nodes to carry a security nonce to prevent off-path attacks 170 against ILNP ICMP messages and also defines a new IPv4 171 Identifier Option used by ILNPv4 nodes. 173 g) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 175 h) [ILNP-ADV] describes optional engineering and deployment 176 functions for ILNP. These are not required for the operation 177 or use of ILNP and are provided as additional options. 179 1.2 ICMPv4 Locator Update 181 As described in [ILNP-ARCH] and [ILNP-ENG], an ILNP for IPv4 182 (ILNPv4) node might need to inform correspondent ILNPv4 nodes of 183 changes to the set of valid Locator values. The new ICMPv4 184 Locator Update message described in this document enables an 185 ILNP-capable node to update its correspondents about the 186 currently valid set of Locators valid to use in reaching the node 187 sending this message [RFC2460] [RFC4443]. 189 This new ICMPv4 message MUST ONLY be used for ILNPv4 sessions. 190 Authentication is always required, as described in the Security 191 Considerations section later in this note. 193 Some might consider any and all use of ICMP to be undesirable. 195 In that context, please note that while this specification uses 196 ICMP, on grounds that this is a control message, there is no 197 architectural difference between using ICMP and using some 198 different framing, for example UDP. 200 1.3 Terminology 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 203 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described 205 in RFC 2119. [RFC2119] 207 2. ICMP Locator Update message for ILNPv4 209 The ICMP for IPv4 message described in this section has ICMP Type 210 253 (as defined for experimental use in Section 8 of [RFC4727]) 211 and is used ONLY with a current ILNPv4 session. This message 212 enables an ILNPv4 node to advertise changes to the active Locator 213 set for the ILNPv4 node that originates this message to its 214 unicast ILNP correspondent nodes. It also enables those 215 correspondents to acknowledge receipt of the advertisement. 217 This particular ICMP for IPv4 message MUST ONLY be used with 218 ILNPv4 sessions. The Checksum field for this message is 219 calculated identically as for any other IPv4 ICMP message. 221 ICMP Locator Update message 223 0 1 2 3 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type | Code | Checksum | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Num of Locs | Operation | RESERVED | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 / Locator [1] / 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Preference [1] | Lifetime [1] | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 / Locator [2] / 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Preference [2] | Lifetime [2] | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ICMP Fields: 240 Type 253 241 This type value is taken from Section 8 242 of [RFC4727], and is allocated for 243 experimental use. 245 Code 0 247 Checksum The 16-bit one's complement of the 248 one's complement sum of the ICMP 249 message, starting with the ICMP Type. 250 For computing the checksum, the 251 Checksum field is set to 0. 253 Num of Locs The number of 32-bit Locator values 254 that are advertised in this message. 256 Locator[i], The 32-bit Locator values currently 257 i = 1..Num of Locs valid for the sending ILNPv4 node. 259 Preference[i], The preferability of each Locator[i], 260 i = 1..Num of Locs relative to other valid Locator[i] 261 values. The Preference numbers here 262 are identical, both in syntax and 263 semantics, to the Preference values 264 for L32 records that are specified by 265 [ILNP-DNS]. 267 Lifetime[i] The maximum number of seconds that this 268 i = 1..Num of Locs particular Locator may be considered 269 valid. Normally, this is identical 270 to the DNS lifetime of the 271 corresponding L32 record, if one 272 exists. 274 Operation The value in this field indicates 275 whether this is a Locator Update 276 Advertisement (0x01) or a Locator 277 Update Acknowledgement (0x02). 279 RESERVED A field reserved for possible future 280 use. At present, the sender MUST 281 initialise this field to zero. 282 Receivers should ignore this field at 283 present. The field might be used for 284 some protocol function in future. 286 NOTE WELL: The ICMP TYPE value is allocated for shared 287 experimental use in Section 8 of [RFC4727]. 288 It is not uniquely assigned to ILNPv4. So 289 implementations need to code particularly 290 defensively as other IPv4 experiments might be 291 using this same ICMP TYPE value for an 292 entirely different purpose with a different 293 ICMP packet format. 295 The Operation field has value 1 (hexadecimal 0x01) for a Locator 296 Update Advertisement. The Operation field has value 2 297 (hexadecimal 0x02) for a Locator Update Acknowledgement. All 298 other values of the Operation field are reserved for future use 299 by future revisions of this specification. 301 A node whose set of valid Locators has changed MUST send Locator 302 Update Advertisement messages to each correspondent node for each 303 active unicast ILNP session. For unicast ILNP sessions, the 304 receiver of a valid (i.e. authentication checks all passed, 305 advertisement is received from a current correspondent node) 306 Locator Update Advertisement addressed to the receiver MUST send 307 a Locator Update Acknowledgement back to the sender of the 308 Locator Update Advertisement. The Acknowledgement message body 309 is identical to the received Advertisement message body, except 310 for the Operation value. 312 All ILNPv4 ICMP Locator Update messages MUST contain a valid 313 ILNPv4 Identifier option and MUST contain an ILNPv4 Nonce Option. 315 ILNPv4 ICMP Locator Update messages also MAY be protected using 316 IP Security for ILNP [ILNP-ENG] [RFC4301]. Deployments in 317 high-threat environments SHOULD also protect ILNPv4 ICMP Locator 318 Update messages using IP Security. While IPsec ESP can protect a 319 payload, no form of IPsec ESP is able to protect an IPv4 option 320 that appears prior to the ESP header. Note that even when IP 321 Security for ILNP is in use, the ILNPv4 Nonce Option still MUST 322 be present. This simplifies protocol processing, and it also 323 means that a receiver can perform the inexpensive check of the 324 Nonce value before performing any (potentially expensive) 325 cryptographic calculation. 327 3. Transport Protocol Effects 329 The ICMP Locator Update message has no impact on any transport protocol. 331 The ICMP Locator Update message might affect where packets for 332 a given transport-layer session are sent, but an ILNP design 333 objective is to decouple transport protocols (e.g., TCP, UDP, 334 SCTP) and transport-layer sessions network-layer changes. 336 4. Implementation Considerations 338 Implementers may use any internal implementation they wish, 339 provided that the external appearance is the same as this 340 implementation approach. 342 To support ILNPv4, and to retain the incremental deployability 343 and backwards compatibility needed, the network layer needs a 344 mode bit in the Transport Control Block (or its equivalent) to 345 track which IP sessions are using the classic IPv4 mode and which 346 IP sessions are using ILNPv4 mode. 348 Further, when supporting ILNPv4, nodes will need to support a 349 Identifier Locator Communication Cache (ILCC) in the network 350 layer as described in [ILNP-ENG]. 352 A node sending an ICMP Locator Update message MUST include all 353 currently valid Locator values in that message. A node receiving 354 a valid ICMP Locator Update message MUST replace the previously 355 current set of Locator values for that correspondent node in its 356 own ILCC with the newly received set of Locator values. 358 Every implementation needs to support a large number of Locator 359 values being sent or received in a single ICMP Locator Update 360 message, because a multi-homed node or multi-homed site might 361 have a large number of upstream links to different service 362 providers, each with its own Locator value. 364 It should be noted that as the ICMP Type uses an experimental 365 value from RFC4727 [RFC4727], care should be taken when using 366 with other protocols also using experimental values. 368 5. Backwards Compatibility 370 This IPv4 ICMP message uses the same checksum calculations as any 371 other IPv4 ICMP message. 373 When ILNPv4 is not in use, the receiving IPv4 mode MUST discard 374 the ICMP Locator Update packet without processing the packet. 376 6. SECURITY CONSIDERATIONS 378 Security considerations for the overall ILNP Architecture 379 are described in [ILNP-ARCH]. Additional common security 380 considerations are described in [ILNP-ENG]. This section 381 describes security considerations specific to ILNPv4 topics 382 discussed in this document. 384 The ICMPv4 Locator Update message MUST ONLY be used for 385 ILNPv4 sessions. 387 The ILNPv4 Nonce Option [ILNP-v4OPTS] MUST be present in packets 388 containing an ICMPv4 Locator Update message. Further, the 389 received Nonce Destination Option must contain the correct nonce 390 value for the packet to be accepted by the recipient and then 391 passed to the ICMPv4 protocol for processing. If either of these 392 requirements are not met, the received packet MUST be discarded 393 as a forgery, and a security event SHOULD be logged by the system 394 receiving the non-authentic packet. 396 ILNP sessions operating in higher risk environments SHOULD use 397 IP Security for ILNP [ILNP-ENG] [RFC4301] *in addition* to the 398 ILNPv4 Nonce Option. Use of IP Security for ILNP to protect a 399 packet does NOT permit the packet to be sent without the Nonce 400 Option. 402 Implementations need to support the case where a single ICMP 403 Locator Update message contains a large number of Locator and 404 Preference values and ought not develop a security fault 405 (e.g. stack overflow) due to a received message containing more 406 Locator values than expected. 408 If the ILNP Nonce value is predictable, then an off-path attacker 409 might be able to forge data or control packets. This risk also 410 is mitigated by the existing common practice of IP Source Address 411 filtering [RFC2827] [RFC3704]. 413 7. IANA CONSIDERATIONS 415 This document makes no request of IANA. 417 If in future the IETF decided to standardise ILNPv4, then 418 allocation of a unique ICMP Type for the Locator Update 419 as part of the IETF standardisation process would be sensible. 421 8. REFERENCES 423 This document has both Normative and Informational References. 425 8.1 Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to 428 Indicate Requirement Levels", BCP 14, RFC 2119, 429 March 1997. 431 [RFC2460] S. Deering & R. Hinden, "Internet Protocol 432 Version 6 Specification", RFC2460, 433 December 1998. 435 [RFC4443] A. Conta, S. Deering, and M. Gupta, "Internet Control 436 Message Protocol Version 6 (ICMPv6) Specification", 437 RFC 4443, March 2006. 439 [RFC4301] S. Kent and K. Seo, "Security Architecture for 440 the Internet Protocol", RFC 4301, December 2005. 442 [RFC4727] B. Fenner, "Experimental Values in IPv4, IPv6, ICMPv4, 443 ICMPv6, UDP, and TCP Headers", RFC 4727, Nov 2006. 445 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, 446 "ILNP Architectural Description", 447 draft-irtf-rrg-ilnp-arch, 10 July 2012. 449 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 450 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 452 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, 453 "ILNP Engineering and Implementation Considerations", 454 draft-irtf-rrg-ilnp-eng, 10 July 2012. 456 [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, 457 "IPv4 Options for ILNP", 458 draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 460 8.2 Informative References 462 [RFC2827] P. Ferguson and D. Senie, "Network Ingress 463 Filtering: Defeating Denial of Service Attacks 464 which employ IP Source Address Spoofing", 465 RFC 2827, May 2000. 467 [RFC2780] S. Bradner and V. Paxson, "IANA Allocation 468 Guidelines For Values In the Internet Protocol 469 and Related Headers", RFC 2780, March 2000. 471 [RFC3704] F. Baker and P. Savola, "Ingress Filtering for 472 Multihomed Networks", RFC 3704, March 2004. 474 [RFC4884] R. Bonica, D. Gan, D. Tappan, C. Pignataro, 475 "Extended ICMP to Support Multi-Part Messages", 476 RFC 4884, April 2007. 478 [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, 479 "DNS Resource Records for ILNP", 480 draft-irtf-rrg-ilnp-dns, 10 July 2012. 482 [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, 483 "Optional Advanced Deployment Scenarios for ILNP", 484 draft-irtf-rrg-ilnp-adv, 10 July 2012. 486 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, 487 "ICMPv6 Locator Update message" 488 draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. 490 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, 491 "IPv6 Nonce Destination Option for ILNPv6", 492 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 494 ACKNOWLEDGEMENTS 496 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 497 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 498 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 499 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 500 order) provided review and feedback on earlier versions of this 501 document. Steve Blake provided an especially thorough review of 502 an early version of the entire ILNP document set, which was 503 extremely helpful. We also wish to thank the anonymous reviewers 504 of the various ILNP papers for their feedback. 506 Roy Arends provided expert guidance on technical and procedural 507 aspects of DNS issues. 509 RFC EDITOR NOTE 511 This section is to be removed prior to publication. 513 Please note that this document is written in British English, so 514 British English spelling is used throughout. This is consistent 515 with existing practice in several other RFCs, for example 516 RFC-5887. 518 This document tries to be very careful with history, in the 519 interest of correctly crediting ideas to their earliest 520 identifiable author(s). So in several places the first published 521 RFC about a topic is cited, rather than the most recent published 522 RFC about that topic. 524 AUTHOR'S ADDRESS 526 RJ Atkinson 527 Consultant 528 San Jose, CA 529 95125 USA 531 Email: rja.lists@gmail.com 533 SN Bhatti 534 School of Computer Science 535 University of St Andrews 536 North Haugh, St Andrews 537 Fife, Scotland 538 KY16 9SX, UK 540 Email: saleem@cs.st-andrews.ac.uk 542 Expires: 10 JAN 2013