idnits 2.17.1 draft-ietf-ipsecme-traffic-visibility-10.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 ([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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 10, 2009) is 5280 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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: May 10, 2010 Microsoft Corporation 5 M. Bhatia 6 Alcatel-Lucent 7 November 10, 2009 9 Wrapped ESP for Traffic Visibility 10 draft-ietf-ipsecme-traffic-visibility-10.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. This document may 16 contain material from IETF Documents or IETF Contributions 17 published or made publicly available before November 10, 2008. 18 The person(s) controlling the copyright in some of this material 19 may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards 21 Process. Without obtaining an adequate license from the 22 person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, 24 and derivative works of it may not be created outside the IETF 25 Standards Process, except to format it for publication as an RFC 26 or to translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet 29 Engineering Task Force (IETF), its areas, and its working 30 groups. Note that other groups may also distribute working 31 documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet- 36 Drafts as reference material or to cite them other than as "work 37 in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on May 10, 2010. 47 Copyright 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license- 55 info). Please review these documents carefully, as they describe 56 your rights and restrictions with respect to this document. 58 Abstract 60 This document describes the Wrapped Encapsulating Security 61 Payload (WESP) protocol, which builds on the Encapsulating 62 Security Payload (ESP) [RFC4303], and is designed to allow 63 intermediate devices to (1) ascertain if data confidentiality is 64 being employed within ESP and if not, (2) inspect the IPsec 65 packets for network monitoring and access control functions. 66 Currently in the IPsec ESP standard, there is no way to 67 differentiate between encrypted and unencrypted payloads by 68 simply examining a packet. This poses certain challenges to the 69 intermediate devices that need to deep inspect the packet before 70 making a decision on what should be done with that packet 71 (Inspect and/or Allow/Drop). The mechanism described in this 72 document can be used to easily disambiguate integrity-only ESP 73 from ESP-encrypted packets, without compromising on the security 74 provided by ESP. 76 Table of Contents 78 1. Introduction...................................................3 79 1.1. Requirements Language.....................................4 80 1.2. Applicability Statement...................................4 81 2. Wrapped ESP (WESP) Header format...............................5 82 2.1. UDP Encapsulation.........................................8 83 2.2. Transport and Tunnel Mode Considerations..................9 84 2.2.1. Transport Mode Processing...........................10 85 2.2.2. Tunnel Mode Processing..............................11 86 2.3. IKE Considerations.......................................12 87 3. Security Considerations.......................................12 88 4. IANA Considerations...........................................13 89 5. Acknowledgments...............................................13 90 6. References....................................................14 91 6.1. Normative References.....................................14 92 6.2. Informative References...................................14 94 1. Introduction 96 Use of ESP within IPsec [RFC4303] specifies how ESP packet 97 encapsulation is performed. It also specifies that ESP can 98 provide data confidentiality and data integrity services. Data 99 integrity without data confidentiality ("integrity-only ESP") is 100 possible via the ESP-NULL encryption algorithm [RFC2410] or via 101 combined-mode algorithms such as AES-GMAC [RFC4543]. The exact 102 encapsulation and algorithms employed are negotiated out-of-band 103 using, for example, IKEv2 [RFC4306] and based on policy. 105 Enterprise environments typically employ numerous security 106 policies (and tools for enforcing them), as related to access 107 control, content screening, firewalls, network monitoring 108 functions, deep packet inspection, Intrusion Detection and 109 Prevention Systems (IDS and IPS), scanning and detection of 110 viruses and worms, etc. In order to enforce these policies, 111 network tools and intermediate devices require visibility into 112 packets, ranging from simple packet header inspection to deeper 113 payload examination. Network security protocols which encrypt 114 the data in transit prevent these network tools from performing 115 the aforementioned functions. 117 When employing IPsec within an enterprise environment, it is 118 desirable to employ ESP instead of AH [RFC4302], as AH does not 119 work in NAT environments. Furthermore, in order to preserve the 120 above network monitoring functions, it is desirable to use 121 integrity-only ESP. In a mixed-mode environment, some packets 122 containing sensitive data employ a given encryption cipher 123 suite, while other packets employ integrity-only ESP. For an 124 intermediate device to unambiguously distinguish which packets 125 are using integrity-only ESP requires knowledge of all the 126 policies being employed for each protected session. This is 127 clearly not practical. Heuristics-based methods can be employed 128 to parse the packets, but these can be very expensive, requiring 129 numerous rules based on each different protocol and payload. 130 Even then, the parsing may not be robust in cases where fields 131 within a given encrypted packet happen to resemble the fields 132 for a given protocol or heuristic rule. In cases where the 133 packets may be encrypted, it is also wasteful to check against 134 heuristics-based rules, when a simple exception policy (e.g., 135 allow, drop or redirect) can be employed to handle the encrypted 136 packets. Because of the non-deterministic nature of heuristics- 137 based rules for disambiguating between encrypted and non- 138 encrypted data, an alternative method for enabling intermediate 139 devices to function in encrypted data environments needs to be 140 defined. Additionally there are many types and classes of 141 network devices employed within a given network and a 142 deterministic approach provides a simple solution for all of 143 them. Enterprise environments typically use both stateful and 144 stateless packet inspection mechanisms. The previous 145 considerations weigh particularly heavy on stateless mechanisms 146 such as router ACLs and NetFlow exporters. Nevertheless, a 147 deterministic approach provides a simple solution for the myriad 148 types of devices employed within a network, regardless of their 149 stateful or stateless nature. 151 This document defines a mechanism to provide additional 152 information in relevant IPsec packets so intermediate devices 153 can efficiently differentiate between encrypted and integrity- 154 only packets. Additionally and in the interest of consistency, 155 this extended format can also be used to carry encrypted packets 156 without loss in disambiguation. 158 The document is consistent with the operation of ESP in NAT 159 environments [RFC3947]. 161 The design principles for this protocol are the following: 163 o Allow easy identification and parsing of integrity-only IPsec 164 traffic 166 o Leverage the existing hardware IPsec parsing engines as much 167 as possible to minimize additional hardware design costs 169 o Minimize the packet overhead in the common case 171 1.1. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 174 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described 176 in RFC 2119 [RFC2119]. 178 1.2. Applicability Statement 180 The document is applicable only to the wrapped ESP header 181 defined below, and does not describe any changes to either ESP 182 [RFC4303] nor IP Authentication Header (AH) [RFC4302]. 184 There are two ways to enable intermediate security devices to 185 distinguish between encrypted and unencrypted ESP traffic: 187 - The heuristics approach [Heuristics I-D] has the intermediate 188 node inspect the unchanged ESP traffic, to determine with 189 extremely high probability whether or not the traffic stream is 190 encrypted. 192 - The Wrapped ESP (WESP) approach described in this document, in 193 contrast, requires the ESP endpoints to be modified to support 194 the new protocol. WESP allows the intermediate node to 195 distinguish encrypted and unencrypted traffic deterministically, 196 using a simpler implementation for the intermediate node. 198 Both approaches are being documented simultaneously by the IP 199 Security Maintenance and Extensions (IPsecME) Working Group, 200 with WESP being put on Standards Track while the heuristics 201 approach is being published as an Informational RFC. While 202 endpoints are being modified to adopt WESP, we expect both 203 approaches to coexist for years, because the heuristic approach 204 is needed to inspect traffic where at least one of the endpoints 205 has not been modified. In other words, intermediate nodes are 206 expected to support both approaches in order to achieve good 207 security and performance during the transition period. 209 2. Wrapped ESP (WESP) Header format 211 Wrapped ESP encapsulation (WESP) uses protocol number (TBD via 212 IANA). Accordingly, the (outer) protocol header (IPv4, IPv6, or 213 Extension) that immediately precedes the WESP header SHALL 214 contain the value (TBD via IANA) in its Protocol (IPv4) or Next 215 Header (IPv6, Extension) field. WESP provides additional 216 attributes in each packet to assist in differentiating between 217 encrypted and non-encrypted data, and to aid parsing of the 218 packet. WESP follows RFC 4303 for all IPv6 and IPv4 219 considerations (e.g., alignment considerations). 221 This extension essentially acts as a wrapper to the existing ESP 222 protocol and provides an additional 4 octets at the front of the 223 existing ESP packet. 225 This may be depicted as follows: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Wrapped ESP Header | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Existing ESP Encapsulation | 233 ~ ~ 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1 WESP Packet Format 239 By preserving the body of the existing ESP packet format, a 240 compliant implementation can simply add in the new header, 241 without needing to change the body of the packet. The value of 242 the new protocol used to identify this new header is TBD via 243 IANA. Further details are shown below: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Next Header | HdrLen | TrailerLen | Flags | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | IPv6Padding (optional) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Existing ESP Encapsulation | 253 ~ ~ 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2 Detailed WESP Packet Format 259 Where: 261 Next Header, 8 bits: This field MUST be the same as the Next 262 Header field in the ESP trailer when using ESP in the Integrity 263 only mode. When using ESP with encryption, the "Next Header" 264 field looses this name and semantics and becomes an empty field 265 which MUST be initialized to all zeros. The receiver MUST do 266 some sanity checks before the WESP packet is accepted. The 267 receiver MUST ensure that the Next Header field in the WESP 268 header and the Next Header field in the ESP trailer match when 269 using ESP in the Integrity only mode. The packet MUST be dropped 270 if the two do not match. Similarly, the receiver MUST ensure 271 that the Next Header field in the WESP header is an empty field 272 initialized to zero if using WESP with encryption. The WESP 273 flags dictate if the packet is encrypted. 275 HdrLen, 8 bits: Offset from the beginning of the WESP header to 276 the beginning of the Rest of Payload Data (i.e., past the IV, if 277 present) within the encapsulated ESP header, in octets. HdrLen 278 MUST be set to zero when using ESP with encryption. When using 279 integrity-only ESP, the following HdrLen values are invalid: any 280 value less than 12; any value that is not a multiple of 4; any 281 value that is not a multiple of 8 when using IPv6. The receiver 282 MUST ensure that this field matches with the header offset 283 computed from using the negotiated SA and MUST drop the packet 284 in case it does not match. 286 TrailerLen, 8 bits: TrailerLen contains the size of the ICV 287 being used by the negotiated algorithms within the IPsec SA. 288 TrailerLen MUST be set to zero when using ESP with encryption. 289 The receiver MUST only accept the packet if this field matches 290 with the value computed from using the negotiated SA. This 291 insures that sender is not deliberately setting this value to 292 obfuscate a part of the payload from examination by a trusted 293 intermediary device. 295 Flags, 8 bits: The bits are defined most-significant-bit (MSB) 296 first, so bit 0 is the most significant bit of the flags octet. 298 0 1 2 3 4 5 6 7 299 +-+-+-+-+-+-+-+-+ 300 |V V|E|P| Rsvd | 301 +-+-+-+-+-+-+-+-+ 303 Figure 3 Flags format 305 Version (V), 2 bits: MUST be sent as 0 and checked by the 306 receiver. If the version is different than an expected version 307 number (e.g. negotiated via the control channel), then the 308 packet MUST be dropped by the receiver. Future modifications to 309 the WESP header may require a new version number. Intermediate 310 nodes dealing with unknown versions are not necessarily able to 311 parse the packet correctly. Intermediate treatment of such 312 packets is policy-dependent (e.g., it may dictate dropping such 313 packets). 315 Encrypted Payload (E), 1 bit: Setting the Encrypted Payload 316 bit to 1 indicates that the WESP (and therefore ESP) payload is 317 protected with encryption. If this bit is set to 0, then the 318 payload is using integrity-only ESP. Setting or clearing this 319 bit also impacts the value in the WESP Next Header field, as 320 described above. The recipient MUST ensure consistency of this 321 flag with the negotiated policy and MUST drop the incoming 322 packet otherwise. 324 Padding header (P), 1 bit: If set (value 1), the 4 octet padding 325 is present. If not set (value 0), the 4 octet padding is absent. This 326 padding MUST be used with IPv6 in order to preserve IPv6 8-octet 327 alignment. If WESP is being used with UDP encapsulation (see 2.1 328 below) and IPv6, the Protocol Identifier (0x00000002) occupies four 329 octets so the IPv6 padding is not needed, as the header is already on 330 an 8-octet boundary. This padding MUST NOT be used with IPv4, as it 331 is not needed to guarantee 4-octet IPv4 alignment. 333 Rsvd, 4 bits: Reserved for future use. The reserved bits 334 MUST be sent as 0, and ignored by the receiver. Future documents 335 defining any of these bits MUST NOT affect the distinction 336 between encrypted and unencrypted packets. Intermediate nodes 337 dealing with unknown reserved bits are not necessarily able to 338 parse the packet correctly. Intermediate treatment of such 339 packets is policy-dependent (e.g., it may dictate dropping such 340 packets). 342 Future versions of this protocol may change the Version number 343 and/or the reserved bits sent, possibly by negotiating them over 344 the control channel. 346 As can be seen, the WESP format extends the standard ESP header 347 by the first 4 octets for IPv4 and optionally (see above) by 8 348 octets for IPv6. The WESP header is integrity protected, along 349 with all the fields specified for ESP in RFC 4303. 351 Modifying the integrity protection in ESP to include the 352 additional WESP header octets means that ESP implementations 353 cannot be simply reused. The chosen tradeoff errs on the side of 354 caution instead of treating ESP as a completely modular 355 component. 357 2.1. UDP Encapsulation 359 This section describes a mechanism for running the new packet 360 format over the existing UDP encapsulation of ESP as defined in 361 RFC 3948. This allows leveraging the existing IKE negotiation of 362 the UDP port for NAT-T discovery and usage [RFC3947, RFC4306], 363 as well as preserving the existing UDP ports for ESP (port 364 4500). With UDP encapsulation, the packet format can be 365 depicted as follows. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Src Port (4500) | Dest Port (4500) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Length | Checksum | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Protocol Identifier (value = 0x00000002) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Next Header | HdrLen | TrailerLen | Flags | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Existing ESP Encapsulation | 379 ~ ~ 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 4 UDP-Encapsulated WESP Header 385 Where: 387 Source/Destination port (4500) and checksum: describes the UDP 388 encapsulation header, per RFC3948. 390 Protocol Identifier: new field to demultiplex between UDP 391 encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and 392 the UDP encapsulation in this specification. 394 According to RFC 3948, clause 2.2, a 4 octet value of zero (0) 395 immediately following the UDP header indicates a Non-ESP marker, 396 which can be used to assume that the data following that value 397 is an IKE packet. Similarly, a value greater then 255 indicates 398 that the packet is an ESP packet and the 4-octet value can be 399 treated as the ESP SPI. However, RFC 4303, clause 2.1 indicates 400 that the values 1-255 are reserved and cannot be used as the 401 SPI. We leverage that knowledge and use one of these reserved 402 values to indicate that the UDP encapsulated ESP header contains 403 this new packet format for ESP encapsulation. 405 The remaining fields in the packet have the same meaning as per 406 section 2 above. 408 2.2. Transport and Tunnel Mode Considerations 410 This extension is equally applicable to transport and tunnel mode 411 where the ESP Next Header field is used to differentiate between 412 these modes, as per the existing IPsec specifications. 414 In the diagrams below, "WESP ICV" refers to the ICV computation as 415 modified by this specification. Namely, the ESP ICV computation is 416 augmented to include the four octets that constitute the WESP header. 417 Otherwise, the ICV computation is as specified by ESP [RFC4303]. 419 2.2.1. Transport Mode Processing 421 In transport mode, ESP is inserted after the IP header and before a 422 next layer protocol, e.g., TCP, UDP, ICMP, etc. The following 423 diagrams illustrate how WESP is applied to the ESP transport mode for 424 a typical packet, on a "before and after" basis. 426 BEFORE APPLYING WESP - IPv4 427 ---------------------------- 428 |orig IP hdr | | | 429 |(any options)| TCP | Data | 430 ---------------------------- 432 AFTER APPLYING WESP - IPv4 433 -------------------------------------------------------- 434 |orig IP hdr | WESP | ESP | | | ESP |WESP| 435 |(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV| 436 -------------------------------------------------------- 437 |<---- encryption ---->| 438 |<----------- integrity ----------->| 440 BEFORE APPLYING WESP - IPv6 441 ---------------------------------------- 442 | orig |hop-by-hop,dest*,|dest| | | 443 |IP hdr|routing,fragment.|opt*|TCP|Data| 444 ---------------------------------------- 446 AFTER APPLYING WESP - IPv6 447 -------------------------------------------------------------- 448 | orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP| 449 |IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV| 450 -------------------------------------------------------------- 451 |<---- encryption --->| 452 |<-------- integrity --------->| 454 * = if present, could be before WESP, after ESP, or both 456 All other considerations are as per RFC 4303. 458 2.2.2. Tunnel Mode Processing 460 In tunnel mode, ESP is inserted after the new IP header and before 461 the original IP header, as per RFC 4303. The following diagram 462 illustrates how WESP is applied to the ESP tunnel mode for a typical 463 packet, on a "before and after" basis. 465 BEFORE APPLYING WESP - IPv4 466 -------------------------- 467 | orig IP hdr* | | | 468 | (any options) |TCP|Data| 469 -------------------------- 471 AFTER APPLYING WESP - IPv4 472 -------------------------------------------------------------- 473 |new IP hdr* | | | orig IP hdr* | | | ESP |WESP| 474 |(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV| 475 -------------------------------------------------------------- 476 |<--------- encryption --------->| 477 |<--------------- integrity ------------->| 479 BEFORE APPLYING WESP - IPv6 480 --------------------------- 481 | orig*|orig ext | | | 482 |IP hdr| hdrs * |TCP|Data| 483 --------------------------- 485 AFTER APPLYING WESP - IPv6 486 ----------------------------------------------------------------- 487 | new* |new ext | | | orig*|orig ext | | | ESP |WESP| 488 |IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 489 ----------------------------------------------------------------- 490 |<--------- encryption ---------->| 491 |<--------------- integrity -------------->| 493 * = if present, construction of outer IP hdr/extensions and 495 modification of inner IP hdr/extensions is discussed in 497 the Security Architecture document. 499 All other considerations are as per RFC 4303. 501 2.3. IKE Considerations 503 This document assumes that WESP negotiation is performed using 504 IKEv2. In order to negotiate the new format of ESP encapsulation 505 via IKEv2 [RFC4306], both parties need to agree to use the new 506 packet format. This can be achieved using a notification method 507 similar to USE_TRANSPORT_MODE defined in RFC 4306. 509 The notification, USE_WESP_MODE (value TBD) MAY be included in a 510 request message that also includes an SA payload requesting a 511 CHILD_SA using ESP. It requests that the CHILD_SA use WESP mode 512 rather than ESP for the SA created. If the request is accepted, 513 the response MUST also include a notification of type 514 USE_WESP_MODE. If the responder declines the request, the 515 CHILD_SA will be established using ESP, as per RFC 4303. If 516 this is unacceptable to the initiator, the initiator MUST delete 517 the SA. Note: Except when using this option to negotiate WESP 518 mode, all CHILD_SAs will use standard ESP. 520 Negotiation of WESP in this manner preserves all other 521 negotiation parameters, including NAT-T [RFC3948]. NAT-T is 522 wholly compatible with this wrapped frame format and can be used 523 as-is, without any modifications, in environments where NAT is 524 present and needs to be taken into account. 526 3. Security Considerations 528 As this document augments the existing ESP encapsulation format, 529 UDP encapsulation definitions specified in RFC 3948 and IKE 530 negotiation of the new encapsulation, the security observations 531 made in those documents also apply here. In addition, as this 532 document allows intermediate device visibility into IPsec ESP 533 encapsulated frames for the purposes of network monitoring 534 functions, care should be taken not to send sensitive data over 535 connections using definitions from this document, based on 536 network domain/administrative policy. A strong key agreement 537 protocol, such as IKEv2, together with a strong policy engine 538 should be used to in determining appropriate security policy for 539 the given traffic streams and data over which it is being 540 employed. 542 ESP is end-to-end and it will be impossible for the intermediate 543 devices to verify that all the fields in the WESP header are 544 correct. It is thus possible to modify the WESP header so that 545 the packet sneaks past a firewall if the fields in the WESP 546 header are set to something that the firewall will allow. The 547 endpoint thus must verify the sanity of the WESP header before 548 accepting the packet. In an extreme case, someone colluding with 549 the attacker, could change the WESP fields back to the original 550 values so that the attack goes unnoticed. However, this is not a 551 new problem and it already exists IPsec. 553 4. IANA Considerations 555 The WESP protocol number is assigned by IANA out of the IP 556 Protocol Number space (and as recorded at the IANA web page at 557 http://www.iana.org/assignments/protocol-numbers) is: TBD. 559 The USE_WESP_MODE notification number is assigned out of the 560 "IKEv2 Notify Message Types - Status Types" registry's 16384- 561 40959 (Expert Review) range: TBD. 563 The SPI value of 2 is assigned by IANA out of the reserved SPI 564 range from the SPI values registry to indicate use of the WESP 565 protocol within a UDP encapsulated, NAT-T environment. 567 This specification requests that IANA create a new registry for 568 "WESP Flags" to be managed as follows: 570 The first 2 bits are the WESP Version Number. The value 0 is 571 assigned to the version defined in this specification. Further 572 assignments of the WESP Version Number are to be managed via the 573 IANA Policy of "Standards Action" [RFC5226]. For WESP version 574 numbers, the unassigned values are 1, 2 and 3. The Encrypted 575 Payload bit is used to indicate if the payload is encrypted or 576 using integrity-only ESP. The extended header bit is used to 577 signal the use of padding required to preserve IPv6 alignment. 578 The remaining 4 bits of the WESP Flags are undefined and future 579 assignment is to be managed via the IANA Policy of 580 "Specification Required". 582 5. Acknowledgments 584 The authors would like to acknowledge the following people for 585 their feedback on updating the definitions in this document. 587 David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron 588 Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier 589 among others. 591 This document was prepared using 2-Word-v2.0.template.doc. 593 6. References 595 6.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm 601 and Its Use With IPsec", RFC 2410, November 1998. 603 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and 604 M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", 605 RFC 3948, January 2005. 607 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 608 RFC 4303, December 2005. 610 [RFC4543] McGrew, D. and Viega J., "The Use of Galois Message 611 Authentication Code (GMAC) in IPsec ESP and AH", RFC 612 4543, May 2006. 614 [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing 615 an IANA Considerations Section in RFCs", RFC 5226, 616 May 2008. 618 6.2. Informative References 620 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 621 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 622 January 2005. 624 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 625 December 2005. 627 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 628 RFC 4306, December 2005. 630 [Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting 631 ESP-NULL packets", Internet Draft, April 2009. 633 Author's Addresses 635 Ken Grewal 636 Intel Corporation 637 2111 NE 25th Avenue, JF3-232 638 Hillsboro, OR 97124 639 USA 641 Phone: 642 Email: ken.grewal@intel.com 644 Gabriel Montenegro 645 Microsoft Corporation 646 One Microsoft Way 647 Redmond, WA 98052 648 USA 650 Phone: 651 Email: gabriel.montenegro@microsoft.com 653 Manav Bhatia 654 Alcatel-Lucent 655 Manyata Embassy 656 Nagawara Bangalore 658 India 660 Phone: 661 Email: manav.bhatia@alcatel-lucent.com