[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

6Lo Working Group                                                S. Raza
Internet-Draft                                              S. Duquennoy
Intended Status: Standard Track                          SICS, Stockholm
                                                             G. Selander
                                                     Ericsson, Stockholm
Expires: September 19, 2016                               March 18, 2016


      Compression of IPsec AH and ESP Headers for 6LoWPAN Networks
                        draft-raza-6lo-ipsec-04

Abstract

   This document describes the header compression mechanisms for IPsec
   [RFC4301] based on the encoding scheme standardized in [RFC6282]. The
   IPsec Authentication Header (AH) and Encapsulated Security Payload
   (ESP) headers are compressed using Next Header Compression (NHC)
   defined in [RFC6282]. This document does not invalidate any encoding
   schemes proposed in 6LoWPAN [RFC6282] but rather complements it with
   compressed IPsec AH and ESP headers using the free bits in the IPv6
   Extension Header encoding. Also, this document does not require any
   changes in a conventional IPsec host on the Internet; the header
   compression is applied only at the 6LoWPAN layer and is effective
   within 6LoWPAN networks.

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 September 19, 2016.


Copyright and License Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Raza                   Expires September 19, 2016               [Page 1]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   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.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  AH in 6LoWPAN Networks  . . . . . . . . . . . . . . . . . .  3
     1.2  IPsec and RPL . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Linking IPsec Headers Compression with 6LoWPAN . . . . . . . .  5
   3. LOWPAN_NHC for Authentication Header  . . . . . . . . . . . . .  5
   4. LOWPAN_NHC for Encapsulated Security Payload (ESP)  . . . . . .  7
   5. Implementation Considerations . . . . . . . . . . . . . . . . .  8
   6. Security Considerations . . . . . . . . . . . . . . . . . . . .  9
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  9
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1. Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2. Informative References  . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

























Raza                   Expires September 19, 2016               [Page 2]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


1  Introduction

   [RFC6282] defines how IPv6 datagrams can be routed over IEEE 802.15.4
   [IEEE802.15.4]-based networks. [RFC6282] defines header compression
   schemes that can significantly reduce the size of IP, IP extension,
   and UDP headers. This enables the routing of heavy-weight IP traffic
   to resource-constrained [IEEE802.15.4]-based wireless networks. The
   security in [IEEE802.15.4]-based IP networks or what is more commonly
   known as 6LoWPAN networks is particularly important when we connect
   vulnerable wireless networks with the insecure Internet. The
   standardized and SHOULD be supported security solution for IPv6 is IP
   security (IPsec) [RFC4301][RFC6434]. This means that every IPv6 host
   on the Internet SHOULD be able to process IP packets secured with
   IPsec. IPsec, in transport mode, can provide end-to-end (E2E) secure
   communication between two hosts in the Internet. Thus, it is
   beneficial to extend 6LoWPAN so that IPsec communication between an
   IPv6 device (e.g. a sensor node) in 6LoWPAN networks and a IPv6 host
   on the Internet becomes possible. This document does not cover the
   tunnel mode of IPsec.


   There are previous proposals to compress IPsec headers. Those
   compression schemes are applicable to any Internet host and are not
   specific to resource-constrained 6LoWPAN networks. Migault et al.
   [draft-mglt-6lo-diet-esp-01][draft-mglt-6lo-aes-implicit-iv-01]
   propose compressing IPsec but require corresponding modifications in
   the conventional Internet host. Similarly, the RObust Header
   Compression (ROHC) [RFC5795][RFC5856] is an efficient and flexible
   header compression concept but targets any Internet host and is not
   specific to 6LoWPAN network. These previous schemes plus Generic
   Header Compression [RFC7400] are complementary to our approach. Our
   header compression mechanisms are confined to 6LoWPAN networks and do
   not require any change in the IPsec AH and ESP standards or in a
   conventional IPsec host on the Internet.

   It is desirable to complement 6LoWPAN header compression with IPsec
   to keep packet sizes reasonable in resource constrained
   [IEEE802.15.4]-based network. There are no header compression
   specified for IPsec's AH[RFC4302] and ESP[RFC4303] extension headers
   for 6LoWPAN networks. This draft therefore proposes AH and ESP
   extension header encoding schemes.

1.1  AH in 6LoWPAN Networks

   AH is underused in the Internet due a number of reason. First, AH is
   incompatible with Network Address Translation (NAT) that changes the
   source IP address, which invalidates the integrity check and results
   in packet rejection by the IPSec peer. Second, ESP can provide both



Raza                   Expires September 19, 2016               [Page 3]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   Integrity protection and encryption. However, ESP can only
   authenticate the ESP header and application data but not the IP
   header part. This is not an issue when the IPsec tunnel mode is use
   because the inner IP header, ESP header and the application data is
   both integrity and confidentiality protected.

   In the IPv6-connected IoT there are no NATs and the transport mode
   that provides end-to-end security is favorable. Therefore, the use of
   ESP along with AH makes more sense in the IoT. As the IP address is a
   part of IPsec AH integrity check, IPsec can protect against the IP
   spoofing attack that is one of the most likely attacks against
   constrained nodes running IPv6. Though IPv6 stateless address auto-
   configuration is proposed, it is not a requirement for IPv6 hosts.
   IPv6 addresses are assigned to resource-constrained nodes in 6LoWPAN
   networks at the deployment time and they most likely stay the same
   during the lifetime of a nodes unless manually changed through
   software/firmware updates. Address auto-configurations for 6LoWPAN
   networks that ensure end-to-end connectivity is in fact out of
   question unless an efficient and suitable mechanism is developed
   targeting 6loWPAN networks. Though mostly there is only one
   application running in a 6LoWPAN node, IPv6 offers potentially
   unlimited address space which allows using multiple IPv6 addresses
   for a single 6LoWPAN node, hence allowing unique IPsec security
   association per application. Also, if IPsec is using IKE [RFC7427]
   unique security association per application can be dynamically
   established.

   Also, for a number of use cases in 6LoWPAN networks, such as sensing
   and transmitting temperature data, only integrity protection is
   required. For these use cases, AH-only is a favorable solution.

1.2  IPsec and RPL

   Unlike IPv4, IPv6 ICMPv6 messages are protected by IPsec. As the RPL
   Control Message [RFC6550] is an ICMPv6 message, it is therefore
   possible to protect it with IPsec.  However, all RPL Control
   Messages, except DAO / DAO-ACK messages in non-storing mode, are
   exchanged between two neighboring devices and have the scope of a
   link. Though IPsec security associations can be created between two
   neighboring devices, IEEE 802.15.4 security at the link layer is more
   suitable for per-hop protection, and IPsec in transport mode can be
   used to protect DAO/DAO-ACK messages in non-storing mode.


1.3  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Raza                   Expires September 19, 2016               [Page 4]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Linking IPsec Headers Compression with 6LoWPAN

   [RFC6282] defines the general format of NHC that can be used to
   encode IP extension headers. [RFC6282] already defines an NHC
   encoding for IPv6 Extension Headers (NHC_EH) that can be used to link
   uncompressed AH and ESP headers to the 6LoWPAN header compression. In
   order to compress the IP extension headers a GHC byte for Extension
   Header (GHC_EH) [RFC7400] is proposed which has the same layout as
   NHC_EH with different ID bits. NHC_EH and GHC_EH consist of an octet
   where three bits (bits 4, 5 and 6) are used to encode the IPv6
   Extension Header ID (EID). Out of eight possible values for the EID,
   six are assigned and the remaining two slots (101 and 110) are
   currently unassigned. As AH and ESP are IP extension headers it makes
   sense to use one of these unassigned slots for the IPsec headers. We
   propose to use the reserved slot 101 for the IPsec headers, AH or
   ESP. The corresponding ID field in the AH or ESP will distinguish
   these headers from each other. It is also necessary to set the NH bit
   in NHC_EH or GHC_EH to 1 to specify that the next header (a header
   after AH or ESP, e.g. UDP) is NHC-encoded.

3. LOWPAN_NHC for Authentication Header

   6LoWPAN  can be used to compress a significant number of bits in AH.
   The next header is decided based on the value of NH bit in the IPv6
   Extension Header Encoding in [RFC6282]. This draft proposes to always
   elide the length field. The payload length field (the length of AH
   header in 32-bit words units minus "2" [RFC4302]) in the AH header is
   always elided, as it can be inferred from the lower layers: either
   from the IEEE 802.15.4 header or the 6LoWPAN header. The size of ICV
   can be obtained from the SPI value because the length of the
   authenticating data depend on the the algorithm used and are fixed
   for any input size. The RESERVED field in the AH header is also
   always elided. The SPI and SN are compressed using the proposed NHC
   encoding for the AH header shown in Figure 1 and are explained
   below.

                     0   1   2   3   4   5   6   7
                   +---+---+---+---+---+---+---+---+
                   | 1 | 1 | 0 | 1 |  SPI  |  SN   |
                   +---+---+---+---+---+---+---+---+

             Figure 1: Proposed LOWPAN NHC encoding for AH

   o  The first four bits in the NHC AH represent the NHC ID we define
      for AH or ESP. These are set to 1101.




Raza                   Expires September 19, 2016               [Page 5]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   o  If SPI = 00: the default SPI for the IEEE 802.15.4 network is used
      and the SPI field is omitted. We set the default SPI value to 1.
      This does not mean that all nodes use the same security
      association (SA), but that every node has a single preferred SA,
      identified by SPI 1. If SPI = 01:  the least significant 8 bits of
      the SPI are carried inline; the remaining 24 bits are elided. If
      SPI = 10:  the least significant 16 bits of the SPI are carried
      inline; the remaining 16 bits are elided. If SPI = 11:  All 32
      bits of the SPI are carried inline.

   o  If SN = 00: the least significant 8 bits of sequence number are
      carried inline. The remaining bits are elided. If SN = 01:  the
      least significant 16 bits of the SN are carried inline; the
      remaining 16 bits are elided. If SN = 10:  the least significant
      24 bits of the SPI are carried inline; the remaining 8 bits are
      elided. If SN = 11:  All 32 bits of the SPI are carried inline.

      The sequence number field in the AH header [RFC4302] contains a
      value 1 for the first packet sent using a given Security
      Association (SA), and it is incremented sequentially for the
      subsequent packets. Note that by using 8-bit sequence number we do
      not limit the size of sequence number to 255, but propose to use 8
      bits for the sequence number prior to the transmission of the
      256th packet on an SA. From the 2^8 to 2^(16-1) we propose to use
      16-bit sequence number. Follow the same procedure for the 24-bit
      sequence number as well. However, the sender and the receiver
      sequence number counters must be reset prior to sending 2^32nd
      packet as proposed in [RFC4302].

   Note that even when used in 6LoWPAN, AH calculates the ICV on the
   uncompressed IP header, thus allowing authenticated communication
   with Internet hosts. The minimum length of a standard AH, supporting
   the mandatory HMAC-SHA1-96[RFC4835], consists of 12 bytes of header
   fields plus 12 bytes of ICV. Figure 2 shows a sample NHC compressed
   IP/UDP packet secured with AH. Using NHC encoding for the AH we can
   reduce the AH header overhead from 24 bytes to 14 bytes: 1 byte of
   next header, 1 byte of length, 2 bytes of Reserved field, 4 bytes of
   SPI, and 2 bytes of sequence number. However, two additional bytes
   are used to define NHC_EH and NHC_AH. Therefore, in the best case,
   with AES-XCBC-MAC-96 [RFC3566] or HMAC-SHA1-96 ciphers (when 12 bytes
   are used for ICV), applying NHC encoding for AH saves 8 bytes in each
   data packet secured with IPsec AH.









Raza                   Expires September 19, 2016               [Page 6]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   |   octet 1     |   octet 2     |    octet 1    |    octet 1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LOWPAN_IPHC           |  Hop Limit    | Source Address|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Address|      Destination Address      | LOWPAN_NHC_EH |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LOWPAN_NHC_AH |    Seq. No    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |       Integrity Check Value-ICV (Variable)                    |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               | LOWPAN_NHC_UDP|S Port | D Port|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                        UDP Payload (Variable)                 |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: A sample NHC compressed IP/UDP packet secured with AH.

4. LOWPAN_NHC for Encapsulated Security Payload (ESP)

   The encryption in the IPsec ESP includes Payload Data, Padding, Pad
   Length and Next Header fields in the ESP. Therefore, we cannot
   compress these fields at the 6LoWPAN layer, and these fields are
   always carried inline. Also, when using ESP the UDP header and
   payload is also encrypted, hence cannot be compressed using NHC
   encodings for UDP defined in the [RFC6282]. However, we can compress
   the SPI and and sequence number (SN) fields in the ESP header. Figure
   3 shows a proposed NHC encodings for the ESP that are explained
   below.

                     0   1   2   3   4   5   6   7
                   +---+---+---+---+---+---+---+---+
                   | 1 | 1 | 1 | 0 |  SPI  |  SN   |
                   +---+---+---+---+---+---+---+---+

             Figure 3: Proposed LOWPAN NHC encoding for ESP

   o  The first four bits in the NHC ESP represent the NHC ID we define
      for ESP. These are set to 1001.

   o  The SPI and SN bits are encoded exactly the same way as in
      Section 3 for the AH header.




Raza                   Expires September 19, 2016               [Page 7]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   In case of ESP we cannot skip the next header unless the end hosts
   are able to execute 6LoWPAN compression/decompression and
   encryption/decryption jointly. The nodes in the 6LoWPAN network make
   their decision about the next header based on the NH value not the
   actual header that is carried inline. In the case of ESP we MUST set
   the NH value in the NHC_EH or GHC_EH to zero to indicate that the
   full 8 bits of next header field are carried inline.

   |   octet 1     |   octet 2     |    octet 1    |    octet 1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LOWPAN_IPHC           |  Hop Limit    | Source Address|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Address|      Destination Address      | LOWPAN_NHC_EH |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LOWPAN_NHC_ESP|     Seq No    |            IV                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      IV [Variable Size]       |           Source Port         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Destination Port       |              Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                     UDP Payload (Variable)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Pad              |   Pad Length  |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                Integrity Check Value (Variable)               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: A sample NHC compressed IP/UDP packet secured with ESP.

   With perfect block alignment, the minimum ESP overhead without
   authentication is 10 bytes [RFC4303]. After optimal compression this
   header overhead is reduced to 6 bytes, considering that two bytes are
   used for NHC_EH and NHC_ESP. ESP also includes an IV which is equal
   to the size of an encryption block; 16 bytes in the case of AES. If
   authentication is enabled in the ESP, additional 12 bytes of ICV are
   also required. Figure 4 shows an UDP/IP packet secured with
   compressed ESP.

5. Implementation Considerations

   We provide an open source implementation of the proposed compression
   scheme in the Contiki operating system. The implementation is



Raza                   Expires September 19, 2016               [Page 8]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   released under BSD license and can be obtained through the
   contikiprojects repository at the following URI:
   svn://svn.code.sf.net/p/contikiprojects/code/sics.se/ipsec

6. Security Considerations

   The compression scheme proposed in this document does not compromise
   any security properties provided by IPsec AH and ESP. In particular,
   the SN field is compressed in an on-demand fashion, as described in
   Section 3. In order to overcome replay attacks, it is recommended
   that the communication end-points should re-establish a security
   association before the sequence number overflows. However, in
   constrained environments, different implementations can decide the
   overflow size; 2^8, 2^16, 2^24, or 2^32. This leads to a trade-off
   between the overhead incurred by establishing a new security
   association and by sending more bits of sequence number. The
   Initialization Vector (IV) and Integrity Check Value (ICV) are also
   not compressed to take full advantage of IPsec AH and ESP security.

7. IANA Considerations

   [RFC6282] creates a new IANA registry for the LOWPAN_NHC header type
   where the two slots, 1110101N and 1110110N, in LOWPAN_NHC for the
   IPv6  Extension Header are unassigned. This document requests the
   assignment of one of these two unassigned values, 1110101N, to IPsec
   AH and ESP. This document also requests the assignment of following
   contents:

   1101XXYY: The 6LOWPAN_NHC encoding for the IPsec Authentication
   Header.

   1001XXYY:  The 6LOWPAN_NHC encoding for the IPsec Encapsulated
   Security Payload Header.

   Capital letters in bit positions represent class-specific bit
   assignments.  The letters XX and YY represent SPI and SN
   respectively, as defined in Section 3.


9. References

9.1. Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997, <http://www.rfc-
              editor.org/info/rfc2119>.




Raza                   Expires September 19, 2016               [Page 9]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <http://www.rfc-editor.org/info/rfc4301>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, DOI
              10.17487/RFC4302, December 2005, <http://www.rfc-
              editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <http://www.rfc-editor.org/info/rfc4303>.

   [RFC6282]  Hui, J., Ed., and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011, <http://www.rfc-
              editor.org/info/rfc6282>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
              2011, <http://www.rfc-editor.org/info/rfc6434>.

   [RFC7400]  C. Bormann , "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, November 2014

9.2. Informative References

  [draft-mglt-6lo-diet-esp-01] Migault, D., Guggemos, T., "Diet-ESP: a
              flexible and compressed format for IPsec/ESP", August
              2015, <https://tools.ietf.org/html/draft-mglt-6lo-diet-
              esp-01>

  [draft-mglt-6lo-aes-implicit-iv-01] Migault, D., Guggemos, T,
              "Implicit IV for AES-CBC, AES-CTR, AES-CCM and AES-GCM",
              August 2015, <https://tools.ietf.org/html/draft-mglt-6lo-
              aes-implicit-iv-01>

   [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, DOI 10.17487/RFC3095,
              July 2001, <http://www.rfc-editor.org/info/rfc3095>.

   [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
              and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,
              September 2003, <http://www.rfc-editor.org/info/rfc3566>.



Raza                   Expires September 19, 2016              [Page 10]


INTERNET DRAFT             IPsec-for-6LoWPAN              March 18, 2016


   [RFC5856]  Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
              "Integration of Robust Header Compression over IPsec
              Security Associations", RFC 5856, DOI 10.17487/RFC5856,
              May 2010, <http://www.rfc-editor.org/info/rfc5856>.

   [RFC7427]  Kivinen, T. and J. Snyder, "Signature Authentication in
              the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
              DOI 10.17487/RFC7427, January 2015, <http://www.rfc-
              editor.org/info/rfc7427>.

   [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, <http://www.rfc-editor.org/info/rfc7400>.



Authors' Addresses


   Shahid Raza
   SICS Swedish ICT AB (SICS)
   Isafjordsgatan 22, 16440 Kista
   SWEDEN

   Phone: +46-(0)768831797
   EMail: shahid@sics.se


   Simon Duquennoy
   SICS Swedish ICT AB (SICS)
   Isafjordsgatan 22, 16440 Kista
   SWEDEN

   Phone: +46-(0)702021482
   EMail: simonduq@sics.se


   Goeran Selander
   Ericsson
   Farogatan 6, 16480 Kista
   SWEDEN

   Email: goran.selander@ericsson.com







Raza                   Expires September 19, 2016              [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/