idnits 2.17.1 draft-ietf-ipsecme-traffic-visibility-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 09, 2009) is 5527 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) Summary: 1 error (**), 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: September 09, 2009 Microsoft Corporation 5 March 09, 2009 7 Wrapped ESP for Traffic Visibility 8 draft-ietf-ipsecme-traffic-visibility-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance 13 with the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 9, 2009. 34 Copyright 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license- 42 info). Please review these documents carefully, as they describe 43 your rights and restrictions with respect to this document. 45 Abstract 47 This document describes an ESP encapsulation for IPsec, allowing 48 intermediate devices to ascertain if ESP-NULL is being employed 49 and hence inspect the IPsec packets for network monitoring and 50 access control functions. Currently in the IPsec standard, 51 there is no way to differentiate between ESP encryption and ESP 52 NULL encryption by simply examining a packet. 54 Table of Contents 56 1. Introduction................................................2 57 1.1. Requirements Language..................................4 58 1.2. Applicability Statement................................4 59 2. Wrapped ESP (WESP) Header format............................4 60 2.1. UDP Encapsulation......................................5 61 2.2. Tunnel and Transport mode of considerations............7 62 2.3. IKE Considerations.....................................7 63 3. Security Considerations.....................................7 64 4. IANA Considerations.........................................8 65 5. Acknowledgments.............................................8 66 6. References..................................................8 67 6.1. Normative References...................................8 68 6.2. Informative References.................................8 70 1. Introduction 72 Use of ESP within IPsec [RFC4303] specifies how ESP packet 73 encapsulation is performed. It also specifies that ESP can use 74 NULL encryption [RFC2410] while preserving data integrity and 75 authenticity. The exact encapsulation and algorithms employed 76 are negotiated out-of-band using, for example, IKEv2 [RFC4306] 77 and based on policy. 79 Enterprise environments typically employ numerous security 80 policies (and tools for enforcing them), as related to access 81 control, firewalls, network monitoring functions, deep packet 82 inspection, Intrusion Detection and Prevention Systems (IDS and 83 IPS), scanning and detection of viruses and worms, etc. In 84 order to enforce these policies, network tools and intermediate 85 devices require visibility into packets, ranging from simple 86 packet header inspection to deeper payload examination. Network 87 security protocols which encrypt the data in transit prevent 88 these network tools from performing the aforementioned 89 functions. 91 When employing IPsec within an enterprise environment, it is 92 desirable to employ ESP instead of AH [RFC4302], as AH does not 93 work in NAT environments. Furthermore, in order to preserve the 94 above network monitoring functions, it is desirable to use ESP- 95 NULL. In a mixed mode environment some packets containing 96 sensitive data employ a given encryption cipher suite, while 97 other packets employ ESP-NULL. For an intermediate device to 98 unambiguously distinguish which packets are leveraging ESP-NULL, 99 they would require knowledge of all the policies being employed 100 for each protected session. This is clearly not practical. 101 Heuristic-based methods can be employed to parse the packets, 102 but these can be very expensive, containing numerous rules based 103 on each different protocol and payload. Even then, the parsing 104 may not be robust in cases where fields within a given encrypted 105 packet happen to resemble the fields for a given protocol or 106 heuristic rule. This is even more problematic when different 107 length Initialization Vectors (IVs), Integrity Check Values 108 (ICVs) and padding are used for different security associations, 109 making it difficult to determine the start and end of the 110 payload data, let alone attempting any further parsing. 111 Furthermore, storage, lookup and cross-checking a set of 112 comprehensive rules against every packet adds cost to hardware 113 implementations and degrades performance. In cases where the 114 packets may be encrypted, it is also wasteful to check against 115 heuristics-based rules, when a simple exception policy (e.g., 116 allow, drop or redirect) can be employed to handle the encrypted 117 packets. Because of the non-deterministic nature of heuristics- 118 based rules for disambiguating between encrypted and non- 119 encrypted data, an alternative method for enabling intermediate 120 devices to function in encrypted data environments needs to be 121 defined. Additionally there are many types and classes of 122 network devices employed within a given network and a 123 deterministic approach would provide a simple solution for all 124 these devices. Enterprise environments typically use both 125 stateful and stateless packet inspection mechanisms. The 126 previous considerations weigh particularly heavy on stateless 127 mechanisms such as router ACLs and NetFlow exporters. 128 Nevertheless, a deterministic approach provides a simple 129 solution for the myriad types of devices employed within a 130 network, regardless of their stateful or stateless nature. 132 This document defines a mechanism to prove additional 133 information in relevant IPsec packets so intermediate devices 134 can efficiently differentiate between encrypted ESP packets and 135 ESP packets with NULL encryption. 137 The document is consistent with the operation of ESP in NAT 138 environments [RFC3947]. 140 The design principles for this protocol are the following: 142 o Allow easy identification and parsing of integrity-only IPsec 143 traffic 144 o Leverage the existing hardware IPsec parsing engines as much 145 as possible to minimize additional hardware design costs 147 o Minimize the packet overhead in the common case 149 1.1. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 152 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described 154 in RFC 2119 [RFC2119]. 156 1.2. Applicability Statement 158 The document is applicable only to the wrapped ESP header 159 defined below, and does not describe any changes to either ESP 160 [RFC4303] nor AH [RFC4302]. 162 2. Wrapped ESP (WESP) Header format 164 The proposal is to define a protocol number for Wrapped ESP 165 encapsulation (WESP), which provides additional attributes in 166 each packet to assist in differentiating between encrypted and 167 non-encrypted data, as well as aid parsing of the packet. WESP 168 follows RFC 4303 for all IPv6 and IPv4 considerations (e.g., 169 alignment considerations). 171 This extension essentially acts as a wrapper to the existing ESP 172 protocol and provides an additional 4 octets at the front of the 173 existing ESP packet. 175 This may be depicted as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Wrapped ESP Header | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Existing ESP Encapsulation | 183 ~ ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1 WESP Packet Format 189 By preserving the body of the existing ESP packet format, a 190 compliant implementation can simply add in the new header, 191 without needing to change the body of the packet. The value of 192 the new protocol used to identify this new header is TBD via 193 IANA. Further details are shown below: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Next Header | HdrLen | TrailerLen | Flags | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Existing ESP Encapsulation | 201 ~ ~ 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2 Detailed WESP Packet Format 207 Where: 209 Next Header, 8 bits: next protocol header (encrypted in ESP 210 trailer, but in the clear in header), providing easy access to a 211 HW parser to extract the upper layer protocol. Note: For 212 security concerns, this value may optionally be set to zero, in 213 which case the next header can be extracted from the ESP 214 trailer. 216 HdrLen, 8 bits: includes the new header, the full ESP header and 217 the IV (if present). It is an offset to the beginning of the 218 Payload Data. 220 TrailerLen, 8 bits: Offset from the end of the packet including 221 the ICV, pad length, and any padding. It is an offset from the 222 end of the packet to the last byte of the payload data. 224 Flags, 8 bits 226 2 bits: Version 228 6 bits: reserved for future use. These MUST be set to zero 229 per this specification, but usage may be defined by other 230 specifications. 232 As can be seen, this wrapped ESP format extends the standard ESP 233 header by the first 4 octets. 235 2.1. UDP Encapsulation 237 This section describes a mechanism for running the new packet 238 format over the existing UDP encapsulation of ESP as defined in 239 RFC 3948. This allows leveraging the existing IKE negotiation of 240 the UDP port for NAT-T discovery and usage [RFC3947], as well as 241 preserving the existing UDP ports for ESP (port 4500). With UDP 242 encapsulation, the packet format can be depicted as follows. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Src Port (4500) | Dest Port (4500) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Checksum | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Protocol Identifier (value = 0x00000001) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Next Header | HdrLen | TrailerLen | Flags | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Existing ESP Encapsulation | 256 ~ ~ 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 3 UDP-Encapsulated WESP Header 262 Where: 264 Source/Destination port (4500) and checksum: describes the UDP 265 encapsulation header, per RFC3948. 267 Protocol Identifier: new field to demultiplex between UDP 268 encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and 269 the UDP encapsulation in this specification. 271 According to RFC 3948, clause 2.2, a 4 octet value of zero (0) 272 immediately following the UDP header indicates a Non-ESP marker, 273 which can be used to assume that the data following that value 274 is an IKE packet. Similarly, a value of non-zero indicates that 275 the packet is an ESP packet and the 4-octet value can be treated 276 as the ESP SPI. However, RFC 4303, clause 2.1 indicates that the 277 values 1-255 are reserved and cannot be used as the SPI. We 278 leverage that knowledge and use a value of 1 to indicate that 279 the UDP encapsulated ESP header contains this new packet format 280 for ESP encapsulation. 282 The remaining fields in the packet have the same meaning as per 283 section 2 above. 285 2.2. Tunnel and Transport mode of considerations 287 This extension is equally applicable for tunnel and transport 288 mode where the ESP Next Header field is used to differentiate 289 between these modes, as per the existing IPsec specifications. 291 2.3. IKE Considerations 293 This document assumes that WESP negotiation is performed using 294 IKEv2. In order to negotiate the new format of ESP encapsulation 295 via IKEv2 [RFC4306], both parties need to agree to use the new 296 packet format. This can be achieved by proposing a new protocol 297 ID within the existing IKE proposal structure as defined by RFC 298 4306, clause 3.3.1. The existing proposal substructure in this 299 clause allows negotiation of ESP/AH (among others) by using 300 different protocol Ids for these protocols. By using the same 301 protocol substructure in the proposal payload and using a new 302 value (TBD) for this encapsulation, the existing IKE negotiation 303 can be leverage with minimal changes to support negotiation of 304 this encapsulation. 306 Furthermore, because the negotiation is at the protocol level, 307 other transforms remain valid for this new encapsulation and 308 consistent with IKEv2 [RFC4306]. Additionally, NAT-T [RFC3948] 309 is wholly compatible with this wrapped frame format and can be 310 used as-is, without any modifications, in environments where NAT 311 is present and needs to be taken into account. 313 3. Security Considerations 315 As this document augments the existing ESP encapsulation format, 316 UDP encapsulation definitions specified in RFC 3948 and IKE 317 negotiation of the new encapsulation, the security observations 318 made in those documents also apply here. In addition, as this 319 document allows intermediate device visibility into IPsec ESP 320 encapsulated frames for the purposes of network monitoring 321 functions, care should be taken not to send sensitive data over 322 connections using definitions from this document, based on 323 network domain/administrative policy. A strong key agreement 324 protocol, such as IKE, together with a strong policy engine 325 should be used to in determining appropriate security policy for 326 the given traffic streams and data over which it is being 327 employed. 329 4. IANA Considerations 331 Reserving an appropriate value for this encapsulation as well as 332 a new value for the protocol in the IKE negotiation is TBD by 333 IANA. 335 5. Acknowledgments 337 The authors would like to acknowledge the following people for 338 their feedback on updating the definitions in this document. 340 David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron 341 Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier 342 among others. 344 6. References 346 6.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm 352 and Its Use With IPsec", RFC 2410, November 1998. 354 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 355 RFC 4303, December 2005. 357 6.2. Informative References 359 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. 360 Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, 361 January 2005. 363 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., 364 and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 365 3948, January 2005. 367 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 368 December 2005. 370 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) 371 Protocol", RFC 4306, December 2005. 373 Author's Addresses 375 Ken Grewal 376 Intel Corporation 377 2111 NE 25th Avenue, JF3-232 378 Hillsboro, OR 97124 379 USA 381 Phone: 382 Email: ken.grewal@intel.com 384 Gabriel Montenegro 385 Microsoft Corporation 386 One Microsoft Way 387 Redmond, WA 98052 388 USA 390 Phone: 391 Email: gabriel.montenegro@microsoft.com