draft-ietf-ipsecme-traffic-visibility-10.txt   draft-ietf-ipsecme-traffic-visibility-11.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: May 10, 2010 Microsoft Corporation Expires: May 30, 2010 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
November 10, 2009 November 30, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-10.txt draft-ietf-ipsecme-traffic-visibility-11.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. This document may with the provisions of BCP 78 and BCP 79. This document may
contain material from IETF Documents or IETF Contributions contain material from IETF Documents or IETF Contributions
published or made publicly available before November 10, 2008. published or made publicly available before November 10, 2008.
The person(s) controlling the copyright in some of this material The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards modifications of such material outside the IETF Standards
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 May 10, 2010. This Internet-Draft will expire on May 30, 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 6, line 16 skipping to change at page 6, line 16
compliant implementation can simply add in the new header, compliant implementation can simply add in the new header,
without needing to change the body of the packet. The value of without needing to change the body of the packet. The value of
the new protocol used to identify this new header is TBD via the new protocol used to identify this new header is TBD via
IANA. Further details are shown below: IANA. Further details are shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags | | Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6Padding (optional) | | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Detailed WESP Packet Format Figure 2 Detailed WESP Packet Format
Where: Where:
skipping to change at page 7, line 6 skipping to change at page 7, line 6
present) within the encapsulated ESP header, in octets. HdrLen present) within the encapsulated ESP header, in octets. HdrLen
MUST be set to zero when using ESP with encryption. When using MUST be set to zero when using ESP with encryption. When using
integrity-only ESP, the following HdrLen values are invalid: any integrity-only ESP, the following HdrLen values are invalid: any
value less than 12; any value that is not a multiple of 4; any value less than 12; any value that is not a multiple of 4; any
value that is not a multiple of 8 when using IPv6. The receiver value that is not a multiple of 8 when using IPv6. The receiver
MUST ensure that this field matches with the header offset MUST ensure that this field matches with the header offset
computed from using the negotiated SA and MUST drop the packet computed from using the negotiated SA and MUST drop the packet
in case it does not match. in case it does not match.
TrailerLen, 8 bits: TrailerLen contains the size of the ICV TrailerLen, 8 bits: TrailerLen contains the size of the ICV
being used by the negotiated algorithms within the IPsec SA. being used by the negotiated algorithms within the IPsec SA, in
TrailerLen MUST be set to zero when using ESP with encryption. octets. TrailerLen MUST be set to zero when using ESP with
The receiver MUST only accept the packet if this field matches encryption. The receiver MUST only accept the packet if this
with the value computed from using the negotiated SA. This field matches with the value computed from using the negotiated
insures that sender is not deliberately setting this value to SA. This insures that sender is not deliberately setting this
obfuscate a part of the payload from examination by a trusted value to obfuscate a part of the payload from examination by a
intermediary device. trusted intermediary device.
Flags, 8 bits: The bits are defined most-significant-bit (MSB) Flags, 8 bits: The bits are defined most-significant-bit (MSB)
first, so bit 0 is the most significant bit of the flags octet. first, so bit 0 is the most significant bit of the flags octet.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V V|E|P| Rsvd | |V V|E|P| Rsvd |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Flags format Figure 3 Flags format
skipping to change at page 7, line 43 skipping to change at page 7, line 43
Encrypted Payload (E), 1 bit: Setting the Encrypted Payload Encrypted Payload (E), 1 bit: Setting the Encrypted Payload
bit to 1 indicates that the WESP (and therefore ESP) payload is bit to 1 indicates that the WESP (and therefore ESP) payload is
protected with encryption. If this bit is set to 0, then the protected with encryption. If this bit is set to 0, then the
payload is using integrity-only ESP. Setting or clearing this payload is using integrity-only ESP. Setting or clearing this
bit also impacts the value in the WESP Next Header field, as bit also impacts the value in the WESP Next Header field, as
described above. The recipient MUST ensure consistency of this described above. The recipient MUST ensure consistency of this
flag with the negotiated policy and MUST drop the incoming flag with the negotiated policy and MUST drop the incoming
packet otherwise. packet otherwise.
Padding header (P), 1 bit: If set (value 1), the 4 octet padding Padding Present (P), 1 bit: If P=1 (Padding Present flag),
is present. If not set (value 0), the 4 octet padding is absent. This the first octet of the Padding field holds the padding length,
padding MUST be used with IPv6 in order to preserve IPv6 8-octet in octets (including the length octet). All other Padding
alignment. If WESP is being used with UDP encapsulation (see 2.1 octets MUST be sent as zero, and MUST be ignored by the
below) and IPv6, the Protocol Identifier (0x00000002) occupies four receiver and intermediate devices (however, this field is
octets so the IPv6 padding is not needed, as the header is already on intended to allow future extensibility, so these restrictions
an 8-octet boundary. This padding MUST NOT be used with IPv4, as it may be relaxed in a future document updating this RFC).
is not needed to guarantee 4-octet IPv4 alignment.
The padding length may be any length between 4 and 252 that
preserves the alignment of the ESP header (4 octet alignment
for IPv4, 8 octet alignment for IPv6). This padding MUST be
used with IPv6 in order to preserve IPv6 8-octet alignment. If
WESP is being used with UDP encapsulation (see 2.1 below) and
IPv6, the Protocol Identifier (0x00000002) occupies four octets
so the padding is not needed, as the header is already on an 8-
octet boundary.
Rsvd, 4 bits: Reserved for future use. The reserved bits Rsvd, 4 bits: Reserved for future use. The reserved bits
MUST be sent as 0, and ignored by the receiver. Future documents MUST be sent as 0, and ignored by the receiver. Future documents
defining any of these bits MUST NOT affect the distinction defining any of these bits MUST NOT affect the distinction
between encrypted and unencrypted packets. Intermediate nodes between encrypted and unencrypted packets. Intermediate nodes
dealing with unknown reserved bits are not necessarily able to dealing with unknown reserved bits are not necessarily able to
parse the packet correctly. Intermediate treatment of such parse the packet correctly. Intermediate treatment of such
packets is policy-dependent (e.g., it may dictate dropping such packets is policy-dependent (e.g., it may dictate dropping such
packets). packets).
skipping to change at page 13, line 30 skipping to change at page 13, line 30
This specification requests that IANA create a new registry for This specification requests that IANA create a new registry for
"WESP Flags" to be managed as follows: "WESP Flags" to be managed as follows:
The first 2 bits are the WESP Version Number. The value 0 is The first 2 bits are the WESP Version Number. The value 0 is
assigned to the version defined in this specification. Further assigned to the version defined in this specification. Further
assignments of the WESP Version Number are to be managed via the assignments of the WESP Version Number are to be managed via the
IANA Policy of "Standards Action" [RFC5226]. For WESP version IANA Policy of "Standards Action" [RFC5226]. For WESP version
numbers, the unassigned values are 1, 2 and 3. The Encrypted numbers, the unassigned values are 1, 2 and 3. The Encrypted
Payload bit is used to indicate if the payload is encrypted or Payload bit is used to indicate if the payload is encrypted or
using integrity-only ESP. The extended header bit is used to using integrity-only ESP. The Padding Present bit is used to
signal the use of padding required to preserve IPv6 alignment. signal the presence of padding. The remaining 4 bits of the WESP
The remaining 4 bits of the WESP Flags are undefined and future Flags are undefined and future assignment is to be managed via
assignment is to be managed via the IANA Policy of the IANA Policy of "Specification Required".
"Specification Required".
5. Acknowledgments 5. Acknowledgments
The authors would like to acknowledge the following people for The authors would like to acknowledge the following people for
their feedback on updating the definitions in this document. their feedback on updating the definitions in this document.
David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron
Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier Sheffer, Pasi Eronen, Men Long, David Durham, Prashant Dewan,
among others. Marc Millier among others.
This document was prepared using 2-Word-v2.0.template.doc. This document was prepared using 2-Word-v2.0.template.doc.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 9 change blocks. 
27 lines changed or deleted 34 lines changed or added

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