idnits 2.17.1 draft-ietf-hip-rfc4843-bis-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4843]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC4843, but the abstract doesn't seem to directly say this. It does mention RFC4843 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 6, 2013) is 4001 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Hi3' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'NodeID' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-11 -- Obsolete informational reference (is this intentional?): RFC 4773 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft Juniper Networks 4 Obsoletes: 4843 (if approved) F. Dupont 5 Intended status: Standards Track Internet Systems Consortium 6 Expires: November 7, 2013 May 6, 2013 8 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 9 Version 2 (ORCHIDv2) 10 draft-ietf-hip-rfc4843-bis-04 12 Abstract 14 This document specifies an updated Overlay Routable Cryptographic 15 Hash Identifiers format that obsoletes the earlier format defined in 16 [RFC4843]. These identifiers are intended to be used as endpoint 17 identifiers at applications and Application Programming Interfaces 18 (API) and not as identifiers for network location at the IP layer, 19 i.e., locators. They are designed to appear as application layer 20 entities and at the existing IPv6 APIs, but they should not appear in 21 actual IPv6 headers. To make them more like regular IPv6 addresses, 22 they are expected to be routable at an overlay level. Consequently, 23 while they are considered non-routable addresses from the IPv6 layer 24 point-of-view, all existing IPv6 applications are expected to be able 25 to use them in a manner compatible with current IPv6 addresses. 27 The Overlay Routable Cryptographic Hash Identifiers originally 28 defined in [RFC4843] lacked a mechanism for cryptographic algorithm 29 agility. The updated ORCHID format specified in this document 30 removes this limitation by encoding in the identifier itself an index 31 to the suite of cryptographic algorithms in use. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 7, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3 69 1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 71 1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 74 3. Routing and Forwarding Considerations . . . . . . . . . . . . 7 75 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative references . . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative references . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Collision Considerations . . . . . . . . . . . . . . 11 84 Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 This document introduces Overlay Routable Cryptographic Hash 89 Identifiers (ORCHID), a new class of IP address-like identifiers. 90 These identifiers are intended to be globally unique in a statistical 91 sense (see Appendix A), non-routable at the IP layer, and routable at 92 some overlay layer. The identifiers are securely bound, via a secure 93 hash function, to the concatenation of an input bitstring and a 94 context tag. Typically, but not necessarily, the input bitstring 95 will include a suitably encoded public cryptographic key. 97 1.1. Rationale and Intent 99 These identifiers are expected to be used at the existing IPv6 100 Application Programming Interfaces (API) and application protocols 101 between consenting hosts. They may be defined and used in different 102 contexts, suitable for different overlay protocols. Examples of 103 these include Host Identity Tags (HIT) in the Host Identity Protocol 104 (HIP) [I-D.ietf-hip-rfc5201-bis] and Temporary Mobile Identifiers 105 (TMI) for Mobile IPv6 Privacy Extension [PRIVACYTEXT]. 107 As these identifiers are expected to be used along with IPv6 108 addresses at both applications and APIs, co-ordination is desired to 109 make sure that an ORCHID is not inappropriately taken for a regular 110 IPv6 address and vice versa. In practice, allocation of a separate 111 prefix for ORCHIDs seems to suffice, making them compatible with IPv6 112 addresses at the upper layers while simultaneously making it trivial 113 to prevent their usage at the IP layer. 115 While being technically possible to use ORCHIDs between consenting 116 hosts without any co-ordination with the IETF and the IANA, the 117 authors would consider such practice potentially dangerous. A 118 specific danger would be realised if the IETF community later decided 119 to use the ORCHID prefix for some different purpose. In that case, 120 hosts using the ORCHID prefix would be, for practical purposes, 121 unable to use the prefix for the other new purpose. That would lead 122 to partial balkanisation of the Internet, similar to what has 123 happened as a result of historical hijackings of non-RFC 1918 124 [RFC1918] IPv4 addresses for private use. 126 The whole need for the proposed allocation grows from the desire to 127 be able to use ORCHIDs with existing applications and APIs. This 128 desire leads to the potential conflict, mentioned above. Resolving 129 the conflict requires the proposed allocation. 131 One can argue that the desire to use these kinds of identifiers via 132 existing APIs is architecturally wrong, and there is some truth in 133 that argument. Indeed, it would be more desirable to introduce a new 134 API and update all applications to use identifiers, rather than 135 locators, via that new API. That is exactly what we expect to happen 136 in the long run. 138 However, given the current state of the Internet, we do not consider 139 it viable to introduce any changes that, at once, require 140 applications to be rewritten and host stacks to be updated. Rather 141 than that, we believe in piece-wise architectural changes that 142 require only one of the existing assets to be touched. ORCHIDs are 143 designed to address this situation: to allow people to experiment 144 with protocol stack extensions, such as secure overlay routing, HIP, 145 or Mobile IP privacy extensions, without requiring them to update 146 their applications. The goal is to facilitate large-scale 147 experiments with minimum user effort. 149 For example, there already exists, at the time of this writing, HIP 150 implementations that run fully in user space, using the operating 151 system to divert a certain part of the IPv6 address space to a user 152 level daemon for HIP processing. In practical terms, these 153 implementations are already using a certain IPv6 prefix for 154 differentiating HIP identifiers from IPv6 addresses, allowing them 155 both to be used by the existing applications via the existing APIs. 157 The Overlay Routable Cryptographic Hash Identifiers originally 158 defined in [RFC4843] lacked a mechanism for cryptographic algorithm 159 agility. The updated ORCHID format specified in this document 160 removes this limitation by encoding in the identifier itself an index 161 to the suite of cryptographic algorithms in use. 163 Because the updated ORCHIDv2 format is not backward compatible with 164 the earlier one, IANA is requested to allocate a new 28-bit prefix 165 out of the IANA IPv6 Special Purpose Address Block, namely 2001: 166 0000::/23, as per [RFC4773]. The prefix that was temporarily 167 allocated for the experimental ORCHID is to be returned to IANA in 168 2014 [RFC4843]. 170 1.2. ORCHID Properties 172 ORCHIDs are designed to have the following properties: 174 o Statistical uniqueness; also see Appendix A 176 o Secure binding to the input parameters used in their generation 177 (i.e., the context identifier and a bitstring). 179 o Aggregation under a single IPv6 prefix. Note that this is only 180 needed due to the co-ordination need as indicated above. Without 181 such co-ordination need, the ORCHID namespace could potentially be 182 completely flat. 184 o Non-routability at the IP layer, by design. 186 o Routability at some overlay layer, making them, from an 187 application point of view, semantically similar to IPv6 addresses. 189 As mentioned above, ORCHIDs are intended to be generated and used in 190 different contexts, as suitable for different mechanisms and 191 protocols. The context identifier is meant to be used to 192 differentiate between the different contexts; see Appendix A for a 193 discussion of the related API and kernel level implementation issues, 194 and Section 4 for the design choices explaining why the context 195 identifiers are used. 197 1.3. Expected use of ORCHIDs 199 Examples of identifiers and protocols that are expected to adopt the 200 ORCHID format include Host Identity Tags (HIT) in the Host Identity 201 Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile 202 Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 203 [PRIVACYTEXT]. The format is designed to be extensible to allow 204 other experimental proposals to share the same namespace. 206 1.4. Action Plan 208 This document requests IANA to allocate a prefix out of the IPv6 209 addressing space for Overlay Routable Cryptographic Hash Identifiers. 211 1.5. Terminology 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 2. Cryptographic Hash Identifier Construction 219 An ORCHID is generated using the ORCHID Generation Algorithm (OGA) 220 below. The algorithm takes a bitstring and a context identifier as 221 input and produces an ORCHID as output. The hash function used in 222 the ORCHID Generation Algorithm is defined for each OGA identifier by 223 the specification for the respective usage context (e.g., HIPv2). 225 Input := any bitstring 226 OGA ID := 4-bits Orchid Generation Algorithm identifier 227 Hash Input := Context ID | Input 228 Hash := Hash_function( Hash Input ) 229 ORCHID := Prefix | Encode_96( Hash ) 231 where: 233 | : Denotes concatenation of bitstrings 235 Input : A bitstring that is unique or statistically unique 236 within a given context. The bitstring is intended 237 to be associated with the to-be-created ORCHID in 238 the given context. 240 Context ID : A randomly generated value defining the expected 241 usage context for the particular ORCHID and the 242 hash function to be used for generation of ORCHIDs 243 in this context. These values are allocated out of 244 the namespace introduced for CGA Type Tags; see RFC 245 3972 and 246 http://www.iana.org/assignments/cga-message-types. 248 OGA ID : A 4-bit long identifier for the Hash_function 249 in use within the specific usage context. 251 Hash_function : The one-way hash function (i.e., hash function 252 with pre-image resistance and second pre-image 253 resistance) to be used as identified by the 254 value for the OGA ID according document 255 defining the context usage identified by the 256 Context ID. For example, the version 2 of the 257 HIP specification defines SHA1 [RFC3174] as 258 the hash function to be used to generate 259 ORCHIDv2 used in the HIPv2 protocol when the 260 OGA ID is 3 [I-D.ietf-hip-rfc5201-bis]. 262 Encode_96( ) : An extraction function in which output is obtained 263 by extracting the middle 96-bit-long bitstring 264 from the argument bitstring. 266 Prefix : A constant 28-bit-long bitstring value 267 (IANA TBD 2001:????::/28 ?). 269 To form an ORCHID, two pieces of input data are needed. The first 270 piece can be any bitstring, but is typically expected to contain a 271 public cryptographic key and some other data. The second piece is a 272 context identifier, which is a 128-bit-long datum, allocated as 273 specified in Section 6. Each specific experiment (such as HIP HITs 274 or MIP6 TMIs) is expected to allocate their own, specific context 275 identifier. 277 The input bitstring and context identifier are concatenated to form 278 an input datum, which is then fed to the cryptographic hash function 279 to be used for the value of the OGA identifier according to the 280 document defining the context usage identified by the Context ID. 281 The result of the hash function is processed by an encoding function, 282 resulting in a 96-bit-long value. This value is prepended with the 283 concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The 284 result is the ORCHID, a 128-bit-long bitstring that can be used at 285 the IPv6 APIs in hosts participating to the particular experiment. 287 The ORCHID prefix is allocated under the IPv6 global unicast address 288 block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast 289 addresses. However, it should be noted that ORCHIDs do not conform 290 with the IPv6 global unicast address format defined in Section 2.5.4 291 of [RFC4291] since they do not have a 64-bit Interface ID formatted 292 as described in Section 2.5.1. of [RFC4291]. 294 3. Routing and Forwarding Considerations 296 ORCHIDs are designed to serve as location independent endpoint- 297 identifiers rather than IP-layer locators. Therefore, routers MAY be 298 configured not to forward any packets containing an ORCHID as a 299 source or a destination address. If the destination address is an 300 ORCHID but the source address is a valid unicast source address, 301 routers MAY be configured to generate an ICMP Destination 302 Unreachable, Administratively Prohibited message. 304 ORCHIDs are not designed for use in IPv6 routing protocols, since 305 such routing protocols are based on the architectural definition of 306 IPv6 addresses. Future non-IPv6 routing systems, such as overlay 307 routing systems, may be designed based on ORCHIDs. Any such ORCHID- 308 based routing system is out of scope of this document. 310 Router software MUST NOT include any special handling code for 311 ORCHIDs. In other words, the non-routability property of ORCHIDs, if 312 implemented, MUST be implemented via configuration and NOT by 313 hardwired software code. At this time, it is RECOMMENDED that the 314 default router configuration not handle ORCHIDs in any special way. 315 In other words, there is no need to touch existing or new routers due 316 to this experiment. If such a reason should later appear, for 317 example, due to a faulty implementation leaking ORCHIDs to the IP 318 layer, the prefix can be and should be blocked by a simple 319 configuration rule. 321 4. Design Choices 323 The design of this namespace faces two competing forces: 325 o As many bits as possible should be preserved for the hash result. 327 o It should be possible to share the namespace between multiple 328 mechanisms. 330 The desire to have a long hash result requires that the prefix be as 331 short as possible, and use few (if any) bits for additional encoding. 332 The present design takes this desire to the maximum: all the bits 333 beyond the prefix and the ORCHID generation algorithm identifier are 334 used as hash output. This leaves no bits in the ORCHID itself 335 available for identifying the context, however the 4 bits used to 336 encode the ORCHID generation algorithm identifier provides 337 cryptographich agility with respect to the hash function in use for a 338 given context; see Section 5. 340 The desire to allow multiple mechanisms to share the namespace has 341 been resolved by including the context identifier in the hash- 342 function input. While this does not allow the mechanism to be 343 directly inferred from a ORCHID, it allows one to verify that a given 344 input bitstring and ORCHID belong to a given context, with high- 345 probability; but also see Section 5. 347 5. Security Considerations 349 ORCHIDs are designed to be securely bound to the Context ID and the 350 bitstring used as the input parameters during their generation. To 351 provide this property, the ORCHID generation algorithm relies on the 352 second-preimage resistance (a.k.a. one-way) property of the hash 353 function used in the generation [RFC4270]. To have this property and 354 to avoid collisions, it is important that the allocated prefix is as 355 short as possible, leaving as many bits as possible for the hash 356 output. 358 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly 359 the same mechanism for generating an ORCHID from the input bitstring. 360 Allowing different mechanisms, without explicitly encoding the 361 mechanism in the Context ID or the ORCHID itself, would allow so- 362 called bidding-down attacks. That is, if multiple different hash 363 functions were allowed to construct ORCHIDs valid for the same 364 Context ID, and if one of the hash functions became insecure, that 365 would allow attacks against even those ORCHIDs valid for the same 366 Context ID that had been constructed using the other, still secure 367 hash functions. 369 An identifier for the hash function to be used for the ORCHID 370 generation is encoded in the ORCHID itself, while the semantic for 371 the values taken by this identifier are defined separately for each 372 Context ID. Therefore, the present design allows to use different 373 hash functions to be used per given Context ID for constructing 374 ORCHIDs from input bitstrings. If more secure hash functions are 375 later needed, newer values for the ORCHID generation algorithm can be 376 defined for the given Context ID. 378 In order to preserve a low enough probability of collisions (see 379 Appendix A), each method MUST utilize a mechanism that makes sure 380 that the distinct input bitstrings are either unique or statistically 381 unique within that context. There are several possible methods to 382 ensure this; for example, one can include into the input bitstring a 383 globally maintained counter value, a pseudo-random number of 384 sufficient entropy (minimum 96 bits), or a randomly generated public 385 cryptographic key. The Context ID makes sure that input bitstrings 386 from different contexts never overlap. These together make sure that 387 the probability of collisions is determined only by the probability 388 of natural collisions in the hash space and is not increased by a 389 possibility of colliding input bitstrings. 391 6. IANA Considerations 393 Because the updated ORCHIDv2 format is not backward compatible with 394 the earlier one, IANA is requested to allocate a new 28-bit prefix 395 out of the IANA IPv6 Special Purpose Address Block, namely 2001: 396 0000::/23, as per [RFC4773]. The prefix that was temporarily 397 allocated for the experimental ORCHID is to be returned to IANA in 398 2014 [RFC4843]. 400 The Context Identifier (or Context ID) is a randomly generated value 401 defining the usage context of an ORCHID and the hash function to be 402 used for generation of ORCHIDs in this context. This document 403 defines no specific value. The Context ID shares the name space 404 introduced for CGA Type Tags. Hence, defining new values follows the 405 rules of Section 8 of [RFC3972], i.e., First Come First Served. 407 7. Contributors 409 Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an 410 earlier, experimental version of this specification [RFC4843]. 412 8. Acknowledgments 414 Special thanks to Geoff Huston for his sharp but constructive 415 critique during the development of this memo. Tom Henderson helped 416 to clarify a number of issues. This document has also been improved 417 by reviews, comments, and discussions originating from the IPv6, 418 Internet Area, and IETF communities. 420 9. References 422 9.1. Normative references 424 [RFC2119] Bradner, S., "Key words for use in RFCs 425 to Indicate Requirement Levels", BCP 14, 426 RFC 2119, March 1997. 428 [RFC3972] Aura, T., "Cryptographically Generated 429 Addresses (CGA)", RFC 3972, March 2005. 431 9.2. Informative references 433 [Hi3] Nikander, P., Arkko, J., and B. Ohlman, 434 "Host Identity Indirection Infrastructure 435 (Hi3)", November 2004. 437 [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and 438 T. Henderson, "Host Identity Protocol 439 Version 2 (HIPv2)", 440 draft-ietf-hip-rfc5201-bis-11 (work in 441 progress), February 2013. 443 [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and 444 J. Rajahalme, "A Node Identity 445 Internetworking Architecture (NodeID)", 446 April 2006. 448 [PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension 449 for Mobile IPv6", Work in Progress, 450 July 2006. 452 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, 453 D., Groot, G., and E. Lear, "Address 454 Allocation for Private Internets", BCP 5, 455 RFC 1918, February 1996. 457 [RFC3174] Eastlake, D. and P. Jones, "US Secure 458 Hash Algorithm 1 (SHA1)", RFC 3174, 459 September 2001. 461 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on 462 Cryptographic Hashes in Internet 463 Protocols", RFC 4270, November 2005. 465 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 466 Addressing Architecture", RFC 4291, 467 February 2006. 469 [RFC4773] Huston, G., "Administration of the IANA 470 Special Purpose IPv6 Address Block", 471 RFC 4773, December 2006. 473 [RFC4843] Nikander, P., Laganier, J., and F. 474 Dupont, "An IPv6 Prefix for Overlay 475 Routable Cryptographic Hash Identifiers 476 (ORCHID)", RFC 4843, April 2007. 478 Appendix A. Collision Considerations 480 As noted earlier, the aim is that so long as keys are not reused, 481 ORCHIDs be globally unique in a statistical sense. That is, given 482 the ORCHID referring to a given entity, the probability of the same 483 ORCHID being used to refer to another entity elsewhere in the 484 Internet must be sufficiently low so that it can be ignored for most 485 practical purposes. We believe that the presented design meets this 486 goal; see Section 4. 488 As mentioned above, ORCHIDs are expected to be used at the legacy 489 IPv6 APIs between consenting hosts. The context ID is intended to 490 differentiate between the various experiments, or contexts, sharing 491 the ORCHID namespace. However, the context ID is not present in the 492 ORCHID itself, but only in front of the input bitstring as an input 493 to the hash function. While this may lead to certain implementation- 494 related complications, we believe that the trade-off of allowing the 495 hash result part of an ORCHID being longer more than pays off the 496 cost. 498 Because ORCHIDs are not routable at the IP layer, in order to send 499 packets using ORCHIDs at the API level, the sending host must have 500 additional overlay state within the stack to determine which 501 parameters (e.g., what locators) to use in the outgoing packet. An 502 underlying assumption here, and a matter of fact in the proposals 503 that the authors are aware of, is that there is an overlay protocol 504 for setting up and maintaining this additional state. It is assumed 505 that the state-set-up protocol carries the input bitstring, and that 506 the resulting ORCHID-related state in the stack can be associated 507 back with the appropriate context and state-set-up protocol. 509 Appendix B. Changes from RFC 4843 511 o Updated HIP references to revised HIP specifications. 513 o The Overlay Routable Cryptographic Hash Identifiers originally 514 defined in [RFC4843] lacked a mechanism for cryptographic 515 algorithm agility. The updated ORCHID format specified in this 516 document removes this limitation by encoding in the identifier 517 itself an index to the suite of cryptographic algorithms in use. 519 o Moved the collision considerations section into an annex, and 520 removed unnecessary discussions. 522 o Removed the discussion on overlay routing. 524 Authors' Addresses 526 Julien Laganier 527 Juniper Networks 528 1094 North Mathilda Avenue 529 Sunnyvale, CA 94089 530 USA 532 Phone: +1 408 936 0385 533 EMail: julien.ietf@gmail.com 535 Francis Dupont 536 Internet Systems Consortium 538 EMail: fdupont@isc.org