draft-ietf-lisp-crypto-09.txt   draft-ietf-lisp-crypto-10.txt 
Internet Engineering Task Force D. Farinacci Internet Engineering Task Force D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental B. Weis Intended status: Experimental B. Weis
Expires: April 15, 2017 cisco Systems Expires: April 17, 2017 cisco Systems
October 12, 2016 October 14, 2016
LISP Data-Plane Confidentiality LISP Data-Plane Confidentiality
draft-ietf-lisp-crypto-09 draft-ietf-lisp-crypto-10
Abstract Abstract
This document describes a mechanism for encrypting LISP encapsulated This document describes a mechanism for encrypting LISP encapsulated
traffic. The design describes how key exchange is achieved using traffic. The design describes how key exchange is achieved using
existing LISP control-plane mechanisms as well as how to secure the existing LISP control-plane mechanisms as well as how to secure the
LISP data-plane from third-party surveillance attacks. LISP data-plane from third-party surveillance attacks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 15, 2017. This Internet-Draft will expire on April 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4 5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4
6. Encoding and Transmitting Key Material . . . . . . . . . . . 5 6. Encoding and Transmitting Key Material . . . . . . . . . . . 5
7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 8 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 8
8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 10 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 10
9. Procedures for Encryption and Decryption . . . . . . . . . . 11 9. Procedures for Encryption and Decryption . . . . . . . . . . 11
10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 12 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 12
11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 13 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 13
12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 14 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 16 14.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 17 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 17
B.1. Changes to draft-ietf-lisp-crypto-09.txt . . . . . . . . 17 B.1. Changes to draft-ietf-lisp-crypto-10.txt . . . . . . . . 17
B.2. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 18 B.2. Changes to draft-ietf-lisp-crypto-09.txt . . . . . . . . 18
B.3. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 18 B.3. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 18
B.4. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 18 B.4. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 18
B.5. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 18 B.5. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 18
B.6. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 18 B.6. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 18
B.7. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 18 B.7. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 18
B.8. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 19 B.8. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 18
B.9. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 19 B.9. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 19
B.10. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 19 B.10. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 19
B.11. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 20 B.11. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 19
B.12. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 20 B.12. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 20
B.13. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 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 The Locator/ID Separation Protocol [RFC6830] defines a set of
functions for routers to exchange information used to map from non- functions for routers to exchange information used to map from non-
routable Endpoint Identifiers (EIDs) to routable Routing Locators routable Endpoint Identifiers (EIDs) to routable Routing Locators
(RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel (RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel
Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs)
and Reencapsulating Tunnel Routers (RTRs). Packets that arrive at and Reencapsulating Tunnel Routers (RTRs). Packets that arrive at
the ITR or PITR are typically not modified, which means no protection the ITR or PITR may not be encrypted, which means no protection or
or privacy of the data is added. If the source host encrypts the privacy of the data is added. When the source host encrypts the data
data stream then the encapsulated packets can be encrypted but would stream, encapsulated packets do not need to be encrypted by LISP.
be redundant. However, when plaintext packets are sent by hosts, However, when plaintext packets are sent by hosts, this design can
this design can encrypt the user payload to maintain privacy on the encrypt the user payload to maintain privacy on the path between the
path between the encapsulator (the ITR or PITR) to a decapsulator encapsulator (the ITR or PITR) to a decapsulator (ETR or RTR). The
(ETR or RTR). The encrypted payload is unidirectional. However, encrypted payload is unidirectional. However, return traffic uses
return traffic uses the same procedures but with different key values the same procedures but with different key values by the same xTRs or
by the same xTRs or potentially different xTRs when the paths between potentially different xTRs when the paths between LISP sites are
LISP sites are asymmetric. asymmetric.
This document has the following requirements (as well as the general This document has the following requirements (as well as the general
requirements from [RFC6973]) for the solution space: requirements from [RFC6973]) for the solution space:
o Do not require a separate Public Key Infrastructure (PKI) that is o Do not require a separate Public Key Infrastructure (PKI) that is
out of scope of the LISP control-plane architecture. out of scope of the LISP control-plane architecture.
o The budget for key exchange MUST be one round-trip time. That is, o The budget for key exchange MUST be one round-trip time. That is,
only a two packet exchange can occur. only a two packet exchange can occur.
skipping to change at page 3, line 34 skipping to change at page 3, line 40
o Provide for rekeying when secret keys are compromised. o Provide for rekeying when secret keys are compromised.
o Support Authenticated Encryption with packet integrity checks. o Support Authenticated Encryption with packet integrity checks.
o Support multiple cipher suites so new crypto algorithms can be o Support multiple cipher suites so new crypto algorithms can be
easily introduced. easily introduced.
Satisfying the above requirements provides the following benefits: Satisfying the above requirements provides the following benefits:
o Avoiding a PKI infrastructure reduces the operational cost of o Avoiding a PKI reduces the operational cost of managing a secure
managing a secure network. Key management is distributed and network. Key management is distributed and independent from any
independent from any other infrastructure. other infrastructure.
o Packet transport is optimized due to less packet headers. Packet o Packet transport is optimized due to less packet headers. Packet
loss is reduced by a more efficient key exchange. loss is reduced by a more efficient key exchange.
o Authentication and privacy are provided with a single mechanism o Authentication and privacy are provided with a single mechanism
thereby providing less per packet overhead and therefore more thereby providing less per packet overhead and therefore more
resource efficiency. resource efficiency.
2. Requirements Notation 2. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definition of Terms 3. Definition of Terms
AEAD: Authenticated Encryption with Additional Data. AEAD: Authenticated Encryption with Additional Data [RFC5116].
ICV: Integrity Check Value. ICV: Integrity Check Value.
LCAF: LISP Canonical Address Format ([LCAF]). LCAF: LISP Canonical Address Format ([LCAF]).
xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs. xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs.
4. Overview 4. Overview
The approach proposed in this document is to NOT rely on the LISP The approach proposed in this document is to NOT rely on the LISP
skipping to change at page 7, line 13 skipping to change at page 7, line 13
be transmitted as 0 and MUST be ignored on receipt. be transmitted as 0 and MUST be ignored on receipt.
Cipher Suite 0: Cipher Suite 0:
Reserved Reserved
Cipher Suite 1: Cipher Suite 1:
Diffie-Hellman Group: 2048-bit MODP [RFC3526] Diffie-Hellman Group: 2048-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256
IV length: 16 bytes IV length: 16 bytes
KDF: HMAC-SHA-256
Cipher Suite 2: Cipher Suite 2:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256
IV length: 16 bytes IV length: 16 bytes
KDF: HMAC-SHA-256
Cipher Suite 3: Cipher Suite 3:
Diffie-Hellman Group: 2048-bit MODP [RFC3526] Diffie-Hellman Group: 2048-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in GCM mode [RFC5116] Encryption: AES with 128-bit keys in GCM mode [RFC5116]
Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM
IV length: 12 bytes IV length: 12 bytes
KDF: HMAC-SHA-256
Cipher Suite 4: Cipher Suite 4:
Diffie-Hellman Group: 3072-bit MODP [RFC3526] Diffie-Hellman Group: 3072-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in GCM mode [RFC5116] Encryption: AES with 128-bit keys in GCM mode [RFC5116]
Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM
IV length: 12 bytes IV length: 12 bytes
KDF: HMAC-SHA-256
Cipher Suite 5: Cipher Suite 5:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in GCM mode [RFC5116] Encryption: AES with 128-bit keys in GCM mode [RFC5116]
Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM
IV length: 12 bytes IV length: 12 bytes
KDF: HMAC-SHA-256
Cipher Suite 6: Cipher Suite 6:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539]
Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305 Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305
IV length: 8 bytes IV length: 8 bytes
KDF: HMAC-SHA-256
The "Public Key Material" field contains the public key generated by The "Public Key Material" field contains the public key generated by
one of the Cipher Suites defined above. The length of the key in one of the Cipher Suites defined above. The length of the key in
octets is encoded in the "Key Length" field. octets is encoded in the "Key Length" field.
When an ITR, PITR, or RTR sends a Map-Request, they will encode their When an ITR, PITR, or RTR sends a Map-Request, they will encode their
own RLOC in the Security Type LCAF format within the ITR-RLOCs field. own RLOC in the Security Type LCAF format within the ITR-RLOCs field.
When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in
Security Type LCAF format within the RLOC-record field of each EID- Security Type LCAF format within the RLOC-record field of each EID-
record supplied. record supplied.
skipping to change at page 8, line 39 skipping to change at page 8, line 47
Request and copied into the Map-Reply. Request and copied into the Map-Reply.
The resulting shared secret is used to compute an AEAD-key for the The resulting shared secret is used to compute an AEAD-key for the
algorithms specified in the cipher suite. A Key Derivation Function algorithms specified in the cipher suite. A Key Derivation Function
(KDF) in counter mode as specified by [NIST-SP800-108] is used to (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 generate the data-plane keys. The amount of keying material that is
derived depends on the algorithms in the cipher suite. derived depends on the algorithms in the cipher suite.
The inputs to the KDF are as follows: The inputs to the KDF are as follows:
o KDF function. This is HMAC-SHA-256. 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 o A key for the KDF function. This is the computed Diffie-Hellman
shared secret. shared secret.
o Context that binds the use of the data-plane keys to this session. 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 The context is made up of the following fields, which are
concatenated and provided as the data to be acted upon by the KDF concatenated and provided as the data to be acted upon by the KDF
function. function.
Context: Context:
skipping to change at page 12, line 14 skipping to change at page 12, line 27
1. The outer IP header, UDP header, LISP header, and IV field are 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 stripped from the start of the packet. The LISP header and IV
are retained and given to the AEAD decryption operation as the are retained and given to the AEAD decryption operation as the
"associated data" argument. "associated data" argument.
2. The packet is decrypted using the AEAD-key and the IV from the 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 packet. The AEAD-key is obtained from a local-cache associated
with the key-id value from the LISP header. The result of the with the key-id value from the LISP header. The result of the
decryption function is a plaintext packet payload if the cipher decryption function is a plaintext packet payload if the cipher
returned a verified ICV. Otherwise, the packet has been tampered returned a verified ICV. Otherwise, the packet is invalid and is
with and is discarded. If the AEAD specification included an discarded. If the AEAD specification included an ICV, the AEAD
ICV, the AEAD decryption function will locate the ICV in the decryption function will locate the ICV in the ciphertext and
ciphertext and compare it to a version of the ICV that the AEAD compare it to a version of the ICV that the AEAD decryption
decryption function computes. If the computed ICV is different function computes. If the computed ICV is different than the ICV
than the ICV located in the ciphertext, then it will be located in the ciphertext, then it will be considered tampered.
considered tampered.
3. If the packet was not tampered with, the decrypted packet is 3. If the packet was not tampered with, the decrypted packet is
forwarded to the destination EID. forwarded to the destination EID.
10. Dynamic Rekeying 10. Dynamic Rekeying
Since multiple keys can be encoded in both control and data messages, 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 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 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 returns a Map-Reply, it should be prepared to decapsulate and decrypt
skipping to change at page 17, line 45 skipping to change at page 17, line 45
security expertise to make lisp-crypto as secure as the state of the security expertise to make lisp-crypto as secure as the state of the
art in cryptography. art in cryptography.
In addition, the support and suggestions from the SAAG working group In addition, the support and suggestions from the SAAG working group
were helpful and appreciative. were helpful and appreciative.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-crypto-09.txt B.1. Changes to draft-ietf-lisp-crypto-10.txt
o Posted October 2016 after October 13th telechat.
o Addressed comments from Kathleen Moriarty, Stephen Farrel, and
Pete Resnick.
B.2. Changes to draft-ietf-lisp-crypto-09.txt
o Posted October 2016. o Posted October 2016.
o Addressed comments from OPs Directorate reviewer Susan Hares. o Addressed comments from OPs Directorate reviewer Susan Hares.
B.2. Changes to draft-ietf-lisp-crypto-08.txt B.3. Changes to draft-ietf-lisp-crypto-08.txt
o Posted September 2016. o Posted September 2016.
o Addressed comments from Security Directorate reviewer Chris o Addressed comments from Security Directorate reviewer Chris
Lonvick. Lonvick.
B.3. Changes to draft-ietf-lisp-crypto-07.txt B.4. Changes to draft-ietf-lisp-crypto-07.txt
o Posted September 2016. o Posted September 2016.
o Addressed comments from Routing Directorate reviewer Danny o Addressed comments from Routing Directorate reviewer Danny
McPherson. McPherson.
B.4. Changes to draft-ietf-lisp-crypto-06.txt B.5. Changes to draft-ietf-lisp-crypto-06.txt
o Posted June 2016. o Posted June 2016.
o Fixed IDnits errors. o Fixed IDnits errors.
B.5. Changes to draft-ietf-lisp-crypto-05.txt B.6. Changes to draft-ietf-lisp-crypto-05.txt
o Posted June 2016. o Posted June 2016.
o Update document which reflects comments Luigi provided as document o Update document which reflects comments Luigi provided as document
shepherd. shepherd.
B.6. Changes to draft-ietf-lisp-crypto-04.txt B.7. Changes to draft-ietf-lisp-crypto-04.txt
o Posted May 2016. o Posted May 2016.
o Update document timer from expiration. o Update document timer from expiration.
B.7. Changes to draft-ietf-lisp-crypto-03.txt B.8. Changes to draft-ietf-lisp-crypto-03.txt
o Posted December 2015. o Posted December 2015.
o Changed cipher suite allocations. We now have 2 AES-CBC cipher o Changed cipher suite allocations. We now have 2 AES-CBC cipher
suites for compatibility, 3 AES-GCM cipher suites that are faster suites for compatibility, 3 AES-GCM cipher suites that are faster
ciphers that include AE and a Chacha20-Poly1305 cipher suite which ciphers that include AE and a Chacha20-Poly1305 cipher suite which
is the fastest but not totally proven/accepted.. is the fastest but not totally proven/accepted..
o Remove 1024-bit DH keys for key exchange. o Remove 1024-bit DH keys for key exchange.
skipping to change at page 19, line 25 skipping to change at page 19, line 30
endian). endian).
o Remove A-bit from Security Type LCAF. No need to do o Remove A-bit from Security Type LCAF. No need to do
authentication only with the introduction of AEAD ciphers. These authentication only with the introduction of AEAD ciphers. These
ciphers can do authentication. So you get ciphertext for free. ciphers can do authentication. So you get ciphertext for free.
o Remove language that refers to "encryption-key" and "integrity- o Remove language that refers to "encryption-key" and "integrity-
key". Used term "AEAD-key" that is used by the AEAD cipher suites key". Used term "AEAD-key" that is used by the AEAD cipher suites
that do encryption and authenticaiton internal to the cipher. that do encryption and authenticaiton internal to the cipher.
B.8. Changes to draft-ietf-lisp-crypto-02.txt B.9. Changes to draft-ietf-lisp-crypto-02.txt
o Posted September 2015. o Posted September 2015.
o Add cipher suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Elliptic Curve 25519 DH exchange.
o Add cipher suite for Chacha20/Poly1305 ciphers. o Add cipher suite for Chacha20/Poly1305 ciphers.
B.9. Changes to draft-ietf-lisp-crypto-01.txt B.10. Changes to draft-ietf-lisp-crypto-01.txt
o Posted May 2015. o Posted May 2015.
o Create cipher suites and encode them in the Security LCAF. o Create cipher suites and encode them in the Security LCAF.
o Add IV to beginning of packet header and ICV to end of packet. o Add IV to beginning of packet header and ICV to end of packet.
o AEAD procedures are now part of encrpytion process. o AEAD procedures are now part of encrpytion process.
B.10. Changes to draft-ietf-lisp-crypto-00.txt B.11. Changes to draft-ietf-lisp-crypto-00.txt
o Posted January 2015. o Posted January 2015.
o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto-
00. This draft has become a working group document 00. This draft has become a working group document
o Add text to indicate the working group may work on a new data o Add text to indicate the working group may work on a new data
encapsulation header format for data-plane encryption. encapsulation header format for data-plane encryption.
B.11. Changes to draft-farinacci-lisp-crypto-01.txt B.12. Changes to draft-farinacci-lisp-crypto-01.txt
o Posted July 2014. o Posted July 2014.
o Add Group-ID to the encoding format of Key Material in a Security o Add Group-ID to the encoding format of Key Material in a Security
Type LCAF and modify the IANA Considerations so this draft can use Type LCAF and modify the IANA Considerations so this draft can use
key exchange parameters from the IANA registry. key exchange parameters from the IANA registry.
o Indicate that the R-bit in the Security Type LCAF is not used by o Indicate that the R-bit in the Security Type LCAF is not used by
lisp-crypto. lisp-crypto.
skipping to change at page 20, line 31 skipping to change at page 20, line 37
process. process.
o Add text indicating that when RLOC-probing is used for RLOC o Add text indicating that when RLOC-probing is used for RLOC
reachability purposes and rekeying is not desired, that the same reachability purposes and rekeying is not desired, that the same
key exchange parameters should be used so a reallocation of a key exchange parameters should be used so a reallocation of a
pubic key does not happen at the ETR. pubic key does not happen at the ETR.
o Add text to indicate that ECDH can be used to reduce CPU o Add text to indicate that ECDH can be used to reduce CPU
requirements for computing shared secret-keys. requirements for computing shared secret-keys.
B.12. Changes to draft-farinacci-lisp-crypto-00.txt B.13. Changes to draft-farinacci-lisp-crypto-00.txt
o Initial draft posted February 2014. o Initial draft posted February 2014.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, California 95120 San Jose, California 95120
USA USA
 End of changes. 29 change blocks. 
55 lines changed or deleted 74 lines changed or added

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