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