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. 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. Octets 2 2 6 6 6 2 6 0-2312 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Frame |Duration|Addr1|Addr2|Addr3|Sequence|Addr4|Body |Frame Check| |Control | ID | | | |Control | | |Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+- Figure 4 802.11 Frame The following figure shows the Frame Control field. For a detailed description of these please consult XXX. Bits 2 2 4 1 1 1 1 1 1 1 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |Protocol|Type |Subtype|To|From|More |Retry|Power|More|WEP|Order| |Version | | |DS|DS |Frags | |Mgmt |Data| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ Figure 5 802.11 Frame’s Frame Control Field 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]