INTERNET-DRAFT Edward Lopez Intended Status: Experimental Fortinet Expires: July 7, 2014 January 3, 2014 Opportunistic Encryption for the Locator/ID Separation Protocol (LISP) draft-lopez-lisp-oe-01 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) IETF Trust and the persons identified as the Lopez, Farinacci Expires July 7, 2014 [Page 1] INTERNET DRAFT draft-lopez-lisp-oe-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 January 3, 2014 Ed Lopez Fortinet Sunnyvale, California USA Phone: 703-220-0988 Email: elopez@fortinet.com Lopez, Farinacci Expires July 7, 2014 [Page 11]