idnits 2.17.1 draft-ietf-idr-bgp-open-policy-18.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 (December 4, 2021) is 867 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: June 7, 2022 Qrator Labs 6 R. Bush 7 Internet Initiative Japan & Arrcus, Inc. 8 K. Patel 9 Arrcus 10 K. Sriram 11 USA NIST 12 December 4, 2021 14 Route Leak Prevention and Detection using Roles in UPDATE and OPEN 15 Messages 16 draft-ietf-idr-bgp-open-policy-18 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 June 7, 2022. 62 Copyright Notice 64 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 11 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 A BGP speaker may apply policy to reduce what is announced, and a 173 recipient may apply policy to reduce the set of routes they accept. 174 Violation of the above rules may result in route leaks. Automatic 175 enforcement of these rules should significantly reduce route leaks 176 that may otherwise occur due to manual configuration mistakes. 178 As specified in Section 4, the Only to Customer (OTC) Attribute is 179 used to identify all the routes in the AS that have been received 180 from a Peer, Provider, or RS. 182 3. BGP Role 184 The BGP Role characterizes the relationship between the eBGP speakers 185 forming a session. One of the Roles described below SHOULD be 186 configured at the local AS for each eBGP session (see definitions in 187 Section 1.1) based on the local AS's knowledge of its Role. The only 188 exception is when the eBGP connection is 'complex' (see Section 5). 190 BGP Roles are mutually confirmed using the BGP Role Capability 191 (described in Section 3.1) on each eBGP session. 193 Allowed Roles for eBGP sessions are: 195 o Provider - the local AS is a transit Provider of the remote AS; 197 o Customer - the local AS is a transit Customer of the remote AS; 199 o RS - the local AS is a Route Server (usually at an Internet 200 exchange point) and the remote AS is its RS-Client; 202 o RS-Client - the local AS is a client of an RS and the RS is the 203 remote AS; 205 o Peer - the local and remote ASes are Peers (i.e., have a lateral 206 peering relationship). 208 3.1. BGP Role Capability 210 The BGP Role Capability is defined as follows: 212 o Code - 9 214 o Length - 1 (octet) 216 o Value - integer corresponding to speaker's BGP Role (see Table 1). 218 +-------+------------------------------+ 219 | Value | Role name (for the local AS) | 220 +-------+------------------------------+ 221 | 0 | Provider | 222 | 1 | RS | 223 | 2 | RS-Client | 224 | 3 | Customer | 225 | 4 | Peer (Lateral Peer) | 226 | 5-255 | Unassigned | 227 +-------+------------------------------+ 229 Table 1: Predefined BGP Role Values 231 If BGP Role is locally configured, the eBGP speaker MUST advertise 232 BGP Role Capability in the BGP OPEN message. An eBGP speaker MUST 233 NOT advertise multiple versions of the BGP Role Capability. 235 3.2. Role Correctness 237 Section 3.1 described how BGP Role encodes the relationship on each 238 eBGP session between autonomous systems (ASes). 240 The mere receipt of BGP Role Capability does not automatically 241 guarantee the Role agreement between two eBGP neighbors. If the BGP 242 Role Capability is advertised, and one is also received from the 243 peer, the roles MUST correspond to the relationships in Table 2. If 244 the roles do not correspond, the BGP speaker MUST reject the 245 connection using the Role Mismatch Notification (code 2, subcode 8). 247 +---------------+----------------+ 248 | Local AS Role | Remote AS Role | 249 +---------------+----------------+ 250 | Provider | Customer | 251 | Customer | Provider | 252 | RS | RS-Client | 253 | RS-Client | RS | 254 | Peer | Peer | 255 +---------------+----------------+ 257 Table 2: Allowed Pairs of Role Capabilities 259 For backward compatibility, if the BGP Role Capability is sent but 260 one is not received, the BGP Speaker SHOULD ignore the absence of the 261 BGP Role Capability and proceed with session establishment. The 262 locally configured BGP Role is used for the procedures described in 263 Section 4. 265 An operator may choose to apply a "strict mode" in which the receipt 266 of a BGP Role Capability from the remote AS is required. When 267 operating in the "strict mode", if the BGP Role Capability is sent, 268 but one is not received, then the connection is rejected using the 269 Role Mismatch Notification (code 2, subcode 8). See comments in 270 Section 7. 272 If an eBGP speaker receives multiple but identical BGP Role 273 Capabilities with the same value in each, then the speaker must 274 consider it to be a single BGP Role Capability and proceed [RFC5492]. 275 If multiple BGP Role Capabilities are received and not all of them 276 have the same value, then the BGP speaker MUST reject the connection 277 using the Role Mismatch Notification (code 2, subcode 8). 279 The BGP Role value for the local AS is used in the route leak 280 prevention and detection procedures described in Section 4. 282 4. BGP Only to Customer (OTC) Attribute 284 The Only to Customer (OTC) Attribute is an optional transitive path 285 attribute with Attribute Type Code 35 and a length of 4 octets. The 286 purpose of this attribute is to guarantee that once a route is sent 287 to a Customer, Peer, or RS-Client, it will subsequently go only to 288 Customers. The attribute value is an AS number (ASN) determined by 289 the policy described below. 291 The following ingress policy applies to the processing of the OTC 292 Attribute: 294 1. If a route with the OTC Attribute is received from a Customer or 295 RS-Client, then it is a route leak and MUST be considered 296 ineligible (see Section 1.1). 298 2. If a route with the OTC Attribute is received from a Peer and at 299 least one of the OTC Attributes has a value that is not equal to 300 the remote (i.e., Peer's) AS number, then it is a route leak and 301 MUST be considered ineligible. 303 3. If a route is received from a Provider, Peer, or RS, and the OTC 304 Attribute is not present, then it MUST be added with a value 305 equal to the AS number of the remote AS. 307 The following egress policy applies to the processing of the OTC 308 Attribute: 310 1. If a route is to be advertised to a Customer, Peer, or RS-Client 311 (when the sender is an RS), and the OTC Attribute is not present, 312 then an OTC Attribute MUST be added with a value equal to the AS 313 number of the local AS. 315 2. If a route already contains the OTC Attribute, it MUST NOT be 316 propagated to Providers, Peers, or RS(s). 318 The described policies provide both leak prevention for the local AS 319 and leak detection and mitigation multiple hops away. In the case of 320 prevention at the local AS, the presence of an OTC Attribute 321 indicates to the egress router that the route was learned from a 322 Peer, Provider, or RS, and it can be advertised only to the 323 customers. The same OTC Attribute which is set locally also provides 324 a way to detect route leaks by an AS multiple hops away if a route is 325 received from a Customer, Peer, or RS-Client. 327 The OTC Attribute may be set by the egress policy of the remote AS or 328 by the ingress policy of the local AS. In both scenarios, the OTC 329 value will be the same. This makes the scheme more robust and 330 benefits early adopters. 332 If an eBGP speaker receives an UPDATE with an OTC Attribute with a 333 length different from 4 octets, then the UPDATE SHALL be considered 334 malformed. If malformed, the UPDATE message SHALL be handled using 335 the approach of "treat-as-withdraw" [RFC7606]. 337 The procedures specified in this document are NOT RECOMMENDED to be 338 used between autonomous systems in an AS Confederation [RFC5065]. If 339 an OTC Attribute is added on egress from the AS Confederation, its 340 value MUST equal the AS Confederation Identifier. Also, on egress 341 from the AS Confederation, an UPDATE MUST NOT contain an OTC 342 Attribute with a value corresponding to any Member-AS Number other 343 than the AS Confederation Identifier. 345 The procedures specified in this document in scenarios that use 346 private AS numbers behind an Internet-facing ASN (e.g., a data center 347 network [RFC7938] or stub customer) may be used, but any details are 348 outside the scope of this document. On egress from the Internet- 349 facing AS, the OTC Attribute MUST NOT contain a value other than the 350 Internet-facing ASN. 352 Once the OTC Attribute has been set, it MUST be preserved unchanged 353 (this also applies to an AS Confederation). 355 Correct implementation of the procedures specified in this document 356 is not expected to result in the presence of multiple OTC Attributes 357 in an UPDATE. However, if an eBGP speaker receives multiple OTC 358 Attributes with a route, then the only difference in the processing 359 is in Step 2 of the ingress policy. 361 The described ingress and egress policies are applicable only for 362 unicast IPv4 and IPv6 address families and MUST NOT be applied to 363 other address families by default. The operator MUST NOT have the 364 ability to modify the policies defined in this section. 366 5. Additional Considerations 368 There are peering relationships that are 'complex', i.e., both 369 parties intentionally advertise prefixes received from each other to 370 their Peers and/or transit Providers. If multiple eBGP sessions can 371 segregate the 'complex' parts of the relationship, then the complex 372 peering roles can be segregated into different normal eBGP sessions, 373 and BGP Roles MUST be used on each of the resulting normal (non- 374 complex) eBGP sessions. 376 No Roles SHOULD be configured on a 'complex' eBGP session (assuming 377 it is not segregated). An operator may want to achieve an equivalent 378 outcome by configuring policies on a per-prefix basis to follow the 379 definitions of peering relations as described in Section 2. However, 380 in this case, there are no built-in measures to check the correctness 381 of the per-prefix peering configuration. 383 The incorrect setting of BGP Roles and/or OTC Attributes may affect 384 prefix propagation. Further, this document does not specify any 385 special handling of incorrect AS numbers in the OTC Attribute. 387 6. IANA Considerations 389 IANA has registered a new BGP Capability (Section 3.1) in the 390 "Capability Codes" registry's "IETF Review" range [RFC5492]. The 391 description for the new capability is "BGP Role". IANA has assigned 392 the value 9 [to be removed upon publication: 393 https://www.iana.org/assignments/capability-codes/capability- 394 codes.xhtml]. This document is the reference for the new capability. 396 The BGP Role capability includes a Value field, for which IANA is 397 requested to create and maintain a new sub-registry called "BGP Role 398 Value" in the Capability Codes registry. Assignments consist of a 399 Value and a corresponding Role name. Initially, this registry is to 400 be populated with the data contained in Table 1 found in Section 3.1. 401 Future assignments may be made by the "IETF Review" policy as defined 402 in [RFC8126]. The registry is as shown in Table 3. 404 +-------+--------------------------------+---------------+ 405 | Value | Role name (for the local AS) | Reference | 406 +-------+--------------------------------+---------------+ 407 | 0 | Provider | This document | 408 | 1 | RS | This document | 409 | 2 | RS-Client | This document | 410 | 3 | Customer | This document | 411 | 4 | Peer (i.e., Lateral Peer) | This document | 412 | 5-255 | To be assigned by IETF Review | 413 +-------+--------------------------------+---------------+ 415 Table 3: IANA Registry for BGP Role 417 IANA has registered a new OPEN Message Error subcode named the "Role 418 Mismatch" (see Section 3.2) in the OPEN Message Error subcodes 419 registry. IANA has assigned the value 8 [to be removed upon 420 publication: https://www.iana.org/assignments/bgp-parameters/bgp- 421 parameters.xhtml#bgp-parameters-6]. This document is the reference 422 for the new subcode. 424 IANA has also registered a new path attribute named "Only to Customer 425 (OTC)" (see Section 4) in the "BGP Path Attributes" registry. IANA 426 has assigned code value 35 [To be removed upon publication: 427 http://www.iana.org/assignments/bgp-parameters/bgp- 428 parameters.xhtml#bgp-parameters-2]. This document is the reference 429 for the new attribute. 431 7. Security Considerations 433 The security considerations of BGP (as specified in [RFC4271] and 434 [RFC4272]) apply. 436 This document proposes a mechanism using BGP Role for the prevention 437 and detection of route leaks that are the result of BGP policy 438 misconfiguration. A misconfiguration of the BGP Role may affect 439 prefix propagation. For example, if a downstream (i.e., towards a 440 Customer) peering link were misconfigured with a Provider or Peer 441 role, this will limit the number of prefixes that can be advertised 442 in this direction. On the other hand, if an upstream provider were 443 misconfigured (by a local AS) with the Customer role, this may result 444 in propagating routes that are received from other Providers or 445 Peers. But the BGP Role negotiation and the resulting confirmation 446 of Roles make such misconfigurations unlikely. 448 Setting the strict mode of operation for BGP Role negotiation as the 449 default may result in a situation where the eBGP session will not 450 come up after a software update. Implementations with such default 451 behavior are strongly discouraged. 453 Removing the OTC Attribute or changing its value can limit the 454 opportunity of route leak detection. Such activity can be done on 455 purpose as part of an on-path attack. For example, an AS can remove 456 the OTC Attribute on a received route and then leak the route to its 457 transit provider. This kind of threat is not new in BGP and it may 458 affect any Attribute (Note: BGPsec [RFC8205] offers protection only 459 for the AS_PATH Attribute). 461 Adding an OTC Attribute when the route is advertised from Customer to 462 Provider will limit the propagation of the route. Such a route may 463 be considered as ineligible by the immediate Provider or its Peers or 464 upper layer Providers. This kind of OTC Attribute addition is 465 unlikely to happen on the Provider side because it will limit the 466 traffic volume towards its Customer. On the Customer side, adding an 467 OTC Attribute for traffic engineering purposes is also discouraged 468 because it will limit route propagation in an unpredictable way. 470 8. References 472 8.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 480 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 481 DOI 10.17487/RFC4271, January 2006, 482 . 484 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 485 System Confederations for BGP", RFC 5065, 486 DOI 10.17487/RFC5065, August 2007, 487 . 489 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 490 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 491 2009, . 493 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 494 Patel, "Revised Error Handling for BGP UPDATE Messages", 495 RFC 7606, DOI 10.17487/RFC7606, August 2015, 496 . 498 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 499 and B. Dickson, "Problem Definition and Classification of 500 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 501 2016, . 503 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 504 Writing an IANA Considerations Section in RFCs", BCP 26, 505 RFC 8126, DOI 10.17487/RFC8126, June 2017, 506 . 508 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 509 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 510 May 2017, . 512 8.2. Informative References 514 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 515 global coordination", IEEE/ACM Transactions on 516 Networking, Volume 9, Issue 6, pp 689-692, DOI 517 10.1109/90.974523, December 2001, 518 . 520 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 521 RFC 4272, DOI 10.17487/RFC4272, January 2006, 522 . 524 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 525 BGP for Routing in Large-Scale Data Centers", RFC 7938, 526 DOI 10.17487/RFC7938, August 2016, 527 . 529 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 530 Specification", RFC 8205, DOI 10.17487/RFC8205, September 531 2017, . 533 Acknowledgments 535 The authors wish to thank Alvaro Retana, Andrei Robachevsky, Daniel 536 Ginsburg, Jeff Haas, Ruediger Volk, Pavel Lunin, Gyan Mishra, Ignas 537 Bagdonas, Sue Hares, and John Scudder for comments, suggestions, and 538 critique. 540 Contributors 542 Brian Dickson 543 Independent 544 Email: brian.peter.dickson@gmail.com 546 Doug Montgomery 547 USA National Institute of Standards and Technology 548 Email: dougm@nist.gov 550 Authors' Addresses 552 Alexander Azimov 553 Qrator Labs & Yandex 554 Ulitsa Lva Tolstogo 16 555 Moscow 119021 556 Russian Federation 558 Email: a.e.azimov@gmail.com 559 Eugene Bogomazov 560 Qrator Labs 561 1-y Magistralnyy tupik 5A 562 Moscow 123290 563 Russian Federation 565 Email: eb@qrator.net 567 Randy Bush 568 Internet Initiative Japan & Arrcus, Inc. 569 5147 Crystal Springs 570 Bainbridge Island, Washington 98110 571 United States of America 573 Email: randy@psg.com 575 Keyur Patel 576 Arrcus 577 2077 Gateway Place, Suite #400 578 San Jose, CA 95119 579 US 581 Email: keyur@arrcus.com 583 Kotikalapudi Sriram 584 USA National Institute of Standards and Technology 585 100 Bureau Drive 586 Gaithersburg, MD 20899 587 United States of America 589 Email: ksriram@nist.gov