--- 1/draft-ietf-ipsecme-traffic-visibility-02.txt 2009-06-01 21:12:08.000000000 +0200 +++ 2/draft-ietf-ipsecme-traffic-visibility-03.txt 2009-06-01 21:12:08.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group K. Grewal Internet Draft Intel Corporation Intended status: Standards Track G. Montenegro -Expires: October 30, 2009 Microsoft Corporation +Expires: November 30, 2009 Microsoft Corporation M. Bhatia Alcatel-Lucent - April 30, 2009 + May 30, 2009 Wrapped ESP for Traffic Visibility - draft-ietf-ipsecme-traffic-visibility-02.txt + draft-ietf-ipsecme-traffic-visibility-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -39,56 +39,57 @@ document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes the Wrapped Encapsulating Security - Payload (WESP) protocol, which builds on top of ESP [RFC4303] - and is designed to allow intermediate devices to ascertain if - ESP-NULL is being employed and hence inspect the IPsec packets - for network monitoring and access control functions. Currently - in the IPsec standard, there is no way to differentiate between - ESP encryption and ESP NULL encryption by simply examining a - packet. This poses certain challenges to the intermediate - devices that need to deep inspect the packet before making a - decision on what should be done with that packet (Inspect and/or - Allow/Drop). The mechanism described in this document can be - used to easily disambiguate ESP-NULL from ESP encrypted packets, - without compromising on the security provided by ESP. + Payload (WESP) protocol, which builds on top of Encapsulating + Security Payload (ESP) [RFC4303] and is designed to allow + intermediate devices to ascertain if ESP-NULL [RFC2410] is being + employed and hence inspect the IPsec packets for network + monitoring and access control functions. Currently in the IPsec + standard, there is no way to differentiate between ESP + encryption and ESP NULL encryption by simply examining a packet. + This poses certain challenges to the intermediate devices that + need to deep inspect the packet before making a decision on what + should be done with that packet (Inspect and/or Allow/Drop). The + mechanism described in this document can be used to easily + disambiguate ESP-NULL from ESP encrypted packets, without + compromising on the security provided by ESP. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................4 1.2. Applicability Statement...................................4 2. Wrapped ESP (WESP) Header format...............................4 2.1. UDP Encapsulation.........................................6 - 2.2. Transport and Tunnel Mode Considerations..................7 - 2.2.1. Transport Mode Processing............................7 - 2.2.2. Tunnel Mode Processing...............................8 - 2.3. IKE Considerations........................................9 - 3. Security Considerations.......................................10 - 4. IANA Considerations...........................................11 - 5. Acknowledgments...............................................11 - 6. References....................................................11 - 6.1. Normative References.....................................11 - 6.2. Informative References...................................11 + 2.2. Transport and Tunnel Mode Considerations..................8 + 2.2.1. Transport Mode Processing............................8 + 2.2.2. Tunnel Mode Processing...............................9 + 2.3. IKE Considerations.......................................10 + 3. Security Considerations.......................................11 + 4. IANA Considerations...........................................12 + 5. Acknowledgments...............................................12 + 6. References....................................................12 + 6.1. Normative References.....................................12 + 6.2. Informative References...................................13 1. Introduction Use of ESP within IPsec [RFC4303] specifies how ESP packet encapsulation is performed. It also specifies that ESP can use - NULL encryption [RFC2410] while preserving data integrity and + NULL encryption while preserving data integrity and authenticity. The exact encapsulation and algorithms employed are negotiated out-of-band using, for example, IKEv2 [RFC4306] and based on policy. Enterprise environments typically employ numerous security policies (and tools for enforcing them), as related to access control, content screening, firewalls, network monitoring functions, deep packet inspection, Intrusion Detection and Prevention Systems (IDS and IPS), scanning and detection of viruses and worms, etc. In order to enforce these policies, @@ -161,30 +162,33 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Applicability Statement The document is applicable only to the wrapped ESP header defined below, and does not describe any changes to either ESP - [RFC4303] nor AH [RFC4302]. + [RFC4303] nor IP Authentication Header (AH) [RFC4302]. 2. Wrapped ESP (WESP) Header format - The proposal is to define a protocol number for Wrapped ESP - encapsulation (WESP), which provides additional attributes in - each packet to assist in differentiating between encrypted and - non-encrypted data, as well as aid parsing of the packet. WESP - follows RFC 4303 for all IPv6 and IPv4 considerations (e.g., - alignment considerations). + Wrapped ESP encapsulation (WESP) uses protocol number (TBD via + IANA) different from AH and ESP. Accordingly, the (outer) + protocol header (IPv4, IPv6, or Extension) that immediately + precedes the WESP header SHALL contain the value (TBD via IANA) + in its Protocol (IPv4) or Next Header (IPv6, Extension) field. + WESP provides additional attributes in each packet to assist in + differentiating between encrypted and non-encrypted data, and to + aid parsing of the packet. WESP follows RFC 4303 for all IPv6 + and IPv4 considerations (e.g., alignment considerations). This extension essentially acts as a wrapper to the existing ESP protocol and provides an additional 4 octets at the front of the existing ESP packet. This may be depicted as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -199,71 +203,97 @@ By preserving the body of the existing ESP packet format, a compliant implementation can simply add in the new header, without needing to change the body of the packet. The value of the new protocol used to identify this new header is TBD via IANA. Further details are shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Next Header | HdrLen | TrailerLen | + | Next Header | HdrLen | TrailerLen | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Existing ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Detailed WESP Packet Format Where: + Next Header, 8 bits: This field MUST be the same as the Next + Header field in the ESP trailer when using ESP in the Integrity + only mode, and MUST be set to zero when using ESP with + Encryption. The receiver MUST do some sanity checks before the + WESP packet is accepted. Receiver MUST ensure that the Next + Header field in the WESP header and the Next Header field in the + ESP trailer match when using ESP in the Integrity only mode. The + packet MUST be dropped if the two do not match. Similarly, the + receiver MUST ensure that the Next Header field in the WESP + header is zero if using ESP with encryption. In this case, the + packet MUST be dropped if it is not set to zero and the packet + is encrypted. + + HdrLen, 8 bits: Offset to the beginning of the Payload Data in + octets. The receiver MUST ensure that this field matches with + the header offset computed from using the negotiated SA and MUST + drop the packet in case it doesn't match. + + TrailerLen, 8 bits: Offset from the end of the packet to the + last byte of the payload data in octets. TrailerLen MUST be set + to zero when using ESP with encryption. The receiver MUST only + accept the packet if this field matches with the value computed + from using the negotiated SA. This insures that sender is not + deliberately setting this value to obfuscate a part of the + payload from examination by a trusted intermediary device. + Flags, 8 bits 2 bits: Version. Version is set to 0 by the transmitter and validated by the receiver. Any modifications to the WESP header - in the future will require an update in the version number. + in the future may require an update in the version number. + Intermediate nodes dealing with unknown versions are not + necessarily able to parse the packet correctly. Intermediate + treatment of such packets is policy-dependent (e.g., it may + dictate dropping such packets). 6 bits: reserved for future use. These MUST be set to zero per this specification, but usage may be defined by other - specifications. + specifications. Intermediate nodes compliant with this + specification SHOULD check that these bits are set to zero. If + any bits are non-zero, it is possible that the packet has a + different format than specified here. Policy dictates final + treatment of such packets at intermediate nodes (e.g., including + dropping such packets). Note: To provide future compatibility, the version number is - negotiated by the control channel handshake. An implementation - compatible with this specification must set the version number - and the reserved bits to the values specified above when - transmitting a packet. On receiving a packet, these values must - be checked to ensure that they are as indicated above. - - Next Header, 8 bits: If using ESP-NULL, this field MUST be - equal to the Next Header field in the ESP trailer. If using ESP - in encryption mode, this field MUST be set to zero.. - - HdrLen, 8 bits: Offset to the beginning of the Payload Data in - octets. - - TrailerLen, 8 bits: Offset from the end of the packet to the - last byte of the payload data in octets. + negotiated by the control channel handshake. An end-node + implementation compatible with this specification must set the + version number and the reserved bits to the values specified + above when transmitting a packet. On receiving a packet, these + values must be checked to ensure that they are as indicated + above and the packet MUST be dropped in case they don't match. - As can be seen, this wrapped ESP format extends the standard ESP - header by the first 4 octets. The WESP header is integrity - protected, along with all the fields specified for ESP in RFC - 4303. + As can be seen, the WESP format extends the standard ESP header + by the first 4 octets. The WESP header is integrity protected, + along with all the fields specified for ESP in RFC 4303. 2.1. UDP Encapsulation This section describes a mechanism for running the new packet format over the existing UDP encapsulation of ESP as defined in RFC 3948. This allows leveraging the existing IKE negotiation of - the UDP port for NAT-T discovery and usage [RFC3947], as well as - preserving the existing UDP ports for ESP (port 4500). With UDP - encapsulation, the packet format can be depicted as follows. + the UDP port for NAT-T discovery and usage [RFC3947, RFC4306], + as well as preserving the existing UDP ports for ESP (port + 4500). With UDP encapsulation, the packet format can be + depicted as follows. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Port (4500) | Dest Port (4500) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Identifier (value = 0x00000002) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -294,23 +324,28 @@ that the values 1-255 are reserved and cannot be used as the SPI. We leverage that knowledge and use one of these reserved values to indicate that the UDP encapsulated ESP header contains this new packet format for ESP encapsulation. The remaining fields in the packet have the same meaning as per section 2 above. 2.2. Transport and Tunnel Mode Considerations - This extension is equally applicable for transport and tunnel - mode where the ESP Next Header field is used to differentiate - between these modes, as per the existing IPsec specifications. + This extension is equally applicable to transport and tunnel mode + where the ESP Next Header field is used to differentiate between + these modes, as per the existing IPsec specifications. + + In the diagrams below, "WESP ICV" refers to the ICV computation as + modified by this specification. Namely, the ESP ICV computation is + augmented to include the four octets that constitute the WESP header. + Otherwise, the ICV computation is as specified by ESP [RFC4303]. 2.2.1. Transport Mode Processing In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. The following diagrams illustrate how WESP is applied to the ESP transport mode for a typical packet, on a "before and after" basis. BEFORE APPLYING WESP - IPv4 ------------------------------------------------- @@ -423,81 +458,100 @@ As this document augments the existing ESP encapsulation format, UDP encapsulation definitions specified in RFC 3948 and IKE negotiation of the new encapsulation, the security observations made in those documents also apply here. In addition, as this document allows intermediate device visibility into IPsec ESP encapsulated frames for the purposes of network monitoring functions, care should be taken not to send sensitive data over connections using definitions from this document, based on network domain/administrative policy. A strong key agreement - protocol, such as IKE, together with a strong policy engine + protocol, such as IKEv2, together with a strong policy engine should be used to in determining appropriate security policy for the given traffic streams and data over which it is being employed. ESP is end-to-end and it will be impossible for the intermediate devices to verify that all the fields in the WESP header are - correct. It is thus possible to tweak the WESP header so that - the packet sneaks past the firewall if the fields in the WESP + correct. It is thus possible to modify the WESP header so that + the packet sneaks past a firewall if the fields in the WESP header are set to something that the firewall will allow. The endpoint thus must verify the sanity of the WESP header before accepting the packet. In an extreme case, someone colluding with the attacker, could change the WESP fields back to the original values so that the attack goes unnoticed. However, this is not a new problem and it already exists IPSec. 4. IANA Considerations - Reserving an appropriate value for this encapsulation as well as - a new value for the protocol in the IKE negotiation is TBD by - IANA. + The WESP protocol number is assigned by IANA out of the IP + Protocol Number space (and as recorded at the IANA web page at + http://www.iana.org/assignments/protocol-numbers) is: TBD. + + The USE_WESP_MODE notification number is assigned out of the + "IKEv2 Notify Message Types - Status Types" registry's 16384- + 40959 (Expert Review) range: TBD. + + This specification requests that IANA create a new registry for + "WESP Flags" to be managed as follows: + + The first 2 bits are the WESP Version Number. The value 0 is + assigned to the version defined in this specification. Further + assignments of the WESP Version Number are to be managed via the + IANA Policy of "Standards Action" [RFC5226]. The final 6 bits of + the WESP Flags are the "Non-version Flags". This specification + defines no values, and future assignment is to be managed via + the IANA Policy of "Specification Required". 5. Acknowledgments The authors would like to acknowledge the following people for their feedback on updating the definitions in this document. David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier among others. This document was prepared using 2-Word-v2.0.template.doc. 6. References 6.1. Normative References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 6.2. Informative References - [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. - Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, + [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, + "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. - [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., - and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC - 3948, January 2005. + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and + M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", + RFC 3948, January 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. - [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) - Protocol", RFC 4306, December 2005. + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + + [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing + an IANA Considerations Section in RFCs", RFC 5226, + May 2008. Author's Addresses Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA Phone: