idnits 2.17.1 draft-ietf-ipsecme-traffic-visibility-06.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.i 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 ([RFC2410], [RFC4303]), 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 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 (August 06, 2009) is 5376 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 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Grewal 2 Internet Draft Intel Corporation 3 Intended status: Standards Track G. Montenegro 4 Expires: February 06, 2010 Microsoft Corporation 5 M. Bhatia 6 Alcatel-Lucent 7 August 06, 2009 9 Wrapped ESP for Traffic Visibility 10 draft-ietf-ipsecme-traffic-visibility-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance 15 with the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 06, 2010. 36 Copyright 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license- 44 info). Please review these documents carefully, as they describe 45 your rights and restrictions with respect to this document. 47 Abstract 49 This document describes the Wrapped Encapsulating Security 50 Payload (WESP) protocol, which builds on top of Encapsulating 51 Security Payload (ESP) [RFC4303] and is designed to allow 52 intermediate devices to ascertain if ESP-NULL [RFC2410] is being 53 employed and hence inspect the IPsec packets for network 54 monitoring and access control functions. Currently in the IPsec 55 standard, there is no way to differentiate between ESP 56 encryption and ESP NULL encryption by simply examining a packet. 57 This poses certain challenges to the intermediate devices that 58 need to deep inspect the packet before making a decision on what 59 should be done with that packet (Inspect and/or Allow/Drop). The 60 mechanism described in this document can be used to easily 61 disambiguate ESP-NULL from ESP encrypted packets, without 62 compromising on the security provided by ESP. 64 Table of Contents 66 1. Introduction...................................................2 67 1.1. Requirements Language.....................................4 68 1.2. Applicability Statement...................................4 69 2. Wrapped ESP (WESP) Header format...............................4 70 2.1. UDP Encapsulation.........................................7 71 2.2. Transport and Tunnel Mode Considerations..................8 72 2.2.1. Transport Mode Processing............................8 73 2.2.2. Tunnel Mode Processing...............................9 74 2.3. IKE Considerations.......................................10 75 3. Security Considerations.......................................11 76 4. IANA Considerations...........................................12 77 5. Acknowledgments...............................................12 78 6. References....................................................12 79 6.1. Normative References.....................................12 80 6.2. Informative References...................................13 82 1. Introduction 84 Use of ESP within IPsec [RFC4303] specifies how ESP packet 85 encapsulation is performed. It also specifies that ESP can use 86 NULL encryption while preserving data integrity and 87 authenticity. The exact encapsulation and algorithms employed 88 are negotiated out-of-band using, for example, IKEv2 [RFC4306] 89 and based on policy. 91 Enterprise environments typically employ numerous security 92 policies (and tools for enforcing them), as related to access 93 control, content screening, firewalls, network monitoring 94 functions, deep packet inspection, Intrusion Detection and 95 Prevention Systems (IDS and IPS), scanning and detection of 96 viruses and worms, etc. In order to enforce these policies, 97 network tools and intermediate devices require visibility into 98 packets, ranging from simple packet header inspection to deeper 99 payload examination. Network security protocols which encrypt 100 the data in transit prevent these network tools from performing 101 the aforementioned functions. 103 When employing IPsec within an enterprise environment, it is 104 desirable to employ ESP instead of AH [RFC4302], as AH does not 105 work in NAT environments. Furthermore, in order to preserve the 106 above network monitoring functions, it is desirable to use ESP- 107 NULL. In a mixed mode environment some packets containing 108 sensitive data employ a given encryption cipher suite, while 109 other packets employ ESP-NULL. For an intermediate device to 110 unambiguously distinguish which packets are leveraging ESP-NULL, 111 they would require knowledge of all the policies being employed 112 for each protected session. This is clearly not practical. 113 Heuristic-based methods can be employed to parse the packets, 114 but these can be very expensive, containing numerous rules based 115 on each different protocol and payload. Even then, the parsing 116 may not be robust in cases where fields within a given encrypted 117 packet happen to resemble the fields for a given protocol or 118 heuristic rule. This is even more problematic when different 119 length Initialization Vectors (IVs), Integrity Check Values 120 (ICVs) and padding are used for different security associations, 121 making it difficult to determine the start and end of the 122 payload data, let alone attempting any further parsing. 123 Furthermore, storage, lookup and cross-checking a set of 124 comprehensive rules against every packet adds cost to hardware 125 implementations and degrades performance. In cases where the 126 packets may be encrypted, it is also wasteful to check against 127 heuristics-based rules, when a simple exception policy (e.g., 128 allow, drop or redirect) can be employed to handle the encrypted 129 packets. Because of the non-deterministic nature of heuristics- 130 based rules for disambiguating between encrypted and non- 131 encrypted data, an alternative method for enabling intermediate 132 devices to function in encrypted data environments needs to be 133 defined. Additionally there are many types and classes of 134 network devices employed within a given network and a 135 deterministic approach would provide a simple solution for all 136 these devices. Enterprise environments typically use both 137 stateful and stateless packet inspection mechanisms. The 138 previous considerations weigh particularly heavy on stateless 139 mechanisms such as router ACLs and NetFlow exporters. 140 Nevertheless, a deterministic approach provides a simple 141 solution for the myriad types of devices employed within a 142 network, regardless of their stateful or stateless nature. 144 This document defines a mechanism to provide additional 145 information in relevant IPsec packets so intermediate devices 146 can efficiently differentiate between encrypted ESP packets and 147 ESP packets with NULL encryption. 149 The document is consistent with the operation of ESP in NAT 150 environments [RFC3947]. 152 The design principles for this protocol are the following: 154 o Allow easy identification and parsing of integrity-only IPsec 155 traffic 157 o Leverage the existing hardware IPsec parsing engines as much 158 as possible to minimize additional hardware design costs 160 o Minimize the packet overhead in the common case 162 1.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 165 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described 167 in RFC 2119 [RFC2119]. 169 1.2. Applicability Statement 171 The document is applicable only to the wrapped ESP header 172 defined below, and does not describe any changes to either ESP 173 [RFC4303] nor IP Authentication Header (AH) [RFC4302]. 175 2. Wrapped ESP (WESP) Header format 177 Wrapped ESP encapsulation (WESP) uses protocol number (TBD via 178 IANA) different from AH and ESP. Accordingly, the (outer) 179 protocol header (IPv4, IPv6, or Extension) that immediately 180 precedes the WESP header SHALL contain the value (TBD via IANA) 181 in its Protocol (IPv4) or Next Header (IPv6, Extension) field. 182 WESP provides additional attributes in each packet to assist in 183 differentiating between encrypted and non-encrypted data, and to 184 aid parsing of the packet. WESP follows RFC 4303 for all IPv6 185 and IPv4 considerations (e.g., alignment considerations). 187 This extension essentially acts as a wrapper to the existing ESP 188 protocol and provides an additional 4 octets at the front of the 189 existing ESP packet. 191 This may be depicted as follows: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Wrapped ESP Header | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Existing ESP Encapsulation | 199 ~ ~ 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1 WESP Packet Format 205 By preserving the body of the existing ESP packet format, a 206 compliant implementation can simply add in the new header, 207 without needing to change the body of the packet. The value of 208 the new protocol used to identify this new header is TBD via 209 IANA. Further details are shown below: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Next Header | HdrLen | TrailerLen | Flags | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Existing ESP Encapsulation | 217 ~ ~ 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2 Detailed WESP Packet Format 223 Where: 225 Next Header, 8 bits: This field MUST be the same as the Next 226 Header field in the ESP trailer when using ESP in the Integrity 227 only mode, and MUST be set to zero when using ESP with 228 Encryption. The receiver MUST do some sanity checks before the 229 WESP packet is accepted. Receiver MUST ensure that the Next 230 Header field in the WESP header and the Next Header field in the 231 ESP trailer match when using ESP in the Integrity only mode. The 232 packet MUST be dropped if the two do not match. Similarly, the 233 receiver MUST ensure that the Next Header field in the WESP 234 header is zero if using WESP with encryption. The WESP flags 235 dictate if the packet is encrypted and/or integrity protected. 237 HdrLen, 8 bits: Offset from the beginning of the WESP header to 238 the beginning of the Rest of Payload Data (i.e., past the IV, if 239 present) within the encapsulated ESP header, in octets. The 240 receiver MUST ensure that this field matches with the header 241 offset computed from using the negotiated SA and MUST drop the 242 packet in case it doesn't match. 244 TrailerLen, 8 bits: Offset from the end of the packet to the 245 last byte of the payload data in octets. TrailerLen MUST be set 246 to zero when using ESP with encryption. The receiver MUST only 247 accept the packet if this field matches with the value computed 248 from using the negotiated SA. This insures that sender is not 249 deliberately setting this value to obfuscate a part of the 250 payload from examination by a trusted intermediary device. 252 Flags, 8 bits 254 2 bits: Version. MUST be sent as 0 and checked by the 255 receiver. Future modifications to the WESP header may require a 256 new version number. Intermediate nodes dealing with unknown 257 versions are not necessarily able to parse the packet correctly. 258 Intermediate treatment of such packets is policy-dependent 259 (e.g., it may dictate dropping such packets). 261 1 bit: Encrypted Payload. Setting the Encrypted Payload bit 262 to 1 indicates that the WESP (and therefore ESP) payload is 263 protected with encryption. If this bit is set to 0, then the 264 payload is using ESP-NULL cipher. Setting or clearing this bit 265 also impacts the value in the WESP Next Header field, as 266 described above. The recipient MUST ensure consistency of this 267 flag with the negotiated policy and MUST drop the incoming 268 packet otherwise. 270 5 bits: Flags, reserved for future use. The flags MUST be 271 sent as 0, and ignored by the receiver. Future documents 272 defining any of these flags MUST NOT affect the distinction 273 between encrypted and unencrypted packets. Intermediate nodes 274 dealing with unknown flags are not necessarily able to parse the 275 packet correctly. Intermediate treatment of such packets is 276 policy-dependent (e.g., it may dictate dropping such packets). 278 Future versions of this protocol may change the Version number 279 and/or the Flag bits sent, possibly by negotiating them over the 280 control channel. The receiver MUST drop packets for which the 281 integrity check is invalid. 283 As can be seen, the WESP format extends the standard ESP header 284 by the first 4 octets. The WESP header is integrity protected, 285 along with all the fields specified for ESP in RFC 4303. 287 2.1. UDP Encapsulation 289 This section describes a mechanism for running the new packet 290 format over the existing UDP encapsulation of ESP as defined in 291 RFC 3948. This allows leveraging the existing IKE negotiation of 292 the UDP port for NAT-T discovery and usage [RFC3947, RFC4306], 293 as well as preserving the existing UDP ports for ESP (port 294 4500). With UDP encapsulation, the packet format can be 295 depicted as follows. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Src Port (4500) | Dest Port (4500) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Length | Checksum | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Protocol Identifier (value = 0x00000002) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Next Header | HdrLen | TrailerLen | Flags | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Existing ESP Encapsulation | 309 ~ ~ 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 3 UDP-Encapsulated WESP Header 315 Where: 317 Source/Destination port (4500) and checksum: describes the UDP 318 encapsulation header, per RFC3948. 320 Protocol Identifier: new field to demultiplex between UDP 321 encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and 322 the UDP encapsulation in this specification. 324 According to RFC 3948, clause 2.2, a 4 octet value of zero (0) 325 immediately following the UDP header indicates a Non-ESP marker, 326 which can be used to assume that the data following that value 327 is an IKE packet. Similarly, a value greater then 255 indicates 328 that the packet is an ESP packet and the 4-octet value can be 329 treated as the ESP SPI. However, RFC 4303, clause 2.1 indicates 330 that the values 1-255 are reserved and cannot be used as the 331 SPI. We leverage that knowledge and use one of these reserved 332 values to indicate that the UDP encapsulated ESP header contains 333 this new packet format for ESP encapsulation. 335 The remaining fields in the packet have the same meaning as per 336 section 2 above. 338 2.2. Transport and Tunnel Mode Considerations 340 This extension is equally applicable to transport and tunnel mode 341 where the ESP Next Header field is used to differentiate between 342 these modes, as per the existing IPsec specifications. 344 In the diagrams below, "WESP ICV" refers to the ICV computation as 345 modified by this specification. Namely, the ESP ICV computation is 346 augmented to include the four octets that constitute the WESP header. 347 Otherwise, the ICV computation is as specified by ESP [RFC4303]. 349 2.2.1. Transport Mode Processing 351 In transport mode, ESP is inserted after the IP header and before a 352 next layer protocol, e.g., TCP, UDP, ICMP, etc. The following 353 diagrams illustrate how WESP is applied to the ESP transport mode for 354 a typical packet, on a "before and after" basis. 356 BEFORE APPLYING WESP - IPv4 357 ------------------------------------------------- 358 |orig IP hdr | ESP | | | ESP | ESP| 359 |(any options)| Hdr | TCP | Data | Trailer | ICV| 360 ------------------------------------------------- 361 |<----encryption ----->| 362 |<------- integrity -------->| 364 AFTER APPLYING WESP - IPv4 365 -------------------------------------------------------- 366 |orig IP hdr | WESP | ESP | | | ESP |WESP| 367 |(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV| 368 -------------------------------------------------------- 369 |<---- encryption ---->| 370 |<----------- integrity ----------->| 372 BEFORE APPLYING WESP - IPv6 373 --------------------------------------------------------- 374 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 375 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 376 --------------------------------------------------------- 377 |<---- encryption --->| 378 |<------ integrity ------>| 380 AFTER APPLYING WESP - IPv6 381 -------------------------------------------------------------- 382 | orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP| 383 |IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV| 384 -------------------------------------------------------------- 385 |<---- encryption --->| 386 |<-------- integrity --------->| 388 * = if present, could be before WESP, after ESP, or both 390 All other considerations are as per RFC 4303. 392 2.2.2. Tunnel Mode Processing 394 In tunnel mode, ESP is inserted after the new IP header and before 395 the original IP header, as per RFC 4303. The following diagram 396 illustrates how WESP is applied to the ESP tunnel mode for a typical 397 packet, on a "before and after" basis. 399 BEFORE APPLYING WESP - IPv4 400 ----------------------------------------------------------- 401 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 402 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 403 ----------------------------------------------------------- 404 |<--------- encryption --------->| 405 |<------------- integrity ------------>| 407 AFTER APPLYING WESP - IPv4 408 -------------------------------------------------------------- 409 |new IP hdr* | | | orig IP hdr* | | | ESP |WESP| 410 |(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV| 411 -------------------------------------------------------------- 412 |<--------- encryption --------->| 413 |<--------------- integrity ------------->| 415 BEFORE APPLYING WESP - IPv6 416 ------------------------------------------------------------ 417 | new* |new ext | | orig*|orig ext | | | ESP | ESP| 418 |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 419 ------------------------------------------------------------ 420 |<--------- encryption ---------->| 421 |<------------ integrity ------------>| 423 AFTER APPLYING WESP - IPv6 424 ----------------------------------------------------------------- 425 | new* |new ext | | | orig*|orig ext | | | ESP |WESP| 426 |IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 427 ----------------------------------------------------------------- 428 |<--------- encryption ---------->| 429 |<--------------- integrity -------------->| 431 * = if present, construction of outer IP hdr/extensions and 433 modification of inner IP hdr/extensions is discussed in 435 the Security Architecture document. 437 All other considerations are as per RFC 4303. 439 2.3. IKE Considerations 441 This document assumes that WESP negotiation is performed using 442 IKEv2. In order to negotiate the new format of ESP encapsulation 443 via IKEv2 [RFC4306], both parties need to agree to use the new 444 packet format. This can be achieved using a notification method 445 similar to USE_TRANSPORT_MODE defined in RFC 4306. 447 The notification, USE_WESP_MODE (value TBD) MAY be included in a 448 request message that also includes an SA payload requesting a 449 CHILD_SA using ESP. It requests that the CHILD_SA use WESP mode 450 rather than ESP for the SA created. If the request is accepted, 451 the response MUST also include a notification of type 452 USE_WESP_MODE. If the responder declines the request, the 453 CHILD_SA will be established using ESP, as per RFC 4303. If 454 this is unacceptable to the initiator, the initiator MUST delete 455 the SA. Note: Except when using this option to negotiate WESP 456 mode, all CHILD_SAs will use standard ESP. 458 Negotiation of WESP in this manner preserves all other 459 negotiation parameters, including NAT-T [RFC3948]. NAT-T is 460 wholly compatible with this wrapped frame format and can be used 461 as-is, without any modifications, in environments where NAT is 462 present and needs to be taken into account. 464 3. Security Considerations 466 As this document augments the existing ESP encapsulation format, 467 UDP encapsulation definitions specified in RFC 3948 and IKE 468 negotiation of the new encapsulation, the security observations 469 made in those documents also apply here. In addition, as this 470 document allows intermediate device visibility into IPsec ESP 471 encapsulated frames for the purposes of network monitoring 472 functions, care should be taken not to send sensitive data over 473 connections using definitions from this document, based on 474 network domain/administrative policy. A strong key agreement 475 protocol, such as IKEv2, together with a strong policy engine 476 should be used to in determining appropriate security policy for 477 the given traffic streams and data over which it is being 478 employed. 480 ESP is end-to-end and it will be impossible for the intermediate 481 devices to verify that all the fields in the WESP header are 482 correct. It is thus possible to modify the WESP header so that 483 the packet sneaks past a firewall if the fields in the WESP 484 header are set to something that the firewall will allow. The 485 endpoint thus must verify the sanity of the WESP header before 486 accepting the packet. In an extreme case, someone colluding with 487 the attacker, could change the WESP fields back to the original 488 values so that the attack goes unnoticed. However, this is not a 489 new problem and it already exists IPSec. 491 4. IANA Considerations 493 The WESP protocol number is assigned by IANA out of the IP 494 Protocol Number space (and as recorded at the IANA web page at 495 http://www.iana.org/assignments/protocol-numbers) is: TBD. 497 The USE_WESP_MODE notification number is assigned out of the 498 "IKEv2 Notify Message Types - Status Types" registry's 16384- 499 40959 (Expert Review) range: TBD. 501 This specification requests that IANA create a new registry for 502 "WESP Flags" to be managed as follows: 504 The first 2 bits are the WESP Version Number. The value 0 is 505 assigned to the version defined in this specification. Further 506 assignments of the WESP Version Number are to be managed via the 507 IANA Policy of "Standards Action" [RFC5226]. The final 6 bits of 508 the WESP Flags are the "Non-version Flags". This specification 509 defines no values, and future assignment is to be managed via 510 the IANA Policy of "Specification Required". 512 5. Acknowledgments 514 The authors would like to acknowledge the following people for 515 their feedback on updating the definitions in this document. 517 David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron 518 Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier 519 among others. 521 This document was prepared using 2-Word-v2.0.template.doc. 523 6. References 525 6.1. Normative References 527 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm 528 and Its Use With IPsec", RFC 2410, November 1998. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 534 RFC 4303, December 2005. 536 6.2. Informative References 538 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 539 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 540 January 2005. 542 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 543 M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", 544 RFC 3948, January 2005. 546 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 547 December 2005. 549 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 550 RFC 4306, December 2005. 552 [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing 553 an IANA Considerations Section in RFCs", RFC 5226, 554 May 2008. 556 Author's Addresses 558 Ken Grewal 559 Intel Corporation 560 2111 NE 25th Avenue, JF3-232 561 Hillsboro, OR 97124 562 USA 564 Phone: 565 Email: ken.grewal@intel.com 566 Gabriel Montenegro 567 Microsoft Corporation 568 One Microsoft Way 569 Redmond, WA 98052 570 USA 572 Phone: 573 Email: gabriel.montenegro@microsoft.com 575 Manav Bhatia 576 Alcatel-Lucent 577 Bangalore 578 India 580 Phone: 581 Email: manav@alcatel-lucent.com