idnits 2.17.1 draft-ietf-ipsecme-traffic-visibility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 412. 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 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 (October 22, 2008) is 5664 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 (==), 8 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: April 22, 2009 Microsoft Corporation 5 October 22, 2008 7 Wrapped ESP for Traffic Visibility 8 draft-ietf-ipsecme-traffic-visibility-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 22, 2009. 37 Abstract 39 This document describes an ESP encapsulation for IPsec, allowing 40 intermediate devices to ascertain if ESP-NULL is being employed 41 and hence inspect the IPsec packets for network monitoring and 42 access control functions. Currently in the IPsec standard, 43 there is no way to differentiate between ESP encryption and ESP 44 NULL encryption by simply examining a packet. 46 Table of Contents 48 1. Introduction................................................2 49 1.1. Requirements Language..................................3 50 1.2. Applicability Statement................................4 51 2. Wrapped ESP (WESP) Header format............................4 52 2.1. UDP Encapsulation......................................5 53 2.2. Tunnel and Transport mode of considerations............7 54 2.3. IKE Considerations.....................................7 55 3. Security Considerations.....................................7 56 4. IANA Considerations.........................................7 57 5. Acknowledgments.............................................8 58 6. References..................................................8 59 6.1. Normative References...................................8 60 6.2. Informative References.................................8 62 1. Introduction 64 Use of ESP within IPsec [RFC4303] specifies how ESP packet 65 encapsulation is performed. It also specifies that ESP can use 66 NULL encryption [RFC2410] while preserving data integrity and 67 authenticity. The exact encapsulation and algorithms employed 68 are negotiated out-of-band using, for example, IKEv2 [RFC4306] 69 and based on policy. 71 Enterprise environments typically employ numerous security 72 policies (and tools for enforcing them), as related to access 73 control, firewalls, network monitoring functions, deep packet 74 inspection, Intrusion Detection and Prevention Systems (IDS and 75 IPS), scanning and detection of viruses and worms, etc. In 76 order to enforce these policies, network tools and intermediate 77 devices require visibility into packets, ranging from simple 78 packet header inspection to deeper payload examination. Network 79 security protocols which encrypt the data in transit prevent 80 these network tools from performing the aforementioned 81 functions. 83 When employing IPsec within an enterprise environment, it is 84 desirable to employ ESP instead of AH [RFC4302], as AH does not 85 work in NAT environments. Furthermore, in order to preserve the 86 above network monitoring functions, it is desirable to use ESP- 87 NULL. In a mixed mode environment some packets containing 88 sensitive data employ a given encryption cipher suite, while 89 other packets employ ESP-NULL. For an intermediate device to 90 unambiguously distinguish which packets are leveraging ESP-NULL, 91 they would require knowledge of all the policies being employed 92 for each protected session. This is clearly not practical. 93 Heuristic-based methods can be employed to parse the packets, 94 but these can be very expensive, containing numerous rules based 95 on each different protocol and payload. Even then, the parsing 96 may not be robust in cases where fields within a given encrypted 97 packet happen to resemble the fields for a given protocol or 98 heuristic rule. This is even more problematic when different 99 length Initialization Vectors (IVs), Integrity Check Values 100 (ICVs) and padding are used for different security associations, 101 making it difficult to determine the start and end of the 102 payload data, let alone attempting any further parsing. 103 Furthermore, storage, lookup and cross-checking a set of 104 comprehensive rules against every packet adds cost to hardware 105 implementations and degrades performance. In cases where the 106 packets may be encrypted, it is also wasteful to check against 107 heuristics-based rules, when a simple exception policy (e.g., 108 allow, drop or redirect) can be employed to handle the encrypted 109 packets. Because of the non-deterministic nature of heuristics- 110 based rules for disambiguating between encrypted and non- 111 encrypted data, an alternative method for enabling intermediate 112 devices to function in encrypted data environments needs to be 113 defined. Enterprise environments typically use both stateful and 114 stateless packet inspection mechanisms. The previous 115 considerations weigh particularly heavy on stateless mechanisms 116 such as router ACLs and NetFlow exporters. 118 This document defines a mechanism to prove additional 119 information in relevant IPsec packets so intermediate devices 120 can efficiently differentiate between encrypted ESP packets and 121 ESP packets with NULL encryption. 123 The document is consistent with the operation of ESP in NAT 124 environments [RFC3947]. 126 The design principles for this protocol are the following: 128 o Allow easy identification and parsing of integrity-only IPsec 129 traffic 131 o Leverage the existing hardware IPsec parsing engines as much 132 as possible to minimize additional hardware design costs 134 o Minimize the packet overhead in the common case 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 139 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described 141 in RFC 2119 [RFC2119]. 143 1.2. Applicability Statement 145 The document is applicable only to the wrapped ESP header 146 defined below, and does not describe any changes to either ESP 147 [RFC4303] nor AH [RFC4302]. 149 2. Wrapped ESP (WESP) Header format 151 The proposal is to define a protocol number for Wrapped ESP 152 encapsulation (WESP), which provides additional attributes in 153 each packet to assist in differentiating between encrypted and 154 non-encrypted data, as well as aid parsing of the packet. This 155 extension essentially acts as a wrapper to the existing ESP 156 protocol and provides an additional 4 octets at the front of the 157 existing ESP packet. This may be depicted simply as follows: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Wrapped ESP Header | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Existing ESP Encapsulation | 165 ~ ~ 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1 WESP Packet Format 171 By preserving the body of the existing ESP packet format, a 172 compliant implementation can simply add in the new header, 173 without needing to change the body of the packet. The value of 174 the new protocol used to identify this new header is TBD via 175 IANA. Further details are shown below: 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 | Next Header | HdrLen | TrailerLen | Flags | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Existing ESP Encapsulation | 183 ~ ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 2 Detailed WESP Packet Format 189 Where: 191 Next Header: next protocol header (encrypted in ESP trailer, 192 but in the clear in header), providing easy access to a HW 193 parser to extract the upper layer protocol. Note: For security 194 concerns, this value may optionally be set to zero, in which 195 case the next header an be extracted from the ESP trailer. 197 HdrLen: includes the new header + full ESP header + the IV (if 198 present). It is an offset to the beginning of the Payload Data. 200 TrailerLen: Offset from the end of the packet including the ICV, 201 pad length, and any padding. It is an offset from the end of 202 the packet to the last byte of the payload data. 204 Flags 206 2 bits: Version 208 6 bits: reserved for future use. These MUST be set to zero 209 per this specification, but usage may be defined by other 210 specifications. 212 As can be seen, this wrapped ESP format simply extends the 213 standard ESP header by the first 4 octets. 215 2.1. UDP Encapsulation 217 This section describes a mechanism for running the new packet 218 format over the existing UDP encapsulation of ESP as defined in 219 RFC 3948. This allows leveraging the existing IKE negotiation of 220 the UDP port for NAT-T discovery and usage [RFC3947], as well as 221 preserving the existing UDP ports for ESP (port 4500). With UDP 222 encapsulation, the packet format can be depicted as follows. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Src Port (4500) | Dest Port (4500) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Checksum | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Protocol Identifier (value = 0x00000001) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Next Header | HdrLen | TrailerLen | Flags | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Existing ESP Encapsulation | 236 ~ ~ 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 3 UDP-Encapsulated WESP Header 242 Where: 244 Source/Destination port (4500) and checksum: describes the UDP 245 encapsulation header, per RFC3948. 247 Protocol Identifier: new field to demultiplex between UDP 248 encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and 249 the UDP encapsulation in this specification. 251 According to RFC 3948, clause 2.2, a 4 octet value of zero (0) 252 immediately following the UDP header indicates a Non-ESP marker, 253 which can be used to assume that the data following that value 254 is an IKE packet. Similarly, a value of non-zero indicates that 255 the packet is an ESP packet and the 4-octet value can be treated 256 as the ESP SPI. However, RFC 4303, clause 2.1 indicates that the 257 values 1-255 are reserved and cannot be used as the SPI. We 258 leverage that knowledge and use a value of 1 to indicate that 259 the UDP encapsulated ESP header contains this new packet format 260 for ESP encapsulation. 262 The remaining fields in the packet have the same meaning as per 263 section 2.0 above. 265 2.2. Tunnel and Transport mode of considerations 267 This extension is equally applicable for tunnel and transport 268 mode where the ESP Next Header field is used to differentiate 269 between these modes, as per the existing IPsec specifications. 271 2.3. IKE Considerations 273 In order to negotiate the new format of ESP encapsulation via 274 IKE [RFC4306], both parties need to agree to use the new packet 275 format. This can be achieved by proposing a new protocol ID 276 within the existing IKE proposal structure as defined by RFC 277 4306, clause 3.3.1. The existing proposal substructure in this 278 clause allows negotiation of ESP/AH (among others) by using 279 different protocol Ids for these protocols. By using the same 280 protocol substructure in the proposal payload and using a new 281 value (TBD) for this encapsulation, the existing IKE negotiation 282 can be leverage with minimal changes to support negotiation of 283 this encapsulation. 285 Furthermore, because the negotiation is at the protocol level, 286 other transforms remain valid for this new encapsulation and 287 consistent with IKEv2 [RFC4306]. Additionally, NAT-T [RFC3948] 288 is wholly compatible with this wrapped frame format and can be 289 used as-is, without any modifications, in environments where NAT 290 is present and needs to be taken into account. 292 3. Security Considerations 294 As this document augments the existing ESP encapsulation format, 295 UDP encapsulation definitions specified in RFC 3948 and IKE 296 negotiation of the new encapsulation, the security observations 297 made in those documents also apply here. In addition, as this 298 document allows intermediate device visibility into IPsec ESP 299 encapsulated frames for the purposes of network monitoring 300 functions, care should be taken not to send sensitive data over 301 connections using definitions from this document, based on 302 network domain/administrative policy. A strong key agreement 303 protocol, such as IKE, together with a strong policy engine 304 should be used to in determining appropriate security policy for 305 the given traffic streams and data over which it is being 306 employed. 308 4. IANA Considerations 310 Reserving an appropriate value for this encapsulation as well as 311 a new value for the protocol in the IKE negotiation is TBD by 312 IANA. 314 5. Acknowledgments 316 The authors would like to acknowledge the following people for 317 their feedback on updating the definitions in this document. 319 David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron 320 Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier 321 among others. 323 6. References 325 6.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm 331 and Its Use With IPsec", RFC 2410, November 1998. 333 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 334 RFC 4303, December 2005. 336 6.2. Informative References 338 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. 339 Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, 340 January 2005. 342 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., 343 and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 344 3948, January 2005. 346 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 347 December 2005. 349 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) 350 Protocol", RFC 4306, December 2005. 352 Author's Addresses 354 Ken Grewal 355 Intel Corporation 356 2111 NE 25th Avenue, JF3-232 357 Hillsboro, OR 97124 358 USA 360 Phone: 361 Email: ken.grewal@intel.com 363 Gabriel Montenegro 364 Microsoft Corporation 365 One Microsoft Way 366 Redmond, WA 98052 367 USA 369 Phone: 370 Email: gabriel.montenegro@microsoft.com 372 Full Copyright Statement 374 Copyright (C) The IETF Trust (2008). 376 This document is subject to the rights, licenses and 377 restrictions contained in BCP 78, and except as set forth 378 therein, the authors retain all their rights. 380 This document and the information contained herein are provided 381 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 382 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 383 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 384 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 385 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 386 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 387 OR FITNESS FOR A PARTICULAR PURPOSE. 389 Intellectual Property Statement 391 The IETF takes no position regarding the validity or scope of 392 any Intellectual Property Rights or other rights that might be 393 claimed to pertain to the implementation or use of the 394 technology described in this document or the extent to which any 395 license under such rights might or might not be available; nor 396 does it represent that it has made any independent effort to 397 identify any such rights. Information on the procedures with 398 respect to rights in RFC documents can be found in BCP 78 and 399 BCP 79. 401 Copies of IPR disclosures made to the IETF Secretariat and any 402 assurances of licenses to be made available, or the result of an 403 attempt made to obtain a general license or permission for the 404 use of such proprietary rights by implementers or users of this 405 specification can be obtained from the IETF on-line IPR 406 repository at http://www.ietf.org/ipr. 408 The IETF invites any interested party to bring to its attention 409 any copyrights, patents or patent applications, or other 410 proprietary rights that may cover technology that may be 411 required to implement this standard. Please address the 412 information to the IETF at ietf-ipr@ietf.org.