draft-ietf-ipsecme-traffic-visibility-05.txt   draft-ietf-ipsecme-traffic-visibility-06.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: December 23, 2009 Microsoft Corporation Expires: February 06, 2010 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
June 24, 2009 August 06, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-05.txt draft-ietf-ipsecme-traffic-visibility-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79. with the provisions of BCP 78 and 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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 October 30, 2009. This Internet-Draft will expire on February 06, 2010.
Copyright Copyright
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license- publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they describe info). Please review these documents carefully, as they describe
skipping to change at page 2, line 28 skipping to change at page 2, line 28
mechanism described in this document can be used to easily mechanism described in this document can be used to easily
disambiguate ESP-NULL from ESP encrypted packets, without disambiguate ESP-NULL from ESP encrypted packets, without
compromising on the security provided by ESP. compromising on the security provided by ESP.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Requirements Language.....................................4 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.........................................6 2.1. UDP Encapsulation.........................................7
2.2. Transport and Tunnel Mode Considerations..................7 2.2. Transport and Tunnel Mode Considerations..................8
2.2.1. Transport Mode Processing............................8 2.2.1. Transport Mode Processing............................8
2.2.2. Tunnel Mode Processing...............................9 2.2.2. Tunnel Mode Processing...............................9
2.3. IKE Considerations.......................................10 2.3. IKE Considerations.......................................10
3. Security Considerations.......................................10 3. Security Considerations.......................................11
4. IANA Considerations...........................................11 4. IANA Considerations...........................................12
5. Acknowledgments...............................................11 5. Acknowledgments...............................................12
6. References....................................................11 6. References....................................................12
6.1. Normative References.....................................11 6.1. Normative References.....................................12
6.2. Informative References...................................12 6.2. Informative References...................................13
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 while preserving data integrity and NULL encryption while preserving data integrity and
authenticity. The exact encapsulation and algorithms employed authenticity. The exact encapsulation and algorithms employed
are negotiated out-of-band using, for example, IKEv2 [RFC4306] are negotiated out-of-band using, for example, IKEv2 [RFC4306]
and based on policy. and based on policy.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
Next Header, 8 bits: This field MUST be the same as the Next 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 Header field in the ESP trailer when using ESP in the Integrity
only mode, and MUST be set to zero when using ESP with only mode, and MUST be set to zero when using ESP with
Encryption. The receiver MUST do some sanity checks before the Encryption. The receiver MUST do some sanity checks before the
WESP packet is accepted. Receiver MUST ensure that the Next WESP packet is accepted. Receiver MUST ensure that the Next
Header field in the WESP header and the Next Header field in the 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 ESP trailer match when using ESP in the Integrity only mode. The
packet MUST be dropped if the two do not match. Similarly, the packet MUST be dropped if the two do not match. Similarly, the
receiver MUST ensure that the Next Header field in the WESP receiver MUST ensure that the Next Header field in the WESP
header is zero if using ESP with encryption. In this case, the header is zero if using WESP with encryption. The WESP flags
packet MUST be dropped if it is not set to zero and the packet dictate if the packet is encrypted and/or integrity protected.
is encrypted.
HdrLen, 8 bits: Offset to the beginning of the Payload Data in HdrLen, 8 bits: Offset from the beginning of the WESP header to
octets. The receiver MUST ensure that this field matches with the beginning of the Rest of Payload Data (i.e., past the IV, if
the header offset computed from using the negotiated SA and MUST present) within the encapsulated ESP header, in octets. The
drop the packet in case it doesn't match. 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 TrailerLen, 8 bits: Offset from the end of the packet to the
last byte of the payload data in octets. TrailerLen MUST be set last byte of the payload data in octets. TrailerLen MUST be set
to zero when using ESP with encryption. The receiver MUST only to zero when using ESP with encryption. The receiver MUST only
accept the packet if this field matches with the value computed accept the packet if this field matches with the value computed
from using the negotiated SA. This insures that sender is not from using the negotiated SA. This insures that sender is not
deliberately setting this value to obfuscate a part of the deliberately setting this value to obfuscate a part of the
payload from examination by a trusted intermediary device. payload from examination by a trusted intermediary device.
Flags, 8 bits Flags, 8 bits
2 bits: Version. MUST be sent as 0 and checked by the 2 bits: Version. MUST be sent as 0 and checked by the
receiver. Future modifications to the WESP header may require a receiver. Future modifications to the WESP header may require a
new version number. Intermediate nodes dealing with unknown new version number. Intermediate nodes dealing with unknown
versions are not necessarily able to parse the packet correctly. versions are not necessarily able to parse the packet correctly.
Intermediate treatment of such packets is policy-dependent Intermediate treatment of such packets is policy-dependent
(e.g., it may dictate dropping such packets). (e.g., it may dictate dropping such packets).
6 bits: Flags, reserved for future use. The flags MUST be 1 bit: Encrypted Payload. Setting the Encrypted Payload bit
to 1 indicates that the WESP (and therefore ESP) payload is
protected with encryption. If this bit is set to 0, then the
payload is using ESP-NULL cipher. Setting or clearing this bit
also impacts the value in the WESP Next Header field, as
described above. The recipient MUST ensure consistency of this
flag with the negotiated policy and MUST drop the incoming
packet otherwise.
5 bits: Flags, reserved for future use. The flags MUST be
sent as 0, and ignored by the receiver. Future documents sent as 0, and ignored by the receiver. Future documents
defining any of these flags MUST NOT affect the distinction defining any of these flags MUST NOT affect the distinction
between encrypted and unencrypted packets. Intermediate nodes between encrypted and unencrypted packets. Intermediate nodes
dealing with unknown flags are not necessarily able to parse the dealing with unknown flags are not necessarily able to parse the
packet correctly. Intermediate treatment of such packets is packet correctly. Intermediate treatment of such packets is
policy-dependent (e.g., it may dictate dropping such packets). policy-dependent (e.g., it may dictate dropping such packets).
Future versions of this protocol may change the Version number Future versions of this protocol may change the Version number
and/or the Flag bits sent, possibly by negotiating them over the and/or the Flag bits sent, possibly by negotiating them over the
control channel. The receiver MUST drop packets for which the control channel. The receiver MUST drop packets for which the
 End of changes. 9 change blocks. 
20 lines changed or deleted 30 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/