doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc8061.txt b/doc/rfc/rfc8061.txt
new file mode 100644
index 0000000..9bdd08f
--- /dev/null
+++ b/doc/rfc/rfc8061.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      D. Farinacci
+Request for Comments: 8061                                   lispers.net
+Category: Experimental                                           B. Weis
+ISSN: 2070-1721                                            Cisco Systems
+                                                           February 2017
+
+
+    Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
+
+Abstract
+
+   This document describes a mechanism for encrypting traffic
+   encapsulated using the Locator/ID Separation Protocol (LISP).  The
+   design describes how key exchange is achieved using existing LISP
+   control-plane mechanisms as well as how to secure the LISP data plane
+   from third-party surveillance attacks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8061.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 1]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Notation ...........................................4
+   3. Definition of Terms .............................................4
+   4. Overview ........................................................4
+   5. Diffie-Hellman Key Exchange .....................................5
+   6. Encoding and Transmitting Key Material ..........................6
+   7. Shared Keys Used for the Data Plane .............................8
+   8. Data-Plane Operation ...........................................10
+   9. Procedures for Encryption and Decryption .......................11
+   10. Dynamic Rekeying ..............................................12
+   11. Future Work ...................................................13
+   12. Security Considerations .......................................14
+      12.1. SAAG Support .............................................14
+      12.2. LISP-Crypto Security Threats .............................14
+   13. IANA Considerations ...........................................15
+   14. References ....................................................16
+      14.1. Normative References .....................................16
+      14.2. Informative References ...................................17
+   Acknowledgments ...................................................18
+   Authors' Addresses ................................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 2]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+1.  Introduction
+
+   This document describes a mechanism for encrypting LISP-encapsulated
+   traffic.  The design describes how key exchange is achieved using
+   existing LISP control-plane mechanisms as well as how to secure the
+   LISP data plane from third-party surveillance attacks.
+
+   The Locator/ID Separation Protocol [RFC6830] defines a set of
+   functions for routers to exchange information used to map from
+   non-routable Endpoint Identifiers (EIDs) to routable Routing Locators
+   (RLOCs).  LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel
+   Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs)
+   and Re-encapsulating Tunnel Routers (RTRs).  Packets that arrive at
+   the ITR or PITR may not be encrypted, which means no protection or
+   privacy of the data is added.  When the source host encrypts the data
+   stream, encapsulated packets do not need to be encrypted by LISP.
+   However, when plaintext packets are sent by hosts, this design can
+   encrypt the user payload to maintain privacy on the path between the
+   encapsulator (the ITR or PITR) to a decapsulator (ETR or RTR).  The
+   encrypted payload is unidirectional.  However, return traffic uses
+   the same procedures but with different key values by the same xTRs or
+   potentially different xTRs when the paths between LISP sites are
+   asymmetric.
+
+   This document has the following requirements (as well as the general
+   requirements from [RFC6973]) for the solution space:
+
+   o  Do not require a separate Public Key Infrastructure (PKI) that is
+      out of scope of the LISP control-plane architecture.
+
+   o  The budget for key exchange MUST be one round-trip time.  That is,
+      only a two-packet exchange can occur.
+
+   o  Use symmetric keying so faster cryptography can be performed in
+      the LISP data plane.
+
+   o  Avoid a third-party trust anchor if possible.
+
+   o  Provide for rekeying when secret keys are compromised.
+
+   o  Support Authenticated Encryption with packet integrity checks.
+
+   o  Support multiple Cipher Suites so new crypto algorithms can be
+      easily introduced.
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 3]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   Satisfying the above requirements provides the following benefits:
+
+   o  Avoiding a PKI reduces the operational cost of managing a secure
+      network.  Key management is distributed and independent from any
+      other infrastructure.
+
+   o  Packet transport is optimized due to fewer packet headers.  Packet
+      loss is reduced by a more efficient key exchange.
+
+   o  Authentication and privacy are provided with a single mechanism
+      thereby providing less per-packet overhead and therefore more
+      resource efficiency.
+
+2.  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].
+
+3.  Definition of Terms
+
+   AEAD: Authenticated Encryption with Associated Data [RFC5116]
+
+   ICV: Integrity Check Value
+
+   LCAF: LISP Canonical Address Format [RFC8060]
+
+   xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs
+
+4.  Overview
+
+   The approach proposed in this document is NOT to rely on the LISP
+   mapping system (or any other key-infrastructure system) to store
+   security keys.  This will provide for a simpler and more secure
+   mechanism.  Secret shared keys will be negotiated between the ITR and
+   the ETR in Map-Request and Map-Reply messages.  Therefore, when an
+   ITR needs to obtain the RLOC of an ETR, it will get security material
+   to compute a shared secret with the ETR.
+
+   The ITR can compute three shared secrets per ETR the ITR is
+   encapsulating to.  When the ITR encrypts a packet before
+   encapsulation, it will identify the key it used for the crypto
+   calculation so the ETR knows which key to use for decrypting the
+   packet after decapsulation.  By using key-ids in the LISP header, we
+   can also get fast rekeying functionality.
+
+   The key management described in this document is unidirectional from
+   the ITR (the encapsulator) to the ETR (the decapsultor).
+
+
+
+Farinacci & Weis              Experimental                      [Page 4]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+5.  Diffie-Hellman Key Exchange
+
+   LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and
+   computation for computing a shared secret.  The Diffie-Hellman
+   parameters will be passed via Cipher Suite code-points in Map-Request
+   and Map-Reply messages.
+
+   Here is a brief description how Diffie-Hellman works:
+
+   +----------------------------+---------+----------------------------+
+   |              ITR           |         |           ETR              |
+   +------+--------+------------+---------+------------+---------------+
+   |Secret| Public | Calculates |  Sends  | Calculates | Public |Secret|
+   +------|--------|------------|---------|------------|--------|------+
+   |  i   |  p,g   |            | p,g --> |            |        |  e   |
+   +------|--------|------------|---------|------------|--------|------+
+   |  i   | p,g,I  |g^i mod p=I |  I -->  |            | p,g,I  |  e   |
+   +------|--------|------------|---------|------------|--------|------+
+   |  i   | p,g,I  |            |  <-- E  |g^e mod p=E |  p,g   |  e   |
+   +------|--------|------------|---------|------------|--------|------+
+   | i,s  |p,g,I,E |E^i mod p=s |         |I^e mod p=s |p,g,I,E | e,s  |
+   +------|--------|------------|---------|------------|--------|------+
+
+        Public-Key Exchange for Computing a Shared Private Key [DH]
+
+   Diffie-Hellman parameters 'p' and 'g' must be the same values used by
+   the ITR and ETR.  The ITR computes public key 'I' and transmits 'I'
+   in a Map-Request packet.  When the ETR receives the Map-Request, it
+   uses parameters 'p' and 'g' to compute the ETR's public key 'E'.  The
+   ETR transmits 'E' in a Map-Reply message.  At this point, the ETR has
+   enough information to compute 's', the shared secret, by using 'I' as
+   the base and the ETR's private key 'e' as the exponent.  When the ITR
+   receives the Map-Reply, it uses the ETR's public key 'E' with the
+   ITR's private key 'i' to compute the same 's' shared secret the ETR
+   computed.  The value 'p' is used as a modulus to create the width of
+   the shared secret 's' (see Section 6).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 5]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+6.  Encoding and Transmitting Key Material
+
+   The Diffie-Hellman key material is transmitted in Map-Request and
+   Map-Reply messages.  Diffie-Hellman parameters are encoded in the
+   LISP Security Key LCAF Type [RFC8060].
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |           AFI = 16387         |     Rsvd1     |     Flags     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Type = 11   |      Rsvd2    |             6 + n             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Key Count   |      Rsvd3    | Cipher Suite  |   Rsvd4     |R|
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |           Key Length          |     Public Key Material ...   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    ... Public Key Material                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |              AFI = x          |       Locator Address ...     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Cipher Suite Field Contains DH Key Exchange and Cipher/Hash Functions
+
+   The Key Count field encodes the number of {'Key-Length',
+   'Key-Material'} fields included in the encoded LCAF.  The maximum
+   number of keys that can be encoded is three, each identified by
+   key-id 1, followed by key-id 2, and finally key-id 3.
+
+   The R bit is not used for this use case of the Security Key LCAF Type
+   but is reserved for [LISP-DDT] security.  Therefore, the R bit SHOULD
+   be transmitted as 0 and MUST be ignored on receipt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 6]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+ Cipher Suite 0:
+    Reserved
+
+ Cipher Suite 1 (LISP_2048MODP_AES128_CBC_SHA256):
+    Diffie-Hellman Group: 2048-bit MODP [RFC3526]
+    Encryption:  AES with 128-bit keys in CBC mode [AES-CBC]
+    Integrity:   Integrated with AEAD_AES_128_CBC_HMAC_SHA_256 [AES-CBC]
+    IV length:   16 bytes
+    KDF:         HMAC-SHA-256
+
+ Cipher Suite 2 (LISP_EC25519_AES128_CBC_SHA256):
+    Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
+    Encryption:  AES with 128-bit keys in CBC mode [AES-CBC]
+    Integrity:   Integrated with AEAD_AES_128_CBC_HMAC_SHA_256 [AES-CBC]
+    IV length:   16 bytes
+    KDF:         HMAC-SHA-256
+
+ Cipher Suite 3 (LISP_2048MODP_AES128_GCM):
+    Diffie-Hellman Group: 2048-bit MODP [RFC3526]
+    Encryption:  AES with 128-bit keys in GCM mode [RFC5116]
+    Integrity:   Integrated with AEAD_AES_128_GCM [RFC5116]
+    IV length:   12 bytes
+    KDF:         HMAC-SHA-256
+
+ Cipher Suite 4 (LISP_3072MODP_AES128_GCM):
+    Diffie-Hellman Group: 3072-bit MODP [RFC3526]
+    Encryption:  AES with 128-bit keys in GCM mode [RFC5116]
+    Integrity:   Integrated with AEAD_AES_128_GCM [RFC5116]
+    IV length:   12 bytes
+    KDF:         HMAC-SHA-256
+
+ Cipher Suite 5 (LISP_256_EC25519_AES128_GCM):
+    Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
+    Encryption:  AES with 128-bit keys in GCM mode [RFC5116]
+    Integrity:   Integrated with AEAD_AES_128_GCM [RFC5116]
+    IV length:   12 bytes
+    KDF:         HMAC-SHA-256
+
+ Cipher Suite 6 (LISP_256_EC25519_CHACHA20_POLY1305):
+    Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
+    Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539]
+    Integrity:  Integrated with AEAD_CHACHA20_POLY1305 [CHACHA-POLY]
+    IV length:  8 bytes
+    KDF:        HMAC-SHA-256
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 7]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   The Public Key Material field contains the public key generated by
+   one of the Cipher Suites defined above.  The length of the key, in
+   octets, is encoded in the Key Length field.
+
+   When an ITR, PITR, or RTR sends a Map-Request, they will encode their
+   own RLOC in the Security Key LCAF Type format within the ITR-RLOCs
+   field.  When an ETR or RTR sends a Map-Reply, they will encode their
+   RLOCs in Security Key LCAF Type format within the RLOC-record field
+   of each EID-record supplied.
+
+   If an ITR, PITR, or RTR sends a Map-Request with the Security Key
+   LCAF Type included and the ETR or RTR does not want to have
+   encapsulated traffic encrypted, they will return a Map-Reply with no
+   RLOC-records encoded with the Security Key LCAF Type.  This signals
+   to the ITR, PITR, or RTR not to encrypt traffic (it cannot encrypt
+   traffic anyway since no ETR public key was returned).
+
+   Likewise, if an ITR or PITR wishes to include multiple key-ids in the
+   Map-Request, but the ETR or RTR wishes to use some but not all of the
+   key-ids, it returns a Map-Reply only for those key-ids it wishes to
+   use.
+
+7.  Shared Keys Used for the Data Plane
+
+   When an ITR or PITR receives a Map-Reply accepting the Cipher Suite
+   sent in the Map-Request, it is ready to create data-plane keys.  The
+   same process is followed by the ETR or RTR returning the Map-Reply.
+
+   The first step is to create a shared secret, using the peer's shared
+   Diffie-Hellman Public Key Material combined with the device's own
+   private keying material, as described in Section 5.  The Diffie-
+   Hellman parameters used are defined in the Cipher Suite sent in the
+   Map-Request and copied into the Map-Reply.
+
+   The resulting shared secret is used to compute an AEAD-key for the
+   algorithms specified in the Cipher Suite.  A Key Derivation Function
+   (KDF) in counter mode, as specified by [NIST-SP800-108], is used to
+   generate the data-plane keys.  The amount of keying material that is
+   derived depends on the algorithms in the Cipher Suite.
+
+   The inputs to the KDF are as follows:
+
+   o  KDF function.  This is HMAC-SHA-256 in this document, but
+      generally specified in each Cipher Suite definition.
+
+   o  A key for the KDF function.  This is the computed Diffie-Hellman
+      shared secret.
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 8]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   o  Context that binds the use of the data-plane keys to this session.
+      The context is made up of the following fields, which are
+      concatenated and provided as the data to be acted upon by the KDF
+      function.  A Context is made up of the following components:
+
+      *  A counter, represented as a two-octet value in network byte
+         order.
+
+      *  The null-terminated string "lisp-crypto".
+
+      *  The ITR's nonce from the Map-Request the Cipher Suite was
+         included in.
+
+      *  The number of bits of keying material required (L), represented
+         as a two-octet value in network byte order.
+
+   The counter value in the context is first set to 1.  When the amount
+   of keying material exceeds the number of bits returned by the KDF
+   function, then the KDF function is called again with the same inputs
+   except that the counter increments for each call.  When enough keying
+   material is returned, it is concatenated and used to create keys.
+
+   For example, AES with 128-bit keys requires 16 octets (128 bits) of
+   keying material, and HMAC-SHA1-96 requires another 16 octets (128
+   bits) of keying material in order to maintain a consistent 128 bits
+   of security.  Since 32 octets (256 bits) of keying material are
+   required, and the KDF function HMAC-SHA-256 outputs 256 bits, only
+   one call is required.  The inputs are as follows:
+
+   key-material = HMAC-SHA-256(dh-shared-secret, context)
+
+       where: context = 0x0001 || "lisp-crypto" || <itr-nonce> || 0x0100
+
+   In contrast, a Cipher Suite specifying AES with 256-bit keys requires
+   32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires
+   another 32 octets (256 bits) of keying material in order to maintain
+   a consistent 256 bits of security.  Since 64 octets (512 bits) of
+   keying material are required, and the KDF function HMAC-SHA-256
+   outputs 256 bits, two calls are required.
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                      [Page 9]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   key-material-1 = HMAC-SHA-256(dh-shared-secret, context)
+
+       where: context = 0x0001 || "lisp-crypto" || <itr-nonce> || 0x0200
+
+   key-material-2 = HMAC-SHA-256(dh-shared-secret, context)
+
+       where: context = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200
+
+   key-material = key-material-1 || key-material-2
+
+   If the key-material is longer than the required number of bits (L),
+   then only the most significant L bits are used.
+
+   From the derived key-material, the most significant 256 bits are used
+   for the AEAD-key by AEAD ciphers.  The 256-bit AEAD-key is divided
+   into a 128-bit encryption key and a 128-bit integrity check key
+   internal to the cipher used by the ITR.
+
+8.  Data-Plane Operation
+
+   The LISP encapsulation header [RFC6830] requires changes to encode
+   the key-id for the key being used for encryption.
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  / |       Source Port = xxxx      |       Dest Port = 4341        |
+UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  \ |           UDP Length          |        UDP Checksum           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+L / |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |\ \
+I   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A
+S \ |                 Instance ID/Locator-Status-Bits               | |D
+P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/
+    |                   Initialization Vector (IV)                  | I
+E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C
+n / |                                                               | V
+c   |                                                               | |
+r   |                Packet Payload with EID Header ...             | |
+y   |                                                               | |
+p \ |                                                               |/
+t   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     K-bits Indicate When a Packet Is Encrypted and Which Key Is Used
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 10]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   When the KK bits are 00, the encapsulated packet is not encrypted.
+   When the value of the KK bits is 1, 2, or 3, it encodes the key-id of
+   the secret keys computed during the Diffie-Hellman
+   Map-Request/Map-Reply exchange.  When the KK bits are not 0, the
+   payload is prepended with an Initialization Vector (IV).  The length
+   of the IV field is based on the Cipher Suite used.  Since all Cipher
+   Suites defined in this document do Authenticated Encryption with
+   Associated Data (AEAD), an ICV field does not need to be present in
+   the packet since it is included in the ciphertext.  The Additional
+   Data (AD) used for the ICV is shown above and includes the LISP
+   header, the IV field, and the packet payload.
+
+   When an ITR or PITR receives a packet to be encapsulated, the device
+   will first decide what key to use, encode the key-id into the LISP
+   header, and use that key to encrypt all packet data that follows the
+   LISP header.  Therefore, the outer header, UDP header, and LISP
+   header travel as plaintext.
+
+   At the time of writing, there is an open working group item to
+   discuss if the data encapsulation header needs change for encryption
+   or any new applications.  This document proposes changes to the
+   existing header so experimentation can continue without making large
+   changes to the data plane at this time.  This document allocates two
+   bits of the previously unused three flag bits (note the R-bit above
+   is still a reserved flag bit, as documented in [RFC6830]) for the KK
+   bits.
+
+9.  Procedures for Encryption and Decryption
+
+   When an ITR, PITR, or RTR encapsulates a packet and has already
+   computed an AEAD-key (detailed in Section 7) that is associated with
+   a destination RLOC, the following encryption and encapsulation
+   procedures are performed:
+
+   1.  The encapsulator creates an IV and prepends the IV value to the
+       packet being encapsulated.  For GCM and ChaCha20 Cipher Suites,
+       the IV is incremented for every packet (beginning with a value of
+       1 in the first packet) and sent to the destination RLOC.  For CBC
+       Cipher Suites, the IV is a new random number for every packet
+       sent to the destination RLOC.  For the ChaCha20 Cipher Suite, the
+       IV is an 8-byte random value that is appended to a 4-byte counter
+       that is incremented for every packet (beginning with a value of 1
+       in the first packet).
+
+   2.  Next encrypt with cipher function AES or ChaCha20 using the AEAD-
+       key over the packet payload following the AEAD specification
+       referenced in the Cipher Suite definition.  This does not include
+       the IV.  The IV must be transmitted as plaintext so the decrypter
+
+
+
+Farinacci & Weis              Experimental                     [Page 11]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+       can use it as input to the decryption cipher.  The payload should
+       be padded to an integral number of bytes a block cipher may
+       require.  The result of the AEAD operation may contain an ICV,
+       the size of which is defined by the referenced AEAD
+       specification.  Note that the AD (i.e., the LISP header exactly
+       as will be prepended in the next step and the IV) must be given
+       to the AEAD encryption function as the "associated data"
+       argument.
+
+   3.  Prepend the LISP header.  The key-id field of the LISP header is
+       set to the key-id value that corresponds to key-pair used for the
+       encryption cipher.
+
+   4.  Lastly, prepend the UDP header and outer IP header onto the
+       encrypted packet and send packet to destination RLOC.
+
+   When an ETR, PETR, or RTR receives an encapsulated packet, the
+   following decapsulation and decryption procedures are performed:
+
+   1.  The outer IP header, UDP header, LISP header, and IV field are
+       stripped from the start of the packet.  The LISP header and IV
+       are retained and given to the AEAD decryption operation as the
+       "associated data" argument.
+
+   2.  The packet is decrypted using the AEAD-key and the IV from the
+       packet.  The AEAD-key is obtained from a local-cache associated
+       with the key-id value from the LISP header.  The result of the
+       decryption function is a plaintext packet payload if the cipher
+       returned a verified ICV.  Otherwise, the packet is invalid and is
+       discarded.  If the AEAD specification included an ICV, the AEAD
+       decryption function will locate the ICV in the ciphertext and
+       compare it to a version of the ICV that the AEAD decryption
+       function computes.  If the computed ICV is different than the ICV
+       located in the ciphertext, then it will be considered tampered.
+
+   3.  If the packet was not tampered with, the decrypted packet is
+       forwarded to the destination EID.
+
+10.  Dynamic Rekeying
+
+   Since multiple keys can be encoded in both control and data messages,
+   an ITR can encapsulate and encrypt with a specific key while it is
+   negotiating other keys with the same ETR.  As soon as an ETR or RTR
+   returns a Map-Reply, it should be prepared to decapsulate and decrypt
+   using the new keys computed with the new Diffie-Hellman parameters
+   received in the Map-Request and returned in the Map-Reply.
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 12]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   RLOC-probing can be used to change keys or Cipher Suites by the ITR
+   at any time.  And when an initial Map-Request is sent to populate the
+   ITR's map-cache, the Map-Request flows across the mapping system
+   where a single ETR from the Map-Reply RLOC-set will respond.  If the
+   ITR decides to use the other RLOCs in the RLOC-set, it MUST send a
+   Map-Request directly to negotiate security parameters with the ETR.
+   This process may be used to test reachability from an ITR to an ETR
+   initially when a map-cache entry is added for the first time, so an
+   ITR can get both reachability status and keys negotiated with one
+   Map-Request/Map-Reply exchange.
+
+   A rekeying event is defined to be when an ITR or PITR changes the
+   Cipher Suite or public key in the Map-Request.  The ETR or RTR
+   compares the Cipher Suite and public key it last received from the
+   ITR for the key-id, and if any value has changed, it computes a new
+   public key and Cipher Suite requested by the ITR from the Map-Request
+   and returns it in the Map-Reply.  Now a new shared secret is computed
+   and can be used for the key-id for encryption by the ITR and
+   decryption by the ETR.  When the ITR or PITR starts this process of
+   negotiating a new key, it must not use the corresponding key-id in
+   encapsulated packets until it receives a Map-Reply from the ETR with
+   the same Cipher Suite value it expects (the values it sent in a Map-
+   Request).
+
+   Note when RLOC-probing continues to maintain RLOC reachability and
+   rekeying is not desirable, the ITR or RTR can either not include the
+   Security Key LCAF Type in the Map-Request or supply the same key
+   material as it received from the last Map-Reply from the ETR or RTR.
+   This approach signals to the ETR or RTR that no rekeying event is
+   requested.
+
+11.  Future Work
+
+   For performance considerations, newer Elliptic-Curve Diffie-Hellman
+   (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to
+   reduce CPU cycles required to compute shared secret keys.
+
+   For better security considerations as well as to be able to build
+   faster software implementations, newer approaches to ciphers and
+   authentication methods will be researched and tested.  Some examples
+   are ChaCha20 and Poly1305 [CHACHA-POLY] [RFC7539].
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 13]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+12.  Security Considerations
+
+12.1.  SAAG Support
+
+   The LISP working group received security advice and guidance from the
+   Security Area Advisory Group (SAAG).  The SAAG has been involved
+   early in the design process, and their input and reviews have been
+   included in this document.
+
+   Comments from the SAAG included:
+
+   1.  Do not use asymmetric ciphers in the data plane.
+
+   2.  Consider adding ECDH early in the design.
+
+   3.  Add Cipher Suites because ciphers are created more frequently
+       than protocols that use them.
+
+   4.  Consider the newer AEAD technology so authentication comes with
+       doing encryption.
+
+12.2.  LISP-Crypto Security Threats
+
+   Since ITRs and ETRs participate in key exchange over a public
+   non-secure network, a man in the middle (MITM) could circumvent the
+   key exchange and compromise data-plane confidentiality.  This can
+   happen when the MITM is acting as a Map-Replier and provides its own
+   public key so the ITR and the MITM generate a shared secret key
+   between them.  If the MITM is in the data path between the ITR and
+   ETR, it can use the shared secret key to decrypt traffic from the
+   ITR.
+
+   Since LISP can secure Map-Replies by the authentication process
+   specified in [LISP-SEC], the ITR can detect when a MITM has signed a
+   Map-Reply for an EID-prefix for which it is not authoritative.  When
+   an ITR determines that the signature verification fails, it discards
+   and does not reuse the key exchange parameters, avoids using the ETR
+   for encapsulation, and issues a severe log message to the network
+   administrator.  Optionally, the ITR can send RLOC-probes to the
+   compromised RLOC to determine if the authoritative ETR is reachable.
+   And when the ITR validates the signature of a Map-Reply, it can begin
+   encrypting and encapsulating packets to the RLOC of ETR.
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 14]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+13.  IANA Considerations
+
+   This document describes a mechanism for encrypting LISP-encapsulated
+   packets based on Diffie-Hellman key exchange procedures.  During the
+   exchange, the devices have to agree on a Cipher Suite to be used
+   (i.e., the cipher and hash functions used to encrypt/decrypt and to
+   sign/verify packets).  The 8-bit Cipher Suite field is reserved for
+   such purpose in the security material section of the Map-Request and
+   Map-Reply messages.
+
+   IANA has created a new registry (as outlined in [RFC5226]) titled
+   "LISP Crypto Cipher Suite".  Initial values for the registry are
+   provided below.  Future assignments are to be made on a "First Come,
+   First Served" basis [RFC5226].
+
+   +-----+--------------------------------------------+------------+
+   |Value| Suite                                      | Reference  |
+   +-----+--------------------------------------------+------------+
+   |  0  | Reserved                                   | Section 6  |
+   +-----+--------------------------------------------+------------+
+   |  1  | LISP_2048MODP_AES128_CBC_SHA256            | Section 6  |
+   +-----+--------------------------------------------+------------+
+   |  2  | LISP_EC25519_AES128_CBC_SHA256             | Section 6  |
+   +-----+--------------------------------------------+------------+
+   |  3  | LISP_2048MODP_AES128_GCM                   | Section 6  |
+   +-----+--------------------------------------------+------------+
+   |  4  | LISP_3072MODP_AES128_GCM                   | Section 6  |
+   +-----+--------------------------------------------+------------+
+   |  5  | LISP_256_EC25519_AES128_GCM                | Section 6  |
+   +-----+--------------------------------------------+------------+
+   |  6  | LISP_256_EC25519_CHACHA20_POLY1305         | Section 6  |
+   +-----+--------------------------------------------+------------+
+
+                         LISP Crypto Cipher Suites
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 15]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+14.  References
+
+14.1.  Normative References
+
+   [NIST-SP800-108]
+              National Institute of Standards and Technology,
+              "Recommendation for Key Derivation Using Pseudorandom
+              Functions", NIST Special Publication SP 800-108,
+              DOI 10.6028/NIST.SP.800-108, October 2009.
+
+   [RFC2119]  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>.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, DOI 10.17487/RFC2631, June 1999,
+              <http://www.rfc-editor.org/info/rfc2631>.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, DOI 10.17487/RFC3526, May 2003,
+              <http://www.rfc-editor.org/info/rfc3526>.
+
+   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
+              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
+              for Transport Layer Security (TLS)", RFC 4492,
+              DOI 10.17487/RFC4492, May 2006,
+              <http://www.rfc-editor.org/info/rfc4492>.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <http://www.rfc-editor.org/info/rfc5116>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
+              Curve Cryptography Algorithms", RFC 6090,
+              DOI 10.17487/RFC6090, February 2011,
+              <http://www.rfc-editor.org/info/rfc6090>.
+
+   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+              Locator/ID Separation Protocol (LISP)", RFC 6830,
+              DOI 10.17487/RFC6830, January 2013,
+              <http://www.rfc-editor.org/info/rfc6830>.
+
+
+
+Farinacci & Weis              Experimental                     [Page 16]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+              Morris, J., Hansen, M., and R. Smith, "Privacy
+              Considerations for Internet Protocols", RFC 6973,
+              DOI 10.17487/RFC6973, July 2013,
+              <http://www.rfc-editor.org/info/rfc6973>.
+
+   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
+              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
+              <http://www.rfc-editor.org/info/rfc7539>.
+
+   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
+              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
+              February 2017, <http://www.rfc-editor.org/info/rfc8060>.
+
+14.2.  Informative References
+
+   [AES-CBC]  McGrew, D., Foley, J., and K. Paterson, "Authenticated
+              Encryption with AES-CBC and HMAC-SHA", Work in Progress,
+              draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
+
+   [CHACHA-POLY]
+              Langley, A. and W. Chang, "ChaCha20 and Poly1305 based
+              Cipher Suites for TLS", Work in Progress,
+              draft-agl-tls-chacha20poly1305-04, November 2013.
+
+   [CURVE25519]
+              Bernstein, D., "Curve25519: new Diffie-Hellman speed
+              records", DOI 10.1007/11745853_14,
+              <http://www.iacr.org/cryptodb/archive/2006/
+              PKC/3351/3351.pdf>.
+
+   [DH]       Wikipedia, "Diffie-Hellman key exchange", January 2017,
+              <https://en.wikipedia.org/w/index.php?title=Diffie%E2%80%9
+              3Hellman_key_exchange&oldid=759611604>.
+
+   [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
+              Smirnov, "LISP Delegated Database Tree", Work in
+              Progress, draft-ietf-lisp-ddt-08, September 2016.
+
+   [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
+              "LISP-Security (LISP-SEC)", Work in Progress,
+              draft-ietf-lisp-sec-12, November 2016.
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 17]
+
+RFC 8061             LISP Data-Plane Confidentiality       February 2017
+
+
+Acknowledgments
+
+   The authors would like to thank Dan Harkins, Joel Halpern, Fabio
+   Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest,
+   suggestions, and discussions about LISP data-plane security.  An
+   individual thank you to LISP WG Chair Luigi Iannone for shepherding
+   this document as well as contributing to the IANA Considerations
+   section.
+
+   The authors would like to give a special thank you to Ilari Liusvaara
+   for his extensive commentary and discussion.  He has contributed his
+   security expertise to make lisp-crypto as secure as the state of the
+   art in cryptography.
+
+   In addition, the support and suggestions from the SAAG working group
+   were helpful and appreciated.
+
+Authors' Addresses
+
+   Dino Farinacci
+   lispers.net
+   San Jose, California  95120
+   United States of America
+
+   Phone: 408-718-2001
+   Email: farinacci@gmail.com
+
+
+   Brian Weis
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, California  95124-1706
+   United States of America
+
+   Phone: 408-526-4796
+   Email: bew@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci & Weis              Experimental                     [Page 18]
+