draft-ietf-lisp-crypto-01.txt   draft-ietf-lisp-crypto-02.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: November 2, 2015 cisco Systems Expires: March 15, 2016 cisco Systems
May 1, 2015 September 12, 2015
LISP Data-Plane Confidentiality LISP Data-Plane Confidentiality
draft-ietf-lisp-crypto-01 draft-ietf-lisp-crypto-02
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 November 2, 2015. This Internet-Draft will expire on March 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3 3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3
4. Encoding and Transmitting Key Material . . . . . . . . . . . 4 4. Encoding and Transmitting Key Material . . . . . . . . . . . 4
5. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 6 5. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7
6. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 8 6. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 8
7. Procedures for Encryption and Decryption . . . . . . . . . . 10 7. Procedures for Encryption and Decryption . . . . . . . . . . 10
8. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 8. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11
9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 10.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12
10.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12 10.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 15
B.1. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 15 B.1. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 15
B.2. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 15 B.2. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 15
B.3. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 15 B.3. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 15
B.4. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 16 B.4. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 15
B.5. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 ITRs and PITRs encapsulate packets to ETRs and RTRs. (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs.
Packets that arrive at the ITR or PITR are typically not modified. Packets that arrive at the ITR or PITR are typically not modified.
Which means no protection or privacy of the data is added. If the Which means no protection or privacy of the data is added. If the
skipping to change at page 6, line 5 skipping to change at page 6, line 5
but is reserved for [LISP-DDT] security. but is reserved for [LISP-DDT] security.
When the A-bit is set, it indicates that Authentication only is When the A-bit is set, it indicates that Authentication only is
performed according to the Integrity hash function defined in the performed according to the Integrity hash function defined in the
Cipher Suites. That is an encapsulator will perform an Integrity Cipher Suites. That is an encapsulator will perform an Integrity
computation over an unencrypted packet and include an ICV value. computation over an unencrypted packet and include an ICV value.
Since the packet contains no ciphertext, there is no IV value Since the packet contains no ciphertext, there is no IV value
included in the message. The 7-bit 'Cipher Suite' field defines the included in the message. The 7-bit 'Cipher Suite' field defines the
following code-points: following code-points:
Cipher Suite 0: Cipher Suite 0:
Reserved Reserved
Cipher Suite 1: Cipher Suite 1:
Diffie-Hellman Group: 1024-bit Modular Exponential (MODP) [RFC2409] Diffie-Hellman Group: 1024-bit Modular Exponential (MODP) [RFC2409]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: HMAC-SHA1-96 [RFC2404] Integrity: HMAC-SHA1-96 [RFC2404]
Cipher Suite 2: Cipher Suite 2:
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: HMAC-SHA1-96 [RFC2404] Integrity: HMAC-SHA1-96 [RFC2404]
Cipher Suite 3: Cipher Suite 3:
Diffie-Hellman Group: 3072-bit MODP [RFC3526] Diffie-Hellman Group: 3072-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: HMAC-SHA1-96 [RFC2404] Integrity: HMAC-SHA1-96 [RFC2404]
Cipher Suite 4:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: HMAC-SHA1-96 [RFC2404]
Cipher Suite 5:
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: Chacha20 [CHACHA-POLY]
Integrity: Poly1305 [CHACHA-POLY] (i.e. AEAD_CHACHA20_POLY1305)
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 or PITR send a Map-Request, they will encode their own When an ITR or PITR send a Map-Request, they will encode their own
RLOC in the Security Type LCAF format within the ITR-RLOCs field. 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 10, line 16 skipping to change at page 10, line 16
When an ITR, PITR, or RTR encapsulate a packet and have already When an ITR, PITR, or RTR encapsulate a packet and have already
computed an encryption-key and integrity-key (detailed in section computed an encryption-key and integrity-key (detailed in section
Section 5) that is associated with a destination RLOC, the following Section 5) that is associated with a destination RLOC, the following
encryption and encapsulation procedures are performed: encryption and encapsulation procedures are performed:
1. The encapsulator creates a random number used as the IV. 1. The encapsulator creates a random number used as the IV.
Prepends the IV value to the packet being encapsulated. The IV Prepends the IV value to the packet being encapsulated. The IV
is incremented for every packet sent to the destination RLOC. is incremented for every packet sent to the destination RLOC.
2. Next encrypt with cipher function AES-CBC using the encryption- 2. Next encrypt with cipher function AES-CBC or CHACHA20 using the
key over the packet payload. This does not include the IV. The encryption-key over the packet payload. This does not include
IV must be transmitted as plaintext so the decrypter can use it the IV. The IV must be transmitted as plaintext so the decrypter
as input to the decryption cipher. The payload should be padded can use it as input to the decryption cipher. The payload should
to an integral number of bytes a block cipher may require. be padded to an integral number of bytes a block cipher may
require.
3. Prepend the LISP header. The key-id field of the LISP header is 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 set to the key-id value that corresponds to key-pair used for the
encryption cipher and for the ICV hash. encryption cipher and for the ICV hash.
4. Next compute the ICV value by hashing the packet (which includes 4. Next compute the ICV value by hashing the packet (which includes
the LISP header, the IV, and the packet payload) with the HMAC- the LISP header, the IV, and the packet payload) with the HMAC-
SHA1 function using the integrity-key. The resulting ICV value SHA1 or POLY1305 function using the integrity-key. The resulting
is appended to the packet. The ICV is not ciphertext so a fast ICV value is appended to the packet. The ICV is not ciphertext
integrity check can be performed without decryption at the so a fast integrity check can be performed without decryption at
receiver. the receiver.
5. Lastly, prepend the UDP header and outer IP header onto the 5. Lastly, prepend the UDP header and outer IP header onto the
encrypted packet and send packet to destination RLOC. encrypted packet and send packet to destination RLOC.
When an ETR, PETR, or RTR receive an encapsulated packet, the When an ETR, PETR, or RTR receive an encapsulated packet, the
following decapsulation and decryption procedures are performed: following decapsulation and decryption procedures are performed:
1. The outer IP header and UDP header are stripped from the start of 1. The outer IP header and UDP header are stripped from the start of
the packet and the ICV is stripped from the end of the packet. the packet and the ICV is stripped from the end of the packet.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
0: Reserved 0: Reserved
1-96: Allocated by registry, but first 3 values defined in this document 1-96: Allocated by registry, but first 3 values defined in this document
97-127: Private use 97-127: Private use
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<http://www.rfc-editor.org/info/rfc2409>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
2631, June 1999. 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) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, DOI 10.17487/RFC3526, May 2003,
<http://www.rfc-editor.org/info/rfc3526>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC (GCM) in IPsec Encapsulating Security Payload (ESP)",
4106, June 2005. RFC 4106, DOI 10.17487/RFC4106, June 2005,
<http://www.rfc-editor.org/info/rfc4106>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. 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 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. 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 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830,
2013. DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
12.2. Informative References 12.2. Informative References
[AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead-
aes-cbc-hmac-sha2-05.txt (work in progress). aes-cbc-hmac-sha2-05.txt (work in progress).
[CHACHA-POLY] [CHACHA-POLY]
Langley, A., "ChaCha20 and Poly1305 based Cipher Suites Langley, A., "ChaCha20 and Poly1305 based Cipher Suites
for TLS", draft-agl-tls-chacha20poly1305-00 (work in for TLS", draft-agl-tls-chacha20poly1305-00 (work in
progress). progress).
[CURVE25519]
Bernstein, D., "Curve25519: new Diffie-Hellman speed
records", Publication
http://www.iacr.org/cryptodb/archive/2006/
PKC/3351/3351.pdf.
[DH] "Diffie-Hellman key exchange", Wikipedia [DH] "Diffie-Hellman key exchange", Wikipedia
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-ietf-lisp-lcaf-04.txt (work in Address Format", draft-ietf-lisp-lcaf-04.txt (work in
progress). progress).
[LISP-DDT] [LISP-DDT]
Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-fuller-lisp-ddt-03 (work Delegated Database Tree", draft-fuller-lisp-ddt-03 (work
skipping to change at page 15, line 4 skipping to change at page 15, line 16
The author would like to thank Dan Harkins, Joel Halpern, Fabio The author would like to thank Dan Harkins, Joel Halpern, Fabio
Maino, Ed Lopez, Roger Jorgensen, Watson Ladd, and Ilari Liusvaara Maino, Ed Lopez, Roger Jorgensen, Watson Ladd, and Ilari Liusvaara
for their interest, suggestions, and discussions about LISP data- for their interest, suggestions, and discussions about LISP data-
plane security. plane security.
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
B.1. Changes to draft-ietf-lisp-crypto-01.txt
B.1. Changes to draft-ietf-lisp-crypto-02.txt
o Posted September 2015.
o Add cipher suite for Elliptic Curve 25519 DH exchange.
o Add cipher suite for Chacha20/Poly1305 ciphers.
B.2. 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.2. Changes to draft-ietf-lisp-crypto-00.txt B.3. 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.3. Changes to draft-farinacci-lisp-crypto-01.txt B.4. 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 16, line 5 skipping to change at page 16, line 23
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.4. Changes to draft-farinacci-lisp-crypto-00.txt B.5. 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. 24 change blocks. 
49 lines changed or deleted 86 lines changed or added

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