Framework for Ethernet VPN Designated Forwarder Election Extensibility
RFC 8584
| Document | Type |
RFC
- Proposed Standard
(April 2019)
Errata
Updates RFC 7432
|
|
|---|---|---|---|
| Authors | Jorge Rabadan , Satya Mohanty , Ali Sajassi , John Drake , Kiran Nagaraj , Senthil Sathappan | ||
| Last updated | 2019-11-12 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Martin Vigoureux | |
| Send notices to | (None) |
RFC 8584
Internet Engineering Task Force (IETF) A. Doherty
Request for Comments: 6063 RSA, The Security Division of EMC
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign, Inc.
S. Machani
Diversinet Corp.
M. Nystrom
Microsoft Corp.
December 2010
Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Abstract
The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-
server protocol for initialization (and configuration) of symmetric
keys to locally and remotely accessible cryptographic modules. The
protocol can be run with or without private key capabilities in the
cryptographic modules and with or without an established public key
infrastructure.
Two variations of the protocol support multiple usage scenarios.
With the four-pass variant, keys are mutually generated by the
provisioning server and cryptographic module; provisioned keys are
not transferred over-the-wire or over-the-air. The two-pass variant
enables secure and efficient download and installation of pre-
generated symmetric keys to a cryptographic module.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6063.
Doherty, et al. Standards Track [Page 1]
RFC 6063 DSKPP December 2010
Copyright Notice
Copyright (c) 2010 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Doherty, et al. Standards Track [Page 2]
RFC 6063 DSKPP December 2010
Table of Contents
1. Introduction ....................................................6
1.1. Key Words ..................................................6
1.2. Version Support ............................................6
1.3. Namespace Identifiers ......................................7
1.3.1. Defined Identifiers .................................7
1.3.2. Identifiers Defined in Related Specifications .......7
1.3.3. Referenced Identifiers ..............................8
2. Terminology .....................................................8
2.1. Definitions ................................................8
2.2. Notation ..................................................10
2.3. Abbreviations .............................................11
3. DSKPP Overview .................................................11
3.1. Protocol Entities .........................................12
3.2. Basic DSKPP Exchange ......................................12
3.2.1. User Authentication ................................12
3.2.2. Protocol Initiated by the DSKPP Client .............14
3.2.3. Protocol Triggered by the DSKPP Server .............16
3.2.4. Variants ...........................................17
3.2.4.1. Criteria for Using the Four-Pass Variant ..17
3.2.4.2. Criteria for Using the Two-Pass Variant ...18
3.3. Status Codes ..............................................18
3.4. Basic Constructs ..........................................20
3.4.1. User Authentication Data (AD) ......................20
3.4.1.1. Authentication Code Format ................20
3.4.1.2. User Authentication Data Calculation ......23
3.4.2. The DSKPP One-Way Pseudorandom Function,
DSKPP-PRF ..........................................24
3.4.3. The DSKPP Message Hash Algorithm ...................24
4. Four-Pass Protocol Usage .......................................25
4.1. The Key Agreement Mechanism ...............................25
4.1.1. Data Flow ..........................................25
4.1.2. Computation ........................................27
4.2. Message Flow ..............................................28
4.2.1. KeyProvTrigger .....................................28
4.2.2. KeyProvClientHello .................................29
4.2.3. KeyProvServerHello .................................30
4.2.4. KeyProvClientNonce .................................32
4.2.5. KeyProvServerFinished ..............................34
5. Two-Pass Protocol Usage ........................................35
5.1. Key Protection Methods ....................................36
5.1.1. Key Transport ......................................36
5.1.2. Key Wrap ...........................................37
5.1.3. Passphrase-Based Key Wrap ..........................37
5.2. Message Flow ..............................................38
5.2.1. KeyProvTrigger .....................................38
5.2.2. KeyProvClientHello .................................39
Doherty, et al. Standards Track [Page 3]
RFC 6063 DSKPP December 2010
Rabadan, et al. Standards Track [Page 17]
RFC 8584 DF Election Framework for EVPN Services April 2019
The DF Election Extended Community is used as follows:
o A PE SHOULD attach the DF Election Extended Community to any
advertised ES route, and the Extended Community MUST be sent if
the ES is locally configured with a DF election algorithm other
than the default DF election algorithm or if a capability is
required to be used. In the Extended Community, the PE indicates
the desired "DF Alg" algorithm and "Bitmap" capabilities to be
used for the ES.
- Only one DF Election Extended Community can be sent along with
an ES route. Note that the intent is not for the advertising
PE to indicate all the supported DF election algorithms and
capabilities but to signal the preferred one.
- DF Alg values 0 and 1 can both be used with Bit 1 (AC-DF) set
to 0 or 1.
- In general, a specific DF Alg SHOULD determine the use of the
reserved bits in the Extended Community, which may be used in a
different way for a different DF Alg. In particular, for DF
Alg values 0 and 1, the reserved bits are not set by the
advertising PE and SHOULD be ignored by the receiving PE.
o When a PE receives the ES routes from all the other PEs for the ES
in question, it checks to see if all the advertisements have the
Extended Community with the same DF Alg and Bitmap:
- If they do, this particular PE MUST follow the procedures for
the advertised DF Alg and capabilities. For instance, if all
ES routes for a given ES indicate DF Alg HRW and AC-DF set
to 1, then the PEs attached to the ES will perform the DF
election as per the HRW algorithm and following the AC-DF
procedures.
- Otherwise, if even a single advertisement for Route Type 4 is
received without the locally configured DF Alg and capability,
the default DF election algorithm MUST be used as prescribed in
[RFC7432]. This procedure handles the case where participating
PEs in the ES disagree about the DF algorithm and capability to
be applied.
- The absence of the DF Election Extended Community or the
presence of multiple DF Election Extended Communities (in the
same route) MUST be interpreted by a receiving PE as an
indication of the default DF election algorithm on the sending
PE -- that is, DF Alg 0 and no DF election capabilities.
Rabadan, et al. Standards Track [Page 18]
RFC 8584 DF Election Framework for EVPN Services April 2019
o When all the PEs in an ES advertise DF Type 31, they will rely on
the local policy to decide how to proceed with the DF election.
o For any new capability defined in the future, the applicability/
compatibility of this new capability to/with the existing DF Alg
values must be assessed on a case-by-case basis.
o Likewise, for any new DF Alg defined in the future, its
applicability/compatibility to/with the existing capabilities must
be assessed on a case-by-case basis.
2.2.1. Backward Compatibility
Implementations that comply with [RFC7432] only (i.e.,
implementations that predate this specification) will not advertise
the DF Election Extended Community. That means that all other
participating PEs in the ES will not receive DF preferences and will
revert to the default DF election algorithm without AC-DF.
Similarly, an implementation that complies with [RFC7432] only and
that receives a DF Election Extended Community will ignore it and
will continue to use the default DF election algorithm.
3. The Highest Random Weight DF Election Algorithm
The procedure discussed in this section is applicable to the DF
election in EVPN services [RFC7432] and the EVPN Virtual Private Wire
Service (VPWS) [RFC8214].
HRW as defined in [HRW1999] is originally proposed in the context of
Internet caching and proxy server load balancing. Given an object
name and a set of servers, HRW maps a request to a server using the
object-name (object-id) and server-name (server-id) rather than the
server states. HRW forms a hash out of the server-id and the
object-id and forms an ordered list of the servers for the particular
object-id. The server for which the hash value is highest serves as
the primary server responsible for that particular object, and the
server with the next-highest value in that hash serves as the backup
server. HRW always maps a given object name to the same server
within a given cluster; consequently, it can be used at client sites
to achieve global consensus on object-to-server mappings. When that
server goes down, the backup server becomes the responsible
designate.
Choosing an appropriate hash function that is statistically oblivious
to the key distribution and imparts a good uniform distribution of
the hash output is an important aspect of the algorithm.
Fortunately, many such hash functions exist. [HRW1999] provides
Rabadan, et al. Standards Track [Page 19]
RFC 8584 DF Election Framework for EVPN Services April 2019
pseudorandom functions based on the Unix utilities rand and srand and
easily constructed XOR functions that satisfy the desired hashing
properties. HRW already finds use in multicast and ECMP [RFC2991]
[RFC2992].
3.1. HRW and Consistent Hashing
HRW is not the only algorithm that addresses the object-to-server
mapping problem with goals of fair load distribution, redundancy, and
fast access. There is another family of algorithms that also
addresses this problem; these fall under the umbrella of the
Consistent Hashing Algorithms [CHASH]. These will not be considered
here.
3.2. HRW Algorithm for EVPN DF Election
This section describes the application of HRW to DF election. Let
DF(V) denote the DF and BDF(V) denote the BDF for the Ethernet Tag V;
Si is the IP address of PE i; Es is the ESI; and Weight is a function
of V, Si, and Es.
Note that while the DF election algorithm provided in [RFC7432] uses
a PE address and VLAN as inputs, this document uses an Ethernet Tag,
PE address, and ESI as inputs. This is because if the same set of
PEs are multihomed to the same set of ESes, then the DF election
algorithm used in [RFC7432] would result in the same PE being elected
DF for the same set of BDs on each ES; this could have adverse
side effects on both load balancing and redundancy. Including an ESI
in the DF election algorithm introduces additional entropy, which
significantly reduces the probability of the same PE being elected DF
for the same set of BDs on each ES. Therefore, when using the HRW
algorithm for EVPN DF election, the ESI value in the Weight function
below SHOULD be set to that of the corresponding ES.
In the case of a VLAN Bundle service, V denotes the lowest VLAN,
similar to the "lowest VLAN in bundle" logic of [RFC7432].
1. DF(V) = Si| Weight(V, Es, Si) >= Weight(V, Es, Sj), for all j.
In the case of a tie, choose the PE whose IP address is
numerically the least. Note that 0 <= i,j < number of PEs in the
redundancy group.
2. BDF(V) = Sk| Weight(V, Es, Si) >= Weight(V, Es, Sk), and
Weight(V, Es, Sk) >= Weight(V, Es, Sj). In the case of a tie,
choose the PE whose IP address is numerically the least.
Rabadan, et al. Standards Track [Page 20]
RFC 8584 DF Election Framework for EVPN Services April 2019
Where:
o DF(V) is defined to be the address Si (index i) for which
Weight(V, Es, Si) is the highest; 0 <= i < N-1.
o BDF(V) is defined as that PE with address Sk for which the
computed Weight is the next highest after the Weight of the DF.
j is the running index from 0 to N-1; i and k are selected values.
Since the Weight is a pseudorandom function with the domain as the
three-tuple (V, Es, S), it is an efficient and deterministic
algorithm that is independent of the Ethernet Tag V sample space
distribution. Choosing a good hash function for the pseudorandom
function is an important consideration for this algorithm to perform
better than the default algorithm. As mentioned previously, such
functions are described in [HRW1999]. We take as a candidate hash
function the first one out of the two that are listed as preferred in
[HRW1999]:
Wrand(V, Es, Si) = (1103515245((1103515245.Si+12345) XOR
D(V, Es))+12345)(mod 2^31)
Here, D(V, Es) is the 31-bit digest (CRC-32 and discarding the
most significant bit (MSB), as noted in [HRW1999]) of the 14-octet
stream (the 4-octet Ethernet Tag V followed by the 10-octet ESI). It
is mandated that the 14-octet stream be formed by the concatenation
of the Ethernet Tag and the ESI in network byte order. The CRC
should proceed as if the stream is in network byte order
(big-endian). Si is the address of the ith server. The server's
IP address length does not matter, as only the low-order 31 bits are
modulo significant.
A point to note is that the Weight function takes into consideration
the combination of the Ethernet Tag, the ES, and the PE IP address,
and the actual length of the server IP address (whether IPv4 or IPv6)
is not really relevant. The default algorithm defined in [RFC7432]
cannot employ both IPv4 and IPv6 PE addresses, since [RFC7432] does
not specify how to decide on the ordering (the ordinal list) when
both IPv4 and IPv6 PEs are present.
HRW solves the disadvantages pointed out in Section 1.3.1 of this
document and ensures that:
o With very high probability, the task of DF election for the VLANs
configured on an ES is more or less equally distributed among the
PEs, even in the case of two PEs (see the first fundamental
problem listed in Section 1.3.1).
Rabadan, et al. Standards Track [Page 21]
RFC 8584 DF Election Framework for EVPN Services April 2019
5.2.3. KeyProvServerFinished ..............................43
6. Protocol Extensions ............................................44
6.1. The ClientInfoType Extension ..............................45
6.2. The ServerInfoType Extension ..............................45
7. Protocol Bindings ..............................................45
7.1. General Requirements ......................................45
7.2. HTTP/1.1 Binding for DSKPP ................................46
7.2.1. Identification of DSKPP Messages ...................46
7.2.2. HTTP Headers .......................................46
7.2.3. HTTP Operations ....................................47
7.2.4. HTTP Status Codes ..................................47
7.2.5. HTTP Authentication ................................47
7.2.6. Initialization of DSKPP ............................47
7.2.7. Example Messages ...................................48
8. DSKPP XML Schema ...............................................49
8.1. General Processing Requirements ...........................49
8.2. Schema ....................................................49
9. Conformance Requirements .......................................58
10. Security Considerations .......................................59
10.1. General ..................................................59
10.2. Active Attacks ...........................................60
10.2.1. Introduction ......................................60
10.2.2. Message Modifications .............................60
10.2.3. Message Deletion ..................................61
10.2.4. Message Insertion .................................62
10.2.5. Message Replay ....................................62
10.2.6. Message Reordering ................................62
10.2.7. Man in the Middle .................................63
10.3. Passive Attacks ..........................................63
10.4. Cryptographic Attacks ....................................63
10.5. Attacks on the Interaction between DSKPP and User
Authentication ...........................................64
10.6. Miscellaneous Considerations .............................65
10.6.1. Client Contributions to K_TOKEN Entropy ...........65
10.6.2. Key Confirmation ..................................65
10.6.3. Server Authentication .............................65
10.6.4. User Authentication ...............................66
10.6.5. Key Protection in Two-Pass DSKPP ..................66
10.6.6. Algorithm Agility .................................67
11. Internationalization Considerations ...........................68
12. IANA Considerations ...........................................68
12.1. URN Sub-Namespace Registration ...........................68
12.2. XML Schema Registration ..................................69
12.3. MIME Media Type Registration .............................69
12.4. Status Code Registration .................................70
12.5. DSKPP Version Registration ...............................70
12.6. PRF Algorithm ID Sub-Registry ............................70
12.6.1. DSKPP-PRF-AES .....................................71
Doherty, et al. Standards Track [Page 4]
RFC 6063 DSKPP December 2010
12.6.2. DSKPP-PRF-SHA256 ..................................71
12.7. Key Container Registration ...............................72
13. Intellectual Property Considerations ..........................73
14. Contributors ..................................................73
15. Acknowledgements ..............................................73
16. References ....................................................74
16.1. Normative References .....................................74
16.2. Informative References ...................................76
Appendix A. Usage Scenarios ......................................78
A.1. Single Key Request ........................................78
A.2. Multiple Key Requests .....................................78
A.3. User Authentication .......................................78
A.4. Provisioning Time-Out Policy ............................78
A.5. Key Renewal ...............................................79
A.6. Pre-Loaded Key Replacement ..............................79
A.7. Pre-Shared Manufacturing Key ............................79
A.8. End-to-End Protection of Key Material ...................80
Appendix B. Examples .............................................80
B.1. Trigger Message ...........................................80
B.2. Four-Pass Protocol ......................................81
B.2.1. <KeyProvClientHello> without a Preceding Trigger ......81
B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger .....82
B.2.3. <KeyProvServerHello> Without a Preceding Trigger ......83
B.2.4. <KeyProvServerHello> Assuming Key Renewal .............84
B.2.5. <KeyProvClientNonce> Using Default Encryption .........85
B.2.6. <KeyProvServerFinished> Using Default Encryption ......85
B.3. Two-Pass Protocol .......................................86
B.3.1. Example Using the Key Transport Method ................86
B.3.2. Example Using the Key Wrap Method .....................90
B.3.3. Example Using the Passphrase-Based Key Wrap Method ..94
Appendix C. Integration with PKCS #11 ............................98
C.1. The Four-Pass Variant ...................................98
C.2. The Two-Pass Variant ....................................98
Appendix D. Example of DSKPP-PRF Realizations .................101
D.1. Introduction .............................................101
D.2. DSKPP-PRF-AES ..........................................101
D.2.1. Identification .......................................101
D.2.2. Definition ...........................................101
D.2.3. Example ..............................................102
D.3. DSKPP-PRF-SHA256 .......................................103
D.3.1. Identification .......................................103
D.3.2. Definition ...........................................103
D.3.3. Example ..............................................104
Doherty, et al. Standards Track [Page 5]
RFC 6063 DSKPP December 2010
1. Introduction
Symmetric-key-based cryptographic systems (e.g., those providing
authentication mechanisms such as one-time passwords and challenge-
response) offer performance and operational advantages over public
key schemes. Such use requires a mechanism for the provisioning of
symmetric keys providing equivalent functionality to mechanisms such
as the Certificate Management Protocol (CMP) [RFC4210] and
Certificate Management over CMS (CMC) [RFC5272] in a Public Key
Infrastructure.
Traditionally, cryptographic modules have been provisioned with keys
during device manufacturing, and the keys have been imported to the
cryptographic server using, e.g., a CD-ROM disc shipped with the
devices. Some vendors also have proprietary provisioning protocols,
which often have not been publicly documented (the Cryptographic
Token Key Initialization Protocol (CT-KIP) is one exception
[RFC4758]).
This document describes the Dynamic Symmetric Key Provisioning
Protocol (DSKPP), a client-server protocol for provisioning symmetric
keys between a cryptographic module (corresponding to DSKPP Client)
and a key provisioning server (corresponding to DSKPP Server).
DSKPP provides an open and interoperable mechanism for initializing
and configuring symmetric keys to cryptographic modules that are
accessible over the Internet. The description is based on the
information contained in [RFC4758], and contains specific
enhancements, such as user authentication and support for the
[RFC6030] format for transmission of keying material.
DSKPP has two principal protocol variants. The four-pass protocol
variant permits a symmetric key to be established that includes
randomness contributed by both the client and the server. The two-
pass protocol requires only one round trip instead of two and permits
a server specified key to be established.
1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Version Support
There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified.
Doherty, et al. Standards Track [Page 6]
RFC 6063 DSKPP December 2010
The purpose for versioning the protocol is to provide a mechanism by
which changes to required cryptographic algorithms (e.g., SHA-256)
and attributes (e.g., key size) can be deployed without disrupting
existing implementations; likewise, outdated implementations can be
de-commissioned without disrupting operations involving newer
protocol versions.
The numbering scheme for DSKPP versions is "<major>.<minor>". The
major and minor numbers MUST be treated as separate integers and each
number MAY be incremented higher than a single digit. Thus, "DSKPP
2.4" would be a lower version than "DSKPP 2.13", which in turn would
be lower than "DSKPP 12.3". Leading zeros (e.g., "DSKPP 6.01") MUST
be ignored by recipients and MUST NOT be sent.
The major version number should be incremented only if the data
formats or security algorithms have changed so dramatically that an
older version implementation would not be able to interoperate with a
newer version (e.g., removing support for a previously mandatory-to-
implement algorithm now found to be insecure). The minor version
number indicates new capabilities (e.g., introducing a new algorithm
option) and MUST be ignored by an entity with a smaller minor version
number but be used for informational purposes by the entity with the
larger minor version number.
1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to
identify resources, algorithms, and semantics.
1.3.1. Defined Identifiers
The XML namespace [XMLNS] URI for Version 1.0 of DSKPP is:
"urn:ietf:params:xml:ns:keyprov:dskpp"
References to qualified elements in the DSKPP schema defined herein
use the prefix "dskpp", but any prefix is allowed.
1.3.2. Identifiers Defined in Related Specifications
This document relies on qualified elements already defined in the
Portable Symmetric Key Container [RFC6030] namespace, which is
represented by the prefix "pskc" and declared as:
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
Doherty, et al. Standards Track [Page 7]
RFC 6063 DSKPP December 2010
1.3.3. Referenced Identifiers
Finally, the DSKPP syntax presented in this document relies on
algorithm identifiers defined in the XML Signature [XMLDSIG]
namespace:
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to algorithm identifiers in the XML Signature namespace
are represented by the prefix "ds".
2. Terminology
2.1. Definitions
Terms are defined below as they are used in this document. The same
terms may be defined differently in other documents.
Authentication Code (AC): User Authentication Code comprised of a
string of hexadecimal characters known to the device and the
server and containing at a minimum a client identifier and a
password. This ClientID/password combination is used only once
and may have a time limit, and then discarded.
Authentication Data (AD): User Authentication Data that is derived
from the Authentication Code (AC)
Client ID: An identifier that the DSKPP Server uses to locate the
real username or account identifier on the server. It can be a
short random identifier that is unrelated to any real usernames.
Cryptographic Module: A component of an application, which enables
symmetric key cryptographic functionality
Device: A physical piece of hardware, or a software framework, that
hosts symmetric key cryptographic modules
Device ID (DeviceID): A unique identifier for the device that houses
the cryptographic module, e.g., a mobile phone
DSKPP Client: Manages communication between the symmetric key
cryptographic module and the DSKPP Server
DSKPP Server: The symmetric key provisioning server that
participates in the DSKPP run
Doherty, et al. Standards Track [Page 8]
RFC 6063 DSKPP December 2010
DSKPP Server ID (ServerID): The unique identifier of a DSKPP Server
Key Agreement: A key establishment protocol whereby two or more
parties can agree on a key in such a way that both influence the
outcome
Key Confirmation: The assurance of the rightful participants in a
key-establishment protocol that the intended recipient of the
shared key actually possesses the shared key
Key Issuer: An organization that issues symmetric keys to end-users
Key Package (KP): An object that encapsulates a symmetric key and
its configuration data
Key ID (KeyID): A unique identifier for the symmetric key
Key Protection Method (KPM): The key transport method used during
two-pass DSKPP
Key Protection Method List (KPML): The list of key protection
methods supported by a cryptographic module
Key Provisioning Server: A lifecycle management system that provides
a key issuer with the ability to provision keys to cryptographic
modules hosted on end-users' devices
Key Transport: A key establishment procedure whereby the DSKPP
Server selects and encrypts the keying material and then sends the
material to the DSKPP Client [NIST-SP800-57]
Key Transport Key: The private key that resides on the cryptographic
module. This key is paired with the DSKPP Client's public key,
which the DSKPP Server uses to encrypt keying material during key
transport [NIST-SP800-57]
Key Type: The type of symmetric key cryptographic methods for which
the key will be used (e.g., Open AUTHentication HMAC-Based One-
Time Password (OATH HOTP) or RSA SecurID authentication, AES
encryption, etc.)
Key Wrapping: A method of encrypting keys for key transport
[NIST-SP800-57]
Doherty, et al. Standards Track [Page 9]
RFC 6063 DSKPP December 2010
Key Wrapping Key: A symmetric key encrypting key used for key
wrapping [NIST-SP800-57]
Keying Material: The data necessary (e.g., keys and key
configuration data) necessary to establish and maintain
cryptographic keying relationships [NIST-SP800-57]
Manufacturer's Key: A unique master key pre-issued to a hardware
device, e.g., a smart card, during the manufacturing process. If
present, this key may be used by a cryptographic module to derive
secret keys
Protocol Run: Complete execution of the DSKPP that involves one
exchange (two-pass) or two exchanges (four-pass)
Security Attribute List (SAL): A payload that contains the DSKPP
version, DSKPP variant (four- or two-pass), key package formats,
key types, and cryptographic algorithms that the cryptographic
module is capable of supporting
2.2. Notation
|| String concatenation
[x] Optional element x
A ^ B Exclusive-OR operation on strings A and B
(where A and B are of equal length)
<XMLElement> A typographical convention used in the body of
the text
DSKPP-PRF(k,s,dsLen) A keyed pseudorandom function
E(k,m) Encryption of m with the key k
K Key used to encrypt R_C (either K_SERVER or
K_SHARED), or in MAC or DSKPP_PRF computations
K_AC Secret key that is derived from the
Authentication Code and used for user
authentication purposes
K_MAC Secret key derived during a DSKPP exchange for
use with key confirmation
K_MAC' A second secret key used for server
authentication
K_PROV A provisioning master key from which two keys
are derived: K_TOKEN and K_MAC
K_SERVER Public key of the DSKPP Server; used for
encrypting R_C in the four-pass protocol
variant
Doherty, et al. Standards Track [Page 10]
RFC 6063 DSKPP December 2010
K_SHARED Secret key that is pre-shared between the DSKPP
Client and the DSKPP Server; used for
encrypting R_C in the four-pass protocol
variant
K_TOKEN Secret key that is established in a
cryptographic module using DSKPP
R Pseudorandom value chosen by the DSKPP Client
and used for MAC computations
R_C Pseudorandom value chosen by the DSKPP Client
and used as input to the generation of K_TOKEN
R_S Pseudorandom value chosen by the DSKPP Server
and used as input to the generation of K_TOKEN
URL_S DSKPP Server address, as a URL
2.3. Abbreviations
AC Authentication Code
AD Authentication Data
DSKPP Dynamic Symmetric Key Provisioning Protocol
HTTP Hypertext Transfer Protocol
KP Key Package
KPM Key Protection Method
KPML Key Protection Method List
MAC Message Authentication Code
PC Personal Computer
PDU Protocol Data Unit
PKCS Public Key Cryptography Standards
PRF Pseudorandom Function
PSKC Portable Symmetric Key Container
SAL Security Attribute List (see Section 2.1)
TLS Transport Layer Security
URL Uniform Resource Locator
USB Universal Serial Bus
XML eXtensible Markup Language
3. DSKPP Overview
The following sub-sections provide a high-level view of protocol
internals and how they interact with external provisioning
applications. Usage scenarios are provided in Appendix A.
Doherty, et al. Standards Track [Page 11]
RFC 6063 DSKPP December 2010
3.1. Protocol Entities
A DSKPP provisioning transaction has three entities:
Server: The DSKPP provisioning server.
Cryptographic Module: The cryptographic module to which the
symmetric keys are to be provisioned, e.g., an authentication
token.
Client: The DSKPP Client that manages communication between the
cryptographic module and the key provisioning server.
The principal syntax is XML [XML] and it is layered on a transport
mechanism such as HTTP [RFC2616] and HTTP Over TLS [RFC2818]. While
it is highly desirable for the entire communication between the DSKPP
Client and server to be protected by means of a transport providing
confidentiality and integrity protection such as HTTP over Transport
Layer Security (TLS), such protection is not sufficient to protect
the exchange of the symmetric key data between the server and the
cryptographic module and DSKPP is designed to permit implementations
that satisfy this requirement.
The server only communicates to the client. As far as the server is
concerned, the client and cryptographic module may be considered to
be a single entity.
From a client-side security perspective, however, the client and the
cryptographic module are separate logical entities and may in some
implementations be separate physical entities as well.
It is assumed that a device will host an application layered above
the cryptographic module, and this application will manage
communication between the DSKPP Client and cryptographic module. The
manner in which the communicating application will transfer DSKPP
elements to and from the cryptographic module is transparent to the
DSKPP Server. One method for this transfer is described in
[CT-KIP-P11].
3.2. Basic DSKPP Exchange
3.2.1. User Authentication
In a DSKPP message flow, the user has obtained a new hardware or
software device embedded with a cryptographic module. The goal of
DSKPP is to provision the same symmetric key and related information
to the cryptographic module and the key management server, and
Doherty, et al. Standards Track [Page 12]
RFC 6063 DSKPP December 2010
o If a PE that is not the DF or the BDF for that VLAN goes down or
its connection to the ES goes down, it does not result in a DF or
BDF reassignment. This saves computation, especially in the case
when the connection flaps.
o More importantly, it avoids the third fundamental problem listed
in Section 1.3.1 (needless disruption) that is inherent in the
existing default DF election.
o In addition to the DF, the algorithm also furnishes the BDF, which
would be the DF if the current DF fails.
4. The AC-Influenced DF Election Capability
The procedure discussed in this section is applicable to the DF
election in EVPN services [RFC7432] and EVPN VPWS [RFC8214].
The AC-DF capability is expected to be generally applicable to any
future DF algorithm. It modifies the DF election procedures by
removing from consideration any candidate PE in the ES that cannot
forward traffic on the AC that belongs to the BD. This section is
applicable to VLAN-based and VLAN Bundle service interfaces.
Section 4.1 describes the procedures for VLAN-aware Bundle service
interfaces.
In particular, when used with the default DF algorithm, the AC-DF
capability modifies Step 3 in the DF election procedure described in
[RFC7432], Section 8.5, as follows:
3. When the timer expires, each PE builds an ordered candidate list
of the IP addresses of all the PE nodes attached to the ES
(including itself), in increasing numeric value. The candidate
list is based on the Originating Router's IP addresses of the ES
routes but excludes any PE from whom no Ethernet A-D per ES route
has been received or from whom the route has been withdrawn.
Afterwards, the DF election algorithm is applied on a per
<ES, Ethernet Tag>; however, the IP address for a PE will not be
considered to be a candidate for a given <ES, Ethernet Tag> until
the corresponding Ethernet A-D per EVI route has been received
from that PE. In other words, the ACS on the ES for a given PE
must be UP so that the PE is considered to be a candidate for a
given BD.
If the default DF algorithm is used, every PE in the resulting
candidate list is then given an ordinal indicating its position in
the ordered list, starting with 0 as the ordinal for the PE with
Rabadan, et al. Standards Track [Page 22]
RFC 8584 DF Election Framework for EVPN Services April 2019
the numerically lowest IP address. The ordinals are used to
determine which PE node will be the DF for a given Ethernet Tag on
the ES, using the following rule:
Assuming a redundancy group of N PE nodes, for VLAN-based service,
the PE with ordinal i is the DF for an <ES, Ethernet Tag V> when
(V mod N) = i. In the case of a VLAN (-aware) Bundle service,
then the numerically lowest VLAN value in that bundle on that ES
MUST be used in the modulo function as the Ethernet Tag.
It should be noted that using the Originating Router's IP Address
field [RFC7432] in the ES route to get the PE IP address needed
for the ordered list allows for a CE to be multihomed across
different Autonomous Systems (ASes) if such a need ever arises.
The modified Step 3, above, differs from [RFC7432], Section 8.5,
Step 3 in two ways:
o Any DF Alg can be used -- not only the described modulus-based DF
Alg (referred to as the default DF election or "DF Alg 0" in this
document).
o The candidate list is pruned based upon non-receipt of Ethernet
A-D routes: a PE's IP address MUST be removed from the ES
candidate list if its Ethernet A-D per ES route is withdrawn. A
PE's IP address MUST NOT be considered to be a candidate DF for an
<ES, Ethernet Tag> if its Ethernet A-D per EVI route for the
<ES, Ethernet Tag> is withdrawn.
The following example illustrates the AC-DF behavior applied to the
default DF election algorithm, assuming the network in Figure 2:
(a) When PE1 and PE2 discover ES12, they advertise an ES route for
ES12 with the associated ES-Import Extended Community and the DF
Election Extended Community indicating AC-DF = 1; they start a
DF Wait timer (independently). Likewise, PE2 and PE3 advertise
an ES route for ES23 with AC-DF = 1 and start a DF Wait timer.
(b) PE1 and PE2 advertise an Ethernet A-D per ES route for ES12.
PE2 and PE3 advertise an Ethernet A-D per ES route for ES23.
(c) In addition, PE1, PE2, and PE3 advertise an Ethernet A-D per EVI
route for AC1, AC2, AC3, and AC4 as soon as the ACs are enabled.
Note that the AC can be associated with a single customer VID
(e.g., VLAN-based service interfaces) or a bundle of customer
VIDs (e.g., VLAN Bundle service interfaces).
Rabadan, et al. Standards Track [Page 23]
RFC 8584 DF Election Framework for EVPN Services April 2019
(d) When the timer expires, each PE builds an ordered candidate list
of the IP addresses of all the PE nodes attached to the ES
(including itself) as explained in the modified Step 3 above.
Any PE from which an Ethernet A-D per ES route has not been
received is pruned from the list.
(e) When electing the DF for a given BD, a PE will not be considered
to be a candidate until an Ethernet A-D per EVI route has been
received from that PE. In other words, the ACS on the ES for a
given PE must be UP so that the PE is considered to be a
candidate for a given BD. For example, PE1 will not consider
PE2 as a candidate for DF election for <ES12, VLAN-1> until an
Ethernet A-D per EVI route is received from PE2 for
<ES12, VLAN-1>.
(f) Once the PEs with ACS = DOWN for a given BD have been removed
from the candidate list, the DF election can be applied for the
remaining N candidates.
Note that this procedure only modifies the existing EVPN control
plane by adding and processing the DF Election Extended Community
and by pruning the candidate list of PEs that take part in the DF
election.
In addition to the events defined in the FSM in Section 2.1, the
following events SHALL modify the candidate PE list and trigger the
DF re-election in a PE for a given <ES, Ethernet Tag>. In the FSM
shown in Figure 3, the events below MUST trigger a transition from
DF_DONE to DF_CALC:
1. Local AC going DOWN/UP.
2. Reception of a new Ethernet A-D per EVI route update/withdrawal
for the <ES, Ethernet Tag>.
3. Reception of a new Ethernet A-D per ES route update/withdrawal
for the ES.
4.1. AC-Influenced DF Election Capability for VLAN-Aware Bundle
Services
The procedure described in Section 4 works for VLAN-based and VLAN
Bundle service interfaces because, for those service types, a PE
advertises only one Ethernet A-D per EVI route per <ES, VLAN> or
<ES, VLAN Bundle>. In Section 4, an Ethernet Tag represents a given
VLAN or VLAN Bundle for the purpose of DF election. The withdrawal
Rabadan, et al. Standards Track [Page 24]
RFC 8584 DF Election Framework for EVPN Services April 2019
of such a route means that the PE cannot forward traffic on that
particular <ES, VLAN> or <ES, VLAN Bundle>; therefore, the PE can be
removed from consideration for DF election.
According to [RFC7432], in VLAN-aware Bundle services, the PE
advertises multiple Ethernet A-D per EVI routes per <ES, VLAN Bundle>
(one route per Ethernet Tag), while the DF election is still
performed per <ES, VLAN Bundle>. The withdrawal of an individual
route only indicates the unavailability of a specific AC and not
necessarily all the ACs in the <ES, VLAN Bundle>.
This document modifies the DF election for VLAN-aware Bundle services
in the following ways:
o After confirming that all the PEs in the ES advertise the AC-DF
capability, a PE will perform a DF election per <ES, VLAN>, as
opposed to per <ES, VLAN Bundle> as described in [RFC7432]. Now,
the withdrawal of an Ethernet A-D per EVI route for a VLAN will
indicate that the advertising PE's ACS is DOWN and the rest of the
PEs in the ES can remove the PE from consideration for DF election
in the <ES, VLAN>.
o The PEs will now follow the procedures in Section 4.
For example, assuming three bridge tables in PE1 for the same MAC-VRF
(each one associated with a different Ethernet Tag, e.g., VLAN-1,
VLAN-2, and VLAN-3), PE1 will advertise three Ethernet A-D per EVI
routes for ES12. Each of the three routes will indicate the status
of each of the three ACs in ES12. PE1 will be considered to be a
valid candidate PE for DF election in <ES12, VLAN-1>, <ES12, VLAN-2>,
and <ES12, VLAN-3> as long as its three routes are active. For
instance, if PE1 withdraws the Ethernet A-D per EVI routes for
<ES12, VLAN-1>, the PEs in ES12 will not consider PE1 as a suitable
DF candidate for <ES12, VLAN-1>. PE1 will still be considered for
<ES12, VLAN-2> and <ES12, VLAN-3>, since its routes are active.
5. Solution Benefits
The solution described in this document provides the following
benefits:
(a) It extends the DF election as defined in [RFC7432] to address
the unfair load balancing and potential black-holing issues with
the default DF election algorithm. The solution is applicable
to the DF election in EVPN services [RFC7432] and EVPN VPWS
[RFC8214].
Rabadan, et al. Standards Track [Page 25]
RFC 8584 DF Election Framework for EVPN Services April 2019
(b) It defines a way to signal the DF election algorithm and
capabilities intended by the advertising PE. This is done by
defining the DF Election Extended Community, which allows the
advertising PE to indicate its support for the capabilities
defined in this document as well as any subsequently defined DF
election algorithms or capabilities.
(c) It is backwards compatible with the procedures defined in
[RFC7432]. If one or more PEs in the ES do not support the new
procedures, they will all follow DF election as defined in
[RFC7432].
6. Security Considerations
This document addresses some identified issues in the DF election
procedures described in [RFC7432] by defining a new DF election
framework. In general, this framework allows the PEs that are part
of the same ES to exchange additional information and agree on the DF
election type and capabilities to be used.
By following the procedures in this document, the operator will
minimize such undesirable situations as unfair load balancing,
service disruption, and traffic black-holing. Because such
situations could be purposely created by a malicious user with access
to the configuration of one PE, this document also enhances the
security of the network. Note that the network will not benefit from
the new procedures if the DF election algorithm is not consistently
configured on all the PEs in the ES (if there is no unanimity among
all the PEs, the DF election algorithm falls back to the default DF
election as provided in [RFC7432]). This behavior could be exploited
by an attacker that manages to modify the configuration of one PE in
the ES so that the DF election algorithm and capabilities in all the
PEs in the ES fall back to the default DF election. If that is the
case, the PEs will be exposed to the unfair load balancing, service
disruption, and black-holing mentioned earlier.
In addition, the new framework is extensible and allows for new
security enhancements in the future. Note that such enhancements are
out of scope for this document. Finally, since this document extends
the procedures in [RFC7432], the same security considerations as
those described in [RFC7432] are valid for this document.
Rabadan, et al. Standards Track [Page 26]
RFC 8584 DF Election Framework for EVPN Services April 2019
7. IANA Considerations
IANA has:
o Allocated Sub-Type value 0x06 in the "EVPN Extended Community
Sub-Types" registry defined in [RFC7153] as follows:
Sub-Type Value Name Reference
-------------- ------------------------------ -------------
0x06 DF Election Extended Community This document
o Set up a registry called "DF Alg" for the DF Alg field in the
Extended Community. New registrations will be made through the
"RFC Required" procedure defined in [RFC8126]. Value 31 is for
experimental use and does not require any other RFC than this
document. The following initial values in that registry exist:
Alg Name Reference
---- ----------------------------- -------------
0 Default DF Election This document
1 HRW Algorithm This document
2-30 Unassigned
31 Reserved for Experimental Use This document
o Set up a registry called "DF Election Capabilities" for the
2-octet Bitmap field in the Extended Community. New registrations
will be made through the "RFC Required" procedure defined in
[RFC8126]. The following initial value in that registry exists:
Bit Name Reference
---- ---------------- -------------
0 Unassigned
1 AC-DF Capability This document
2-15 Unassigned
Rabadan, et al. Standards Track [Page 27]
RFC 8584 DF Election Framework for EVPN Services April 2019
8. References
8.1. Normative References
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432,
February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Rabadan, et al. Standards Track [Page 28]
RFC 8584 DF Election Framework for EVPN Services April 2019
8.2. Informative References
[VPLS-MH] Kothari, B., Kompella, K., Henderickx, W., Balus, F., and
J. Uttaro, "BGP based Multi-homing in Virtual Private LAN
Service", Work in Progress,
draft-ietf-bess-vpls-multihoming-03, March 2019.
[CHASH] Karger, D., Lehman, E., Leighton, T., Panigrahy, R.,
Levine, M., and D. Lewin, "Consistent Hashing and Random
Trees: Distributed Caching Protocols for Relieving Hot
Spots on the World Wide Web", ACM Symposium on Theory of
Computing, ACM Press, New York, DOI 10.1145/258533.258660,
May 1997.
[CLRS2009] Cormen, T., Leiserson, C., Rivest, R., and C. Stein,
"Introduction to Algorithms (3rd Edition)", MIT
Press, ISBN 0-262-03384-8, 2009.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991,
DOI 10.17487/RFC2991, November 2000,
<https://www.rfc-editor.org/info/rfc2991>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[HRW1999] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings
to Increase Hit Rates", IEEE/ACM Transactions on
Networking, Volume 6, No. 1, February 1998,
<https://www.microsoft.com/en-us/research/wp-content/
uploads/2017/02/HRW98.pdf>.
[Knuth] Knuth, D., "The Art of Computer Programming: Volume 3:
Sorting and Searching", 2nd Edition, Addison-Wesley,
Page 516, 1998.
Rabadan, et al. Standards Track [Page 29]
RFC 8584 DF Election Framework for EVPN Services April 2019
Acknowledgments
The authors want to thank Ranganathan Boovaraghavan, Sami Boutros,
Luc Andre Burdet, Anoop Ghanwani, Mrinmoy Ghosh, Jakob Heitz, Leo
Mermelstein, Mankamana Mishra, Tamas Mondal, Laxmi Padakanti, Samir
Thoria, and Sriram Venkateswaran for their review and contributions.
Special thanks to Stephane Litkowski for his thorough review and
detailed contributions.
They would also like to thank their working group chairs, Matthew
Bocci and Stephane Litkowski, and their AD, Martin Vigoureux, for
their guidance and support.
Finally, they would like to thank the Directorate reviewers and the
ADs for their thorough reviews and probing questions, the answers to
which have substantially improved the quality of the document.
Contributors
The following people have contributed substantially to this document
and should be considered coauthors:
Antoni Przygienda
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Email: prz@juniper.net
Vinod Prabhu
Nokia
Email: vinod.prabhu@nokia.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Wen Lin
Juniper Networks, Inc.
Email: wlin@juniper.net
Rabadan, et al. Standards Track [Page 30]
RFC 8584 DF Election Framework for EVPN Services April 2019
Patrice Brissette
Cisco Systems
Email: pbrisset@cisco.com
Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com
Autumn Liu
Ciena
Email: hliu@ciena.com
Authors' Addresses
Jorge Rabadan (editor)
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: jorge.rabadan@nokia.com
Satya Mohanty (editor)
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
United States of America
Email: satyamoh@cisco.com
Ali Sajassi
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
Rabadan, et al. Standards Track [Page 31]
RFC 8584 DF Election Framework for EVPN Services April 2019
John Drake
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Email: jdrake@juniper.net
Kiran Nagaraj
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: kiran.nagaraj@nokia.com
Senthil Sathappan
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: senthil.sathappan@nokia.com
Rabadan, et al. Standards Track [Page 32]