goswami-ipsec-espll-00.txt

Internet DRAFT - draft-goswami-ipsec-espll

draft-goswami-ipsec-espll

Last Version:	draft-goswami-ipsec-espll-00.txt	Tracker Entry
Date:	`22-Jan-2004`
Disposition:	removed
Previous Versions:	draft-goswami-ipsec-espll-00.txt (diff) - 07-May-2003

IPSEC
Internet Draft S. Goswami
Document: draft-goswami-ipsec-espll-00.txt Independent
Consultant
Expires: November 2003 May 2003

Encapsulating Security Payload for Link Layers (ESPLL)

Status of this Memo

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

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.

Abstract

The trend has been to use different encryption mechanism for
different layers. Although it can be argued that multiple layers is
good protection, such an approach is higly inefficient from the view
performance and necessity. In some situations this kind separate
encryption mechanism may afford the bytes 7 levels of encryption, for
example : AES (from 802.11)+ 3DES (from IPSec) + 3DES (from TLS/SSL).
Recently link layer encryption has become an important issue,
specially in the context of wireless networks. Although this document
does not attempt to solve this multiple layer encryption issue, it is
an effort to that goal. Specifically, this document describes a way
to use ESP in several link layer technologies.

Goswami Expires - November 2003 [Page 1]
ESPLL May 2003

Conventions used in this document

In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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.

Table of Contents

1. Overview and Rationale.........................................2
2. ESP Packet for Link Layer......................................2
3. Link Layer Issues..............................................4
3.1 Security Parameter Index (SPI).............................4
3.2 Fragmentation..............................................4
3.3 Encryption Algorithms......................................5
3.4 Authentication Algorithms..................................5
4. Operational Advantages.........................................5
5. Specific Link Layers...........................................7
5.1 802.11 Links...............................................7
5.2 802.3 Links................................................8
5.3 802.15 Links...............................................8
5.4 802.16 Links...............................................8
6. Formal Syntax..................................................9
7. Security Considerations........................................9
8. References.....................................................9
Acknowledgments..................................................10
Author's Addresses...............................................10

1. Overview and Rationale

The Encapsulating Security Payload (ESP) header is designed to
provide services in IPv4 and IPv6. Over time ESP has proven to be a
robust mechanism for securing an IP connection. For wireline security
at the link layer has been achieved through physical isolation. One
exception has been the cellular network, where the link layer is
secured through encryption. Recently several new link layer
technologies have matured - - 802.11, 802.15, 802.16, and 802.20. All
of these new link layer technologies can benefit from using ESP on
multiple fronts: ESP is a proven protocol, use of ESP at multiple
layers would allow reuse of code/modules, ESP works very well with
key exchange protocols such as IKE, etc.

2. ESP Packet for Link Layer

Goswami Expires - November 2003 [Page 2]
ESPLL May 2003

ESP has two modes, transport and tunnel [1,2]. ESP header is inserted
after the IP header and before the upper layer protocol header in
transport mode or before an encapsulated IP header in tunnel mode.
Although both modes are possible, we will consider only transport for
ESPLL.

ESP provides confidentiality, data origin authentication,
connectionless integrity, an anti-replay service, and limited traffic
flow confidentiality.

The following figure shows the ESP packet format, which is kept
unchanged in ESPLL.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 ESP Packet format

The SPI is a 32 bit value (some specific values have been reserved)
that together with the destination address (using a MAC address
instead of an IP address) and protocol type (ESPLL) uniquely
identifies a Security Association (SA).

The Sequence Number is a 32 bit that is monotonically increased
starting at 0 when an SA is established between two peers.

Payload Data is a variable-length field containing data that is
described by the Next Header field. The Payload Data field is
mandatory and is an integral number of octets in length. An
encryption algorithm that uses cryptographic synchronization data
such as Initialization Vector (IV) usually is defined in a RFC that

Goswami Expires - November 2003 [Page 3]
ESPLL May 2003

shows the length, structure of the cryptographic synchronization
data.

Padding has been used in ESP for several purposes: 4-byte boundary
termination requirement, partial traffic flow confidentiality, the
block size of a block cipher, etc.

The Pad Length field indicates the number of pad bytes immediately
preceding it.

The Next Header is an 8-bit field that identifies the type of data
contained in the Payload Data field, e.g., an extension header in
IPv6 or an upper layer protocol identifier. The value of this field
is chosen from the set of Protocol Numbers defined in the most recent
"Assigned Numbers" [IETF STD-2] RFC from the Internet Assigned
Numbers Authority (IANA).

The Authentication Data is a field of variable-length that contains
an Integrity Check Value (ICV) computed over the ESP packet by
excluding the the Authentication Data itslef. The length of the
field is specified by the authentication function selected. The
Authentication Data field is optional, and is included only if the
authentication service has been configured for the SA.

3. Link Layer Issues

Link LayerÆs have some issues that are not shared by the IP layer and
there are issues that are shared by the IP layer.

3.1 Security Parameter Index (SPI)

The SPI in the ESP packet is a 32-bit value that is used by a
receiver to identify the Security Association (SA) to which an
incoming packet is bound. In addition to the SPI, the source and
destination addresses can be used to determine the exact SA. For
unicast traffic usually only the SPI is sufficient for determining
SA, for multicast traffic the group address and the source address
can be used in addition to SPI to determine the SA. The SPI to be
used with ESP is generated during Phase 2 of IKE exchange in the
IPSec DOI. Thus for ESPLL, the SPI can be entered manually or IKE
for Link Layer can be defined or a IEEE 802.11i based key exchange
can be used.

3.2 Fragmentation

If necessary ESP allows fragmentation to be performed after ESP
processing within an IPsec implementation. Thus, transport mode ESP

Goswami Expires - November 2003 [Page 4]
ESPLL May 2003

is applied only to a whole IP datagrams (not to IP fragments). An IP
packet to which ESP has been applied may itself be fragmented by IP
routers in the route, and such fragments are reassembled prior to ESP
processing at a receiver.

Some link layers (e.g. 802.11) have fragmentation and
defragmentation capability, whereas others (e.g. 802.3) do not have
any.

Thus each link layer requires a separate discussion.

3.3 Encryption Algorithms

The only mandatory encryption algorithms that ESP supports are DES in
CBC mode and NULL. The cipher text is generated from the payload by
encrypting the result (Payload Data, Padding, Pad Length, and Next
Header) using the key, encryption algorithm, algorithm mode indicated
by the SA and cryptographic synchronization data (if any). In both
DES and 3DES, the actual cipher data is preceded by an Initialization
Vector (IV) field. The cipher text is generated from the payload and
pad.

In ESPLL also, the process of generating the cipher remain the same,
except in the Next Header field. The Next Header field in ESP usually
contains the header type of the original (pre-encrypted) payload. The
Next Header field length is different in link layer technologies
(i.e. known as Type/Subtype in 802.11, Type in Ethernet II, Type in
SNAP, none in 802.3/802.2 etc.). In accordance with ESP, in ESPLL the
Next Header field contains the appropriate value( after an
appropriate mapping from 2 octets to 1 octets if required).

3.4 Authentication Algorithms

The Authentication Data is a variable-length field containing an
integrity check value computed over the ESP packet minus the
Authentication Data. The length of the field is specified by the
authentication function selected. The Authentication Data field is
optional in ESP and is computed after encryption of the payload
field.

4. Operational Advantages

Using ESPLL has the advantage that the same code, same SPD and SAD
can be used for both the link layer and the network layer. In other
words the SPD and SAD can be shared between IPSec ESP and ESPLL. The
following figure shows diagram of such a node.

Goswami Expires - November 2003 [Page 5]
ESPLL May 2003

[IP Stack ]
[IPSec ESP ]-------
[Driver ] |--- (SPD)(SAD)
[ESPLL ]-------
[NIC ]

Fig. 2 An ESPLL node with IPSec ESP

In the IP layer, according to RFC 2401, SPD is indexed by selectors
which are composed of the following elements: Source/Destination IP
Address, User ID, System Name, Transport Layer Protocol,
Source/Destination Ports. For the ESPLL case the port field, User
ID, and System Name may not exist (although as SPD is used for
outbound packet processing these information can be made available),
whereas the protocol field may be available for use along with Source
and Destination MAC addresses instead of IP addresses.

Similarly RFC 2401 also mentions a selector for SAD as follows:
Destination IP Address, IPSec protocol type (AH or ESP), and SPI. In
ESPLL these information are available if the IP address is replaced
by MAC address.

In addition it is possible to transfer an SA between network and link
layers. The following figure shows how three ESPLL and IPSec enabled
nodes may first establish an ESPLL SA, which could then be
transferred to IPSec or vice-versa (step 2a in the figure below). The
exact protocol for SA transfer is to be described later.

---------------------- ---------------- ----------------
| [Key Exchange] |<--0-->|[Key Exchange]| | |
| | | | | |
| [ IPSec ] |<------|-----3--------|-->| [IPSec] |
| \ | | | | / |
| \ | | 2b | | / |
| \ 2a | | /------|---|-- |
| \ | | / | | |
| [ESPLL] |<--1-->| [ESPLL] | | |
| | | | | |
---------------------- ---------------- ----------------
| | | |
-------------------- ------------- Links

Node 1 Node 2 Node 3

Goswami Expires - November 2003 [Page 6]
ESPLL May 2003

Fig. 3 ESP SA transfer

5. Specific Link Layers

In the following are described how ESPLL can be used with a few
popular Link Layers.

5.1 802.11 Links

The following figure shows a 802.11 frame [8,9,10]. The frame has a
header and a trailer. The header is composed of several fields and
the trailer is Frame Check Sequence.

The following figure shows the Frame Control field. For a detailed
description of these please consult XXX.

Type value of 10 represents Data frames, subtypes 0000-0111 have been
defined. For ESPLL a subtype from the currently reserved range of
1000-1111 is chosen, say 1000. Also, the WEP bit is turned off.
In 802.11 frames can potentially be fragmented. The Frame Control
field as shown in the above diagram allocates 4 bits to identify
fragments. In the WEP mode supported by 802.11 encryption is
carried out after fragmentation, unlike IPsec ESP where fragmentation
is carried out after encryption. The primary reason behind this
difference is that in the transport mode IPSec, IP packets may
traverse multiple link where each IP packet may be fragmented in an
intermediate router, thus fragmented packets that are ESPÆed can
again be fragmented.

Goswami Expires - November 2003 [Page 7]
ESPLL May 2003

5.2 802.3 Links

To be added

5.3 802.15 Links

To be added

5.4 802.16 Links

802.16 specification supports both time division duplex (TDD) and
frequency division duplex (FDD) configurations over 10-66 GHZ radio
frequency. The uplink channel is based on a combination of time
division multiple access (TDMA) and demand assigned multiple access
(DAMA). The uplink channel is divided into a number of time slots.
The number of slots assigned for various uses (registration,
contention, guard, or user traffic) may vary over time for optimal
performance. The downlink channel is time division multiplexed , with
the information for each subscriber station multiplexed onto a single
stream of data and received by all subscriber stations. The 802.16
MAC is connection oriented and a MAC frames is as follows.

Bits
1 1 6 1 1 2 1 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|HT |EC |Type |R |CI |EKS |R | LEN |
| | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LEN |CID |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CID |HCS |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAYLOAD |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

HT- Header Type CI- CRC Indicator
EC- 802.16 Encryption EKS- 802.16 Encryption Key Sequence
Type- Payload Type LEN- Length including header

Goswami Expires - November 2003 [Page 8]
ESPLL May 2003

R- Reserved CID- Connection ID
HCS- Header Check Sequence

Figure 6 802.16 Frame

Each 802.16 station is identified with a 48-bit MAC address. The MAC
address is used during the registration process, after a connection
is established the 16-bit Connection ID is used.

A 802.16 ESPLL frame can be indicated by Type, say 0x06.

6. Formal Syntax

No special syntax used.

7. Security Considerations

8. References

1. Kent, S., "The Encapsulating Security Payload (ESP)", RFC 2406,
November 1998.
2. Kent, S., IP Encapsulating Security Payload (ESP), draft-ietf-
ipsec-esp-v3-05.txt, April 2003.
3. Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
4. Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
With Explicit IV", RFC 2405, November 1998.
5. Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", RFC 2403, November 1998.
6. Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
7. Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also: http://www.iana.org/numbers.html
8. IEEE, IEEE Standard for Information technology--
Telecommunications and information exchange between systems--
Local and metropolitan area networks--Specific requirements--
Part 3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications.
9. IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", 1999.
10. IEEE, "802.11i Draft 3.2", April 2003.

Goswami Expires - November 2003 [Page 9]
ESPLL May 2003

11. IEEE, ææ802.16-2001ÆÆ, Part 16: Air Interface for Fixed Broadband
Wireless Access Systems, 2001.

Acknowledgments

Author's Addresses

Subrata Goswami
Independent Consultant
6151G Joaquin Murieta, Newark, CA 94560
Phone:
Email: sgoswami@umich.edu

Goswami Expires - November 2003 [Page 10]