idnits 2.17.1 draft-rja-ilnp-nonce-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.2b on line 464. -- Found old boilerplate from RFC 3978, Section 5.3 on line 466. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 461. -- 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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 5616 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-4301' is mentioned on line 253, but not defined == Unused Reference: 'RFC-2119' is defined on line 376, 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-intro-01 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-dns-00 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-icmp-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 draft-rja-ilnp-nonce-01.txt Extreme Networks 4 Expires: 10 June 2009 10 December 2008 5 Category: Experimental 7 Nonce Destination Option 8 draft-rja-ilnp-nonce-01.txt 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 By submitting this Internet-Draft, each author represents 15 that any applicable patent or other IPR claims of which he 16 or she is aware have been or will be disclosed, and any of 17 which he or she becomes aware will be disclosed, in 18 accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by 27 other documents at any time. It is inappropriate to use 28 Internet-Drafts as reference material or to cite them other 29 than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be 35 accessed at http://www.ietf.org/shadow.html. 37 This document is a contribution to the IRTF Routing 38 Research Group. It is neither a contribution to the IETF, 39 nor to any IETF Working Group, nor to any IETF Area. 41 Abstract 43 This document describes an experimental Nonce Destination 44 Option that could be used as part of an Identifier Locator 45 Network Protocol (ILNP) that is based upon IPv6. 47 Table of Contents 49 1. Introduction ...............................................2 50 2. Syntax......................................................3 51 3. Transport Protocol Effects..................................4 52 4. Location Changes............................................4 53 5. Implementation Considerations...............................5 54 6. Backwards Compatibility.....................................6 55 7. Security Considerations ....................................8 56 8. IANA Considerations ........................................9 57 9. References .................................................9 59 1. Introduction 61 At present, the IRTF Routing Research Group is studying several 62 different approaches to evolving the Internet Architecture. 64 Several different classes of evolution are being considered. One 65 class is often called "Map and Encapsulate", where traffic would be 66 mapped and then tunnelled through the inter-domain core of the 67 Internet. Another class being considered is sometimes known as 68 "Identifier/Locator Split".[GSE][8+8] This document relates to a 69 proposal that is in the latter class of evoluationary approaches. 70 This particular approach, the Identifier Locator Network Protocol 71 (ILNP), described in this document and in related Internet-Drafts, 72 is a possible evolutionary direction for IPv6.[ILNP-Intro] 73 [ILNP-DNS][ILNP-ICMP][RFC-2460] 75 The Nonce Destination Option described in this document provides 76 two functions. First, it provides protection against off-path 77 attacks for packets when an Identifier/ Locator split is in use. 78 Second, it provides a signal during initial IP session creation 79 that the Identifier/ Locator Split operating mode is proposed 80 for use with this session. This last function is particularly 81 important for ensuring that the new Identifier/Locator Split 82 operating mode is both incrementally deployable and backwards 83 compatible with classical IPv6. 85 Further, each Nonce value is unidirectional. Since packets often 86 travel asymmetric paths between two correspondents, having separate 87 Nonces for each direction limits the number of on-path nodes that 88 can easily learn a session's nonce. So a typical TCP session will 89 have 2 different nonce values in use: one nonce is used from Local 90 Node to the Correspondent Node and a different nonce is used from 91 the Correspondent Node to the Local Node. 93 Before reading this draft, readers should read the related 94 Internet-Draft titled "ILNP Concept of Operations", as that document 95 will help the reader understand the overall context for this option. 97 2. Syntax 99 The Nonce Option is an IPv6 Destination Option. 101 In the diagram below, we show not only the Nonce Option, 102 but also the 2-byte header for the IPv6 Destination Option. 104 More than one option might be inside the IPv6 Destination Option, 105 however at most 1 Nonce Option exists in a given IPv6 packet. 106 A system that receives a packet containing more than one 107 Nonce Option should discard the packet as "Authentication 108 Failed" (instead of passing the packet up to the appropriate 109 transport-layer protocol or to ICMP). 111 As of this writing, IPv6 Destination Options are extremely 112 uncommon in the deployed Internet. So, it is expected that 113 most commonly Nonce Option would be the only IPv6 Destination 114 Option present in a given IPv6 packet. 116 ------------------------------------------------------------ 117 | Next Header | Hdr Ext Len | Option Type | Option Length| 118 +-------------+---------------+-------------+--------------+ 119 / Nonce Value / 120 +-------------+---------------+-------------+--------------+ 122 Next Header: 8-bit selector. Identifies the type of header 123 immediately following the Destination Options 124 header. Uses the same values as the IPv4 125 Protocol field [RFC-1700 et seq.]. 127 Hdr Ext Len: 8-bit unsigned integer. Length of the 128 Destination Options header in 8-octet units, 129 not including the first 8 octets. 131 Option Type: This contains the value 0x1e, which is used 132 (for now) to indicate the start of the Nonce 133 Option. 135 Option Length: This indicates the length in 8-bit octets of 136 the Nonce Value field of the Nonce Option. 137 This value must be selected so that the 138 enveloping IPv6 Destination Option complies 139 with the IPv6 header alignment rules. Common 140 values are 4 (when the Nonce Value is 32-bits), 141 and 12 (when the Nonce value is 96-bits). 143 Nonce Value: This is an unpredictable cryptographically 144 random value used to prevent off-path 145 off-path attacks on an ILNP session. [RFC-4086] 146 This field has variable length, with the 147 length indicated by the Option Length field 148 preceding it. Note that the overall IPv6 149 IPv6 Destination Option must comply with 150 IPv6 header alignment rules. Implementations 151 must support sending and receiving 32-bit 152 and 96-bit Nonce values. 154 3. Transport Protocol Effects 156 When the initial packet(s) of an IPv6 session contain this Nonce 157 Destination Option, the Identifier/Locator Split operating mode 158 is in use for that IP session. 160 When an IPv6 session is in the Identifier/Locator Split operating 161 mode, the transport-layer pseudo-header calculations zero the 162 high-order 64-bits ("Locator" or "Routing Prefix") of each IPv6 163 address. This has the effect that the transport-layer is no 164 longer cognizant of the topological network location of 165 either node in the session. 167 The preceding rule applies not only to unicast sessions, but also 168 to multicast or anycast sessions when the Identifier/Locator Split 169 operating mode is in use. 171 4. Location Changes 173 When a node has an unexpected change in its Locator set that causes 174 all previously valid Locators to become invalid, the node must send 175 an ICMP Locator Update message (containing the Nonce Option with the 176 appropriate nonce value) to each of its correspondents. 178 In the deployed Internet, packets sometimes arrive at a destination 179 out of order. A receiving node will drop a packet arriving from a 180 correspondent if the Source Locator of the received packet is not 181 in the receiving node's ILNP Correspondents Cache's Correspondent 182 Locator Set UNLESS that packet contains a Nonce Option with the 183 appropriate nonce value for that Source Identifier and Destination 184 Identifier pair. This is done to reduce the risk of session hijacking 185 or session interference attacks. 187 Hence, the node that unexpectedly had all previously valid Locators 188 become invalid must include the Nonce Option with the appropriate 189 nonce value in all packets (data or otherwise) to all correspondents 190 for at least 3 round-trip times for each correspondent. (NB: An 191 implementation need not actually calculate RTT values; it could just 192 use a fixed timer with a time long enough to cover the longest RTT 193 path, such as 1 minute.) This 'gratuitous authentication' ensures 194 that the correspondent can authenticate any received packet, even if 195 the ICMP Locator Update control message arrives and is processed 196 AFTER some other packet using the new Source Locator(s). If a 197 session is using IP Security, then of course IP Security should 198 continue to be used in this case. Because IP Security for ILNP 199 binds only to the Identifiers, and not to the Locators in the packet, 200 changes in Locator value have no impact on IP Security sessions. 202 As mobility and multi-homing are functionally equivalent, 203 this section applies equally to either situation. 205 5. Implementation Considerations 207 Implementers may use any internal implementation they wish, 208 provided that the external appearance is the same as this 209 implementation approach. 211 5.1 Mode Indicator 213 To support the Identifier/Locator Split operating mode, and retain the 214 incremental deployability and backwards compatibility needed, the 215 network layer needs a mode bit in the Transport Control Block (or 216 equivalent for one's implementation) to track which IP sessions are 217 using the classic IPv6 mode, and which IP sessions are using the 218 Identifier/Locator Split mode. 220 If a given transport-layer session is in the I/L Split Mode, then an 221 entry corresponding to that session will exist in the Correspondent 222 Cache. Note that multiple transport-layer sessions between a given 223 pair of nodes normally share a single entry in the Correspondent 224 Cache. 226 5.2 Correspondent Cache 228 Further, when in the Identifier/Locator Split mode, nodes will need to 229 retain a Correspondent cache containing several variables for each 230 correspondent. This cache is per-correspondent, rather than per-flow 231 or per-session so that if there are multiple sessions with a single 232 correspondent, Locator changes for all sessions with that 233 correspondent are handled with a single Locator Update message. 234 Conceptually, and architecturally, this Correspondents Cache is at the 235 top of the network-layer since it contains network-layer information 236 (e.g. Locators) that ought not be made visible to the transport-layer. 238 The Correspondent Cache contains, for each correspondent, at least: 239 - Local Identifier(s) in use 240 - Local Locator(s) in use 241 - Correspondent's Identifier(s) in use 242 - Correspondent's Locator(s) in use 243 - Session Nonce value used Local Node to Correspondent 244 - Session Nonce value used Correspondent to Local Node 245 - Information about whether IPsec is being used with 246 this correspondent. 248 5.3 IP Security 250 Note that (whether or not the I/L-Split Mode is in use) the IPsec 251 subsystem is required to maintain an IPsec Security Association 252 Database (SAD) and also information about which IPsec Selectors 253 apply to traffic received by or sent from the local node. [RFC-4301] 254 By combining the information in the IPsec SAD, of what IPsec 255 Selectors apply, and the Correspondent Cache, an implementation 256 has sufficient knowledge to apply IPsec properly to both received 257 and transmitted packets. 259 6. Backwards Compatibility 261 If a node has been enhanced to support the Identifier/Locator Split 262 operating mode, that node's fully-qualified domain name will normally 263 have one or more I records and one or more L records associated with 264 it in the DNS. 266 When a host ("initiator") initiates a new IP session with a 267 correspondent ("responder"), it normally will perform a DNS lookup 268 to determine the address(es) of the responder. A host that has been 269 enhanced to support the Identifier/ Locator Split operating mode 270 normally will look for Identifier ("I") and Locator ("L") records 271 in any received DNS replies. DNS servers that support I and L 272 records should include them (when they exist) as additional data 273 in all DNS replies to queries for DNS AAAA records. 275 If the initiator supports the I/L Split mode and from DNS 276 data learns that the responder also supports the I/L Split 277 mode, then the initiator will generate an unpredictable 278 nonce value, store that value in a local session cache, and 279 will include the Nonce Destination Option in its initial 280 packet(s) to the responder. [RFC-4086] 282 If the responder supports the I/L Split mode and receives 283 initial packet(s) containing the Nonce Destination Option, 284 the responder will thereby know that the initiator supports 285 the I/L Split mode and the responder will also operate in 286 I/L Split mode for this new IP session. 288 If the responder supports the I/L Split mode and receives 289 initial packet(s) NOT containing the Nonce Destination 290 Option, the responder will thereby know that the initiator 291 does NOT support the I/L Split mode and the responder will 292 operate in classic IPv6 mode for this new IP session. 294 If the responder does not support the I/L Split mode and 295 receives initial packet(s) containing the Nonce Destination 296 Option, the responder will drop the packet and send an ICMP 297 Parameter Problem error message back to the initiator. 299 If the initiator EITHER does not receive a response from the 300 responder in a timely manner (e.g. within the applicable TCP 301 timeout for a TCP session) and also does not receive an ICMP 302 Unreachable error message for that packet, OR if the 303 initiator receives an ICMP Parameter Problem error message 304 for that packet, then the initiator knows that the responder 305 is not able to support the I/L Split Operating mode. In 306 this case, the initiator should try again to create the new 307 IP session but this time using classic IPv6 mode and hence 308 OMITTING the Nonce Destination Option. 310 6. Security Considerations 312 The Nonce Destination Option is used ONLY for IPv6 sessions using 313 Identifier/Locator Split mode, because this option is part of the 314 backwards-compatibility and incremental-deployment approach for 315 the Identifier/Locator Network Protocol (ILNP). 317 The Nonce Destination Option only seeks to provide protection 318 against off-path attacks on an IP session. Ordinary IPv6 is 319 vulnerable to on-path attacks unless the IP Authentication 320 Header or IP Encapsulating Security Payload are in use. This 321 option exists to provide equivalent protection for non-IPsec 322 traffic when the Identifier/Locator Split mode is in use 323 for an IP session. 325 When the Identifier/Locator split mode is in use for an existing IP 326 session, the Nonce Destination Option must be included in any ICMP 327 control messages (e.g. ICMP Unreachable, ICMP Locator Update) sent 328 with regard to that IPv6 session, even if IP Security is also in use 329 for that session. 331 When in the I/L Split operating mode for an existing IPv6 session, 332 any ICMP control messages received without a Nonce Destination 333 Option must be discarded as forgeries. This security event 334 should be logged. 336 When in the I/L Split operating mode for an existing IPv6 session, 337 ICMP control messages received without a correct nonce value inside 338 the Nonce Destination Option must be discarded as forgeries. This 339 security event should be logged. 341 Of course, longer nonce values provide greater resistance to random 342 guessing of the nonce value. However, ID/Locator Split mode sessions 343 operating in higher risk environments should use the cryptographic 344 authentication provided by IP Authentication Header. Note that the 345 Nonce Option must be present -- even if the IP Authentication Header 346 is in use for a given session. As an implementation optimisation, 347 it is suggested that when both the Nonce Option and IP Security are 348 present in a packet, that the Nonce Option value be checked for 349 validity before beginning IP Security processing. 351 For environments with data at differing sensitivity levels operating 352 over common infrastructure, it is recommended that the Nonce Option 353 is encrypted by using ESP Transport-Mode or ESP Tunnel-Mode in order 354 to reduce the covert channel bandwidth potential created by the 355 Nonce Option. 357 In all cases, the Nonce Value must be unpredictable and 358 cryptographically random. RFC-4086 provides concrete advice 359 on how to generate a suitable nonce value.[RFC-4086] 361 This option could be designed to optionally carry a 64-bit unsigned 362 Identifier for the sender as well, if that were considered important. 364 7. IANA Considerations 366 A new option number will need to be assigned by IANA to the 367 Nonce Option described in this note. 369 Temporarily, for early experimentation, the value 0x1e is 370 used to mark the Nonce Option. 372 8. References 374 8.1. Normative References 376 [RFC-2119] Bradner, S., "Key words for use in RFCs to 377 Indicate Requirement Levels", BCP 14, RFC 2119, 378 March 1997. 380 [RFC-2460] S. Deering & R. Hinden, "Internet Protocol 381 Version 6 Specification", RFC-2460, 382 December 1998. 384 8.2. Informative References 386 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 387 Architecture for IPv6", Internet-Draft, 388 October 1996. 390 [GSE] M. O'Dell, "GSE - An Alternate Addressing 391 Architecture for IPv6", Internet-Draft, 392 February 1997. 394 [ILNP-Intro] Atkinson, R, "Identifier/Locator Concept of 395 Operations", draft-rja-ilnp-intro-01.txt, 396 June 2008. 398 [ILNP-DNS] Atkinson, R, "DNS Resource Records for 399 Identifier/Locator Use", 400 draft-rja-ilnp-dns-00.txt, June 2008. 402 [ILNP-ICMP] Atkinson, R, "ICMP Locator Update message" 403 draft-rja-ilnp-icmp-00.txt, June 2008. 405 [RFC-4086] D. Eastlake 3rd, J. Schiller, & S. Crocker, 406 "Randomness Requirements for Security", 407 RFC-4086, June 2005. 409 (Additional references to be added later.) 411 Author's Address 413 R. Atkinson 414 Extreme Networks 415 3585 Monroe Street 416 Santa Clara, CA 417 95051 USA 419 +1 (408)579-2800 420 rja@extremenetworks.com 422 Full Copyright Statement 424 Copyright (C) The IETF Trust (2008). 426 This document is subject to the rights, licenses and restrictions 427 contained in BCP 78, and except as set forth therein, the authors 428 retain all their rights. 430 This document and the information contained herein are provided 431 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 432 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 433 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 434 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 435 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 436 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 437 OR FITNESS FOR A PARTICULAR PURPOSE. 439 Intellectual Property 441 The IETF takes no position regarding the validity or scope of any 442 Intellectual Property Rights or other rights that might be claimed 443 to pertain to the implementation or use of the technology 444 described in this document or the extent to which any license 445 under such rights might or might not be available; nor does it 446 represent that it has made any independent effort to identify any 447 such rights. Information on the procedures with respect to 448 rights in RFC documents can be found in BCP 78 and BCP 79. 450 Copies of IPR disclosures made to the IETF Secretariat and any 451 assurances of licenses to be made available, or the result of an 452 attempt made to obtain a general license or permission for the use 453 of such proprietary rights by implementers or users of this 454 specification can be obtained from the IETF on-line IPR repository 455 at http://www.ietf.org/ipr. 457 The IETF invites any interested party to bring to its attention 458 any copyrights, patents or patent applications, or other 459 proprietary rights that may cover technology that may be required 460 to implement this standard. Please address the information to the 461 IETF at ietf-ipr@ietf.org. 463 This document may not be modified, and derivative works of it 464 may not be created. 466 This document may only be posted in an Internet-Draft. 468 Expires: 10 June 2009