Internet DRAFT - draft-mglt-dice-ipsec-for-application-payload
draft-mglt-dice-ipsec-for-application-payload
DICE D. Migault (Ed)
Internet-Draft Orange
Intended status: Standards Track C. Bormann
Expires: January 24, 2015 Universitaet Bremen TZI
July 23, 2014
IPsec/ESP for Application Payload
draft-mglt-dice-ipsec-for-application-payload-00.txt
Abstract
This document is a strawman specification describing how IPsec/ESP
could be used to secure application payloads, in particular to enable
multicast applications where DTLS would be used for unicast.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 24, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Migault (Ed) & Bormann Expires January 24, 2015 [Page 1]
Internet-Draft IPsec/ESP for Application Payload July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. State of the Art . . . . . . . . . . . . . . . . . . . . . . 3
3. UDP-Encapsulation Header . . . . . . . . . . . . . . . . . . 5
4. Removing Transport Header . . . . . . . . . . . . . . . . . . 6
5. Additional Compression . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[I-D.keoh-dice-multicast-security] defines a way to protect multicast
traffic against group outsiders using a modified DTLS record
protocol. Reservations have been voiced about modifying DTLS this
way without strengthening security by adding data origin
authentication.
However, many applications do not require this additional security.
One protocol that already supports group-level security for multicast
is IPsec.
This document discusses how IPsec can be used to secure data at the
application layer. The resulting packet structure is expected to
resemble a DTLS flavor as represented in Figure 1.
+--------+-------------------------------------------------+
| | +--------+------------------------------------+ |
| | | | +-------------+------------------+ | |
| | | | | | +--------------+ | | |
| IP | | UDP | | Security | | Application | | | |
| header | | header | | Header | | Data | | | |
| | | | | | +--------------+ | | |
| | | | +-------------+------------------+ | |
| | +--------+------------------------------------+ |
+--------+-------------------------------------------------+
Figure 1: Securing Application Data
Migault (Ed) & Bormann Expires January 24, 2015 [Page 2]
Internet-Draft IPsec/ESP for Application Payload July 2014
1.1. Requirements notation
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 [RFC2119].
2. State of the Art
IPsec/ESP [RFC4303] has been designed to secure IP payload according
to two different modes: the transport mode and the tunnel mode.
Figure 2 represents an non protected UDP packet that is protected
with IPsec/ESP. UDP is chosen as an example and could be any other
transport mode like TCP or SCTP, or ANY for unknown transport.
Figure 3 illustrates how IPsec/ESP secures the non protected packet
using the transport mode and Figure 4 illustrates how IPsec/ESP
secures the packet with the tunnel mode.
+--------------------------+
| IP Header |
+--------------------------+
| UDP Header |
+--------------------------+
| Application |
| Data |
+--------------------------+
Figure 2: Example: non protected IP Packet
+--------------------------+
| IP Header |
+--------------------------+---
| ESP Header | ^
---+--------------------------+ |
^ | IV | |
| +--------------------------+ |
| | UDP Header | | Integrity
| +--------------------------+ | Protection
Encryption | | Application | |
| | Data | |
| +--------------------------+ |
v | ESP Trailer | v
--- +--------------------------+---
| ICV |
+--------------------------+
Figure 3: Example: IPsec/ESP with transport mode
Migault (Ed) & Bormann Expires January 24, 2015 [Page 3]
Internet-Draft IPsec/ESP for Application Payload July 2014
+--------------------------+
| Tunnel IP Header |
+--------------------------+---
| ESP Header | ^
---+--------------------------+ |
^ | IV | |
| +--------------------------+ |
| | IP Header | | Integrity
Encryption | +--------------------------+ | Protection
| | UDP Header | |
| +--------------------------+ |
| | Encrypted Application | |
| | Data | |
| +--------------------------+ |
v | ESP Trailer | v
---+--------------------------+---
| ICV |
+--------------------------+
Figure 4: Ex: IPsec/ESP with tunnel mode
This document does not consider the tunnel mode and only the
transport mode. DTLS is usually used to secure application data.
Among other differences, IPsec/ESP with transport mode differs from
DTLS on the following aspects: 1) The Security Header is placed
before the transport header, as a result 2) the transport header is
encrypted. Then 3) IPsec/ESP is an extension of IP which makes the
whole packet described in Figure 3 and Figure 4 an IP packet with an
empty IP payload. One consequence is that the packet has to respect
the bit alignment required for IP headers, that is 32 bit alignment
for IPv4 and 64 bit alignment for IPv6. This is why the ESP Trailer
presents some Padding.
Figure 3 and Figure 4 mentions the IV which is necessary for
encryption and decryption. The IV is usually not part of the IPsec/
ESP protocol, but is defined by the encryption protocol used by
IPsec/ESP. Each encryption protocol defines the size of its IV. It
is mentioned in the figures in order to clarify the way we compute
the overhead.
For NAT traversal, IPsec has defined a UDP encapsulation in
[RFC3948]. UDP encapsulation of the IPsec/ESP packet with transport
mode is illustrated in Figure 5.
Migault (Ed) & Bormann Expires January 24, 2015 [Page 4]
Internet-Draft IPsec/ESP for Application Payload July 2014
+--------------------------+
| IP Header |
+--------------------------+
| UDP-Encapsulation |
+--------------------------+---
| ESP Header | ^
---+--------------------------+ |
^ | IV | |
| +--------------------------+ |
| | UDP Header | | Integrity
| +--------------------------+ | Protection
Encryption | | Application | |
| | Data | |
| +--------------------------+ |
v | ESP Trailer | v
--- +--------------------------+---
| ICV |
+--------------------------+
Figure 5: Ex: UDP Encapsulation of IPsec/ESP Transport mode
As illustrated in Figure 5, using IPsec/ESP with UDP encapsulation
achieves our goal: A UDP packet carries a encrypted payload. In
Figure 5, the encrypted payload is the concatenation of the IV, the
UDP header, the application data and the ESP Trailer.
The overhead of such a packet is the ESP Header (8 bytes), the IV (8
bytes for AES-CCM mode [RFC4309]), an extra UDP header (8 bytes), the
ESP Trailer (2 bytes and padding bytes. Padding bytes are between 0
and 8 for 64 bit alignment in IPv6 and between 0 and 4 bytes for
IPv4. As a result, the average is 6 bytes for IPv6 and 4 bytes for
IPv4). This leads to a 30 bytes overhead for IPv6 and 28 byte
overhead for IPv4.
If this approach is to be pursued, it is probably worthwhile to
reduce this overhead
The remaining sections describe ways to do that.
3. UDP-Encapsulation Header
[RFC3948] specifies that ports of the UDP-Encapsulation Header MUST
be the one used during the IKEv2 negotiation. In addition IKEv2 is
listening for UDP encapsulation on port 4500. As a result, the port
of the responder is always set to 4500 for any ESP packet.
The use of a fix port in 4500 for IKEv2 is a standard port that
specifies, IKEv2 packets are expected to be UDP encapsulated. The
Migault (Ed) & Bormann Expires January 24, 2015 [Page 5]
Internet-Draft IPsec/ESP for Application Payload July 2014
reason to keep these ports in the ESP UDP encapsulated communication,
is that 1) IKEv2 has set a channel between the peers through a NAT --
note that each peer may have a different set of (port source, port
destination). 2) IKEv2 is used to set up the IPsec/ESP communication
on each peer by setting the various IPsec database. Since IKEv2 is
aware of a through-NAT-reachable channel, IKEv2 can proceed to UDP
encapsulation setting on each hosts.
Port fixing is not required in applications other than the UDP
encapsulation or if IKEv2 is not used to setup the IPsec/ESP
communication.
4. Removing Transport Header
The Transport Header is used to identify the application with ports,
once IPsec has decrypted an incoming packet. For sending packets,
the ports in the transport header can be used as Traffic Selectors to
identify the right Securicy Policy.
Removing the Transport Header implies that none of the ports or
transport protocol can be used as selectors. IPsec [RFC4301] does
not prevent that, and only the IP addresses will be considered, and
thus all applications that do not use ports as selectors between the
two peers will be protected with the same SA. Note that IPsec SPD is
an ordered database. This means that if an application between the
two peers with ports specified as Traffic Selectors needs a specific
Security Association, this is still possible. The policy has simply
to be placed before the policy using only IP addresses.
5. Additional Compression
With the current standard [RFC3948], [RFC4301], no additional
compression can be completed, which leaves an overhead of 22 bytes
for IPv4 and 20 bytes for IPv4.
Protocols like 6LowPAN [I-D.raza-6lowpan-ipsec], ROHC [RFC3095],
[RFC5225] can compress the ESP Header up to zero bytes. The ESP
Header contains a Security Policy Index (SPI) of 4 bytes and a
Sequence Number (SN) of 4 bytes. The SPI may be completely
compressed if the UDP decapsulation decompressor is able to derive
the SPI from UDP ports. Both SPI and SN are necessary to perform
authentication and integrity check.
Compression of the ESP Trailer cannot be currently performed.
However, ongoing work [I-D.mglt-ipsecme-diet-esp] makes possible the
compression of all fields of the ESP Trailer.
Migault (Ed) & Bormann Expires January 24, 2015 [Page 6]
Internet-Draft IPsec/ESP for Application Payload July 2014
Compression of IV is not currently permitted with IPsec, and this
field MUST be included in each IP packet. However, some ongoing work
[I-D.mglt-ipsecme-diet-esp-iv-generation].
Finally, compression of the transport header may also be performed
using [I-D.mglt-ipsecme-diet-esp-payload-compression]. The advanatge
of compressing it over removing it is that compression enables the
use of ports as Traffic Selectors without carrying the transport
header. Note that this is done under conditions.
6. IANA Considerations
There are no IANA consideration for this document.
7. Security Considerations
The security considerations of IPsec and Diet-ESP (if used) apply.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005.
Migault (Ed) & Bormann Expires January 24, 2015 [Page 7]
Internet-Draft IPsec/ESP for Application Payload July 2014
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, April 2008.
8.2. Informational References
[I-D.keoh-dice-multicast-security]
Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Rahman, "DTLS-based Multicast Security in Constrained
Environments", draft-keoh-dice-multicast-security-08 (work
in progress), July 2014.
[I-D.mglt-ipsecme-diet-esp]
Migault, D. and T. Guggemos, "Diet-ESP: a flexible and
compressed format for IPsec/ESP", draft-mglt-ipsecme-diet-
esp-01 (work in progress), July 2014.
[I-D.mglt-ipsecme-diet-esp-iv-generation]
Migault, D. and T. Guggemos, "Diet-ESP: Generating
compressed IV and SN", draft-mglt-ipsecme-diet-esp-iv-
generation-00 (work in progress), July 2014.
[I-D.mglt-ipsecme-diet-esp-payload-compression]
Migault, D. and T. Guggemos, "Diet-IPsec: ESP Payload
Compression of IPv6 / UDP / TCP / UDP-Lite", draft-mglt-
ipsecme-diet-esp-payload-compression-00 (work in
progress), July 2014.
[I-D.raza-6lowpan-ipsec]
Raza, S., Duquennoy, S., and G. Selander, "Compression of
IPsec AH and ESP Headers for Constrained Environments",
draft-raza-6lowpan-ipsec-01 (work in progress), September
2013.
Authors' Addresses
Daniel Migault
Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: daniel.migault@orange.com
Migault (Ed) & Bormann Expires January 24, 2015 [Page 8]
Internet-Draft IPsec/ESP for Application Payload July 2014
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Migault (Ed) & Bormann Expires January 24, 2015 [Page 9]
