First off, I apologize to all for my absence on the mailing list, particularly
Dino. My company is relatively new to IETF WG participation, and there were
some backend discussions I had to have back at corporate to ensure that I was
both in compliance with the IETF Note Well, as well as my company’s internal IP
processes. This has been resolved, and I will be resuming active participation
on the list.
At the time, I was working with Dino on crypto solutions for LISP. Enclosed in
my draft regarding opportunistic encryption for LISP. While there are
significant similarities with regard to the goals of one exchange of key
material, non-reliance on PKI, nor storing keys on the mapping system, I
proposed the use of IPSec ESP in transport mode for the actual encryption of
packets between xTRs, as opposed to developing support for encryption within
the LISP protocol itself. I feel this has significant advantages toward ease
of deployment and hardware acceleration, as well as support for multiple
available encryption/hash algorithms.
The use of the security type (11) LCAF is very similar, except I propose that
the Key Algorithm field be used to support encryption/hash algorithm sets,
rather than individual algorithms. In this way, we can use Key Count values to
signify ITF preferences.
Another significant different is that this draft makes use of the R-bit to
signal when Keys should be revoked, and can be used locally by xTRs to signal
expiry conditions such as lifetime, peer detection failure, etc.
Thanks!
Ed Lopez
*** Please note that this message and any attachments may contain confidential
and proprietary material and information and are intended only for the use of
the intended recipient(s). If you are not the intended recipient, you are hereby
notified that any review, use, disclosure, dissemination, distribution or
copying
of this message and any attachments is strictly prohibited. If you have received
this email in error, please immediately notify the sender and destroy this
e-mail
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed
in this message are those of the individual sender and do not necessarily
reflect
the views of Fortinet, Inc., its affiliates, and emails are not binding on
Fortinet and only a writing manually signed by Fortinet's General Counsel can be
a binding commitment of Fortinet to Fortinet's customers or partners. Thank
you. ***
INTERNET-DRAFT Edward Lopez
Intended Status: Experimental Fortinet
Dino Farinacci
lispers.net
Expires: July 7, 2014 January 3, 2014
Opportunistic Encryption for the Locator/ID Separation Protocol (LISP)
draft-lopez-lisp-oe-00
Abstract
The Locator/ID Separation Protocol (LISP), allows the creation of
VPNs between routing locators (RLOCs). As LISP encapsulated packets
are generally expected to traverse publically routed spaces, it is
desirable to encrypt the payloads of these packets, to protect them
from pervasive surveillance attacks. This document describes a
methodology to encrypt LISP encapsulated packets, as they traverse
between RLOCs.
For a full description of LISP, please consult [RFC6830].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) <year> IETF Trust and the persons identified as the
Lopez, Farinacci Expires July 7, 2014 [Page 1]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
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 . . . . . . . . . . . . . . . . . . . . . 3
3 Opportunistic Encryption in LISP . . . . . . . . . . . . . . . 4
3.1 Key Exchange Between RLOCs . . . . . . . . . . . . . . . . 4
3.1.1 Key Count . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 R-Bit . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 Key Material . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Encryption of LISP Encapsulated Packets . . . . . . . . . . 8
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 10
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Lopez, Farinacci Expires July 7, 2014 [Page 2]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
1 Introduction
Opportunistic encryption has been widely discussed as a methodology
to mitigate pervasive surveillance attacks against protocols. The
brief definition of opportunistic encryption is the ability to apply
strong encryption with a protocol to protect personally identifiable
data from being readable in cleartext, where the encryption is
independent of other external protocols, and does not place an
excessive burden on the protocol to which opportunistic encryption is
applied. In the case of LISP, which is an encapsulating protocol,
this means that opportunistic encryption does not rely on the packets
undergoing encapsulation to be previously encrypted. In short,
opportunistic encryption within LISP is an additional step performed
by LISP when encapsulating packets.
However, it is also understood that while protocols such as LISP may
include opportunistic encryption, that the encryption mechanisms
applied should utilize available standards in encryption algorithms,
hashing algorithms, authentication methods, and key exchange methods,
whenever possible. The reason for this is to allow the broadest
opportunity for implementation relative to common and tested
software, hardware acceleration, and interoperability between
implementations.
In the case of LISP, the encryption/hash algorithms and methodology
is intended to be consistent with the IETF standard for Encapsulating
Security Payload [RFC 4303], when performing in Transport Mode
Processing (Section 3.1.1), which does not result in a double
encapsulation of the original packet. The methodology of key
exchange will be integrated within the LISP Map Server/Map Resolver
functionality, so as to seamlessly perform requires key exchanges as
part of the standard LISP mapping functions. The intended result is
that the payload of LISP encapsulated packets, which are UDP packets,
will be encrypted as the packet traverses between LISP Tunneling
Routers (xTRs).
It is important to note that as opportunistic encryption methods are
being integrated into existing LISP functionality, this document does
not obsolete or supercede any current RFCs associated with affected
LISP functionality. It is the solely the burden of the methods
described within this document to ensure interoperability with
devices supporting LISP without opportunistic encryption.
2 Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Lopez, Farinacci Expires July 7, 2014 [Page 3]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3 Opportunistic Encryption in LISP
It is important to understand that the purpose of opportunistic
encryption is to protect data from pervasive surveillance attacks.
However, this does not necessarily means that it adds to the security
or integrity of the data being shielded. This may seem to be an
unusual concept. Another way to state this is that opportunistic
encryption for LISP packets (LISP-OE) is anonymous between xTRs. No
effort is used to authenticate the identity of the xTRs beyond a
willingness to participate with the key exchange and packet
encryption process. Communication is shielded by the opportunistic
encryption from external third-parties, but no additional security is
added to the integrity of communications between xTRs themselves.
The methodology for this opportunistic encryption is straightforward.
The two xTRs involved with perform a basic Diffie-Hellman key
enchange [RFC2631], transmitting the key-material within the Map-
Request and Map-Reply messages. Each of the two xTRs will then
generate a shared secret key, which will be used as a manual
encryption key for an IPSec Encapsulating Security Payload (ESP)
encryption, operating in Transport-mode of operation.
There are a number of advantages in using IPSec ESP for opportunistic
encryption of LISP packets. IPSec ESP is a well established
encrypting protocol, which has been well commoditized and accelerated
via silicon (ASICs, FPGAs, specialty processors, etc). This means
that the deployment of LISP-OE can benefit from wide adoption with
high-performance implementations. The nature of IPSec ESP allows for
support for multiple encryption and hash schemes. Finally, the
resulting packets are not outwardly detected as LISP packets by
third-parties, nor by LISP xTRs not participating within LISP-OE.
This is an important concern regarding interoperability between xTRs
supporting LISP-OE, and those that do not.
3.1 Key Exchange Between RLOCs
As noted, the key exchange will make use of Map-Request and Map-Reply
messages between xTRs to transmit key material between each other.
It is important for the operation of LISP that this exchange be
performed within a single exchange between xTRs, in order to mitigate
the potential for packet loss due to delay in establishing LISP-OE.
As noted, the LISP mapping system will not store or distribute any
additional identity information, such as PKI certificates or pre-
Lopez, Farinacci Expires July 7, 2014 [Page 4]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
shared keys, for the purpose of authenticating LISP-OE speakers. The
nature of LISP-OE is to be anonymous, which also helps to limit the
key exchange to a single packet exchange. However, it is possible to
consider the use of a black/white list or similar ACL type schema in
which limits which other xTRs a given xTR can communicate with via
LISP-OE.
The Map-Request and Map-Reply messages will use the LISP security
type LCAF to encode the key material within the messages.
Security Key Canonical Address Format:
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that start with the Key
Material field.
Key Count: the Key Count field declares the number of Key sections
included in this LCAF.
Key Algorithm: the Algorithm field identifies the key's
cryptographic algorithm and specifies the format of the Public Key
field.
R bit: this is the revoke bit and, if set, it specifies that this
Key is being Revoked.
Key Length: this field determines the length in bytes of the Key
Material field.
Key Material: the Key Material field stores the key material. The
format of the key material stored depends on the Key Algorithm field.
AFI = x: x can be any AFI value from [AFI].This is the locator
Lopez, Farinacci Expires July 7, 2014 [Page 5]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
address that owns the encoded security key.
Details on how each of these fields are used for LISP-OE follow in
subsequent sub-sections
3.1.1 Key Count
While Key Count is an 8-bit field, LISP-OE supports a maximum of two
Key sections within this LCAF. Each of these Key sections represents
a unique encryption/hash set proposal for performing LISP-OE.
The first Key section represents the preferred encryption/hash set
proposal for use with LISP-OE, and the second optional Key section
represents an alternative proposal, if the first is not supported.
The receiving xTR may support any or both proposals, but should only
respond to the Key section which will be used. Should the receiving
xTR respond to both proposals, the initiating xTRs preference will be
used
3.1.2 Key Algorithm As the underlying encryption for LISP-OE will make
use of IPSec ESP, it is important that the message exchange reflect
the encryption and hash algorithm sets which can be supported. These
proposals should be expressed within the 8 bits of this field, with
the first 4 bits supporting the encryption algorithm, and the last 4
bits supporting the hash algorithm. This will allow up to 16 of each
type (encryption/hash) to be supported
Encryption Values
-----------
0000 = Null
0001 = DES
0010 = 3DES
0011 = AES
0100-1100 = Reserved for future use
1101-1111 = Reserved for private use
Hash Values
Lopez, Farinacci Expires July 7, 2014 [Page 6]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
-----------
0000 = Null
0001 = MD5
0010 = SHA1
0011 = SHA256
0100 = SHA384
0101 = SHA512
0110-1100 = Reserved for future use
1101-1111 = Reserved for private use
For example, a Key Algorithm Value of 51, or binary 00110011 would
represent a proposal for an AES/SHA256 encryption/hash set.
While LISP-OE makes use of IPSec-ESP with a manual key, it is
important that the algorithm proposals made in these Key sections are
supportable by the the host. There is no mechanism proposed within
this draft to synchronize these Key section proposals with the host's
IPSec ESP configuration
Three values each for encryption and hash, 1101-1111 within their
respective four bits, is reserved for private use. This allows for
the support of LISP-OE with non standard algorithms.
3.1.3 R-Bit The R-bit when set represents the revocation of an existing
Key. Relative to LISP-OE, and xTR can revoke a Key for any reason,
but most likely based on exceeding a locally configured lifetime
value. It is important to note the xTRs participating in LISP-OE do
not negotiate Key lifetimes, but instead can revoke a Key based on
locally configured conditions.
3.1.4 Key Material
As previously noted, the goal for LISP-OE's use of the Security Type
LCAF is to establish an IPSec ESP security association (SA), with a
single packet exchange between xTRs. This means that the Key
Material field must include sufficient information to perform the
following:
Lopez, Farinacci Expires July 7, 2014 [Page 7]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
- Creation of a Security Parameters Index (SPI) to be used by the
IPSec ESP SA- Initial sequence number calculation, including use of
64-bit extended sequence number- The actual exchange of key material
required by the encryption/hash algorithm set proposed in the Key
Algorithm field- Determine in NAT traversal (NAT-T) is to be used in
associated with the resulting SA
Following the exchange of this information within the Key Material
field, the xTRs can then individually establish an IPSec ESP SA,
based on their local configurations.
3.2 Encryption of LISP Encapsulated Packets
Once the key exchange is complete between a pair of xTRs, each xTR
will use its key material as the manual key configuration to be used
within an IPSec ESP SA. The operation of IPSec ESP is covered by
[RFC4303]. This section describes how LISP-OE uses IPSec ESP to
perform opportunistic encryption of LISP packets.
The IPSec ESP will be performed using IPSec ESP in transport mode,
based on section 3.1.1 of [RFC4303]. As LISP already encapsulates
the original IP traffic between source and destination EIDs, with the
outer LISP header using the source ITR and destination ETR IP
addresses, it would be needlessly redundant to make use of tunnel
mode operation. LISP-OE assumes the use of transport mode for IPSec
ESP operations.
Optionally, NAT traversal (NAT-T) may be supported if one or both
xTRs participating in LISP-OE resides behind a NAT boundary. An
example of this may be in the use of carrier-grade NAT (CGN) between
RLOCs
The following diagrams provide an overview of how a LISP packet would
be transformed using LISP-OE. LISP-OE can support both IPv4 and
IPv6, and additional IPv6 header information is assumed to follow the
Original LISP IP Header, as well as within the LISP Payload
Original LISP Data Packet
-----------------------------------
|Original LISP| UDP/4341 | LISP |
| IP Header |(LISP Data)|Payload|
-----------------------------------
Resulting LISP-OE Packet w/ LISP Data
Lopez, Farinacci Expires July 7, 2014 [Page 8]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
------------------------------------------------------
|Original LISP| ESP | UDP/4341 | LISP | ESP |ESP|
| IP Header |Header|(LISP Data)|Payload|Trailer|ICV|
------------------------------------------------------
|<- - - - - encryption - - - ->|
|<- - - - - - - integrity - - - - - ->|
Resulting LISP-OE Packet using NAT-T w/ LISP Data
---------------------------------------------------------------
|Original LISP|UDP/4500| ESP | UDP/4341 | LISP | ESP |ESP|
| IP Header |(NAT-T) |Header|(LISP Data)|Payload|Trailer|ICV|
---------------------------------------------------------------
|<- - - - - encryption - - - ->|
|<- - - - - - - integrity - - - - - ->|
4 Security Considerations
It is anticipated that any security review of LISP-OE will find that
the overall security of LISP-OE is relatively weak. There is no
mechanism to authenticate or otherwise verify the integrity of the
xTRs performing LISP-OE. The key exchange methodology offers no
explicit protection of the key material. Also, the operation of
IPSec ESP on an encryption-only mode relies heavily on local
configuration rather than mutually defined policies (such as key/SA
lifetime).
However, it is important to note that the principal purpose of LISP-
OE is to provide protection for LISP encapsulated packets to third-
party pervasive surveillance, and not to provide additional security
between the participating xTRs themselves.
The exchange of key material is performed using Map-Request/Map-Reply
messages in the LISP control plane. As this communication is on a
separate path from LISP data plane communications, it can be
protected by the use of internal protocols such as IPSec between the
xTR and the LISP Mapping Server/Resolver
Of critical requirement is for LISP-OE to establish this protection
with a minimal number of additional packet exchanges (in this case
one), to prevent excessive packet drops while the opportunistic
encryption is being established.
The use of IPSec ESP as the means for LISP-OE to perform
opportunistic encryption is intended to prevent the need to support a
wholly separate encryption methodology, while taking advantage of
Lopez, Farinacci Expires July 7, 2014 [Page 9]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
proven and commercially available implementations of IPSec. This
draft predominantly focuses on the use of LISP mapping messages as a
means to exchange key-material, as an efficient alternative to other
exchange mechanisms such as Internet Key Exchange (IKE).
As previously noted within this document's Introduction, as
opportunistic encryption methods are being integrated into existing
LISP functionality, this document does not obsolete or supercede any
current RFCs associated with the associated LISP functionality. It
is the solely the burden of the methods described within this
document to ensure interoperability with devices supporting LISP
without opportunistic encryption.
5 IANA Considerations
Implementation of the methodologies described by this document does
not incur additional IANA considerations
6 References
6.1 Normative References
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013.
6.2 Informative References
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-ietf-lisp-lcaf-04.txt.
7 Authors' Addresses
Lopez, Farinacci Expires July 7, 2014 [Page 10]
INTERNET DRAFT draft-lopez-lisp-oe-00 January 3, 2014
Ed Lopez
Fortinet
Sunnyvale, California
USA
Phone: 703-220-0988
Email: [email protected]
Dino Farinacci
lispers.net
San Jose, California
USA
Phone: 408-718-2001
Email: [email protected]
Lopez, Farinacci Expires July 7, 2014 [Page 11]
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
