idnits 2.17.1 draft-farinacci-lisp-ecdsa-auth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 275: '... MUST agree on the hash bit length....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 19, 2018) is 2170 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6833' is defined on line 453, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-geo-05 == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-05 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-10 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental E. Nordmark 5 Expires: October 21, 2018 Zededa 6 April 19, 2018 8 LISP Control-Plane ECDSA Authentication and Authorization 9 draft-farinacci-lisp-ecdsa-auth-02 11 Abstract 13 This draft describes how LISP control-plane messages can be 14 individually authenticated and authorized without a a priori shared- 15 key configuration. Public-key cryptography is used with no new PKI 16 infrastructure required. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 21, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Public-Key Hash . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Hash-EID Mapping Entry . . . . . . . . . . . . . . . . . . . 6 57 6. Hash-EID Structure . . . . . . . . . . . . . . . . . . . . . 7 58 7. Keys and Signatures . . . . . . . . . . . . . . . . . . . . . 7 59 8. Signed Map-Register Encoding . . . . . . . . . . . . . . . . 8 60 9. Signed Map-Request Encoding . . . . . . . . . . . . . . . . . 8 61 10. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 11. EID Authorization . . . . . . . . . . . . . . . . . . . . . . 9 63 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 14.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 12 70 B.1. Changes to draft-farinacci-lisp-ecdsa-auth-02.txt . . . . 12 71 B.2. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt . . . . 12 72 B.3. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 The LISP architecture and protocols [RFC6830] introduces two new 78 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 79 (RLOCs) which provide an architecture to build overlays on top of the 80 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 81 a Mapping Database System. EIDs and RLOCs come in many forms than 82 just IP addresses, using a general syntax that includes Address 83 Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other 84 addressing information have privacy requirements. Access to private 85 information is granted only to those who are authorized and 86 authenticated. Using asymmetric keying with public key cryptography 87 enforces authentication for entities that read from and write to the 88 mapping system. The proposal described in this document takes 89 advantage of the latest in Elliptic Curve Cryptography. 91 In this proposal the EID is derived from a public key, and the 92 corresponding private key is used to authenticate and authorize Map- 93 Register messages. Thus only the owner of the corresponding private 94 key can create and update mapping entries from the EID. Furthermore, 95 the same approach is used to authenticate Map-Request messages. This 96 in combination with the mapping database containing authorization 97 information for Map-Requests is used to restrict which EIDs can 98 lookup up the RLOCs for another EID. 100 This specification introduces how to use the Distinguished-Name AFI 101 [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and 102 signatures in the LISP mapping database. The information in the 103 mapping database is used to verify cryptographic signatures in LISP 104 control-plane messages such as the Map-Request and Map-Register. 106 2. Definition of Terms 108 Crypto-EID: is an IPv6 EID where part of the EID includes a hash 109 value of a public-key. An IPv6 EID is a Crypto-EID when the Map- 110 Server is configured with an Crypto-EID Prefix that matches the 111 IPv6 EID. 113 Crypto-EID Hash Length: is the number of low-order bits in a Crypto- 114 EID which make up the hash of a public-key. The hash length is 115 determined by the Map-Server when it is configured with a Crypto- 116 EID Prefix. 118 Crypto-EID Prefix: is a configuration parameter on the Map-Server 119 that indicates which IPv6 EIDs are Crypto-EIDs and what is the 120 Crypto-EID Hash Length for the IPv6 EID. This can be different 121 for different LISP Instance-IDs. 123 Hash-EID: is a distinguished name EID-record stored in the mapping 124 database. The EID format is 'hash-'. When a key- 125 pair is generated for an endpoint, the produced private-key does 126 not leave the xTR that will register the Crypto-EID. A hash of 127 the public-key is used to produce a Crypto-EID and a Hash-EID. 128 The Crypto-EID is assigned to the endpoint and the xTR that 129 supports the LISP-site registers the Crypto-EID. Another entity 130 registers the Hash-EID mapping with the public-key as an RLOC- 131 record. 133 Public-Key RLOC: is a JSON string that encodes a public-key as an 134 RLOC-record for a Hash-EID mapping entry. The format of the JSON 135 string is '{ "public-key" : "" }'. 137 Control-Plane Signature: a Map-Request or Map-Register sender signs 138 the message with its private key. The format of the signature is 139 a JSON string that includes sender information and the signature 140 value. The JSON string is included in Map-Request and Map- 141 Register messages. 143 Signature-EID: is a Crypto-EID used for a Control-Plane signature to 144 register or request any type of EID. The Signature-EID is 145 included with the JSON-encoded signature in Map-Request and Map- 146 Register messages. 148 3. Overview 150 LISP already has several message authentication mechanisms. They can 151 be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and 152 [RFC8061]. The mechanisms in this draft are providing a more 153 granular level of authentication as well as a simpler way to manage 154 keys and passwords. 156 A client of the mapping system can be authenticated using public-key 157 cryptography. The client is required to have a private/public key- 158 pair where it uses the private-key to sign Map-Requests and Map- 159 Registers. The server, or the LISP entity, that processes Map- 160 Requests and Map-Registers uses the public-key to verify signatures. 162 The following describes how the mapping system is used to implement 163 the public-key crypto system: 165 1. An entity registers Hash-EID to Public-Key RLOC mappings. A 166 third-party entity that provides a service can register or the 167 client itself can register. 169 2. Anyone can lookup the Hash-EID mappings. These mappings are not 170 usually authenticated with the mechanisms in this draft but use 171 the shared configured password mechanisms from 172 [I-D.ietf-lisp-rfc6833bis] that provide group level 173 authentication. 175 3. When a Crypto-EID, or any EID type, is registered to the mapping 176 system, a signature is included in the Map-Register message. 177 When a non-Crypto-EID is registered a Signature-EID is also 178 included in the Map-Register message. 180 4. The Map-Server processes the registration by constructing the 181 Hash-EID from the registered Crypto-EID, looks up the Hash-EID in 182 the mapping system, obtains the public-key from the RLOC-record 183 and verifies the signature. If Hash-EID lookup fails or the 184 signature verification fails, the Map-Register is not accepted. 186 5. When a Crypto-EID, or any EID type, is looked up in the mapping 187 system, a signature is included with a Signature-EID in the Map- 188 Request message. 190 6. The Map-Server processes the request for a Crypto-EID by 191 constructing the Hash-EID from the Signature-EID included in the 192 Map-Request. The signer-EID is a Crypto-EID that accompanies a 193 signature in the Map-Request. The Hash-EID is looked up in the 194 mapping system, obtains the public-key from the RLOC-record and 195 verifies the Map-Request signature. If the Hash-EID lookup fails 196 or the signature verification fails, the Map-Request is not 197 accepted and a Negative Map-Reply is sent back with an action of 198 "auth-failure". 200 4. Public-Key Hash 202 When a private/public key-pair is created for a node, its IPv6 EID is 203 pre-determined based on the public key generated. Note if the key- 204 pair is compromised or is changed for the node, a new IPv6 EID is 205 assigned for the node. 207 The sha256 [RFC6234] hex digest function is used to compute the hash. 208 The hash is run over the following hex byte string: 210 212 Where each field is defined to be: 214 : is a 4-byte (leading zeroes filled) binary value of the 215 Instance-ID the EID will be registered with in the mapping 216 database. For example, if the instance-id is 171, then the 4-byte 217 value is 0x000000ab. 219 : is a variable length IPv6 prefix in binary format (with no 220 colons) and IS quad-nibble zero-filled. The length of the prefix 221 is 128 minus the Crypto-EID hash bit length. For example, if the 222 prefix is 2001:5:3::/48, then the 6 byte value is 0x200100050003. 224 : is a DER [RFC7468] encoded public-key. 226 The public-key hash is used to construct the Crypto-EID and Hash-EID. 228 5. Hash-EID Mapping Entry 230 A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI 231 as specified in [I-D.farinacci-lisp-name-encoding]. The format of 232 the string is: 234 EID-record: 'hash-' 236 Where is a public-key hash as described in Section 4. The 237 RLOC-record to encode and store the public-key is in LCAF JSON Type 238 format of the form: 240 RLOC-record: '{ "public-key" : "" }' 242 Where is a base64 [RFC4648] encoding of the public- 243 key generated for the system that is assigned the Hash-EID. 245 6. Hash-EID Structure 247 Since the Hash-EID is formatted as a distinguished-name AFI, the 248 format of the for EID 'hash-' needs to be 249 specified. The format will be an IPv6 address [RFC3513] where colons 250 are used between quad-nibble characters when the hash bit length is a 251 multiple of 4. And when the hash bit length is not a multiple of 4 252 but a multiple of 2, a leading 2 character nibble-pair is present. 253 Here are some examples for different hash bit lengths: 255 Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64: 256 Hash-EID is: 'hash-1111:2222:3333:4444' 258 Crypto-EID: 2001:5::11:22:33:44, hash length 64: 259 Hash-EID is: 'hash-0011:0022:0033:0044' 261 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80: 262 Hash-EID is: 'hash-bbbb:1111:2222:3333:4444' 264 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72: 265 Hash-EID is: 'hash-bb:1111:2222:3333:4444' 267 Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72: 268 Hash-EID is: 'hash-bb:1111:0022:0033:4444' 270 Note when leading zeroes exist in a IPv6 encoded quad between colons, 271 the zeros are included in the quad for the Hash-EID string. 273 The entity that creates the hash, the entity that registers the 274 Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups 275 MUST agree on the hash bit length. 277 7. Keys and Signatures 279 Key generation, message authentication with digital signatures, and 280 signature verification will use the Elliptic Curve Digital Signature 281 Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is 282 used and recommended. 284 Signatures are computed over signature data that depends on the type 285 of LISP message sent. See Section 8 and Section 9 for each message 286 type. The signature data is passed through a sha256 hash function 287 before it is signed or verified. 289 8. Signed Map-Register Encoding 291 When a ETR registers its Crypto-EID or any EID type to the mapping 292 system, it builds a LISP Map-Register message. The mapping includes 293 an EID-record which encodes the Crypto-EID, or any EID type, and an 294 RLOC-set. One of the RLOC-records in the RLOC-set includes the the 295 ETR's signature and signature-EID. The RLOC-record is formatted with 296 a LCAF JSON Type, in the following format: 298 { "signature" : "", "signature-eid" : "" } 300 Where is a base64 [RFC4648] encoded string over 301 the following ascii [RFC0020] string signature data: 303 [] 305 Where is the decimal value of the instance-ID the Crypto-EID is 306 registering to and the is in the form of [RFC3513] where 307 quad-nibbles between colons ARE NOT zero-filled. 309 The Map-Server that process an EID-record with a Crypto-EID and a 310 RLOC-record with a signature extracts the public-key hash value from 311 the Crypto-EID to build a Hash-EID. The Map-Server looks up the 312 Hash-EID in the mapping system to obtain the public-key RLOC-record. 313 The Map-Server verifies the signature over the signature data to 314 determine if it should accept the EID-record registration. 316 9. Signed Map-Request Encoding 318 When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the 319 mapping system to request the RLOC-set for a Crypto-EID, it signs the 320 Map-Request so it can authenticate itself to the Map-Server the 321 Crypto-EID is registered to. The Map-Request target-EID field will 322 contain the Crypto-EID and the source-EID field will contain an LCAF 323 JSON Type string with the following signature information: 325 { "source-eid" : "", "signature-eid" : "", 326 "signature" : "" } 328 Where is an IPv6 encoded string according to [RFC3513] 329 where quad-nibbles between colons ARE NOT zero-filled. The is 330 the source EID from the data packet that is invoking the Map-Request 331 or the entire key/value pair for "source-eid" can be excluded when a 332 data packet did not invoke the Map-Request (i.e. lig or an API 333 request). The is the IPv6 Crypto-EID of the xTR that is 334 providing the Map-Request signature. 336 The signature string is a base64 [RFC4648] encoded 337 string over the following signature data: 339 341 Where is a hex string [RFC0020] of the nonce used in the Map- 342 Request and the and are hex strings 343 [RFC0020] of an IPv6 address in the form of [RFC3513] where quad- 344 nibbles between colons ARE NOT zero-filled. When is not 345 included in the Map-Request, string "0::0" is used for . 347 10. Other Uses 349 The mechanisms described within this document can be used to sign 350 other types of LISP messages. And for further study is how to use 351 these mechanisms to sign LISP encapsulated data packets in a 352 compressed manner to reduce data packet header overhead. 354 In addition to authenticating other types of LISP messages, other 355 types of EID-records can be encoded as well and is not limited to 356 IPv6 EIDs. It is possible for a LISP xTR to register and request non 357 IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing 358 and verifying EID-records. 360 Examples of other EID types that can be authenticated in Map-Request 361 and Map-Register messages are: 363 +-----------------------+------------------------------------+ 364 | EID-Type | Format Definition | 365 +-----------------------+------------------------------------+ 366 | IPv4 address prefixes | [RFC1123] | 367 | | | 368 | Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | 369 | | | 370 | Geo-Coordinates | [I-D.farinacci-lisp-geo] | 371 | | | 372 | LCAF defined EIDs | [RFC8060] | 373 +-----------------------+------------------------------------+ 375 11. EID Authorization 377 When a Crypto-EID is being used for IPv6 communication, it is 378 implicit that the owner has the right to use the EID since it was 379 generated from the key-pair provisioned for the owner. For other EID 380 types that are not directly associated with signature keys, they must 381 be validated for use by the mapping system they are registered to. 382 This policy information for the mapping system must be configured in 383 the Map-Servers the EID owner registers to. 385 12. Security Considerations 387 The mechanisms within this specification are intentionally using 388 accepted practices and state of the art public-key cryptography. 390 Crypto-EIDs can be made private when control messages are encrypted, 391 for instance, using [RFC8061]. 393 The topological or physical location of a Crypto-EID is only 394 available to the other Crypto-EIDs that register in the same LISP 395 Instance-ID and have their corresponding Hash-EIDs registered. 397 This draft doesn't address reply attacks directly. If a man-in-the- 398 middle captures Map-Register messages, it could send such captured 399 packets at a later time which contains signatures of the source. In 400 which case, the Map-Server verifies the signature as good and 401 interprets the contents to be valid where in fact the contents can 402 contain old mapping information. This problem can be solved by 403 encrypting the contents of Map-Registers using a third-party protocol 404 like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by 405 encapsulating Map-Registers in LISP data packets (using port 4341). 407 13. IANA Considerations 409 Since there are no new packet formats introduced for the 410 functionality in this specification, there are no specific requests 411 for IANA. 413 14. References 415 14.1. Normative References 417 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 418 RFC 20, DOI 10.17487/RFC0020, October 1969, 419 . 421 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 422 Application and Support", STD 3, RFC 1123, 423 DOI 10.17487/RFC1123, October 1989, 424 . 426 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 427 DOI 10.17487/RFC1700, October 1994, 428 . 430 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 431 (IPv6) Addressing Architecture", RFC 3513, 432 DOI 10.17487/RFC3513, April 2003, 433 . 435 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 436 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 437 . 439 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 440 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 441 DOI 10.17487/RFC6234, May 2011, 442 . 444 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 445 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 446 January 2012, . 448 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 449 Locator/ID Separation Protocol (LISP)", RFC 6830, 450 DOI 10.17487/RFC6830, January 2013, 451 . 453 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 454 Protocol (LISP) Map-Server Interface", RFC 6833, 455 DOI 10.17487/RFC6833, January 2013, 456 . 458 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 459 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 460 April 2015, . 462 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 463 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 464 February 2017, . 466 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 467 (LISP) Data-Plane Confidentiality", RFC 8061, 468 DOI 10.17487/RFC8061, February 2017, 469 . 471 14.2. Informative References 473 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 474 NUMBERS http://www.iana.org/assignments/address-family- 475 numbers/address-family-numbers.xhtml?, Febuary 2007. 477 [I-D.farinacci-lisp-geo] 478 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 479 farinacci-lisp-geo-05 (work in progress), April 2018. 481 [I-D.farinacci-lisp-name-encoding] 482 Farinacci, D., "LISP Distinguished Name Encoding", draft- 483 farinacci-lisp-name-encoding-05 (work in progress), March 484 2018. 486 [I-D.ietf-lisp-rfc6833bis] 487 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 488 "Locator/ID Separation Protocol (LISP) Control-Plane", 489 draft-ietf-lisp-rfc6833bis-10 (work in progress), March 490 2018. 492 [I-D.ietf-lisp-sec] 493 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 494 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 495 (work in progress), April 2018. 497 [X9.62] American National Standards Institute, "Public Key 498 Cryptography for the Financial Services Industry: The 499 Elliptic Curve Digital Signature Algorithm (ECDSA)", 500 NIST ANSI X9.62-2005, November 2005. 502 Appendix A. Acknowledgments 504 A special thanks goes to Sameer Merchant for his ideas and technical 505 contributions to the ideas in this draft. 507 Appendix B. Document Change Log 509 [RFC Editor: Please delete this section on publication as RFC.] 511 B.1. Changes to draft-farinacci-lisp-ecdsa-auth-02.txt 513 o Draft posted April 2018. 515 o Generalize text to allow Map-Reqeusting and Map-Registering for 516 any EID type with a proper signature-EID and signature encoded 517 together. 519 B.2. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt 521 o Draft posted October 2017. 523 o Make it more clear what values and format the EID hash is run 524 over. 526 o Update references to newer RFCs and Internet Drafts. 528 B.3. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt 530 o Initial draft posted July 2017. 532 Authors' Addresses 534 Dino Farinacci 535 lispers.net 536 San Jose, CA 537 USA 539 Email: farinacci@gmail.com 541 Erik Nordmark 542 Zededa 543 Santa Clara, CA 544 USA 546 Email: erik@zededa.com