< draft-mglt-ipsecme-diet-esp-06.txt   draft-mglt-ipsecme-diet-esp-07.txt >
ipsecme D. Migault ipsecme D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track T. Guggemos Intended status: Standards Track T. Guggemos
Expires: November 30, 2018 LMU Munich Expires: September 12, 2019 LMU Munich
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
D. Schinazi D. Schinazi
Apple Inc. Google LLC
May 29, 2018 March 11, 2019
ESP Header Compression and Diet-ESP ESP Header Compression and Diet-ESP
draft-mglt-ipsecme-diet-esp-06 draft-mglt-ipsecme-diet-esp-07
Abstract Abstract
With the use of encrypted ESP for secure IP communication, the
compression of IP payload is only possible with complex frameworks,
such as RObust Header Compression (ROHC). Such frameworks are too
complex for numerous use cases and especially for IoT scenarios,
which makes IPsec not being used here, although it offers
architectural benefits.
ESP Header Compression (EHC) defines a flexible framework to compress ESP Header Compression (EHC) defines a flexible framework to compress
communications protected with IPsec/ESP. Compression and communications protected with IPsec/ESP. Compression and
decompression is defined by EHC Rules orchestrated by EHC Strategies. decompression is defined by EHC Rules orchestrated by EHC Strategies.
The necessary state is hold within the IPsec Security Association and
can be negotiated during key agreement, e.g. with IKEv2.
The document specifies the Diet-ESP EHC Strategy and associated EHC The document specifies the necessary parameters of the EHC Context to
Rules. Diet-ESP compresses up to 32 bytes per packet for traditional allow compression of ESP and the most common included protocols, such
IPv6 VPN and up to 66 bytes for IPv6 VPN sent over a single TCP or as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. It also
UDP session. defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per
packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent
over a single TCP or UDP session.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2018. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. IPsec Compression Mode . . . . . . . . . . . . . . . . . . . 5 5. IPsec Compression Mode . . . . . . . . . . . . . . . . . . . 7
6. EHC Context . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. EHC Context . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Diet-ESP Context Parameters for ESP . . . . . . . . . . . 6 6.1. EHC Context Parameters for ESP . . . . . . . . . . . . . 8
6.2. EHC Context Parameters for Inner IP . . . . . . . . . . . 7 6.2. EHC Context Parameters for Inner IP . . . . . . . . . . . 8
6.3. EHC Context Parameters for Transport Protocol . . . . . . 8 6.3. EHC Context Parameters for Transport Protocol . . . . . . 9
7. EHC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. EHC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. EHC Rules for ESP . . . . . . . . . . . . . . . . . . . . 12 7.1. EHC Rules for ESP . . . . . . . . . . . . . . . . . . . . 13
7.2. EHC Rules for inner IPv4 . . . . . . . . . . . . . . . . 13 7.2. EHC Rules for inner IPv4 . . . . . . . . . . . . . . . . 15
7.3. EHC Rules for inner IPv6 . . . . . . . . . . . . . . . . 15 7.3. EHC Rules for inner IPv6 . . . . . . . . . . . . . . . . 17
7.4. EHC Rules for UDP . . . . . . . . . . . . . . . . . . . . 17 7.4. EHC Rules for UDP . . . . . . . . . . . . . . . . . . . . 18
7.5. EHC Rules for UDP-Lite . . . . . . . . . . . . . . . . . 18 7.5. EHC Rules for UDP-Lite . . . . . . . . . . . . . . . . . 19
7.6. EHC Rules for TCP . . . . . . . . . . . . . . . . . . . . 19 7.6. EHC Rules for TCP . . . . . . . . . . . . . . . . . . . . 20
8. Diet-ESP EHC Strategy . . . . . . . . . . . . . . . . . . . . 20 8. Diet-ESP EHC Strategy . . . . . . . . . . . . . . . . . . . . 21
8.1. Outbound Packet Processing . . . . . . . . . . . . . . . 23 8.1. Outbound Packet Processing . . . . . . . . . . . . . . . 24
8.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 25 8.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informational References . . . . . . . . . . . . . . . . 31 13.2. Informational References . . . . . . . . . . . . . . . . 32
Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 31
A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 31 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 33
A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 34 A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 33
A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 37 A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Introduction 2. Introduction
skipping to change at page 3, line 28 skipping to change at page 3, line 34
IPsec/ESP was not designed to minimize its associated networking IPsec/ESP was not designed to minimize its associated networking
overhead. In fact, bandwidth optimization often adds computational overhead. In fact, bandwidth optimization often adds computational
overhead that may negatively impact large infrastructures in which overhead that may negatively impact large infrastructures in which
bandwidth usage is not a constraint. On the other hand, in IoT bandwidth usage is not a constraint. On the other hand, in IoT
communications, sending extra bytes can significantly impact the communications, sending extra bytes can significantly impact the
battery life of devices and thus the life time of the device. The battery life of devices and thus the life time of the device. The
document describes a framework that optimizes the networking overhead document describes a framework that optimizes the networking overhead
associated to IPsec/ESP for these devices. associated to IPsec/ESP for these devices.
ESP Header Compression (EHC) is a framework that compresses ESP Most compression mechanisms work with dynamic compression contexts.
Some mechanisms, such as ROHC, agree and dynamically change the
context over a dedicated channel. Others, such as 6LowPAN, send the
context together with the actual protocol information in a separate
compression header. Those mechanism fail when it comes to compress
encrypted payloads as appearing in ESP. This is found to be a major
reason, why IPsec and in particular ESP is not widely developed in
environments where bandwidth saving is a critical task, such as in
IoT scenarios.
ESP Header Compression (EHC) chooses another form of context
agreement, which is similar to the one defined by Static Context
Header Compression (SCHC). It works with a static compression
context agreed for a specific Security Association. The context
itself can be negotiated during the key agreement, which allows only
minimal the changes to the actual ESP implementation.
EHC itself is defined as a framework that specifically compresses ESP
protected communications. EHC is highly flexible to address any use protected communications. EHC is highly flexible to address any use
case where compression is necessary. EHC takes advantage of the case where compression is necessary. EHC takes advantage of the
negotiation between the communication endpoint to agree on the negotiation between the communication endpoint to agree on the
cryptographic parameters. In some cases, the agreement already cryptographic parameters, which in some cases already includes
includes parameters that remain constant during the communications parameters that remain constant during the communications (like layer
(like layer 4 ports, or IP addresses). EHC takes advantage of these 4 ports, or IP addresses) and can thus be used as part of the
already agreed parameters and defines additional parameters that compression context. Only additional, EHC specific parameters need
could be agreed for the purpose of compression. Similarly, EHC also to be agreed for the purpose of compression. In addition EHC Rules
defines EHC Rules which define how fields may be compressed and define how fields may be compressed and decompressed given the
decompressed given the provided parameters. Finally, EHC defines EHC provided parameters. Finally, EHC defines EHC Strategy which defines
Strategy which defines how a set of EHC Rule is coordinated. how a set of EHC Rule is coordinated.
The document specifies the Diet-ESP EHC Strategy and associated EHC This document specifies EHC Context parameters for the most common
Rules. Diet-ESP compresses up to 32 bytes per packet for traditional Layer 3 and 4 protocols and the associated EHC Rules. Additionally,
VPN and up to 66 bytes for VPN set over a single TCP or UDP session. an EHC Strategy called Diet-ESP is defined, which compresses up to 32
bytes per packet for traditional VPN and up to 66 bytes for VPN set
over a single TCP or UDP session. Its main purpose is a maximum
level of compression with a minimum of additional agreement. This is
achieved by defining a default usage of existing IPsec SA parameters
wherever possible.
3. Terminology 3. Terminology
This document uses the following terminology: This document uses the following terminology:
- EHC ESP Header Compression - EHC ESP Header Compression
- IoT Internet of Things - IoT Internet of Things
- IP If not stated otherwise, IP means IPv6. - IP If not stated otherwise, IP means IPv6.
- LSB Least Significant Bytes - LSB Least Significant Bytes
- MSB Most Significant Bytes - MSB Most Significant Bytes
skipping to change at page 4, line 25 skipping to change at page 5, line 5
- IIV Implicit Initialization Vector - IIV Implicit Initialization Vector
- ICV Integrity Check Value - ICV Integrity Check Value
- VPN Virtual Private Network - VPN Virtual Private Network
4. Protocol Overview 4. Protocol Overview
ESP Header Compression (EHC) compresses IPsec ESP packets, thus ESP Header Compression (EHC) compresses IPsec ESP packets, thus
reducing the size of the packet sent on the wire, while carrying an reducing the size of the packet sent on the wire, while carrying an
equivalent level of information with an equivalent level of security. equivalent level of information with an equivalent level of security.
The primarily motivation for payload size reduction were IoT related EHC is able to compress any protocol encapsulated in ESP and ESP
use cases, were the cost of sending extra bytes largely overcomes itself. Concerned fields include those of the ESP protocol, as well
additional computations and thus considerably reduces the life time as other protocols in the ESP payload such as the IP header when the
of battery powered devices. As a result, IoT communication rather tunnel mode is used, but also upper layer protocols, such as the UDP
favors expensive compression over additional bandwidth. Standard or the TCP header. Non ESP fields may be compressed by ESP under
IPsec VPN may also consider reduction of their bandwidth, but on the certain circumstances, but EHC is not intended to provide a generic
other hand, the acceptable computation overhead must remain very low. way outside of ESP to compress these protocols. Compression of the
The ESP Header Compression designated in this document together with unprotected IP header and the unencrypted ESP header may be performed
the EHC Strategy named Diet-ESP attempts to reach both of these two by mechanism such as 6LoWPAN [RFC4944], SCHC
goals. [I-D.toutain-6lpwa-ipv6-static-context-hc], ROHC [RFC5795] or
6LoWPAN-GHC [RFC7400].
ESP Header Compression compresses the standard ESP payload by EHC is based on a static compression context, EHC Rules coordinated
compressing different fields with specific compression rules by an EHC Strategy:
performed in the ESP stack. Concerned fields include those of the
ESP protocol, as well as other protocols in the ESP payload such as
the IP header when the tunnel mode is used, the UDP or the TCP
header. In fact non ESP fields may be compressed by ESP under
certain circumstances and ESP Header Compression is not intended to
provide a generic way outside of ESP to compress these protocols.
Further compression of the ESP payload may be performed by generic
mechanism and outside ESP with more generic mechanisms such as for
example ROHCoverIPsec [RFC5858] or SCHC
[I-D.toutain-6lpwa-ipv6-static-context-hc] which are orthogonal to
ESP Header Compression.
As depicted in Figure 1, in order to compress the ESP packets, the EHC Context: Stores the information of a specific header field which
two peers are expected to agree on the EHC Strategy - Diet-ESP in our can be compressed by EHC. This can be specific header values
case - as well as some extra parameters needed to derive the EHC such as IP addresses or L4 ports do not have to be send on the
Rules and EHC Context. wire at all, or compression information for fields which can be
partially compressed, such as sequence numbers.
EHC Rules: Defines how the information of the EHC Context is used to
compress a specific field. It defines compression functions,
such as "elided", "least significant byte" and others, being
applied on the header field.
EHC Strategy: Is applied to efficiently coordinate EHC Context and
EHC Strategy. The EHC Strategy "Diet-ESP" defined in this
document utilizes the information in the IPsec SA to pre-define
the EHC Context without explicitly exchanging the EHC Context.
As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case -
and the EHC Context are agreed upon between the two peers, e.g.
during key exchange. The EHC Rules are to be implemented on the
peers and do not require further agreement.
EHC Strategy, EHC Strategy, EHC Strategy, EHC Strategy,
EHC Context <==================> EHC Context EHC Context <==================> EHC Context
| | | |
EHC Rules | EHC Rules | EHC Rules | EHC Rules |
| | | | | | | |
v v v v v v v v
+====================+ +====================+ +====================+ +====================+
| ESP | | ESP | | ESP | | ESP |
+====================+ +====================+ +====================+ +====================+
skipping to change at page 5, line 28 skipping to change at page 6, line 26
| < clear text esp > | | < clear text esp > | | < clear text esp > | | < clear text esp > |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| < encryption > | | < encryption > | | < encryption > | | < encryption > |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| < post-esp > | | < post-esp > | | < post-esp > | | < post-esp > |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1: ESP Header Compression Overview Figure 1: ESP Header Compression Overview
In Figure 1, the ESP stack is represented by various sub layers In Figure 1, the ESP stack is represented by various sub layers
describing the packet processing inside the ESP. The "pre-esp" layer describing the packet processing inside the ESP:
represents treatment performed to a non ESP packet, i.e. before ESP
encapsulation or decapsulation is being proceeded. "clear text esp" pre-esp: represents treatment performed to a non ESP packet, i.e.
designates the ESP encapsulation / decapsulation processing performed before ESP encapsulation or decapsulation is being performed.
on an non encrypted ESP packet. "encryption" designates the Any compression of protocols not specific to but encrypted by
encryption/decryption phase and "post-esp" the processing performed ESP, such as L4 and higher protocols, is performed here.
on an ESP encrypted packet. EHC Rules may be processed at any of clear text esp: designates the ESP encapsulation / decapsulation
these layers - except for "encryption" layer, and thus impact processing performed on an non encrypted ESP packet. This layer
includes compression for fields which are included during the ESP
encapsulation. A typical example is the later encrypted Tunnel
IP header and the fields of the ESP trailer.
encryption: designates the encryption/decryption phase This layer
could include compression of encryption information (e.g.
Initialization Vector, etc.), but this is currently out of scope
of this document.
post-esp the processing performed on an ESP encrypted packet. This
layer includes compression of the ESP header.
EHC Rules may be processed at any of these layers and thus impact
differently the standard ESP. More specifically, EHC Rules performed differently the standard ESP. More specifically, EHC Rules performed
at the "pre-esp" or "post-esp" layer do not require the current ESP at the "pre-esp" or "post-esp" layer do not require the current ESP
stack to be updated and can simply be appended to the current ESP stack to be updated and can simply be appended to the current ESP
stack. On the other hand, EHC Rules at the "clear text esp" may stack. On the other hand, EHC Rules at the "clear text esp" may
require modification of the current ESP stack. require modification of the current ESP stack.
The set of EHC rules described in this document as well as the EHC The set of EHC rules described in this document as well as the EHC
Strategies may be extended in the future. Nothing prevents such EHC Strategies may be extended in the future. Nothing prevents such EHC
Rules and Strategies to be updated. Rules and Strategies to be updated.
skipping to change at page 6, line 28 skipping to change at page 7, line 39
given EHC Context and EHC Strategy, it MUST NOT apply compression. given EHC Context and EHC Strategy, it MUST NOT apply compression.
If an SA with IPsec Mode "Tunnel"/"Transport" is available, the If an SA with IPsec Mode "Tunnel"/"Transport" is available, the
sender SHOULD send the packet uncompressed, rather than discard the sender SHOULD send the packet uncompressed, rather than discard the
packet. When there is no uncompressed SA available, the packet MUST packet. When there is no uncompressed SA available, the packet MUST
be dropped. be dropped.
6. EHC Context 6. EHC Context
The EHC Context provides the necessary information so the two peers The EHC Context provides the necessary information so the two peers
can proceed to the appropriated compression and decompression defined can proceed to the appropriated compression and decompression defined
by the EHC Strategy. As this document is limited to the Diet-ESP by the EHC Strategy.
strategy, the EHC Context in this section is also designated as Diet-
ESP Context and is used by the Diet-ESP Strategy to activate specific The EHC Context is defined on a per-SA basis. A context can be
EHC Rules as well as to execute the EHC Rule by providing the defined for any protocol encapsulated with ESP and for ESP itself.
For each header field, a context attribute is provided to the EHC
Context in order to allow compression and decompression. Most power
of EHC lies in the fact, that the attributes for some protocols are
already available in the IPsec SA (e.g. IP addresses in the Traffic
Selector). Such attributes are designated by "Yes" in the "In SA"
column. All others need to be negotiated separately in order to
allow EHC to work properly.
As this document is limited to the Diet-ESP strategy, the EHC Context
in this section used by the Diet-ESP Strategy to activate specific
EHC Rules as well as to execute the EHC Rules by providing the
necessary parameters.. necessary parameters..
The Diet-ESP Context is defined on a per-SA basis. It is composed of 6.1. EHC Context Parameters for ESP
attributes that are not Diet-ESP specific, as well as attributes that
are Diet-ESP specific. Attributes that are not Diet-ESP specific are
already stored in some form in the SA (e.g. IP addresses in the
Traffic Selector). Such attributes are designated by "Yes" in the
"In SA" column. Diet-ESP specific attributes may need to be
specified so Diet-ESP can be executed properly.
6.1. Diet-ESP Context Parameters for ESP
+-------------------+-------+--------------------------+ +-------------------+-------+--------------------------+
| Context Attribute | In SA | Possible Values | | Context Attribute | In SA | Possible Values |
+-------------------+-------+--------------------------+ +-------------------+-------+--------------------------+
| ipsec_mode | Yes | "Tunnel", "Transport" | | ipsec_mode | Yes | "Tunnel", "Transport" |
| outer_version | Yes | "IPv4", "IPv6" | | outer_version | Yes | "IPv4", "IPv6" |
| esp_spi | Yes | ESP SPI | | esp_spi | Yes | ESP SPI |
| esp_spi_lsb | No | 0, 1, 2, 3, 4 | | esp_spi_lsb | No | 0, 1, 2, 3, 4 |
| esp_sn | Yes | ESP Sequence Number | | esp_sn | Yes | ESP Sequence Number |
| esp_sn_lsb | No | 0, 1, 2, 3, 4 | | esp_sn_lsb | No | 0, 1, 2, 3, 4 |
| esp_sn_gen | No | "Time", "Incremental" | | esp_sn_gen | No | "Time", "Incremental" |
skipping to change at page 30, line 44 skipping to change at page 32, line 5
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005, RFC 4309, DOI 10.17487/RFC4309, December 2005,
<https://www.rfc-editor.org/info/rfc4309>. <https://www.rfc-editor.org/info/rfc4309>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>.
[RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec
Extensions to Support Robust Header Compression over Extensions to Support Robust Header Compression over
IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010,
<https://www.rfc-editor.org/info/rfc5858>. <https://www.rfc-editor.org/info/rfc5858>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informational References 13.2. Informational References
[I-D.toutain-6lpwa-ipv6-static-context-hc] [I-D.toutain-6lpwa-ipv6-static-context-hc]
Minaburo, A. and L. Toutain, "6LPWA Static Context Header Minaburo, A. and L. Toutain, "6LPWA Static Context Header
Compression (SCHC) for IPV6 and UDP", draft-toutain-6lpwa- Compression (SCHC) for IPV6 and UDP", draft-toutain-6lpwa-
ipv6-static-context-hc-01 (work in progress), June 2016. ipv6-static-context-hc-01 (work in progress), June 2016.
[I-D.mglt-ipsecme-implicit-iv] [I-D.mglt-ipsecme-implicit-iv]
Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for
Counter-based Ciphers in IPsec", draft-mglt-ipsecme- Counter-based Ciphers in IPsec", draft-mglt-ipsecme-
implicit-iv-04 (work in progress), June 2017. implicit-iv-04 (work in progress), June 2017.
[I-D.ietf-tsvwg-udp-options] [I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-02 (work in progress), January 2018. udp-options-07 (work in progress), March 2019.
[fit-iot-lab] [fit-iot-lab]
"Future Internet of Things (FIT) IoT-LAB", "Future Internet of Things (FIT) IoT-LAB",
<https://www.iot-lab.info>. <https://www.iot-lab.info>.
Appendix A. Illustrative Examples Appendix A. Illustrative Examples
A.1. Single UDP Session IoT VPN A.1. Single UDP Session IoT VPN
This section considers a IoT IPv6 probe hosting a UDP application. This section considers a IoT IPv6 probe hosting a UDP application.
skipping to change at page 45, line 31 skipping to change at page 47, line 31
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
David Schinazi David Schinazi
Apple Inc. Google LLC
1 Infinite Loop 1600 Amphitheatre Parkway
Cupertino, California 95014 Mountain View, California 94043
US USA
Email: dschinazi@apple.com Email: dschinazi.ietf@gmail.com
 End of changes. 25 change blocks. 
102 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/