idnits 2.17.1 draft-ietf-ipsecme-traffic-visibility-05.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 (June 24, 2009) is 5419 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: December 23, 2009 Microsoft Corporation 5 M. Bhatia 6 Alcatel-Lucent 7 June 24, 2009 9 Wrapped ESP for Traffic Visibility 10 draft-ietf-ipsecme-traffic-visibility-05.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 October 30, 2009. 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.........................................6 71 2.2. Transport and Tunnel Mode Considerations..................7 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.......................................10 76 4. IANA Considerations...........................................11 77 5. Acknowledgments...............................................11 78 6. References....................................................11 79 6.1. Normative References.....................................11 80 6.2. Informative References...................................12 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 ESP with encryption. In this case, the 235 packet MUST be dropped if it is not set to zero and the packet 236 is encrypted. 238 HdrLen, 8 bits: Offset to the beginning of the Payload Data in 239 octets. The receiver MUST ensure that this field matches with 240 the header offset computed from using the negotiated SA and MUST 241 drop the packet in case it doesn't match. 243 TrailerLen, 8 bits: Offset from the end of the packet to the 244 last byte of the payload data in octets. TrailerLen MUST be set 245 to zero when using ESP with encryption. The receiver MUST only 246 accept the packet if this field matches with the value computed 247 from using the negotiated SA. This insures that sender is not 248 deliberately setting this value to obfuscate a part of the 249 payload from examination by a trusted intermediary device. 251 Flags, 8 bits 253 2 bits: Version. MUST be sent as 0 and checked by the 254 receiver. Future modifications to the WESP header may require a 255 new version number. Intermediate nodes dealing with unknown 256 versions are not necessarily able to parse the packet correctly. 257 Intermediate treatment of such packets is policy-dependent 258 (e.g., it may dictate dropping such packets). 260 6 bits: Flags, reserved for future use. The flags MUST be 261 sent as 0, and ignored by the receiver. Future documents 262 defining any of these flags MUST NOT affect the distinction 263 between encrypted and unencrypted packets. Intermediate nodes 264 dealing with unknown flags are not necessarily able to parse the 265 packet correctly. Intermediate treatment of such packets is 266 policy-dependent (e.g., it may dictate dropping such packets). 268 Future versions of this protocol may change the Version number 269 and/or the Flag bits sent, possibly by negotiating them over the 270 control channel. The receiver MUST drop packets for which the 271 integrity check is invalid. 273 As can be seen, the WESP format extends the standard ESP header 274 by the first 4 octets. The WESP header is integrity protected, 275 along with all the fields specified for ESP in RFC 4303. 277 2.1. UDP Encapsulation 279 This section describes a mechanism for running the new packet 280 format over the existing UDP encapsulation of ESP as defined in 281 RFC 3948. This allows leveraging the existing IKE negotiation of 282 the UDP port for NAT-T discovery and usage [RFC3947, RFC4306], 283 as well as preserving the existing UDP ports for ESP (port 284 4500). With UDP encapsulation, the packet format can be 285 depicted as follows. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Src Port (4500) | Dest Port (4500) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Length | Checksum | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Protocol Identifier (value = 0x00000002) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Next Header | HdrLen | TrailerLen | Flags | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Existing ESP Encapsulation | 299 ~ ~ 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3 UDP-Encapsulated WESP Header 305 Where: 307 Source/Destination port (4500) and checksum: describes the UDP 308 encapsulation header, per RFC3948. 310 Protocol Identifier: new field to demultiplex between UDP 311 encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and 312 the UDP encapsulation in this specification. 314 According to RFC 3948, clause 2.2, a 4 octet value of zero (0) 315 immediately following the UDP header indicates a Non-ESP marker, 316 which can be used to assume that the data following that value 317 is an IKE packet. Similarly, a value greater then 255 indicates 318 that the packet is an ESP packet and the 4-octet value can be 319 treated as the ESP SPI. However, RFC 4303, clause 2.1 indicates 320 that the values 1-255 are reserved and cannot be used as the 321 SPI. We leverage that knowledge and use one of these reserved 322 values to indicate that the UDP encapsulated ESP header contains 323 this new packet format for ESP encapsulation. 325 The remaining fields in the packet have the same meaning as per 326 section 2 above. 328 2.2. Transport and Tunnel Mode Considerations 330 This extension is equally applicable to transport and tunnel mode 331 where the ESP Next Header field is used to differentiate between 332 these modes, as per the existing IPsec specifications. 334 In the diagrams below, "WESP ICV" refers to the ICV computation as 335 modified by this specification. Namely, the ESP ICV computation is 336 augmented to include the four octets that constitute the WESP header. 337 Otherwise, the ICV computation is as specified by ESP [RFC4303]. 339 2.2.1. Transport Mode Processing 341 In transport mode, ESP is inserted after the IP header and before a 342 next layer protocol, e.g., TCP, UDP, ICMP, etc. The following 343 diagrams illustrate how WESP is applied to the ESP transport mode for 344 a typical packet, on a "before and after" basis. 346 BEFORE APPLYING WESP - IPv4 347 ------------------------------------------------- 348 |orig IP hdr | ESP | | | ESP | ESP| 349 |(any options)| Hdr | TCP | Data | Trailer | ICV| 350 ------------------------------------------------- 351 |<----encryption ----->| 352 |<------- integrity -------->| 354 AFTER APPLYING WESP - IPv4 355 -------------------------------------------------------- 356 |orig IP hdr | WESP | ESP | | | ESP |WESP| 357 |(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV| 358 -------------------------------------------------------- 359 |<---- encryption ---->| 360 |<----------- integrity ----------->| 362 BEFORE APPLYING WESP - IPv6 363 --------------------------------------------------------- 364 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 365 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 366 --------------------------------------------------------- 367 |<---- encryption --->| 368 |<------ integrity ------>| 370 AFTER APPLYING WESP - IPv6 371 -------------------------------------------------------------- 372 | orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP| 373 |IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV| 374 -------------------------------------------------------------- 375 |<---- encryption --->| 376 |<-------- integrity --------->| 378 * = if present, could be before WESP, after ESP, or both 380 All other considerations are as per RFC 4303. 382 2.2.2. Tunnel Mode Processing 384 In tunnel mode, ESP is inserted after the new IP header and before 385 the original IP header, as per RFC 4303. The following diagram 386 illustrates how WESP is applied to the ESP tunnel mode for a typical 387 packet, on a "before and after" basis. 389 BEFORE APPLYING WESP - IPv4 390 ----------------------------------------------------------- 391 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 392 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 393 ----------------------------------------------------------- 394 |<--------- encryption --------->| 395 |<------------- integrity ------------>| 397 AFTER APPLYING WESP - IPv4 398 -------------------------------------------------------------- 399 |new IP hdr* | | | orig IP hdr* | | | ESP |WESP| 400 |(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV| 401 -------------------------------------------------------------- 402 |<--------- encryption --------->| 403 |<--------------- integrity ------------->| 405 BEFORE APPLYING WESP - IPv6 406 ------------------------------------------------------------ 407 | new* |new ext | | orig*|orig ext | | | ESP | ESP| 408 |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 409 ------------------------------------------------------------ 410 |<--------- encryption ---------->| 411 |<------------ integrity ------------>| 413 AFTER APPLYING WESP - IPv6 414 ----------------------------------------------------------------- 415 | new* |new ext | | | orig*|orig ext | | | ESP |WESP| 416 |IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 417 ----------------------------------------------------------------- 418 |<--------- encryption ---------->| 419 |<--------------- integrity -------------->| 421 * = if present, construction of outer IP hdr/extensions and 423 modification of inner IP hdr/extensions is discussed in 424 the Security Architecture document. 426 All other considerations are as per RFC 4303. 428 2.3. IKE Considerations 430 This document assumes that WESP negotiation is performed using 431 IKEv2. In order to negotiate the new format of ESP encapsulation 432 via IKEv2 [RFC4306], both parties need to agree to use the new 433 packet format. This can be achieved using a notification method 434 similar to USE_TRANSPORT_MODE defined in RFC 4306. 436 The notification, USE_WESP_MODE (value TBD) MAY be included in a 437 request message that also includes an SA payload requesting a 438 CHILD_SA using ESP. It requests that the CHILD_SA use WESP mode 439 rather than ESP for the SA created. If the request is accepted, 440 the response MUST also include a notification of type 441 USE_WESP_MODE. If the responder declines the request, the 442 CHILD_SA will be established using ESP, as per RFC 4303. If 443 this is unacceptable to the initiator, the initiator MUST delete 444 the SA. Note: Except when using this option to negotiate WESP 445 mode, all CHILD_SAs will use standard ESP. 447 Negotiation of WESP in this manner preserves all other 448 negotiation parameters, including NAT-T [RFC3948]. NAT-T is 449 wholly compatible with this wrapped frame format and can be used 450 as-is, without any modifications, in environments where NAT is 451 present and needs to be taken into account. 453 3. Security Considerations 455 As this document augments the existing ESP encapsulation format, 456 UDP encapsulation definitions specified in RFC 3948 and IKE 457 negotiation of the new encapsulation, the security observations 458 made in those documents also apply here. In addition, as this 459 document allows intermediate device visibility into IPsec ESP 460 encapsulated frames for the purposes of network monitoring 461 functions, care should be taken not to send sensitive data over 462 connections using definitions from this document, based on 463 network domain/administrative policy. A strong key agreement 464 protocol, such as IKEv2, together with a strong policy engine 465 should be used to in determining appropriate security policy for 466 the given traffic streams and data over which it is being 467 employed. 469 ESP is end-to-end and it will be impossible for the intermediate 470 devices to verify that all the fields in the WESP header are 471 correct. It is thus possible to modify the WESP header so that 472 the packet sneaks past a firewall if the fields in the WESP 473 header are set to something that the firewall will allow. The 474 endpoint thus must verify the sanity of the WESP header before 475 accepting the packet. In an extreme case, someone colluding with 476 the attacker, could change the WESP fields back to the original 477 values so that the attack goes unnoticed. However, this is not a 478 new problem and it already exists IPSec. 480 4. IANA Considerations 482 The WESP protocol number is assigned by IANA out of the IP 483 Protocol Number space (and as recorded at the IANA web page at 484 http://www.iana.org/assignments/protocol-numbers) is: TBD. 486 The USE_WESP_MODE notification number is assigned out of the 487 "IKEv2 Notify Message Types - Status Types" registry's 16384- 488 40959 (Expert Review) range: TBD. 490 This specification requests that IANA create a new registry for 491 "WESP Flags" to be managed as follows: 493 The first 2 bits are the WESP Version Number. The value 0 is 494 assigned to the version defined in this specification. Further 495 assignments of the WESP Version Number are to be managed via the 496 IANA Policy of "Standards Action" [RFC5226]. The final 6 bits of 497 the WESP Flags are the "Non-version Flags". This specification 498 defines no values, and future assignment is to be managed via 499 the IANA Policy of "Specification Required". 501 5. Acknowledgments 503 The authors would like to acknowledge the following people for 504 their feedback on updating the definitions in this document. 506 David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron 507 Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier 508 among others. 510 This document was prepared using 2-Word-v2.0.template.doc. 512 6. References 514 6.1. Normative References 516 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm 517 and Its Use With IPsec", RFC 2410, November 1998. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 523 RFC 4303, December 2005. 525 6.2. Informative References 527 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 528 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 529 January 2005. 531 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 532 M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", 533 RFC 3948, January 2005. 535 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 536 December 2005. 538 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 539 RFC 4306, December 2005. 541 [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing 542 an IANA Considerations Section in RFCs", RFC 5226, 543 May 2008. 545 Author's Addresses 547 Ken Grewal 548 Intel Corporation 549 2111 NE 25th Avenue, JF3-232 550 Hillsboro, OR 97124 551 USA 553 Phone: 554 Email: ken.grewal@intel.com 555 Gabriel Montenegro 556 Microsoft Corporation 557 One Microsoft Way 558 Redmond, WA 98052 559 USA 561 Phone: 562 Email: gabriel.montenegro@microsoft.com 564 Manav Bhatia 565 Alcatel-Lucent 566 Bangalore 567 India 569 Phone: 570 Email: manav@alcatel-lucent.com