wdiff draft-grewal-ipsec-traffic-visibility-00.txt draft-grewal-ipsec-traffic-visibility-01.txt

Internet Draft Engineering Task Force K. Grewal
D. Durham
M. Long
Network Working Group
Internet-Draft Intel Corporation
draft-grewal-ipsec-traffic-visibility-00.txt
Intended Status: status: Standards Track G. Montenegro
Expires: June December 25, 2008 January Microsoft Corporation
June 23, 2008

XESP for Traffic visibility using IPsec ESP NULL encryption Visibility
draft-grewal-ipsec-traffic-visibility-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is 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.

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].

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
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 December 25, 2008.

Abstract

This document describes leveraging UDP an ESP encapsulation for IPsec, using
ESP NULL encryption in order for intermediary allowing
intermediate devices to ascertain if ESP-NULL is being employed and
hence inspect the IPsec packets. packets for network monitoring and 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.

Conventions used in this document

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 [ii].

Table of Contents

1. Introduction...................................................2
1.1 Applicability Statement....................................3
2. UDP Encapsulation of IPsec ESP.................................3
2.1 Extension Header...........................................4
2.2 Tunnel and Transport mode of considerations................5
2.3 Port conflicts.............................................5
3. IANA Considerations............................................6
4. Formal Syntax..................................................6
5. Security Considerations........................................6
6. References.....................................................6
7. Acknowledgements...............................................7
Author's Addresses.............................................7
Full Copyright Statement.......................................8

1. Introduction

The RFCs for leveraging

Use of ESP within IPsec describes [RFC4303] specifies how ESP packet
encapsulation is performed. Other RFCs describe how It also specifies that ESP can be
leveraged using use NULL encryption,
encryption [RFC2410] while preserving data integrity and
authenticity. However, the The exact encapsulation employed and the algorithms employed are
negotiated out-of-band using the Internet-
Key-Exchange (IKE) protocol. Once the packet is formatted using, for example, IKE [RFC2409] or IKEv2
[RFC4306] and sent based on
the wire, it is infeasible to distinguish if encryption has been
employed or is absent (ESP-NULL) by purely examining the packet.
In the case of employing IPsec within the policy.

Enterprise environment, it
is desirable environments typically employ numerous security policies
(and tools for intermediate devices (such enforcing them), as load balancers, related to access control,
firewalls, network monitoring functions, deep packet inspection,
Intrusion Detection / and Prevention Systems (IDS/IPS)) (IDS and IPS), scanning
and detection of viruses and worms, etc. In order to have access 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 each packet 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 existing critical the above
network
services. monitoring functions, it is desirable to use ESP-NULL. In a
mixed mode environment, where environment some packets containing sensitive data may employ
a given encryption cipher suite, while other packets are employing ESP-NULL, the employ ESP-NULL.
For an intermediate devices is
unable device to discern unambiguously distinguish which packets
are leveraging ESP-NULL, hence
inhibiting further analysis 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 that packet. 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 document describes 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
mechanism leveraging UDP-encapsulation set of IPsec ESP comprehensive rules against every packet
adds cost to hardware implementations and degrades performance. In
cases where the packets using may be encrypted, it is also wasteful to
check against heuristics-based rules, when a
fixed destination port, allowing 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 device
devices to function in encrypted data environments needs to be
defined. 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.

This document defines a mechanism to prove additional information in
relevant IPsec packets so intermediate devices can efficiently
differentiate between encrypted data ESP packets and ESP packets with NULL encrypted data
encryption.

The document is consistent with the operation of ESP in NAT
environments [RFC3947].

The design principles for ESP.

1.1 this protocol are the following:

o Allow easy identification and parsing of integrity-only IPsec
traffic

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 IPsec the Extended ESP only header defined
below, and does not describe any changes to IPsec AH.

2. UDP Encapsulation of IPsec either ESP

UDP encapsulation of IPsec [RFC4303] nor
AH [RFC4302].

2. Extended ESP packets (XESP) Header format

The proposal is defined to define an Extended ESP protocol number, which
provides additional attributes in RFC 3948 each packet. The value of the new
protocol is TBD and
takes the following basic format. format of the new encapsulation is defined
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV (variable) |
~ ~
| Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | TFC Padding * (optional, variable) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Padding (0-255 bytes) |PAD Length | Checksum Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP header [RFC2406] Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

According to RFC 3948,

XESP Header

Figure 1

Where:

Next Header: next protocol header (encrypted in ESP trailer, but in
the source / destination port values are as clear in header), providing easy access to a HW parser to
extract the same as used by IKE.
We extend upper layer protocol. Note: For security concerns,
this value may optionally be set to include a discrete destination port (value TBD) zero, in which identifies case the UDP/ESP payload as accessible for intermediate
devices. The source UDP port must next
header can be as used by IKE and does not
change extracted from the above specification. Having a reserved, unique
destination port to identify ESP trailer.

HdrLen: includes the payload as decipherable by
intermediate devices provides flexibility in adding an additional,
unique new header following the UDP + full ESP header which allows + the intermediate
device IV (if
present). It is an offset to parse the packet according to additional hints on how beginning of the Payload Data.

TrailerLen: Offset from the end of the packet has been encoded. This including the ICV, pad
length, and any padding. It is needed to pass information within
each an offset from the end of the
packet on to the algorithm employed for last byte of the data authenticity and
hence any IV requirements payload data.

Flags

2 bits: Version

1 bit: IntegrityOnly: Payload Data is not encrypted (ESP-NULL).

5 bits: reserved for that particular algorithm. As different
algorithms future use. These MUST be set to zero per
this specification, but usage may have differing IV requirements, be defined by other
specifications.

As can be seen, this extension allows
the intermediate device to take into account IV (/ICV) for a given
algorithm and parse Extended ESP format simply extended the remaining data pertaining to standard
ESP header by the upper layer
protocol. first 4 octets.

2.1. UDP Encapsulation

This extension encoding is section describes a fixed size and encodes
information about the specific data authenticity algorithm used mechanism for running the given new packet / SA, format
over the offset to existing UDP encapsulation of ESP as defined in RFC 3948.
This allows leveraging the upper layer protocol existing IKE negotiation of the UDP port
for NAT-T discovery and usage [RFC3947], as well as preserving the
upper layer protocol value. Diagrammatically, this may
existing UDP ports for ESP (port 4500). With UDP encapsulation, the
packet format can be depicted as follows.

The attributes in the extension header are described further below.

The extension header is exactly 32-bits, where |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDP-encapsulated XESP Header

Figure 2

Where:

Source/Destination port (4500) and checksum: describes the first 8-bits are
used UDP
encapsulation header, per RFC3948.

Protocol Identifier: new field to convey the upper layer protocol being carried in the ESP
payload. The value demultiplex between UDP
encapsulation of this field is copied directly from the Next
Header field IKE, UDP encapsulation of the ESP trailer and can be used by the intermediate
device to determine / parse the upper layer protocol without having
to find per RFC 3948, and parse the ESP trailer. The second 8-bits are used
this proposal.

According to
convey the offset RFC 3948, clause 2.2, a 4 octet value of zero (0)
immediately following the upper layer protocol from the end of this
extension UDP header (described further below). The third 8 bits are
reserved for future expansion and set to zero. The last 8-bits
contain the Algorithm Encoding and carries information about the
algorithm being used to compute the ICV. This extension is needed in
order for the intermediate device to determine indicates a Non-ESP marker,
which authentication
algorithm is being can be used for generation of the ESP Integrity Check
Value (ICV) and further parse the packet to extract assume that the data portion.
The size following that value is an
IKE packet. Similarly, a value of non-zero indicates that the IV and ICV in the IPsec packet
is algorithm
dependent.
In this document, we do not define explicit values for the Algorithm
Encoding, but choose to reuse an ESP packet and the same values defined in various
IPsec RFCs which describe how to negotiate a given algorithm using
IKE. In this manner, this specification will 4-octet value can be future proofed for
any new algorithm definitions. For example, treated as the ESP SPI.
However, RFC 4302, section 3.3.2
defines specific values for 4303, clause 2.1 indicates that the integrity algorithms, which are used
within IKE. These values 1-255 are
reserved for IKE via IANA. Additional RFCs
defining other (newer) algorithms build upon these definitions and
define new values for these algorithms. One example is RFC 4543,
which describes usage of AES-GMAC within IPsec and hence defines the
values cannot be used for different AES key sizes in section 9. The algorithm
encoding is also useful in determining the size of the ICV for a
given algorithm in order to deterministically extract the upper layer
payload.

The offset is an 8-bit value, which defines the number of octets
between as the end of this extension header SPI. We leverage that knowledge
and the start use a value of 1 to indicate that the upper
layer protocol. This includes the UDP encapsulated ESP header, any additional IP header
contains this new packet format for tunnel mode and also the size of the IV, which may be
algorithm dependent. Having an explicit value for the offset ESP encapsulation.

The remaining fields in the packet allows the intermediate device to directly parse past any
algorithm dependent structures within the packet and reach the upper
layer protocol header.
The reserved 8-bits are used to pad this extension to a long word
alignment. This should be set to 0 by the sender, but it is not
mandatory for have the recipient to validate this value.

2.2 same meaning as per
section 2.0 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 Port conflicts

Another consideration is that a legacy client may choose the UDP port
reserved for this specification as a random source port for a totally
different protocol exchange. Although this should not happen if the
client is choosing ports from the dynamic range specified by IANA, it
is still possible and hence

2.3. IKE Considerations

In order to negotiate the responsibility rests on new format of ESP encapsulation via IKE,
both sides of the
intermediate device security channel need to ensure it can differentiate between agree upon using the two
cases. The intermediate device new
packet format. This can ensure that it is looking at ESP-
NULL traffic that is UDP encapsulated in this form be achieved by validating
additional data elements following proposing a new protocol ID
within the UDP header. existing IKE proposal structure as defined by RFC 4306,
clause 3.3.1. The format of the
UDP extension described above can be validated. If existing proposal substructure in this is deemed
insufficient, then as a process clause
allows negotiation of extracting the upper layer payload
from the ESP encapsulated packet, ESP/AH (among others) by using different
protocol Ids for these protocols. By using the ESP trailer needs to be
examined (this will be at a fixed place same protocol
substructure in the packet, proceeding the
ICV value) proposal payload and using a new value (TBD) for
this encapsulation, the existing IKE negotiation can be validated according leverage with
minimal changes to IPsec ESP trailer
construction, which may include some padding octets. support negotiation of this encapsulation.

Furthermore, because the
intermediate device can now validate that negotiation is at the upper layer protocol
begins after a fixed length following the UDP header (UDP extension +
ESP header). level, other
transforms remain valid for this new encapsulation and consistent
with IKEv2 [RFC4306]. Additionally, if the upper layer protocol contains a
checksum, the intermediate device can further validate the checksum
to ensure that packet construction NAT-T [RFC3948] is as expected. Validating these
additional elements reduces the probability of wholly
compatible with this extended frame format and can be used as-is,
without any random payload for
a UDP exchange modifications, in environments where the source port NAT is the same as this
specification from being treated as an ESP encapsulated payload.
These checks are not mandatory, but should present and
needs to be performed taken into account.

3. Acknowledgements

The authors would like to cater acknowledge the following people for
this exception case. The extent and number of additional their
feedback on updating the checks
performed are protocol dependent.

3. definitions in this document.

David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron
Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier among
others.

4. IANA Considerations

Reserving an appropriate value for the UDP destination port in order
to provide this encapsulation is TBD and can happen after further
peer review of this document.

4. Formal Syntax

The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described well as a
new value for the protocol in RFC-2234 [iii].

There the IKE negotiation is no new syntax defined TBD by this document. IANA.

5. Security Considerations

As this document augments the existing ESP encapsulation format, UDP
encapsulation definitions specified in RFC 3948, 3948 and IKE negotiation
of the new encapsulation, the security observations made in that document those
documents also apply here. In addition, as this document promotes allows
intermediate device visibility into IPsec ESP encapsulated frames for
the purposes of Network network monitoring functions, care should be taken
not to send sensitive data over connections using definitions from
this document. 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.

6. References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997

[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium
and Demon Internet Ltd., November 1997

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2401] Kent,

[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and R. Atkinson, "Security Architecture for the
Internet Protocol",
Its Use With IPsec", RFC 2401, 2410, November 1998.

[RFC2406]

[RFC4303] Kent, S. and R. Atkinson, S., "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998. 4303, December 2005.

6.2. Informative References

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.

[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4543] McGrew & Viega, "GMAC in

[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP and AH", Packets",
RFC 4543, May 2006. 3948, January 2005.

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.

[RFC4306] Kaufman, C. C., "Internet Key Exchange (IKEv2) Protocol ", Protocol",
RFC 4306, December 2005.

7. Acknowledgements

Author's

Authors' Addresses

Ken Grewal
Intel Corporation
2111 NE 25th Avenue Avenue, JF3-232
Hillsboro, OR 97124
USA

Phone:
Email: ken.grewal@intel.com

David Durham
Intel

Gabriel Montenegro
Microsoft Corporation
2111 NE 25th Avenue
JF3-232
Hillsboro, OR 97124
USA
Email: david.durham@intel.com
Men Long
Intel Corporation
2111 NE 25th Avenue
JF3-232
Hillsboro, OR 97124
One Microsoft Way
Redmond, WA 98052
USA

Phone:
Email: men.long@intel.com gabriel.montenegro@microsoft.com

Full Copyright Statement

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 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

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.