Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-12
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5840.
|
|
---|---|---|---|
Authors | Manav Bhatia , Ken Grewal , Gabriel Montenegro | ||
Last updated | 2015-10-14 (Latest revision 2010-01-20) | ||
Replaces | draft-grewal-ipsec-traffic-visibility | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 5840 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Pasi Eronen | ||
Send notices to | (None) |
draft-ietf-ipsecme-traffic-visibility-12
quot;
field looses this name and semantics and becomes an empty field
which MUST be initialized to all zeros. The receiver MUST do
some sanity checks before the WESP packet is accepted. The
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 an empty field
initialized to zero if using WESP with encryption. The WESP
flags dictate if the packet is encrypted.
Grewal, et. al. Expires July 19 2010 [Page 6]
Internet-Draft WESP For Traffic Visibility January 2010
HdrLen, 8 bits: Offset from the beginning of the WESP header to
the beginning of the Rest of Payload Data (i.e., past the IV, if
present and any other WESP options defined in future) within the
encapsulated ESP header, in octets. HdrLen MUST be set to zero
when using ESP with encryption. When using 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 that is not a
multiple of 8 when using IPv6. 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 does not
match.
TrailerLen, 8 bits: TrailerLen contains the size of the ICV
being used by the negotiated algorithms within the IPsec SA, 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: The bits are defined most-significant-bit (MSB)
first, so bit 0 is the most significant bit of the flags octet.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V V|E|P| Rsvd |
+-+-+-+-+-+-+-+-+
Figure 3 Flags format
Version (V), 2 bits: MUST be sent as 0 and checked by the
receiver. If the version is different than an expected version
number (e.g. negotiated via the control channel), then the
packet MUST be dropped by the receiver. Future modifications to
the WESP header require a new version number. In particular, the
version of WESP defined in this document does not allow for any
extensions. However, old implementations will still be able to
find the encapsulated cleartext packet using the HdrLen field
from the WESP header, when the 'E' bit is not set. 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).
Encrypted Payload (E), 1 bit: 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 integrity-only ESP. Setting or clearing this
Grewal, et. al. Expires July 19 2010 [Page 7]
Internet-Draft WESP For Traffic Visibility January 2010
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.
Padding header (P), 1 bit: If set (value 1), the 4 octet
padding is present. If not set (value 0), the 4 octet padding
is absent. 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 IPv6 padding is not
needed, as the header is already on an 8-octet boundary. This
padding MUST NOT be used with IPv4, as it is not needed to
guarantee 4-octet IPv4 alignment.
Rsvd, 4 bits: Reserved for future use. The reserved bits
MUST be sent as 0, and ignored by the receiver. Future documents
defining any of these bits MUST NOT affect the distinction
between encrypted and unencrypted packets or the semantics of
HdrLen. In other words, even if new bits are defined, old
implementations will be able to find the encapsulated packet
correctly. Intermediate nodes dealing with unknown reserved bits
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).
Future versions of this protocol may change the version number
and/or the reserved bits sent, possibly by negotiating them over
the control channel.
As can be seen, the WESP format extends the standard ESP header
by the first 4 octets for IPv4 and optionally (see above) by 8
octets for IPv6.
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, RFC4306],
as well as preserving the existing UDP ports for ESP (port
4500). With UDP encapsulation, the packet format can be
depicted as follows.
Grewal, et. al. Expires July 19 2010 [Page 8]
Internet-Draft WESP For Traffic Visibility January 2010
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 UDP-Encapsulated WESP Header
Where:
Source/Destination port (4500) and checksum: describes the UDP
encapsulation header, per RFC3948.
Protocol Identifier: new field to demultiplex between UDP
encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and
the UDP encapsulation in this specification.
According to RFC 3948, clause 2.2, a 4 octet value of zero (0)
immediately following the UDP header indicates a Non-ESP marker,
which can be used to assume that the data following that value
is an IKE packet. Similarly, a value greater then 255 indicates
that 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 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 to transport and tunnel mode
where the ESP Next Header field is used to differentiate between
these modes, as per the existing IPsec specifications.
Grewal, et. al. Expires July 19 2010 [Page 9]
Internet-Draft WESP For Traffic Visibility January 2010
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
-------------------------------------------------
|orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------
|orig IP hdr | WESP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|
--------------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
BEFORE APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
AFTER APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| | |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
* = if present, could be before WESP, after ESP, or both
All other considerations are as per RFC 4303.
Grewal, et. al. Expires July 19 2010 [Page 10]
Internet-Draft WESP For Traffic Visibility January 2010
2.2.2. Tunnel Mode Processing
In tunnel mode, ESP is inserted after the new IP header and before
the original IP header, as per RFC 4303. The following diagram
illustrates how WESP is applied to the ESP tunnel mode for a typical
packet, on a "before and after" basis.
BEFORE APPLYING WESP - IPv4
---------------------------------------------------------
|new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------------
|new IP hdr* | | | orig IP hdr* | | | ESP | ESP|
|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
BEFORE APPLYING WESP - IPv6
-----------------------------------------------------------------
| new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
AFTER APPLYING WESP - IPv6
-----------------------------------------------------------------
| new* |new ext | | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
All other considerations are as per RFC 4303.
Grewal, et. al. Expires July 19 2010 [Page 11]
Internet-Draft WESP For Traffic Visibility January 2010
2.3. IKE Considerations
This document assumes that WESP negotiation is performed using
IKEv2. In order to negotiate the new format of ESP encapsulation
via IKEv2 [RFC4306], both parties need to agree to use the new
packet format. This can be achieved using a notification method
similar to USE_TRANSPORT_MODE defined in RFC 4306.
The notification, USE_WESP_MODE (value TBD) MUST be included in
a request message that also includes an SA payload requesting a
CHILD_SA using ESP. It signals that the sender supports the
WESP version defined in the current document a requests that the
CHILD_SA use WESP mode rather than ESP for the SA created. If
the request is accepted, the response MUST also include a
notification of type USE_WESP_MODE. If the responder declines
the request, the CHILD_SA will be established using ESP, as per
RFC 4303. If this is unacceptable to the initiator, the
initiator MUST delete the SA. Note: Except when using this
option to negotiate WESP mode, all CHILD_SAs will use standard
ESP.
Negotiation of WESP in this manner preserves all other
negotiation parameters, including NAT-T [RFC3948]. NAT-T is
wholly compatible with this wrapped frame format and can be used
as-is, without any modifications, in environments where NAT is
present and needs to be taken into account.
WESP version negotiation is not introduced as part of this
specification. If the WESP version is updated in a future
specification, then that document MUST specify how the WESP
version is negotiated.
3. Security Considerations
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 IKEv2, together with a strong policy engine
should be used in determining appropriate security policy for
the given traffic streams and data over which it is being
employed.
Grewal, et. al. Expires July 19 2010 [Page 12]
Internet-Draft WESP For Traffic Visibility January 2010
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 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
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.
The SPI value of 2 is assigned by IANA out of the reserved SPI
range from the SPI values registry to indicate use of the WESP
protocol within a UDP encapsulated, NAT-T environment.
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]. For WESP version
numbers, the unassigned values are 1, 2 and 3. The Encrypted
Payload bit is used to indicate if the payload is encrypted or
using integrity-only ESP. The Padding Present bit is used to
signal the presence of padding. The remaining 4 bits of the WESP
Flags are undefined and future assignment is to be managed via
the IANA Policy of "IETF Review" [RFC5226].
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, Pasi Eronen, Men Long, David Durham, Prashant Dewan,
Marc Millier, Russ Housley, Jari Arkko among others.
Grewal, et. al. Expires July 19 2010 [Page 13]
Internet-Draft WESP For Traffic Visibility January 2010
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 Kent, S., "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4543] McGrew, D. and Viega J., "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006.
[RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
May 2008.
6.2. Informative References
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting
ESP-NULL packets", Internet Draft, April 2009.
Grewal, et. al. Expires July 19 2010 [Page 14]
Internet-Draft WESP For Traffic Visibility January 2010
Author's Addresses
Ken Grewal
Intel Corporation
2111 NE 25th Avenue, JF3-232
Hillsboro, OR 97124
USA
Phone:
Email: ken.grewal@intel.com
Gabriel Montenegro
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone:
Email: gabriel.montenegro@microsoft.com
Manav Bhatia
Alcatel-Lucent
Manyata Embassy
Nagawara Bangalore
India
Phone:
Email: manav.bhatia@alcatel-lucent.com
Grewal, et. al. Expires July 19 2010 [Page 15]