Network Working Group K. Grewal
Internet Draft Intel Corporation
Intended status: Standards Track G. Montenegro
Expires: September 09, 2009 Microsoft Corporation
March 09, 2009
Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-01.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.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
This document describes an ESP encapsulation for IPsec, allowing
intermediate devices to ascertain if ESP-NULL is being employed
and hence inspect the IPsec packets for network monitoring and
Grewal, et. al. Expires September 09, 2009 [Page 1]
Internet-Draft WESP For Traffic Visibility March 2009
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.
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......................................5
2.2. Tunnel and Transport mode of considerations............7
2.3. IKE Considerations.....................................7
3. Security Considerations.....................................7
4. IANA Considerations.........................................8
5. Acknowledgments.............................................8
6. References..................................................8
6.1. Normative References...................................8
6.2. Informative References.................................8
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
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, 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, network tools and intermediate
devices require visibility into packets, ranging from simple
packet header inspection to deeper payload examination. Network
security protocols which encrypt the data in transit prevent
these network tools from performing the aforementioned
functions.
When employing IPsec within an enterprise environment, it is
desirable to employ ESP instead of AH [RFC4302], as AH does not
work in NAT environments. Furthermore, in order to preserve the
above network monitoring functions, it is desirable to use ESP-
NULL. In a mixed mode environment some packets containing
Grewal, et. al. Expires September 9 2009 [Page 2]
Internet-Draft WESP For Traffic Visibility March 2009
sensitive data employ a given encryption cipher suite, while
other packets employ ESP-NULL. For an intermediate device to
unambiguously distinguish which packets are leveraging ESP-NULL,
they would require knowledge of all the policies being employed
for each protected session. This is clearly not practical.
Heuristic-based methods can be employed to parse the packets,
but these can be very expensive, containing numerous rules based
on each different protocol and payload. Even then, the parsing
may not be robust in cases where fields within a given encrypted
packet happen to resemble the fields for a given protocol or
heuristic rule. This is even more problematic when different
length Initialization Vectors (IVs), Integrity Check Values
(ICVs) and padding are used for different security associations,
making it difficult to determine the start and end of the
payload data, let alone attempting any further parsing.
Furthermore, storage, lookup and cross-checking a set of
comprehensive rules against every packet adds cost to hardware
implementations and degrades performance. In cases where the
packets may be encrypted, it is also wasteful to check against
heuristics-based rules, when a simple exception policy (e.g.,
allow, drop or redirect) can be employed to handle the encrypted
packets. Because of the non-deterministic nature of heuristics-
based rules for disambiguating between encrypted and non-
encrypted data, an alternative method for enabling intermediate
devices to function in encrypted data environments needs to be
defined. Additionally there are many types and classes of
network devices employed within a given network and a
deterministic approach would provide a simple solution for all
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
information in relevant IPsec packets so intermediate devices
can efficiently differentiate between encrypted ESP packets and
ESP packets with NULL encryption.
The document is consistent with the operation of ESP in NAT
environments [RFC3947].
The design principles for this protocol are the following:
o Allow easy identification and parsing of integrity-only IPsec
traffic
Grewal, et. al. Expires September 9 2009 [Page 3]
Internet-Draft WESP For Traffic Visibility March 2009
o Leverage the existing hardware IPsec parsing engines as much
as possible to minimize additional hardware design costs
o Minimize the packet overhead in the common case
1.1. Requirements Language
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].
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).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrapped ESP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 WESP Packet Format
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
Grewal, et. al. Expires September 9 2009 [Page 4]
Internet-Draft WESP For Traffic Visibility March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Detailed WESP Packet Format
Where:
Next Header, 8 bits: next protocol header (encrypted in ESP
trailer, but in the clear in header), providing easy access to a
HW parser to extract the upper layer protocol. Note: For
security concerns, this value may optionally be set to zero, in
which case the next header can be extracted from the ESP
trailer.
HdrLen, 8 bits: includes the new header, the full ESP header and
the IV (if present). It is an offset to the beginning of the
Payload Data.
TrailerLen, 8 bits: Offset from the end of the packet including
the ICV, pad length, and any padding. It is an offset from the
end of the packet to the last byte of the payload data.
Flags, 8 bits
2 bits: Version
6 bits: reserved for future use. These MUST be set to zero
per this specification, but usage may be defined by other
specifications.
As can be seen, this wrapped ESP format extends the standard ESP
header by the first 4 octets.
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
Grewal, et. al. Expires September 9 2009 [Page 5]
Internet-Draft WESP For Traffic Visibility March 2009
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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier (value = 0x00000001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 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 of non-zero 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 a value of 1 to indicate that
the UDP encapsulated ESP header contains this new packet format
for ESP encapsulation.
Grewal, et. al. Expires September 9 2009 [Page 6]
Internet-Draft WESP For Traffic Visibility March 2009
The remaining fields in the packet have the same meaning as per
section 2 above.
2.2. Tunnel and Transport mode of considerations
This extension is equally applicable for tunnel and transport
mode where the ESP Next Header field is used to differentiate
between these modes, as per the existing IPsec specifications.
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 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
clause allows negotiation of ESP/AH (among others) by using
different protocol Ids for these protocols. By using the same
protocol substructure in the proposal payload and using a new
value (TBD) for this encapsulation, the existing IKE negotiation
can be leverage with minimal changes to support negotiation of
this encapsulation.
Furthermore, because the negotiation is at the protocol level,
other transforms remain valid for this new encapsulation and
consistent with IKEv2 [RFC4306]. Additionally, NAT-T [RFC3948]
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.
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 IKE, 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.
Grewal, et. al. Expires September 9 2009 [Page 7]
Internet-Draft WESP For Traffic Visibility March 2009
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.
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.
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.
[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,
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.
Grewal, et. al. Expires September 9 2009 [Page 8]
Internet-Draft WESP For Traffic Visibility March 2009
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
Grewal, et. al. Expires September 9 2009 [Page 9]