idnits 2.17.1 draft-montenegro-ipsecme-wesp-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([WESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 9, 2009) is 5274 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Montenegro 2 Internet Draft Microsoft Corporation 3 Intended status: Standards Track K. Grewal 4 Expires: May 9, 2010 Intel Corporation 5 November 9, 2009 7 Wrapped ESP Extensions 8 draft-montenegro-ipsecme-wesp-extensions-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance 13 with the provisions of BCP 78 and BCP 79. This document may 14 contain material from IETF Documents or IETF Contributions 15 published or made publicly available before November 10, 2008. 16 The person(s) controlling the copyright in some of this material 17 may not have granted the IETF Trust the right to allow 18 modifications of such material outside the IETF Standards 19 Process. Without obtaining an adequate license from the 20 person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, 22 and derivative works of it may not be created outside the IETF 23 Standards Process, except to format it for publication as an RFC 24 or to translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF), its areas, and its working 28 groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them other than as "work 35 in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on May 09, 2010. 45 Copyright 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license- 53 info). Please review these documents carefully, as they describe 54 your rights and restrictions with respect to this document. 56 Abstract 58 This document defines the Wrapped ESP (WESP) Extensions 59 capability, which builds on the Wrapped Encapsulating Security 60 Payload [WESP]. The extensions described in this document enable 61 applications like operations and management as well as traffic 62 inspection by intermediate nodes for value added network 63 services such as Intrusion Detection and Prevention (IDS/IPS) on 64 traffic that is encrypted. 66 Table of Contents 68 1. Introduction...................................................2 69 1.1. Requirements Language.....................................3 70 1.2. Applicability Statement...................................3 71 2. Wrapped ESP (WESP) Header Extensions format....................3 72 2.1. Operation Administration and Maintenance (OAM) Options....5 73 2.1.1. Connectivity Verification Option (OAM-CV)............6 74 2.1.2. Error Notification Option (OAM-EN)...................6 75 2.1.3. SA Monitoring Option (OAM-SM)........................7 76 2.2. Pad Option................................................8 77 2.3. Encryption Offset Option..................................8 78 3. IKE Considerations.............................................9 79 4. Security Considerations........................................9 80 5. IANA Considerations............................................9 81 6. Acknowledgments...............................................10 82 7. References....................................................10 83 7.1. Normative References.....................................10 84 7.2. Informative References...................................10 86 1. Introduction 88 This document defines an extension mechanism for Wrapped ESP 89 (WESP) [WESP]. 91 The document is consistent with the operation of ESP in NAT 92 environments [RFC3947]. 94 The design principles for this extension to WESP are: 96 o Provide an extensible packet format to enable better 97 diagnostics and future innovation in IPsec. 99 o Leverage packet extensions to convey encryption offsets (if 100 used), allowing visibility into packet headers, while still 101 protecting the packet payload and its integrity. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 106 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described 108 in RFC 2119 [RFC2119]. 110 1.2. Applicability Statement 112 The document is applicable only to wrapped ESP [WESP]. 114 2. Wrapped ESP (WESP) Header Extensions format 116 Wrapped ESP encapsulation (WESP) follows RFC 4303 [RFC4303] for 117 all IPv6 and IPv4 considerations (e.g., alignment 118 considerations) within ESP, and these considerations apply 119 equally to the WESP Extensions mechanisms defined in this 120 document. 122 The WESP Extension is present if the 'X' (eXtension) flag in the 123 WESP Header Flags field is set. If so, the WESP extension 124 payload is inserted between the WESP Header and the ESP 125 encapsulation. 127 This may be depicted as follows: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | WESP Header | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | WESP Extension Payload | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | ESP Encapsulation | 137 ~ ~ 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 1 WESP Packet Format with Extensions 143 Further details (including the 'X' bit in the Flags field in the 144 WESP header) are shown below: 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Next Header | HdrLen | TrailerLen |V|V|E|P|X|Flags| 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type | Length | Data (variable) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Data (variable) | 154 ~ ~ 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ESP Encapsulation | 158 ~ ~ 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 2 Detailed WESP Packet Format with Extensions 164 Where: 166 All fields in the WESP Header are as defined in [WESP], except 167 for the Flags field in which one additional bit is used to 168 signal the use of WESP extensions as follows: 170 Flags, 8 bits: The bits are defined LSB first, so bit 0 is the 171 least significant bit of the flags octet. [WESP] 173 175 1 bit: Extensions Present (X). Setting the Extensions 176 Present bit to 1 indicates that WESP Extensions are present 177 between the WESP Header and the ESP Header (as shown above). The 178 recipient MUST ensure consistency of this flag with the 179 negotiated policy and MUST drop the incoming packet otherwise. 181 3 bits: Flags, reserved for future use. The flags MUST be 182 sent as 0, and ignored by the receiver. Otherwise, these flags 183 are treated per [WESP]. 185 The fields in the WESP Extension allow the definition of options 186 with the following format: 188 Type, 8 bits: defines the WESP Extension type 190 Length, 8 bits: defines the length of the WESP Extension in 191 octets, excluding the Type and Length fields 192 Data, variable length: defines the value(s) associated with a 193 given WESP Extension. The length is defined by the Length field 194 above. 196 Furthermore, the Type contains some fixed format bits, following 197 RFC 2460, clause 4.2 to ensure consistency with IPv6 extension 198 header encoding. This will allow simple and consistent hardware- 199 based parsing of the WESP Extensions. [RFC2460] 201 Accordingly, the high order 2 bits specify the following 202 behavior when the option is not recognized. 204 00 - silently skip the option 206 01 - silently discard the packet 208 10 - discard and send ICMP parameter error 210 11 - discard and send ICMP parameter error if not multicast 212 The next high order bit specifies mutability of the option 213 field. 215 0 - option data does not change en-route. This option is 216 included in the WESP ICV computation. 218 1 - option data may change en-route. This option is excluded 219 from the ICV computation. 221 The possibility of using WESP Extensions applies equally to the 222 UDP Encapsulation of WESP. 224 2.1. Operation Administration and Maintenance (OAM) Options 226 In its most common implementation, IPsec uses different protocols for 227 key negotiation (IKE over UDP port 500/4500) and traffic 228 encapsulation (ESP, UDP-ESP(NAT-T), or AH). Having different control 229 and data channels can make troubleshooting connectivity difficult. 230 The various OAM options enable the monitoring of connectivity within 231 the data channel. 233 OAM options can potentially be generated for every packet. It is up 234 to the implementation to properly keep this traffic within reasonable 235 bounds, e.g by piggybacking OAM options onto existing packets or 236 throttling the generation of OAM options. 238 2.1.1. Connectivity Verification Option (OAM-CV) 240 The OAM-CV option allows a sender to test for connectivity to a 241 remote peer over an IPsec SA. 243 OAM-CV is a zero-length option. The OAM-CV option is immutable. 245 0 1 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type (OAM-CV)| 0 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 The recipient of an OAM CV option MUST add the OAM CV option to the 252 first subsequent packet that is small enough to hold it, or generate 253 an empty packet after a timeout. 255 2.1.2. Error Notification Option (OAM-EN) 257 The OAM-EN option is used to notify communicating peers of an error 258 in the path. The OAM-EN option can be generated by the end host or by 259 an intermediary (e.g. an intermediary dropping a packet because of 260 policy restrictions on the type of traffic that can go through it). 261 An intermediary generating an OAM-EN option SHOULD forward it to both 262 the source and destination of the packet triggering the error. 264 The OAM-EN option is mutable, hence not included in the integrity 265 check for a packet. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type (PAD) | Length | Error Code | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Extended Information (variable) | 273 ~ ~ 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Where: 278 Type: defines the option type 279 Length: defines the length of the option in octets. 281 Error Code, 2 octets: A code indicating the nature of the error. 282 Extended Information, variable length: Additional error code specific 283 information. 285 The currently defined error codes are: 287 Error Code Value generated by Extended Information 288 ========== ===== ============ ================== 289 RESERVED 0 N/A N/A 290 NO_SA 1 end node N/A 291 ADMIN_PROHIB 2 end node, IP address (optional) 292 intermediary 293 NOT_PARSED 3 intermediary IP address (optional) 295 Types 4-16383 are reserved to IANA. Values 16384-32767 are for 296 private use among mutually consenting parties. 298 The NO_SA error code SHOULD be sent by an end node in an empty packet 299 when it receives a packet which cannot match the corresponding SA. 301 The ADMIN_PROHIB error code indicates that the packet has been 302 dropped by a firewalling policy. If the end node drops the packet, it 303 SHOULD send back the ADMIN_PROHIB error code with no extended 304 information to the sender. If an intermediary node drops the packet, 305 it SHOULD send the ADMIN_PROHIB error code with its IP address in the 306 extended information to both the sender and the end node. 308 The NOT_PARSED error code indicates that an intermediary was not able 309 to correctly parse the packet and dropped it. This typically happens 310 when an intermediary requires all traffic to be NULL encrypted and 311 receives an encrypted packet. The intermediary SHOULD then send the 312 ADMIN_PROHIB error code with its IP address in the extended 313 information to both the sender and the end node. 315 2.1.3. SA Monitoring Option (OAM-SM) 317 The OAM-SM option is used to report statistics on the current SA 318 usage. It is patterned after [RFC1989]. 320 The OAM-SM option is immutable. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type (OAM-SM) | Length | Data (variable) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Data (variable) | 328 ~ ~ 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 2.2. Pad Option 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type (PAD) | Length | PAD Data (variable) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | PAD Data (variable) | 340 ~ ~ 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Where: 345 Type, 8 bits: defines the Pad option identifier (value TBD) 346 Length, 8 bits: defines the length of the pad in octets, excluding 347 the type and length fields. 348 PAD Data, variable: defines the pad value (the exact data used to pad 349 is implementation dependent). 351 The purpose of this option is to allow additional data obfuscation 352 and also used to align the options data on a 4 octet boundary. This 353 option MUST be used if other options are present and do not align the 354 options data on a 4-octet boundary. 356 2.3. Encryption Offset Option 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type (EO) | Length | Offset | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Where: 366 Type: Encryption Offset (EO) option identifier (value TBD) 367 Length: 2 octets 368 Offset: Defines the encryption offset in octets. This is the number 369 of octets that are not encrypted (but integrity protected) from the 370 beginning of the payload data. 372 The purpose of this option is to allow additional visibility into the 373 payload data, when a given encryption scheme is used. The exact value 374 of the offset is negotiated via the control channel handshake. This 375 option can be used in scenarios where intermediate devices require 376 visibility into headers of upper layer protocols (TCP/UDP headers), 377 without compromising the confidentiality of the application payload. 379 3. IKE Considerations 381 This document assumes that WESP Extensions negotiation is 382 performed using IKEv2. In order to negotiate WESP extensions 383 support via IKEv2 [RFC4306], both parties need to agree to 384 support the WESP extensions. This requirement assumes that both 385 parties are already able to negotiate and support WESP. The WESP 386 extensions negotiation can be achieved using a notification 387 method similar to USE_TRANSPORT_MODE defined in RFC 4306. 389 The notification, USE_WESP_EXTENSIONS (value TBD) MAY be 390 included in a request message that also includes an SA payload 391 requesting a CHILD_SA using WESP. It requests that the CHILD_SA 392 use WESP extensions for the SA created. If the request is 393 accepted, the response MUST also include a notification of type 394 USE_WESP_EXTENSIONS. If the responder declines the request, the 395 CHILD_SA will be established without WESP extensions. If this 396 is unacceptable to the initiator, the initiator MUST delete the 397 SA. 399 4. Security Considerations 401 TBD 403 5. IANA Considerations 405 This specification requests that IANA assign the 'X' bit for 406 Extensions Present (as shown above) out of the "WESP Flags" 407 field. 409 This specification requests that IANA create new registries for 410 WESP Extension Type and Error Notification Option Error Codes as 411 follows. To Be Completed. 413 Further assignments of these fields are to be managed via the 414 IANA policy of "Specification Required" [RFC5226]. 416 6. Acknowledgments 418 The authors thank the following people for their feedback on 419 this document. 421 Philippe Joubert, Brian Swander, Pascal Menezez. 423 This document was prepared using 2-Word-v2.0.template.doc. 425 7. References 427 7.1. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 433 RFC 4303, December 2005. 435 [WESP] Grewal, K., Montenegro., G., Bhatia, M., "Wrapped ESP for 436 Traffic Visibility", draft-ietf-ipsecme-traffic- 437 visibility, September 2009. 439 7.2. Informative References 441 [RFC1989] Simpson, W., "PPP Link Quality Monitoring", RFC 1989, 442 August 1996. 444 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 445 6 (IPv6) Specification", RFC 2460, December 1998. 447 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 448 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 449 January 2005. 451 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 452 RFC 4306, December 2005. 454 [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing 455 an IANA Considerations Section in RFCs", RFC 5226, 456 May 2008. 458 Author's Addresses 460 Gabriel Montenegro 461 Microsoft Corporation 462 One Microsoft Way 463 Redmond, WA 98052 464 USA 466 Phone: 467 Email: gabriel.montenegro@microsoft.com 469 Ken Grewal 470 Intel Corporation 471 2111 NE 25th Avenue, JF3-232 472 Hillsboro, OR 97124 473 USA 475 Phone: 476 Email: ken.grewal@intel.com