idnits 2.17.1 draft-grewal-ipsec-traffic-visibility-01.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 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. 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 (June 23, 2008) is 5786 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 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Grewal 3 Internet-Draft Intel Corporation 4 Intended status: Standards Track G. Montenegro 5 Expires: December 25, 2008 Microsoft Corporation 6 June 23, 2008 8 XESP for Traffic Visibility 9 draft-grewal-ipsec-traffic-visibility-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 25, 2008. 36 Abstract 38 This document describes an ESP encapsulation for IPsec, allowing 39 intermediate devices to ascertain if ESP-NULL is being employed and 40 hence inspect the IPsec packets for network monitoring and access 41 control functions. Currently in the IPsec standard, there is no way 42 to differentiate between ESP encryption and ESP NULL encryption by 43 simply examining a packet. 45 1. Introduction 47 Use of ESP within IPsec [RFC4303] specifies how ESP packet 48 encapsulation is performed. It also specifies that ESP can use NULL 49 encryption [RFC2410] while preserving data integrity and 50 authenticity. The exact encapsulation and algorithms employed are 51 negotiated out-of-band using, for example, IKE [RFC2409] or IKEv2 52 [RFC4306] and based on policy. 54 Enterprise environments typically employ numerous security policies 55 (and tools for enforcing them), as related to access control, 56 firewalls, network monitoring functions, deep packet inspection, 57 Intrusion Detection and Prevention Systems (IDS and IPS), scanning 58 and detection of viruses and worms, etc. In order to enforce these 59 policies, network tools and intermediate devices require visibility 60 into packets, ranging from simple packet header inspection to deeper 61 payload examination. Network security protocols which encrypt the 62 data in transit prevent these network tools from performing the 63 aforementioned functions. 65 When employing IPsec within an enterprise environment, it is 66 desirable to employ ESP instead of AH [RFC4302], as AH does not work 67 in NAT environments. Furthermore, in order to preserve the above 68 network monitoring functions, it is desirable to use ESP-NULL. In a 69 mixed mode environment some packets containing sensitive data employ 70 a given encryption cipher suite, while other packets employ ESP-NULL. 71 For an intermediate device to unambiguously distinguish which packets 72 are leveraging ESP-NULL, they would require knowledge of all the 73 policies being employed for each protected session. This is clearly 74 not practical. Heuristic-based methods can be employed to parse the 75 packets, but these can be very expensive, containing numerous rules 76 based on each different protocol and payload. Even then, the parsing 77 may not be robust in cases where fields within a given encrypted 78 packet happen to resemble the fields for a given protocol or 79 heuristic rule. This is even more problematic when different length 80 Initialization Vectors (IVs), Integrity Check Values (ICVs) and 81 padding are used for different security associations, making it 82 difficult to determine the start and end of the payload data, let 83 alone attempting any further parsing. Furthermore, storage, lookup 84 and cross-checking a set of comprehensive rules against every packet 85 adds cost to hardware implementations and degrades performance. In 86 cases where the packets may be encrypted, it is also wasteful to 87 check against heuristics-based rules, when a simple exception policy 88 (e.g., allow, drop or redirect) can be employed to handle the 89 encrypted packets. Because of the non-deterministic nature of 90 heuristics-based rules for disambiguating between encrypted and non- 91 encrypted data, an alternative method for enabling intermediate 92 devices to function in encrypted data environments needs to be 93 defined. Enterprise environments typically use both stateful and 94 stateless packet inspection mechanisms. The previous considerations 95 weigh particularly heavy on stateless mechanisms such as router ACLs 96 and NetFlow exporters. 98 This document defines a mechanism to prove additional information in 99 relevant IPsec packets so intermediate devices can efficiently 100 differentiate between encrypted ESP packets and ESP packets with NULL 101 encryption. 103 The document is consistent with the operation of ESP in NAT 104 environments [RFC3947]. 106 The design principles for this protocol are the following: 108 o Allow easy identification and parsing of integrity-only IPsec 109 traffic 111 o Leverage the existing hardware IPsec parsing engines as much as 112 possible to minimize additional hardware design costs 114 o Minimize the packet overhead in the common case 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 1.2. Applicability Statement 124 The document is applicable only to the Extended ESP header defined 125 below, and does not describe any changes to either ESP [RFC4303] nor 126 AH [RFC4302]. 128 2. Extended ESP (XESP) Header format 130 The proposal is to define an Extended ESP protocol number, which 131 provides additional attributes in each packet. The value of the new 132 protocol is TBD and the format of the new encapsulation is defined 133 below. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Next Header | HdrLen | TrailerLen | Flags | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Security Parameters Index (SPI) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Sequence Number | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | IV (variable) | 145 ~ ~ 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Payload Data | 149 ~ ~ 150 | | 151 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | TFC Padding * (optional, variable) | 153 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | Padding (variable) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |Padding (0-255 bytes) |PAD Length | Next Header | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Integrity Check Value-ICV (variable) | 159 ~ ~ 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 XESP Header 165 Figure 1 167 Where: 169 Next Header: next protocol header (encrypted in ESP trailer, but in 170 the clear in header), providing easy access to a HW parser to 171 extract the upper layer protocol. Note: For security concerns, 172 this value may optionally be set to zero, in which case the next 173 header can be extracted from the ESP trailer. 175 HdrLen: includes the new header + full ESP header + the IV (if 176 present). It is an offset to the beginning of the Payload Data. 178 TrailerLen: Offset from the end of the packet including the ICV, pad 179 length, and any padding. It is an offset from the end of the 180 packet to the last byte of the payload data. 182 Flags 184 2 bits: Version 186 1 bit: IntegrityOnly: Payload Data is not encrypted (ESP-NULL). 188 5 bits: reserved for future use. These MUST be set to zero per 189 this specification, but usage may be defined by other 190 specifications. 192 As can be seen, this Extended ESP format simply extended the standard 193 ESP header by the first 4 octets. 195 2.1. UDP Encapsulation 197 This section describes a mechanism for running the new packet format 198 over the existing UDP encapsulation of ESP as defined in RFC 3948. 199 This allows leveraging the existing IKE negotiation of the UDP port 200 for NAT-T discovery and usage [RFC3947], as well as preserving the 201 existing UDP ports for ESP (port 4500). With UDP encapsulation, the 202 packet format can be depicted as follows. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Src Port (4500) | Dest Port (4500) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Checksum | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Protocol Identifier (value = 0x00000001) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Next Header | HdrLen | TrailerLen | Flags | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Security Parameters Index (SPI) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Sequence Number | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | IV (variable) | 220 ~ ~ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Payload Data | 224 ~ ~ 225 | | 226 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | TFC Padding * (optional, variable) | 228 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | Padding (0-255 bytes) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |Padding (0-255 bytes) |PAD Length | Next Header | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Integrity Check Value-ICV (variable) | 234 ~ ~ 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 UDP-encapsulated XESP Header 240 Figure 2 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 this proposal. 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 is an 254 IKE packet. Similarly, a value of non-zero indicates that the packet 255 is an ESP packet and the 4-octet value can be treated as the ESP SPI. 256 However, RFC 4303, clause 2.1 indicates that the values 1-255 are 257 reserved and cannot be used as the SPI. We leverage that knowledge 258 and use a value of 1 to indicate that the UDP encapsulated ESP header 259 contains this new packet format for ESP encapsulation. 261 The remaining fields in the packet have the same meaning as per 262 section 2.0 above. 264 2.2. Tunnel and Transport mode of considerations 266 This extension is equally applicable for tunnel and transport mode 267 where the ESP Next Header field is used to differentiate between 268 these modes, as per the existing IPsec specifications. 270 2.3. IKE Considerations 272 In order to negotiate the new format of ESP encapsulation via IKE, 273 both sides of the security channel need to agree upon using the new 274 packet format. This can be achieved by proposing a new protocol ID 275 within the existing IKE proposal structure as defined by RFC 4306, 276 clause 3.3.1. The existing proposal substructure in this clause 277 allows negotiation of ESP/AH (among others) by using different 278 protocol Ids for these protocols. By using the same protocol 279 substructure in the proposal payload and using a new value (TBD) for 280 this encapsulation, the existing IKE negotiation can be leverage with 281 minimal changes to support negotiation of this encapsulation. 283 Furthermore, because the negotiation is at the protocol level, other 284 transforms remain valid for this new encapsulation and consistent 285 with IKEv2 [RFC4306]. Additionally, NAT-T [RFC3948] is wholly 286 compatible with this extended frame format and can be used as-is, 287 without any modifications, in environments where NAT is present and 288 needs to be taken into account. 290 3. Acknowledgements 292 The authors would like to acknowledge the following people for their 293 feedback on updating the definitions in this document. 295 David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron 296 Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier among 297 others. 299 4. IANA Considerations 301 Reserving an appropriate value for this encapsulation as well as a 302 new value for the protocol in the IKE negotiation is TBD by IANA. 304 5. Security Considerations 306 As this document augments the existing ESP encapsulation format, UDP 307 encapsulation definitions specified in RFC 3948 and IKE negotiation 308 of the new encapsulation, the security observations made in those 309 documents also apply here. In addition, as this document allows 310 intermediate device visibility into IPsec ESP encapsulated frames for 311 the purposes of network monitoring functions, care should be taken 312 not to send sensitive data over connections using definitions from 313 this document, based on network domain/administrative policy. A 314 strong key agreement protocol, such as IKE, together with a strong 315 policy engine should be used to in determining appropriate security 316 policy for the given traffic streams and data over which it is being 317 employed. 319 6. References 321 6.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 327 Its Use With IPsec", RFC 2410, November 1998. 329 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 330 RFC 4303, December 2005. 332 6.2. Informative References 334 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 335 (IKE)", RFC 2409, November 1998. 337 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 338 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 339 January 2005. 341 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 342 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 343 RFC 3948, January 2005. 345 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 346 December 2005. 348 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 349 RFC 4306, December 2005. 351 Authors' Addresses 353 Ken Grewal 354 Intel Corporation 355 2111 NE 25th Avenue, JF3-232 356 Hillsboro, OR 97124 357 USA 359 Phone: 360 Email: ken.grewal@intel.com 362 Gabriel Montenegro 363 Microsoft Corporation 364 One Microsoft Way 365 Redmond, WA 98052 366 USA 368 Phone: 369 Email: gabriel.montenegro@microsoft.com 371 Full Copyright Statement 373 Copyright (C) The IETF Trust (2008). 375 This document is subject to the rights, licenses and restrictions 376 contained in BCP 78, and except as set forth therein, the authors 377 retain all their rights. 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 382 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 383 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 384 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Intellectual Property 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org.