idnits 2.17.1 draft-ietf-idr-bgp-open-policy-19.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2022) is 838 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) ** Downref: Normative reference to an Informational RFC: RFC 7908 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Azimov 3 Internet-Draft Qrator Labs & Yandex 4 Intended status: Standards Track E. Bogomazov 5 Expires: July 11, 2022 Qrator Labs 6 R. Bush 7 Internet Initiative Japan & Arrcus, Inc. 8 K. Patel 9 Arrcus 10 K. Sriram 11 USA NIST 12 January 7, 2022 14 Route Leak Prevention and Detection using Roles in UPDATE and OPEN 15 Messages 16 draft-ietf-idr-bgp-open-policy-19 18 Abstract 20 Route leaks are the propagation of BGP prefixes that violate 21 assumptions of BGP topology relationships, e.g., announcing a route 22 learned from one transit provider to another transit provider or a 23 lateral (i.e., non-transit) peer or announcing a route learned from 24 one lateral peer to another lateral peer or a transit provider. 25 These are usually the result of misconfigured or absent BGP route 26 filtering or lack of coordination between autonomous systems (ASes). 27 Existing approaches to leak prevention rely on marking routes by 28 operator configuration, with no check that the configuration 29 corresponds to that of the eBGP neighbor, or enforcement that the two 30 eBGP speakers agree on the relationship. This document enhances the 31 BGP OPEN message to establish an agreement of the relationship on 32 each eBGP session between autonomous systems in order to enforce 33 appropriate configuration on both sides. Propagated routes are then 34 marked according to the agreed relationship, allowing both prevention 35 and detection of route leaks. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 41 "OPTIONAL" in this document are to be interpreted as described in 42 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 43 capitals, as shown here. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on July 11, 2022. 62 Copyright Notice 64 Copyright (c) 2022 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 4 82 3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3.1. BGP Role Capability . . . . . . . . . . . . . . . . . . . 5 84 3.2. Role Correctness . . . . . . . . . . . . . . . . . . . . 6 85 4. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 7 86 5. Additional Considerations . . . . . . . . . . . . . . . . . . 9 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 91 8.2. Informative References . . . . . . . . . . . . . . . . . 12 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 96 1. Introduction 98 Route leaks are the propagation of BGP prefixes that violate 99 assumptions of BGP topology relationships, e.g., announcing a route 100 learned from one transit provider to another transit provider or a 101 lateral (i.e., non-transit) peer or announcing a route learned from 102 one lateral peer to another lateral peer or a transit provider 103 [RFC7908]. These are usually the result of misconfigured or absent 104 BGP route filtering or lack of coordination between autonomous 105 systems (ASes). 107 Existing approaches to leak prevention rely on marking routes by 108 operator configuration, with no check that the configuration 109 corresponds to that of the eBGP neighbor, or enforcement that the two 110 eBGP speakers agree on the relationship. This document enhances the 111 BGP OPEN message to establish an agreement of the relationship on 112 each eBGP session between autonomous systems in order to enforce 113 appropriate configuration on both sides. Propagated routes are then 114 marked according to the agreed relationship, allowing both prevention 115 and detection of route leaks. 117 This document provides configuration automation using BGP Roles, 118 which are negotiated using a BGP Role Capability in the OPEN message 119 [RFC5492]. An eBGP speaker may require the use of this capability 120 and confirmation of BGP Role with a neighbor for the BGP OPEN to 121 succeed. 123 An optional, transitive BGP Path Attribute, called Only to Customer 124 (OTC), is specified in Section 4. It prevents ASes from creating 125 leaks and detects leaks created by the ASes in the middle of an AS 126 path. The main focus/applicability is the Internet (IPv4 and IPv6 127 unicast route advertisements). 129 1.1. Terminology 131 In the rest of this document, the term "Peer" is used to refer to a 132 "lateral (i.e., non-transit) peer" for simplicity. Also, the terms 133 Provider and Customer are used to refer to a transit provider and a 134 transit customer, respectively. Further, the terms RS and RS-Client 135 are used to refer to a Route Server and its client, respectively. 137 The terms "local AS" and "remote AS" are used to refer to the two 138 ends of an eBGP session. The "local AS" is the AS where the protocol 139 action being described is to be performed, and "remote AS" is the AS 140 at the other end of the eBGP session in consideration. 142 The use of the term "route is ineligible" in this document has the 143 same meaning as in [RFC4271], i.e., "route is ineligible to be 144 installed in Loc-RIB and will be excluded from the next phase of 145 route selection." 147 2. Peering Relationships 149 The terms defined and used in this document (see below) do not 150 necessarily represent business relationships based on payment 151 agreements. These terms are used to represent restrictions on BGP 152 route propagation, sometimes known as the Gao-Rexford model [Gao]. 153 The following is a list of BGP Roles for eBGP peering and the 154 corresponding rules for route propagation: 156 Provider: MAY propagate any available route to a Customer. 158 Customer: MAY propagate any route learned from a Customer, or 159 locally originated, to a Provider. All other routes MUST NOT be 160 propagated. 162 Route Server (RS): MAY propagate any available route to a Route 163 Server Client (RS-Client). 165 RS-Client: MAY propagate any route learned from a Customer, or 166 locally originated, to an RS. All other routes MUST NOT be 167 propagated. 169 Peer: MAY propagate any route learned from a Customer, or locally 170 originated, to a Peer. All other routes MUST NOT be propagated. 172 If the local AS has one of the above Roles (in the order shown), then 173 the corresponding peering relationship with the remote AS is 174 Provider-to-Customer, Customer-to-Provider, RS-to-RS-Client, RS- 175 Client-to-RS, or Peer-to-Peer (i.e., lateral peers), respectively. 176 These are called normal peering relationships. 178 If the local AS has more than one peering role with the remote AS 179 such peering relation is called Complex. An example is when the 180 peering relationship is Provider-to-Customer for some prefixes while 181 it is Peer-to-Peer for other prefixes [Gao]. 183 A BGP speaker may apply policy to reduce what is announced, and a 184 recipient may apply policy to reduce the set of routes they accept. 185 Violation of the above rules may result in route leaks. Automatic 186 enforcement of these rules should significantly reduce route leaks 187 that may otherwise occur due to manual configuration mistakes. 189 As specified in Section 4, the Only to Customer (OTC) Attribute is 190 used to identify all the routes in the AS that have been received 191 from a Peer, Provider, or RS. 193 3. BGP Role 195 The BGP Role characterizes the relationship between the eBGP speakers 196 forming a session. One of the Roles described below SHOULD be 197 configured at the local AS for each eBGP session (see definitions in 198 Section 1.1) based on the local AS's knowledge of its Role. The only 199 exception is when the eBGP connection is Complex (see Section 5). 200 BGP Roles are mutually confirmed using the BGP Role Capability 201 (described in Section 3.1) on each eBGP session. 203 Allowed Roles for eBGP sessions are: 205 o Provider - the local AS is a transit Provider of the remote AS; 207 o Customer - the local AS is a transit Customer of the remote AS; 209 o RS - the local AS is a Route Server (usually at an Internet 210 exchange point) and the remote AS is its RS-Client; 212 o RS-Client - the local AS is a client of an RS and the RS is the 213 remote AS; 215 o Peer - the local and remote ASes are Peers (i.e., have a lateral 216 peering relationship). 218 3.1. BGP Role Capability 220 The BGP Role Capability is defined as follows: 222 o Code - 9 224 o Length - 1 (octet) 226 o Value - integer corresponding to speaker's BGP Role (see Table 1). 228 +-------+------------------------------+ 229 | Value | Role name (for the local AS) | 230 +-------+------------------------------+ 231 | 0 | Provider | 232 | 1 | RS | 233 | 2 | RS-Client | 234 | 3 | Customer | 235 | 4 | Peer (Lateral Peer) | 236 | 5-255 | Unassigned | 237 +-------+------------------------------+ 239 Table 1: Predefined BGP Role Values 241 If BGP Role is locally configured, the eBGP speaker MUST advertise 242 BGP Role Capability in the BGP OPEN message. An eBGP speaker MUST 243 NOT advertise multiple versions of the BGP Role Capability. 245 3.2. Role Correctness 247 Section 3.1 described how BGP Role encodes the relationship on each 248 eBGP session between autonomous systems (ASes). 250 The mere receipt of BGP Role Capability does not automatically 251 guarantee the Role agreement between two eBGP neighbors. If the BGP 252 Role Capability is advertised, and one is also received from the 253 peer, the roles MUST correspond to the relationships in Table 2. If 254 the roles do not correspond, the BGP speaker MUST reject the 255 connection using the Role Mismatch Notification (code 2, subcode 256 TBD). 258 +---------------+----------------+ 259 | Local AS Role | Remote AS Role | 260 +---------------+----------------+ 261 | Provider | Customer | 262 | Customer | Provider | 263 | RS | RS-Client | 264 | RS-Client | RS | 265 | Peer | Peer | 266 +---------------+----------------+ 268 Table 2: Allowed Pairs of Role Capabilities 270 For backward compatibility, if the BGP Role Capability is sent but 271 one is not received, the BGP Speaker SHOULD ignore the absence of the 272 BGP Role Capability and proceed with session establishment. The 273 locally configured BGP Role is used for the procedures described in 274 Section 4. 276 An operator may choose to apply a "strict mode" in which the receipt 277 of a BGP Role Capability from the remote AS is required. When 278 operating in the "strict mode", if the BGP Role Capability is sent, 279 but one is not received, then the connection is rejected using the 280 Role Mismatch Notification (code 2, subcode TBD). See comments in 281 Section 7. 283 If an eBGP speaker receives multiple but identical BGP Role 284 Capabilities with the same value in each, then the speaker must 285 consider it to be a single BGP Role Capability and proceed [RFC5492]. 286 If multiple BGP Role Capabilities are received and not all of them 287 have the same value, then the BGP speaker MUST reject the connection 288 using the Role Mismatch Notification (code 2, subcode TBD). 290 The BGP Role value for the local AS (in conjunction with the OTC 291 Attribute in the received UPDATE message) is used in the route leak 292 prevention and detection procedures described in Section 4. 294 4. BGP Only to Customer (OTC) Attribute 296 The Only to Customer (OTC) Attribute is an optional transitive path 297 attribute of the UPDATE message with Attribute Type Code 35 and a 298 length of 4 octets. The purpose of this attribute is to guarantee 299 that once a route is sent to a Customer, Peer, or RS-Client, it will 300 subsequently go only to Customers. The attribute value is an AS 301 number (ASN) determined by the policy described below. 303 The following ingress policy applies to the processing of the OTC 304 Attribute: 306 1. If a route with the OTC Attribute is received from a Customer or 307 RS-Client, then it is a route leak and MUST be considered 308 ineligible (see Section 1.1). 310 2. If a route with the OTC Attribute is received from a Peer and the 311 Attribute has a value that is not equal to the remote (i.e., 312 Peer's) AS number, then it is a route leak and MUST be considered 313 ineligible. 315 3. If a route is received from a Provider, Peer, or RS, and the OTC 316 Attribute is not present, then it MUST be added with a value 317 equal to the AS number of the remote AS. 319 The following egress policy applies to the processing of the OTC 320 Attribute: 322 1. If a route is to be advertised to a Customer, Peer, or RS-Client 323 (when the sender is an RS), and the OTC Attribute is not present, 324 then an OTC Attribute MUST be added with a value equal to the AS 325 number of the local AS. 327 2. If a route already contains the OTC Attribute, it MUST NOT be 328 propagated to Providers, Peers, or RS(s). 330 The described policies provide both leak prevention for the local AS 331 and leak detection and mitigation multiple hops away. In the case of 332 prevention at the local AS, the presence of an OTC Attribute 333 indicates to the egress router that the route was learned from a 334 Peer, Provider, or RS, and it can be advertised only to the 335 customers. The same OTC Attribute which is set locally also provides 336 a way to detect route leaks by an AS multiple hops away if a route is 337 received from a Customer, Peer, or RS-Client. 339 The OTC Attribute may be set by the egress policy of the remote AS or 340 by the ingress policy of the local AS. In both scenarios, the OTC 341 value will be the same. This makes the scheme more robust and 342 benefits early adopters. 344 If an eBGP speaker receives an UPDATE with an OTC Attribute with a 345 length different from 4 octets, then the UPDATE SHALL be considered 346 malformed. If malformed, the UPDATE message SHALL be handled using 347 the approach of "treat-as-withdraw" [RFC7606]. 349 The procedures specified in this document are NOT RECOMMENDED to be 350 used between autonomous systems in an AS Confederation [RFC5065]. If 351 an OTC Attribute is added on egress from the AS Confederation, its 352 value MUST equal the AS Confederation Identifier. Also, on egress 353 from the AS Confederation, an UPDATE MUST NOT contain an OTC 354 Attribute with a value corresponding to any Member-AS Number other 355 than the AS Confederation Identifier. 357 The procedures specified in this document in scenarios that use 358 private AS numbers behind an Internet-facing ASN (e.g., a data center 359 network [RFC7938] or stub customer) may be used, but any details are 360 outside the scope of this document. On egress from the Internet- 361 facing AS, the OTC Attribute MUST NOT contain a value other than the 362 Internet-facing ASN. 364 Once the OTC Attribute has been set, it MUST be preserved unchanged 365 (this also applies to an AS Confederation). 367 The described ingress and egress policies are applicable only for 368 unicast IPv4 and IPv6 address families and MUST NOT be applied to 369 other address families by default. The operator MUST NOT have the 370 ability to modify the policies defined in this section. 372 5. Additional Considerations 374 Roles MUST NOT be configured on an eBGP session with a Complex 375 peering relationship. If multiple eBGP sessions can segregate the 376 Complex peering relationship into eBGP sessions with normal peering 377 relationships, BGP Roles SHOULD be used on each of the resulting eBGP 378 sessions. 380 An operator may want to achieve an equivalent outcome by configuring 381 policies on a per-prefix basis to follow the definitions of peering 382 relations as described in Section 2. However, in this case, there 383 are no built-in measures to check the correctness of the per-prefix 384 peering configuration. 386 The incorrect setting of BGP Roles and/or OTC Attributes may affect 387 prefix propagation. Further, this document does not specify any 388 special handling of incorrect AS numbers in the OTC Attribute. 390 6. IANA Considerations 392 IANA has registered a new BGP Capability (Section 3.1) in the 393 "Capability Codes" registry's "IETF Review" range [RFC5492]. The 394 description for the new capability is "BGP Role". IANA has assigned 395 the value 9 [to be removed upon publication: 396 https://www.iana.org/assignments/capability-codes/capability- 397 codes.xhtml]. This document is the reference for the new capability. 399 The BGP Role capability includes a Value field, for which IANA is 400 requested to create and maintain a new sub-registry called "BGP Role 401 Value" in the Capability Codes registry. Assignments consist of a 402 Value and a corresponding Role name. Initially, this registry is to 403 be populated with the data contained in Table 1 found in Section 3.1. 404 Future assignments may be made by the "IETF Review" policy as defined 405 in [RFC8126]. The registry is as shown in Table 3. 407 +-------+--------------------------------+---------------+ 408 | Value | Role name (for the local AS) | Reference | 409 +-------+--------------------------------+---------------+ 410 | 0 | Provider | This document | 411 | 1 | RS | This document | 412 | 2 | RS-Client | This document | 413 | 3 | Customer | This document | 414 | 4 | Peer (i.e., Lateral Peer) | This document | 415 | 5-255 | To be assigned by IETF Review | 416 +-------+--------------------------------+---------------+ 418 Table 3: IANA Registry for BGP Role 420 IANA has registered a new OPEN Message Error subcode named the "Role 421 Mismatch" (see Section 3.2) in the OPEN Message Error subcodes 422 registry. IANA has assigned the value TBD [to be removed upon 423 publication: https://www.iana.org/assignments/bgp-parameters/bgp- 424 parameters.xhtml#bgp-parameters-6]. This document is the reference 425 for the new subcode. 427 IANA has also registered a new path attribute named "Only to Customer 428 (OTC)" (see Section 4) in the "BGP Path Attributes" registry. IANA 429 has assigned code value 35 [To be removed upon publication: 430 http://www.iana.org/assignments/bgp-parameters/bgp- 431 parameters.xhtml#bgp-parameters-2]. This document is the reference 432 for the new attribute. 434 7. Security Considerations 436 The security considerations of BGP (as specified in [RFC4271] and 437 [RFC4272]) apply. 439 This document proposes a mechanism using BGP Role for the prevention 440 and detection of route leaks that are the result of BGP policy 441 misconfiguration. A misconfiguration of the BGP Role may affect 442 prefix propagation. For example, if a downstream (i.e., towards a 443 Customer) peering link were misconfigured with a Provider or Peer 444 role, this will limit the number of prefixes that can be advertised 445 in this direction. On the other hand, if an upstream provider were 446 misconfigured (by a local AS) with the Customer role, this may result 447 in propagating routes that are received from other Providers or 448 Peers. But the BGP Role negotiation and the resulting confirmation 449 of Roles make such misconfigurations unlikely. 451 Setting the strict mode of operation for BGP Role negotiation as the 452 default may result in a situation where the eBGP session will not 453 come up after a software update. Implementations with such default 454 behavior are strongly discouraged. 456 Removing the OTC Attribute or changing its value can limit the 457 opportunity of route leak detection. Such activity can be done on 458 purpose as part of an on-path attack. For example, an AS can remove 459 the OTC Attribute on a received route and then leak the route to its 460 transit provider. This kind of threat is not new in BGP and it may 461 affect any Attribute (Note: BGPsec [RFC8205] offers protection only 462 for the AS_PATH Attribute). 464 Adding an OTC Attribute when the route is advertised from Customer to 465 Provider will limit the propagation of the route. Such a route may 466 be considered as ineligible by the immediate Provider or its Peers or 467 upper layer Providers. This kind of OTC Attribute addition is 468 unlikely to happen on the Provider side because it will limit the 469 traffic volume towards its Customer. On the Customer side, adding an 470 OTC Attribute for traffic engineering purposes is also discouraged 471 because it will limit route propagation in an unpredictable way. 473 8. References 475 8.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 483 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 484 DOI 10.17487/RFC4271, January 2006, 485 . 487 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 488 System Confederations for BGP", RFC 5065, 489 DOI 10.17487/RFC5065, August 2007, 490 . 492 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 493 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 494 2009, . 496 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 497 Patel, "Revised Error Handling for BGP UPDATE Messages", 498 RFC 7606, DOI 10.17487/RFC7606, August 2015, 499 . 501 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 502 and B. Dickson, "Problem Definition and Classification of 503 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 504 2016, . 506 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 507 Writing an IANA Considerations Section in RFCs", BCP 26, 508 RFC 8126, DOI 10.17487/RFC8126, June 2017, 509 . 511 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 512 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 513 May 2017, . 515 8.2. Informative References 517 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 518 global coordination", IEEE/ACM Transactions on 519 Networking, Volume 9, Issue 6, pp 689-692, DOI 520 10.1109/90.974523, December 2001, 521 . 523 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 524 RFC 4272, DOI 10.17487/RFC4272, January 2006, 525 . 527 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 528 BGP for Routing in Large-Scale Data Centers", RFC 7938, 529 DOI 10.17487/RFC7938, August 2016, 530 . 532 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 533 Specification", RFC 8205, DOI 10.17487/RFC8205, September 534 2017, . 536 Acknowledgments 538 The authors wish to thank Alvaro Retana, Andrei Robachevsky, Daniel 539 Ginsburg, Jeff Haas, Ruediger Volk, Pavel Lunin, Gyan Mishra, Ignas 540 Bagdonas, Sue Hares, and John Scudder for comments, suggestions, and 541 critique. 543 Contributors 545 Brian Dickson 546 Independent 547 Email: brian.peter.dickson@gmail.com 549 Doug Montgomery 550 USA National Institute of Standards and Technology 551 Email: dougm@nist.gov 553 Authors' Addresses 554 Alexander Azimov 555 Qrator Labs & Yandex 556 Ulitsa Lva Tolstogo 16 557 Moscow 119021 558 Russian Federation 560 Email: a.e.azimov@gmail.com 562 Eugene Bogomazov 563 Qrator Labs 564 1-y Magistralnyy tupik 5A 565 Moscow 123290 566 Russian Federation 568 Email: eb@qrator.net 570 Randy Bush 571 Internet Initiative Japan & Arrcus, Inc. 572 5147 Crystal Springs 573 Bainbridge Island, Washington 98110 574 United States of America 576 Email: randy@psg.com 578 Keyur Patel 579 Arrcus 580 2077 Gateway Place, Suite #400 581 San Jose, CA 95119 582 US 584 Email: keyur@arrcus.com 586 Kotikalapudi Sriram 587 USA National Institute of Standards and Technology 588 100 Bureau Drive 589 Gaithersburg, MD 20899 590 United States of America 592 Email: ksriram@nist.gov