draft-ietf-ipsecme-traffic-visibility-00.txt   draft-ietf-ipsecme-traffic-visibility-01.txt 
Network Working Group K. Grewal Network Working Group K. Grewal
Internet Draft Intel Corporation Internet Draft Intel Corporation
Intended status: Standards Track G. Montenegro Intended status: Standards Track G. Montenegro
Expires: April 22, 2009 Microsoft Corporation Expires: September 09, 2009 Microsoft Corporation
October 22, 2008 March 09, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-00.txt draft-ietf-ipsecme-traffic-visibility-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance
any applicable patent or other IPR claims of which he or she is with the provisions of BCP 78 and BCP 79.
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2009. This Internet-Draft will expire on September 9, 2009.
Copyright
Copyright (c) 2009 IETF Trust and the persons identified as the
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 Abstract
This document describes an ESP encapsulation for IPsec, allowing This document describes an ESP encapsulation for IPsec, allowing
intermediate devices to ascertain if ESP-NULL is being employed intermediate devices to ascertain if ESP-NULL is being employed
and hence inspect the IPsec packets for network monitoring and and hence inspect the IPsec packets for network monitoring and
access control functions. Currently in the IPsec standard, access control functions. Currently in the IPsec standard,
there is no way to differentiate between ESP encryption and ESP there is no way to differentiate between ESP encryption and ESP
NULL encryption by simply examining a packet. NULL encryption by simply examining a packet.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction................................................2
1.1. Requirements Language..................................3 1.1. Requirements Language..................................4
1.2. Applicability Statement................................4 1.2. Applicability Statement................................4
2. Wrapped ESP (WESP) Header format............................4 2. Wrapped ESP (WESP) Header format............................4
2.1. UDP Encapsulation......................................5 2.1. UDP Encapsulation......................................5
2.2. Tunnel and Transport mode of considerations............7 2.2. Tunnel and Transport mode of considerations............7
2.3. IKE Considerations.....................................7 2.3. IKE Considerations.....................................7
3. Security Considerations.....................................7 3. Security Considerations.....................................7
4. IANA Considerations.........................................7 4. IANA Considerations.........................................8
5. Acknowledgments.............................................8 5. Acknowledgments.............................................8
6. References..................................................8 6. References..................................................8
6.1. Normative References...................................8 6.1. Normative References...................................8
6.2. Informative References.................................8 6.2. Informative References.................................8
1. Introduction 1. Introduction
Use of ESP within IPsec [RFC4303] specifies how ESP packet Use of ESP within IPsec [RFC4303] specifies how ESP packet
encapsulation is performed. It also specifies that ESP can use encapsulation is performed. It also specifies that ESP can use
NULL encryption [RFC2410] while preserving data integrity and NULL encryption [RFC2410] while preserving data integrity and
skipping to change at page 3, line 23 skipping to change at page 3, line 29
Furthermore, storage, lookup and cross-checking a set of Furthermore, storage, lookup and cross-checking a set of
comprehensive rules against every packet adds cost to hardware comprehensive rules against every packet adds cost to hardware
implementations and degrades performance. In cases where the implementations and degrades performance. In cases where the
packets may be encrypted, it is also wasteful to check against packets may be encrypted, it is also wasteful to check against
heuristics-based rules, when a simple exception policy (e.g., heuristics-based rules, when a simple exception policy (e.g.,
allow, drop or redirect) can be employed to handle the encrypted allow, drop or redirect) can be employed to handle the encrypted
packets. Because of the non-deterministic nature of heuristics- packets. Because of the non-deterministic nature of heuristics-
based rules for disambiguating between encrypted and non- based rules for disambiguating between encrypted and non-
encrypted data, an alternative method for enabling intermediate encrypted data, an alternative method for enabling intermediate
devices to function in encrypted data environments needs to be devices to function in encrypted data environments needs to be
defined. Enterprise environments typically use both stateful and defined. Additionally there are many types and classes of
stateless packet inspection mechanisms. The previous network devices employed within a given network and a
considerations weigh particularly heavy on stateless mechanisms deterministic approach would provide a simple solution for all
such as router ACLs and NetFlow exporters. these devices. Enterprise environments typically use both
stateful and stateless packet inspection mechanisms. The
previous considerations weigh particularly heavy on stateless
mechanisms such as router ACLs and NetFlow exporters.
Nevertheless, a deterministic approach provides a simple
solution for the myriad types of devices employed within a
network, regardless of their stateful or stateless nature.
This document defines a mechanism to prove additional This document defines a mechanism to prove additional
information in relevant IPsec packets so intermediate devices information in relevant IPsec packets so intermediate devices
can efficiently differentiate between encrypted ESP packets and can efficiently differentiate between encrypted ESP packets and
ESP packets with NULL encryption. ESP packets with NULL encryption.
The document is consistent with the operation of ESP in NAT The document is consistent with the operation of ESP in NAT
environments [RFC3947]. environments [RFC3947].
The design principles for this protocol are the following: The design principles for this protocol are the following:
skipping to change at page 4, line 16 skipping to change at page 4, line 27
The document is applicable only to the wrapped ESP header The document is applicable only to the wrapped ESP header
defined below, and does not describe any changes to either ESP defined below, and does not describe any changes to either ESP
[RFC4303] nor AH [RFC4302]. [RFC4303] nor AH [RFC4302].
2. Wrapped ESP (WESP) Header format 2. Wrapped ESP (WESP) Header format
The proposal is to define a protocol number for Wrapped ESP The proposal is to define a protocol number for Wrapped ESP
encapsulation (WESP), which provides additional attributes in encapsulation (WESP), which provides additional attributes in
each packet to assist in differentiating between encrypted and each packet to assist in differentiating between encrypted and
non-encrypted data, as well as aid parsing of the packet. This non-encrypted data, as well as aid parsing of the packet. WESP
extension essentially acts as a wrapper to the existing ESP 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 protocol and provides an additional 4 octets at the front of the
existing ESP packet. This may be depicted simply as follows: existing ESP packet.
This may be depicted as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrapped ESP Header | | Wrapped ESP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 5 skipping to change at page 5, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Detailed WESP Packet Format Figure 2 Detailed WESP Packet Format
Where: Where:
Next Header: next protocol header (encrypted in ESP trailer, Next Header, 8 bits: next protocol header (encrypted in ESP
but in the clear in header), providing easy access to a HW trailer, but in the clear in header), providing easy access to a
parser to extract the upper layer protocol. Note: For security HW parser to extract the upper layer protocol. Note: For
concerns, this value may optionally be set to zero, in which security concerns, this value may optionally be set to zero, in
case the next header an be extracted from the ESP trailer. which case the next header can be extracted from the ESP
trailer.
HdrLen: includes the new header + full ESP header + the IV (if HdrLen, 8 bits: includes the new header, the full ESP header and
present). It is an offset to the beginning of the Payload Data. the IV (if present). It is an offset to the beginning of the
Payload Data.
TrailerLen: Offset from the end of the packet including the ICV, TrailerLen, 8 bits: Offset from the end of the packet including
pad length, and any padding. It is an offset from the end of the ICV, pad length, and any padding. It is an offset from the
the packet to the last byte of the payload data. end of the packet to the last byte of the payload data.
Flags Flags, 8 bits
2 bits: Version 2 bits: Version
6 bits: reserved for future use. These MUST be set to zero 6 bits: reserved for future use. These MUST be set to zero
per this specification, but usage may be defined by other per this specification, but usage may be defined by other
specifications. specifications.
As can be seen, this wrapped ESP format simply extends the As can be seen, this wrapped ESP format extends the standard ESP
standard ESP header by the first 4 octets. header by the first 4 octets.
2.1. UDP Encapsulation 2.1. UDP Encapsulation
This section describes a mechanism for running the new packet This section describes a mechanism for running the new packet
format over the existing UDP encapsulation of ESP as defined in format over the existing UDP encapsulation of ESP as defined in
RFC 3948. This allows leveraging the existing IKE negotiation of RFC 3948. This allows leveraging the existing IKE negotiation of
the UDP port for NAT-T discovery and usage [RFC3947], as well as the UDP port for NAT-T discovery and usage [RFC3947], as well as
preserving the existing UDP ports for ESP (port 4500). With UDP preserving the existing UDP ports for ESP (port 4500). With UDP
encapsulation, the packet format can be depicted as follows. encapsulation, the packet format can be depicted as follows.
skipping to change at page 6, line 44 skipping to change at page 7, line 6
which can be used to assume that the data following that value which can be used to assume that the data following that value
is an IKE packet. Similarly, a value of non-zero indicates that is an IKE packet. Similarly, a value of non-zero indicates that
the packet is an ESP packet and the 4-octet value can be treated the packet is an ESP packet and the 4-octet value can be treated
as the ESP SPI. However, RFC 4303, clause 2.1 indicates that the as the ESP SPI. However, RFC 4303, clause 2.1 indicates that the
values 1-255 are reserved and cannot be used as the SPI. We values 1-255 are reserved and cannot be used as the SPI. We
leverage that knowledge and use a value of 1 to indicate that leverage that knowledge and use a value of 1 to indicate that
the UDP encapsulated ESP header contains this new packet format the UDP encapsulated ESP header contains this new packet format
for ESP encapsulation. for ESP encapsulation.
The remaining fields in the packet have the same meaning as per The remaining fields in the packet have the same meaning as per
section 2.0 above. section 2 above.
2.2. Tunnel and Transport mode of considerations 2.2. Tunnel and Transport mode of considerations
This extension is equally applicable for tunnel and transport This extension is equally applicable for tunnel and transport
mode where the ESP Next Header field is used to differentiate mode where the ESP Next Header field is used to differentiate
between these modes, as per the existing IPsec specifications. between these modes, as per the existing IPsec specifications.
2.3. IKE Considerations 2.3. IKE Considerations
In order to negotiate the new format of ESP encapsulation via This document assumes that WESP negotiation is performed using
IKE [RFC4306], both parties need to agree to use the new packet IKEv2. In order to negotiate the new format of ESP encapsulation
format. This can be achieved by proposing a new protocol ID via IKEv2 [RFC4306], both parties need to agree to use the new
within the existing IKE proposal structure as defined by RFC packet format. This can be achieved by proposing a new protocol
ID within the existing IKE proposal structure as defined by RFC
4306, clause 3.3.1. The existing proposal substructure in this 4306, clause 3.3.1. The existing proposal substructure in this
clause allows negotiation of ESP/AH (among others) by using clause allows negotiation of ESP/AH (among others) by using
different protocol Ids for these protocols. By using the same different protocol Ids for these protocols. By using the same
protocol substructure in the proposal payload and using a new protocol substructure in the proposal payload and using a new
value (TBD) for this encapsulation, the existing IKE negotiation value (TBD) for this encapsulation, the existing IKE negotiation
can be leverage with minimal changes to support negotiation of can be leverage with minimal changes to support negotiation of
this encapsulation. this encapsulation.
Furthermore, because the negotiation is at the protocol level, Furthermore, because the negotiation is at the protocol level,
other transforms remain valid for this new encapsulation and other transforms remain valid for this new encapsulation and
skipping to change at page 9, line 24 skipping to change at line 392
Email: ken.grewal@intel.com Email: ken.grewal@intel.com
Gabriel Montenegro Gabriel Montenegro
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: Phone:
Email: gabriel.montenegro@microsoft.com Email: gabriel.montenegro@microsoft.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
 End of changes. 19 change blocks. 
38 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/