Internet Engineering Task Force D. Farinacci
Internet-Draft lispers.net
Intended status: Experimental February 14, 2014
Expires: August 18, 2014
LISP Data-Plane Confidentiality
draft-farinacci-lisp-crypto-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 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.
Farinacci Expires August 18, 2014 [Page 1]
Internet-Draft LISP Data-Plane Confidentiality February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 5
4. Encoding and Transmitting Key Material . . . . . . . . . . . . 6
5. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . . 8
6. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . . 9
7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 15
B.1. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Farinacci Expires August 18, 2014 [Page 2]
Internet-Draft LISP Data-Plane Confidentiality February 2014
1. Introduction
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 ITRs and PITRs encapsulate packets to ETRs and RTRs.
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
source host encrypts the data stream then the encapsulated packets
can be encrypted but would be redundant. 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).
This draft has the following requirements 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 At this time, encapsulated packet authentication is not a strong
requirement.
Farinacci Expires August 18, 2014 [Page 3]
Internet-Draft LISP Data-Plane Confidentiality February 2014
2. Overview
The approach proposed in this draft is to not rely on the LISP
mapping 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 3 shared-secrets per ETR the ITR is encapsulating
to. And 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 rekeying
functionality.
Farinacci Expires August 18, 2014 [Page 4]
Internet-Draft LISP Data-Plane Confidentiality February 2014
3. 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 in Map-Request and Map-Reply messages.
Here is a brief description how Diff-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'.
Farinacci Expires August 18, 2014 [Page 5]
Internet-Draft LISP Data-Plane Confidentiality February 2014
4. 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 Type LCAF [LCAF].
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 | Key Algorithm | Rsvd4 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Length | Key Material ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Key Material |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Diffie-Hellman parameters encoded in Key Material field
The 'Key Count' field encodes the number of {'Key-Length', 'Key-
Material'} fields included in the encoded LCAF. A maximum number of
keys that can be encoded are 3 keys, each identified by key-id 1,
followed by key-id 2, an finally key-id 3.
The 'Key Algorithm' encodes the cryptographic algorithm used. The
following values are defined:
Null: 0
AES: 1
3DES: 2
SHA-256: 3
The 'Key Material' field is encoded as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g-length | g-value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| p-length | p-value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Length describes the length of the Key Material field
Farinacci Expires August 18, 2014 [Page 6]
Internet-Draft LISP Data-Plane Confidentiality February 2014
When an ITR or PITR sends a Map-Request, they will encode their own
RLOC in Security Type LCAF format within the ITR-RLOCs field. 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-
record supplied.
If an ITR or PITR sends a Map-Request with a Security Type LCAF
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 Type LCAF. This signals to the ITR or PITR
that it should not encrypt traffic (it cannot encrypt traffic anyways
since no ETR public-key was returned).
Farinacci Expires August 18, 2014 [Page 7]
Internet-Draft LISP Data-Plane Confidentiality February 2014
5. Data-Plane Operation
The LISP encapsulation header [RFC6830] requires changes to encode
the key-id for the key being used for encryption.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|P|K|K| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K-bits indicate when packet is encrypted and which key used
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 an ITR or PITR receives a packet to be encapsulated, they 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.
Farinacci Expires August 18, 2014 [Page 8]
Internet-Draft LISP Data-Plane Confidentiality February 2014
6. 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. 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.
RLOC-probing can be used to change keys by the ITR at any time. And
when an initial Map-Request is sent to populate the ITR's map-cache,
the Map-Requests 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 key negotiate 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 p,
g, or the public-key in a Map-Request. The ETR or RTR compares the
p, g, 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 of its own
with the new p and g values 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 p and g values it
expects (the values it sent in a Map-Request).
Farinacci Expires August 18, 2014 [Page 9]
Internet-Draft LISP Data-Plane Confidentiality February 2014
7. Future Work
By using AES-GCM [RFC5116], or HMAC-CBC [AES-CBC], it has been
suggested that encapsulated packet authentication (through encryption
[RFC4106]) could be supported. There is current work in progress to
investigate these techniques for the LISP data-plane. However, it
will require encapsulation header changes to LISP.
Farinacci Expires August 18, 2014 [Page 10]
Internet-Draft LISP Data-Plane Confidentiality February 2014
8. Security Considerations
The LISP working group will seek help from the SAAG working group for
security advice. The SAAG will be involved early in the design
process so they have early input and review.
Farinacci Expires August 18, 2014 [Page 11]
Internet-Draft LISP Data-Plane Confidentiality February 2014
9. IANA Considerations
This draft requires no considerations from IANA.
Farinacci Expires August 18, 2014 [Page 12]
Internet-Draft LISP Data-Plane Confidentiality February 2014
10. References
10.1. Normative References
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
10.2. Informative References
[AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA",
draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt (work in
progress).
[DH] "Diffie-Hellman key exchange", Wikipedia http://
en.wikipedia.org/wiki/Diffie-Hellman_key_exchange.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-ietf-lisp-lcaf-04.txt (work in
progress).
Farinacci Expires August 18, 2014 [Page 13]
Internet-Draft LISP Data-Plane Confidentiality February 2014
Appendix A. Acknowledgments
The author would like to thank Dan Harkins, Brian Weis, Joel Halpern,
Fabio Maino, Ed Lopez, and Roger Jorgensen for their interest,
suggestions, and discussions about LISP data-plane security.
In addition, the support and suggestions from the SAAG working group
were helpful and appreciative.
Farinacci Expires August 18, 2014 [Page 14]
Internet-Draft LISP Data-Plane Confidentiality February 2014
Appendix B. Document Change Log
B.1. Changes to draft-farinacci-lisp-crypto-00.txt
o Initial draft posted February 2014.
Farinacci Expires August 18, 2014 [Page 15]
Internet-Draft LISP Data-Plane Confidentiality February 2014
Author's Address
Dino Farinacci
lispers.net
San Jose, California
USA
Phone: 408-718-2001
Email: farinacci@gmail.com
Farinacci Expires August 18, 2014 [Page 16]