draft-ietf-lisp-crypto-08.txt   draft-ietf-lisp-crypto-09.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: March 29, 2017 cisco Systems Expires: April 15, 2017 cisco Systems
September 25, 2016 October 12, 2016
LISP Data-Plane Confidentiality LISP Data-Plane Confidentiality
draft-ietf-lisp-crypto-08 draft-ietf-lisp-crypto-09
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 March 29, 2017. This Internet-Draft will expire on April 15, 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 . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . 7 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 8
8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 9 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 10
9. Procedures for Encryption and Decryption . . . . . . . . . . 10 9. Procedures for Encryption and Decryption . . . . . . . . . . 11
10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 12
11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 13
12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 13 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 17
B.1. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 16 B.1. Changes to draft-ietf-lisp-crypto-09.txt . . . . . . . . 17
B.2. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 17 B.2. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 18
B.3. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 17 B.3. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 18
B.4. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 17 B.4. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 18
B.5. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 17 B.5. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 18
B.6. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 17 B.6. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 18
B.7. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 18 B.7. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 18
B.8. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 18 B.8. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 19
B.9. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 18 B.9. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 19
B.10. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 18 B.10. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 19
B.11. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 19 B.11. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 B.12. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
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 are typically not modified, which means no protection
skipping to change at page 3, line 31 skipping to change at page 3, line 32
o Avoid a third-party trust anchor if possible. o Avoid a third-party trust anchor if possible.
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:
o Avoiding a PKI infrastructure 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 less 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 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.
skipping to change at page 9, line 46 skipping to change at page 10, line 46
of the secret keys computed during the Diffie-Hellman Map-Request/ of the secret keys computed during the Diffie-Hellman Map-Request/
Map-Reply exchange. When the KK bits are not 0, the payload is Map-Reply exchange. When the KK bits are not 0, the payload is
prepended with an Initialization Vector (IV). The length of the IV prepended with an Initialization Vector (IV). The length of the IV
field is based on the cipher suite used. Since all cipher suites field is based on the cipher suite used. Since all cipher suites
defined in this document do Authenticated Encryption (AEAD), an ICV defined in this document do Authenticated Encryption (AEAD), an ICV
field does not need to be present in the packet since it is included 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 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 shown above and includes the LISP header, the IV field and the packet
payload. payload.
When an ITR or PITR receives a packet to be encapsulated, they will When an ITR or PITR receives a packet to be encapsulated, the device
first decide what key to use, encode the key-id into the LISP header, will first decide what key to use, encode the key-id into the LISP
and use that key to encrypt all packet data that follows the LISP header, and use that key to encrypt all packet data that follows the
header. Therefore, the outer header, UDP header, and LISP header LISP header. Therefore, the outer header, UDP header, and LISP
travel as plaintext. header travel as plaintext.
There is an open working group item to discuss if the data There is an open working group item to discuss if the data
encapsulation header needs change for encryption or any new encapsulation header needs change for encryption or any new
applications. This document proposes changes to the existing header applications. This document proposes changes to the existing header
so experimentation can continue without making large changes to the so experimentation can continue without making large changes to the
data-plane at this time. This document allocates 2 bits of the data-plane at this time. This document allocates 2 bits of the
previously unused 3 flag bits (note the R-bit above is still a previously unused 3 flag bits (note the R-bit above is still a
reserved flag bit as documented in [RFC6830]) for the KK bits. reserved flag bit as documented in [RFC6830]) for the KK bits.
9. Procedures for Encryption and Decryption 9. Procedures for Encryption and Decryption
skipping to change at page 16, 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-08.txt B.1. Changes to draft-ietf-lisp-crypto-09.txt
o Posted October 2016.
o Addressed comments from OPs Directorate reviewer Susan Hares.
B.2. 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.2. Changes to draft-ietf-lisp-crypto-07.txt B.3. 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.3. Changes to draft-ietf-lisp-crypto-06.txt B.4. 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.4. Changes to draft-ietf-lisp-crypto-05.txt B.5. 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.5. Changes to draft-ietf-lisp-crypto-04.txt B.6. 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.6. Changes to draft-ietf-lisp-crypto-03.txt B.7. 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 18, line 16 skipping to change at page 19, line 25
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.7. Changes to draft-ietf-lisp-crypto-02.txt B.8. 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.8. Changes to draft-ietf-lisp-crypto-01.txt B.9. 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.9. Changes to draft-ietf-lisp-crypto-00.txt B.10. 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.10. Changes to draft-farinacci-lisp-crypto-01.txt B.11. 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 19, line 23 skipping to change at page 20, line 31
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.11. Changes to draft-farinacci-lisp-crypto-00.txt B.12. 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. 18 change blocks. 
48 lines changed or deleted 68 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/