idnits 2.17.1 draft-irtf-rrg-ilnp-v4opts-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (9 January 2012) is 4489 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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-v4opts-00.txt Consultant 4 Expires: 09 JUL 2012 SN Bhatti 5 Category: Experimental U. St Andrews 6 9 January 2012 8 IPv4 Options for ILNPv4 9 draft-irtf-rrg-ilnp-v4opts-00.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 without 26 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 IETF 32 Contributions published or made publicly available before November 33 10, 2008. The person(s) controlling the copyright in some of this 34 material may not have granted the IETF Trust the right to allow 35 modifications of such material outside the IETF Standards Process. 36 Without obtaining an adequate license from the person(s) controlling 37 the copyright in such materials, this document may not be modified 38 outside the IETF Standards Process, and derivative works of it may 39 not be created outside the IETF Standards Process, except to format 40 it for publication as an RFC or to translate it into languages other 41 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 documents 50 at any time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 This document is not on the IETF standards-track and does not 60 specify any level of standard. This document merely provides 61 information for the Internet community. 63 This document is part of the ILNP document set, and has had 64 extensive review within the IRTF Routing Research Group. ILNP is 65 one of the recommendations made by the RG Chairs. Separately, 66 various refereed research papers on ILNP have also been published 67 during this decade. So the ideas contained herein have had much 68 broader review than the IRTF Routing RG. The views in this 69 document were considered controversial by the Routing RG, but the 70 RG reached a consensus that the document still should be 71 published. The Routing RG has had remarkably little consensus on 72 anything, so virtually all Routing RG outputs are considered 73 controversial. 75 Abstract 77 This document defines 2 new IPv4 options that are used with ILNP 78 for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary 79 enhancement to IP. This document is a product of the IRTF Routing 80 RG. 82 Table of Contents - ### to be updated 84 1. Introduction............................. 85 2. IPv4 Options for ILNPv4.................. 86 3. Security Considerations.................. 87 4. IANA Considerations...................... 88 5. References............................... 90 1. INTRODUCTION 92 The Identifier Locator Network Protocol (ILNP) is an proposal for 93 evolving the Internet Architecture. It differs from the current 94 Internet Architecture primarily by deprecating the concept of an 95 IP Address, and instead defining two new objects, each having 96 crisp syntax and semantics. The first new object is the Locator, 97 a topology-dependent name for a subnetwork. The other new object 98 is the Identifier, which provides a topology-independent name for 99 a node. 101 1.1 ILNP Document Roadmap 103 The ILNP Architecture document [ILNP-ARCH] is the best place to 104 start reading about ILNP. ILNP has multiple instantiations. 105 [ILNP-ENG] discusses engineering and implementation aspects 106 common to all instances of ILNP. This document discusses 107 engineering and implementation details that are specific to ILNP 108 for IPv4 (ILNPv4). [ILNP-DNS] describes new Domain Name System 109 (DNS) resource records used with ILNP. [ILNP-ICMPv4] defines the 110 ICMP Locator Update message used with ILNPv4. Other documents 111 describe ILNP for IPv6 (ILNPv6) [ILNP-ICMPv6] [ILNP-NONCE6]. 113 1.2 Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 116 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described 118 in RFC 2119. [RFC-2119] 120 2. IPv4 Options for ILNPv4 122 ILNP for IPv4 (ILNPv4) is merely a different instantiation of the 123 ILNP architecture, so it retains the crisp distinction between 124 the Locator and the Identifier. As with ILNP for IPv6 (ILNPv6), 125 when ILNPv4 is used for a network-layer session, the upper-layer 126 protocols (e.g. TCP/UDP pseudo-header checksum, IPsec Security 127 Association) bind only to the Identifiers, never to the Locators. 128 As with ILNPv6, only the Locator values are used for routing and 129 forwarding ILNPv4 packets. 131 However, just as the packet format for IPv4 is different to IPv6, 132 so the engineering details for ILNPv4 are different also. Just as 133 ILNPv6 is carefully engineered to be backwards-compatible with 134 IPv6, ILNPv4 is carefully engineered to be backwards-compatible 135 with IPv4. 137 2.1 ILNPv4 Packet Format 139 The Source IP Address in the IPv4 header becomes the Source 140 ILNPv4 Locator value, while the Destination IP Address of the 141 IPv4 header becomes the Destination ILNPv4 Locator value. Of 142 course, backwards compatibility requirements mean that ILNPv4 143 Locators use the same number space as IPv4 routing prefixes. 145 ILNPv4 uses the same 64-bit Identifier, with the same modified 146 EUI-64 syntax, as ILNPv6. Because the IPv4 address is much 147 smaller than the IPv6 address, ILNPv4 cannot carry the 148 Identifier values in the fixed portion of the IPv4 header. 149 The obvious two ways to carry the ILNP Identifier with ILNPv4 150 are either as an IPv4 Option or as an IPv6-style Extension 151 Header placed after the IPv4 header and before the upper-layer 152 protocol (e.g. OSPF, TCP, UDP, SCTP). 154 Currently deployed IPv4 routers from multiple router vendors use 155 packet forwarding silicon that is able to parse past IPv4 options 156 to examine the upper-layer protocol header at wire-speed on 157 reasonably fast (e.g. 1 Gbps or better) network interfaces. By 158 contrast, no existing IPv4-capable packet forwarding silicon is 159 able to parse past a new Extension Header for IPv4. Hence, for 160 engineering reasons, ILNPv4 uses a new IPv4 Option to carry the 161 Identifier values. Another new IPv4 option also carries a nonce 162 value, performing the same function for ILNPv4 as the IPv6 Nonce 163 Destination Option [ILNP-NONCE6] performs for ILNPv6. 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |Version|IHL=12 |Type of Service| Total Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Identification |Flags| Fragment Offset | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Time to Live | Protocol | Header Checksum | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Source Locator (32 bits) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Destination Locator (32 bits) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | OT=ILNPv4_ID | OL=5 | Padding=0x0000 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 + Source Identifier + 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 + Destination Identifier + 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |OT=ILNPv4_NONCE| OL=2 | top 16 bits of nonce | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | lower 32 bits of nonce | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: ILNPv4 header with ILNP ID option 192 and ILNP Nonce option. 194 Notation for Figure 1: 195 IHL: Internet Header Length 196 OT: Option Type 197 OL: Option Length 199 2.2 ILNP Identifier Option for IPv4 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | OT=ILNPv4_ID | OL=5 | Reserved (16 bits) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 205 + Source Identifier + 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 + Destination Identifier + 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2: ILNP Identifier Option for IPv4 215 Notation for Figure 2: 216 OT: Option Type 217 OL: Option Length 219 ## need to verify units used for IPv4 options (bytes vs words) 221 The Source Identifier and Destination Identifier are unsigned 222 64-bit integers. [ILNP-ENG] specifies the syntax, semantics, 223 and generation of ILNP Identifier values. Using the same 224 syntax and semantics for all instantiations of ILNP Identifiers 225 simplifies specification and implementation, while also 226 facilitating translation or transition between ILNPv4 and 227 ILNPv6 should that be desirable in future. 229 This IP option MUST NOT be present in an IPv4 packet unless 230 the packet is part of an ILNPv4 session. ILNPv4 sessions 231 MUST include this option in the first few packets of each 232 session, and MAY include this option in all packets of the 233 session. It is RECOMMENDED to include this option in all 234 packets of the session if packet loss higher than normal. 236 2.3 ILNP Nonce Option for IPv4 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |OT=ILNPv4_NONCE| OL=2 | NONCE (upper 16 bits) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | NONCE (lower 32 bits) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 3: ILNP Nonce Option for IPv4 246 Notation for Figure 3: 247 OT: Option Type 248 OL: Option Length 250 ## need to verify units used for IPv4 options (bytes vs words) 252 This option contains a 48-bit ILNP Nonce. As noted in 253 [ILNP-ARCH] and [ILNP-ENG], all ILNP Nonce values are 254 unidirectional. This means, for example, that a typical 255 TCP/ILNPv4 session will have two different NONCE values: one from 256 Initiator to Responder and another from Responder to Initiator. 257 The ILNP Nonce is used to provide non-cryptographic protection 258 against off-path attacks (e.g. forged ICMP messages from the 259 remote end of a TCP session). 261 Each NONCE value MUST be unpredictable (i.e. cryptographically 262 random). [RFC-4086] provides guidance to implementers on 263 generating cryptographically random values. 265 This IP option MUST NOT be present in an IPv4 packet unless the 266 packet is part of an ILNPv4 session. ILNPv4 nodes MUST include 267 this option in the first few packets of each ILNP session, MUST 268 include this option in all ICMP messages generated by endpoints 269 participating in an ILNP session, and MAY include this option in 270 all packets of an ILNPv4 session. 272 3. SECURITY CONSIDERATIONS 274 Security considerations for the overall ILNP Architecture are 275 described in [ILNP-ARCH]. Additional common security 276 considerations are described in [ILNP-ENG]. This section 277 describes security considerations specific to ILNPv4 topics 278 discussed in this document. 280 If the ILNP Nonce value is predictable, then an off-path attacker 281 might be able to forge data or control packets. This risk also 282 is mitigated by the existing common practice of IP Source Address 283 filtering [RFC-2827] [RFC-3704]. 285 IP Security for ILNP [ILNP-ENG] [RFC-4301] provides cryptographic 286 protection for ILNP data and control packets. The ILNP Nonce 287 option is required in the circumstances described in Section 3, 288 even if IP Security is also in use. Deployments of ILNPv4 in 289 high-threat environments SHOULD use IP Security for additional 290 risk reduction. 292 4. IANA CONSIDERATIONS 294 IANA is requested to assign new IPv4 option values for the ILNPv4 295 Identifier option (ILNPv4_ID) and the ILNPv4 Nonce option 296 (ILNPv4_NONCE) in accordance with the procedures of [RFC-2780]. 297 The short name for ILNPv4_ID is "ID", for consistency with 298 [ILNP-DNS], and the short name for ILNPv4_NONCE is "INONCE". 300 Each of these options MUST be copied upon fragmentation. 301 Each of these options is used for control, so uses Option Class 0. 303 5. REFERENCES 305 This document has both Normative and Informational References. 307 5.1 Normative References 309 [ILNP-ARCH] R. Atkinson and S. Bhatti, "ILNP Architecture", 310 draft-irtf-rrg-ilnp-arch, January 2012. 312 [ILNP-ENG] R. Atkinson and S. Bhatti, "ILNP Engineering 313 Considerations", draft-irtf-rrg-ilnp-eng, January 2012. 315 [ILNP-DNS] R. Atkinson and S. Bhatti, "DNS Resource Records 316 for ILNP", draft-irtf-rrg-ilnp-dns, January 2012. 318 [ILNP-ICMPv4] R. Atkinson and S. Bhatti, "ICMP Locator Update 319 message for ILNPv4", draft-irtf-rrg-ilnp-icmpv4, 320 January 2012. 322 [RFC-2119] Bradner, S., "Key words for use in RFCs to 323 Indicate Requirement Levels", BCP 14, RFC 2119, 324 March 1997. 326 [RFC-4301] S. Kent and K. Seo, "Security Architecture for 327 the Internet Protocol", RFC-4301, December 2005. 329 5.2 Informative References 331 [ILNP-NONCE6] R. Atkinson and S. Bhatti, "ILNPv6 Nonce 332 Destination Option", draft-irtf-rrg-ilnp-noncev6, 333 January 2012. 335 [ILNP-ICMPv6] R. Atkinson and S. Bhatti, "ICMPv6 Locator 336 Update Message for ILNPv6", 337 draft-irtf-rrg-ilnp-icmpv6, January 2012. 339 [RFC-2780] 341 [RFC-2827] P. Ferguson and D. Senie, "Network Ingress 342 Filtering: Defeating Denial of Service Attacks 343 which employ IP Source Address Spoofing", 344 RFC-2827, May 2000. 346 [RFC-3704] F. Baker and P. Savola, "Ingress Filtering for 347 Multihomed Networks", RFC-3704, March 2004. 349 [RFC-4086] D. Eastlake 3rd, J. Schiller, and S. Crocker, 350 "Randomness Requirements for Security", RFC-4086, 351 June 2005. 353 ACKNOWLEDGEMENTS 355 Steve Blake, Mohamed Boucadair, Noel Chiappa, Steve Hailes, Joel 356 Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, 357 Tony Li, Yakov Rehkter and Robin Whittle (in alphabetical order) 358 provided review and feedback on earlier versions of the ILNP 359 documents. Steve Blake provided an especially thorough review of 360 an earlier version of the entire ILNP document set, which was 361 extremely helpful. We also wish to thank the anonymous reviewers 362 for their feedback. 364 AUTHOR'S ADDRESS 366 RJ Atkinson 367 Consultant 368 San Jose, CA, 369 95125 USA 371 Email: rja.lists@gmail.com 373 SN Bhatti 374 School of Computer Science 375 University of St Andrews 376 North Haugh, St Andrews 377 Fife, Scotland 378 KY16 9SX, UK 380 Email: saleem@cs.st-andrews.ac.uk 381 Expires: 09 JUL 2012