idnits 2.17.1 draft-ietf-idr-bgp-open-policy-16.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The described ingress and egress policies are applicable only for unicast IPv4 and IPv6 address families and MUST not affect other address families by default. The operator MUST NOT have the ability to modify the policies defined in this section. -- The document date (August 10, 2021) is 961 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 4272 ** Downref: Normative reference to an Informational RFC: RFC 7908 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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: February 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 August 10, 2021 14 Route Leak Prevention and Detection using Roles in UPDATE and OPEN 15 Messages 16 draft-ietf-idr-bgp-open-policy-16 18 Abstract 20 Route leaks are the propagation of BGP prefixes that violate 21 assumptions of BGP topology relationships, e.g., passing a route 22 learned from one lateral peer to another lateral peer or a transit 23 provider and passing a route learned from one transit provider to 24 another transit provider or a lateral peer. Existing approaches to 25 leak prevention rely on marking routes by operator configuration, 26 with no check that the configuration corresponds to that of the eBGP 27 neighbor, or enforcement that the two eBGP speakers agree on the 28 relationship. This document enhances the BGP OPEN message to 29 establish an agreement of the relationship on each eBGP session 30 between autonomous systems in order to enforce appropriate 31 configuration on both sides. Propagated routes are then marked 32 according to the agreed relationship, allowing both prevention and 33 detection of route leaks. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 39 "OPTIONAL" in this document are to be interpreted as described in 40 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 41 capitals, as shown here. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on February 11, 2022. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 4 80 3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3.1. BGP Role Capability . . . . . . . . . . . . . . . . . . . 5 82 3.2. Role Correctness . . . . . . . . . . . . . . . . . . . . 5 83 4. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6 84 5. Additional Considerations . . . . . . . . . . . . . . . . . . 8 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 89 8.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 91 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 A BGP route leak occurs when a route is learned from a transit 97 provider or lateral peer and then announced to another provider or 98 lateral peer [RFC7908]. These are usually the result of 99 misconfigured or absent BGP route filtering or lack of coordination 100 between autonomous systems (ASes). 102 Existing approaches to leak prevention rely on marking routes by 103 operator configuration, with no check that the configuration 104 corresponds to that of the eBGP neighbor, or enforcement that the two 105 eBGP speakers agree on the relationship. This document enhances the 106 BGP OPEN message to establish an agreement of the relationship on 107 each eBGP session between autonomous systems in order to enforce 108 appropriate configuration on both sides. Propagated routes are then 109 marked according to the agreed relationship, allowing both prevention 110 and detection of route leaks. 112 This document provides configuration automation using BGP Roles, 113 which are negotiated using a BGP Role Capability in the OPEN message 114 [RFC5492]. An eBGP speaker may require the use of this capability 115 and confirmation of BGP Role with a neighbor for the BGP OPEN to 116 succeed. 118 An optional, transitive BGP Path Attribute, called Only to Customer 119 (OTC), is specified in Section 4. It prevents ASes from creating 120 leaks, and detects leaks created by the ASes in the middle of an AS 121 path. The main focus/applicability is the Internet (IPv4 and IPv6 122 unicast route advertisements). 124 1.1. Terminology 126 In the rest of this document, the term "Peer" is used to refer to a 127 "lateral peer" for simplicity. Also, the terms Provider and Customer 128 are used to refer to a transit provider and a transit customer, 129 respectively. Further, the terms RS and RS-Client are used to refer 130 to a Route Server and its client, respectively. 132 The terms "local AS" and "remote AS" are used to refer to the two 133 ends of an eBGP session. The "local AS" is the AS where the protocol 134 action being described is to be performed, and "remote AS" is the AS 135 at the other end of the eBGP session in consideration. 137 The use of the term "route is ineligible" in this document has the 138 same meaning as in [RFC4271], i.e., "route is ineligible to be 139 installed in Loc-RIB and will be excluded from the next phase of 140 route selection." 142 2. Peering Relationships 144 The terms defined and used in this document (see below) do not 145 necessarily represent business relationships based on payment 146 agreements. These terms are used to represent restrictions on BGP 147 route propagation, sometimes known as the Gao-Rexford model [Gao]. 148 The following is a list of BGP Roles for eBGP peering and the 149 corresponding rules for route propagation: 151 Provider: MAY propagate any available route to a Customer. 153 Customer: MAY propagate any route learned from a Customer, or 154 locally originated, to a Provider. All other routes MUST NOT be 155 propagated. 157 Route Server (RS): MAY propagate any available route to a Route 158 Server Client (RS-Client). 160 RS-Client: MAY propagate any route learned from a Customer, or 161 locally originated, to an RS. All other routes MUST NOT be 162 propagated. 164 Peer: MAY propagate any route learned from a Customer, or locally 165 originated, to a Peer. All other routes MUST NOT be propagated. 167 A BGP speaker may apply policy to reduce what is announced, and a 168 recipient may apply policy to reduce the set of routes they accept. 169 Violation of the above rules may result in route leaks. Automatic 170 enforcement of these rules should significantly reduce route leaks 171 that may otherwise occur due to manual configuration mistakes. 173 3. BGP Role 175 The BGP Role characterizes the relationship between the eBGP speakers 176 forming a session. BGP Role is configured on a per-session basis. 177 An eBGP speaker SHOULD configure the BGP Role locally based on the 178 local AS's knowledge of its Role. The only exception is when the 179 eBGP connection is complex (see Section 5). BGP Roles are mutually 180 confirmed using the BGP Role Capability (described in Section 3.1) on 181 each eBGP session between autonomous systems (ASes). One of the 182 Roles described below SHOULD be configured at the local AS for each 183 eBGP session with a neighbor (remote AS) (see definitions in 184 Section 1.1). 186 Allowed Roles for eBGP sessions are: 188 o Provider - the local AS is a transit Provider of the remote AS; 189 o Customer - the local AS is a transit Customer of the remote AS; 191 o RS - the local AS is a Route Server (usually at an Internet 192 exchange point) and the remote AS is its RS-Client; 194 o RS-Client - the local AS is a client of an RS and the RS is the 195 remote AS; 197 o Peer - the local and remote ASes are Peers (i.e., have a lateral 198 peering relationship). 200 3.1. BGP Role Capability 202 The BGP Role Capability is defined as follows: 204 o Code - 9 206 o Length - 1 (octet) 208 o Value - integer corresponding to speaker's BGP Role (see Table 1). 210 +-------+------------------------------+ 211 | Value | Role name (for the local AS) | 212 +-------+------------------------------+ 213 | 0 | Provider | 214 | 1 | RS | 215 | 2 | RS-Client | 216 | 3 | Customer | 217 | 4 | Peer (Lateral Peer) | 218 | 5-255 | Unassigned | 219 +-------+------------------------------+ 221 Table 1: Predefined BGP Role Values 223 If BGP Role is locally configured, the eBGP speaker MUST advertise 224 BGP Role Capability in the BGP OPEN message. An eBGP speaker MUST 225 NOT advertise multiple versions of the BGP Role Capability. 227 3.2. Role Correctness 229 Section 3.1 described how BGP Role encodes the relationship on each 230 eBGP session between autonomous systems (ASes). 232 The mere receipt of BGP Role Capability does not automatically 233 guarantee the Role agreement between two eBGP neighbors. If the BGP 234 Role Capability is advertised, and one is also received from the 235 peer, the roles MUST correspond to the relationships in Table 2. If 236 the roles do not correspond, the BGP speaker MUST reject the 237 connection using the Role Mismatch Notification (code 2, subcode 8). 239 +---------------+----------------+ 240 | Local AS Role | Remote AS Role | 241 +---------------+----------------+ 242 | Provider | Customer | 243 | Customer | Provider | 244 | RS | RS-Client | 245 | RS-Client | RS | 246 | Peer | Peer | 247 +---------------+----------------+ 249 Table 2: Allowed Pairs of Role Capabilities 251 If the BGP Role Capability is sent, but one is not received, then the 252 connection MAY be rejected using the Role Mismatch Notification (code 253 2, subcode 8); this mode of operation is called the "strict mode". 254 For backward compatibility, if the BGP speaker does not receive the 255 capability from its peer, it SHOULD ignore the absence of BGP Role 256 Capability and proceed with session establishment; this SHOULD be the 257 default non-strict mode of operation. In this case, the locally 258 configured BGP Role is used for the procedures described in 259 Section 4. 261 If an eBGP speaker receives multiple but identical BGP Role 262 Capabilities with the same value in each, then the speaker MUST 263 consider it to be a single BGP Role Capability and proceed [RFC5492]. 264 If multiple BGP Role Capabilities are received and not all of them 265 have the same value, then the BGP speaker MUST reject the connection 266 using the Role Mismatch Notification (code 2, subcode 8). 268 The BGP Role value for the local AS is used in the route leak 269 prevention and detection procedures described in Section 4. 271 4. BGP Only to Customer (OTC) Attribute 273 The Only to Customer (OTC) Attribute is an optional transitive path 274 attribute with Attribute Type Code 35 and a length of 4 octets. The 275 purpose of this attribute is to guarantee that once a route is sent 276 to a Customer, Peer, or RS-Client, it will subsequently go only to 277 Customers. The attribute value is an AS number determined by the 278 policy described below. 280 The following ingress policy applies to the processing of the OTC 281 Attribute: 283 1. If a route with the OTC Attribute is received from a Customer or 284 RS-Client, then it is a route leak and MUST be considered 285 ineligible (see Section 1.1). 287 2. If a route with the OTC Attribute is received from a Peer and at 288 least one of the OTC Attributes has a value that is not equal to 289 the remote (i.e., Peer's) AS number, then it is a route leak and 290 MUST be considered ineligible. 292 3. If a route is received from a Provider, Peer, or RS, and the OTC 293 Attribute is not present, then it MUST be added with a value 294 equal to the AS number of the remote AS. 296 The following egress policy applies to the processing of the OTC 297 Attribute: 299 1. If a route is to be advertised to a Customer, Peer, or RS-Client 300 (when the sender is an RS), and the OTC Attribute is not present, 301 then an OTC Attribute MUST be added with a value equal to the AS 302 number of the local AS. 304 2. If a route already contains the OTC Attribute, it MUST NOT be 305 propagated to Providers, Peers, or RS(s). 307 The described policies provide both leak prevention for the local AS 308 and leak detection and mitigation multiple hops away. In the case of 309 prevention at the local AS, the presence of an OTC Attribute 310 indicates to the egress router that the route was learned from a 311 Peer, Provider, or RS, and it can be advertised only to the 312 customers. The same OTC Attribute which is set locally also provides 313 a way to detect route leaks by an AS multiple hops away if a route is 314 received from a Customer, Peer, or RS-Client. 316 The OTC Attribute may be set by the egress policy of remote AS or by 317 the ingress policy of local AS. In both scenarios, the OTC value 318 will be the same. This makes the scheme more robust and benefits 319 early adopters. 321 If an eBGP speaker receives an UPDATE with an OTC Attribute with a 322 length different from 4 octets, then the UPDATE SHALL be considered 323 malformed. If malformed, the UPDATE message SHALL be handled using 324 the approach of "treat-as-withdraw" [RFC7606]. 326 Once the OTC Attribute has been set, it MUST be preserved unchanged. 328 Correct implementation of the procedures specified in this document 329 is not expected to result in the presence of multiple OTC Attributes 330 in an UPDATE. However, if an eBGP speaker receives multiple OTC 331 Attributes with a route, then the only difference in the processing 332 is in Step 2 of the ingress policy. 334 The described ingress and egress policies are applicable only for 335 unicast IPv4 and IPv6 address families and MUST not affect other 336 address families by default. The operator MUST NOT have the ability 337 to modify the policies defined in this section. 339 5. Additional Considerations 341 There are peering relationships that are 'complex', i.e., both 342 parties intentionally advertise prefixes received from each other to 343 their Peers and/or transit Providers. If multiple eBGP sessions can 344 segregate the 'complex' parts of the relationship, then the complex 345 peering roles can be segregated into different normal eBGP sessions, 346 and BGP Roles MUST be used on each of the resulting normal (non- 347 complex) eBGP sessions. 349 No Roles SHOULD be configured on a 'complex' eBGP session (assuming 350 it is not segregated) and in that case, the OTC Attribute processing 351 MUST be done relying on configuration on a per-prefix basis. Also, 352 in this case, the per-prefix peering configuration MUST follow the 353 same definitions of peering relations as described in Section 2. 354 However, in this case, there are no built-in measures to check 355 correctness of the per-prefix peering configuration. 357 The incorrect setting of BGP Roles and/or OTC Attributes may affect 358 prefix propagation. Further, this document does not specify any 359 special handling of incorrect AS numbers in the OTC Attribute. Such 360 errors should not happen with proper configuration. 362 6. IANA Considerations 364 IANA has registered a new BGP Capability described in Section 3.1 in 365 the "Capability Codes" registry's "IETF Review" range [RFC5492]. The 366 description for the new capability is "BGP Role". IANA has assigned 367 the value 9 [to be removed upon publication: 368 https://www.iana.org/assignments/capability-codes/capability- 369 codes.xhtml]. This document is the reference for the new capability. 371 The BGP Role capability includes a Value field, for which IANA is 372 requested to create and maintain a new sub-registry called "BGP Role 373 Value" in the Capability Codes registry. Assignments consist of a 374 Value and a corresponding Role name. Initially, this registry is to 375 be populated with the data contained in Table 1 found in Section 3.1. 376 Future assignments may be made by the "IETF Review" policy as defined 377 in [RFC8126]. The registry is as shown in Table 3. 379 +-------+--------------------------------+---------------+ 380 | Value | Role name (for the local AS) | Reference | 381 +-------+--------------------------------+---------------+ 382 | 0 | Provider | This document | 383 | 1 | RS | This document | 384 | 2 | RS-Client | This document | 385 | 3 | Customer | This document | 386 | 4 | Peer (i.e., Lateral Peer) | This document | 387 | 5-255 | To be assigned by IETF Review | 388 +-------+--------------------------------+---------------+ 390 Table 3: IANA Registry for BGP Role 392 IANA has registered a new OPEN Message Error subcode named the "Role 393 Mismatch" (see Section 3.2) in the OPEN Message Error subcodes 394 registry. IANA has assigned the value 8 [to be removed upon 395 publication: https://www.iana.org/assignments/bgp-parameters/bgp- 396 parameters.xhtml#bgp-parameters-6]. This document is the reference 397 for the new subcode. 399 IANA has also registered a new path attribute named "Only to Customer 400 (OTC)" (see Section 4) in the "BGP Path Attributes" registry. IANA 401 has assigned code value 35 [To be removed upon publication: 402 http://www.iana.org/assignments/bgp-parameters/bgp- 403 parameters.xhtml#bgp-parameters-2]. This document is the reference 404 for the new attribute. 406 7. Security Considerations 408 The security considerations of BGP (as specified in [RFC4271] and 409 [RFC4272]) apply. 411 This document proposes a mechanism using BGP Role for the prevention 412 and detection of route leaks that are the result of BGP policy 413 misconfiguration. A misconfiguration of the BGP Role may affect 414 prefix propagation. For example, if a downstream (i.e., towards a 415 Customer) peering link were misconfigured with a Provider or Peer 416 role, this will limit the number of prefixes that can be advertised 417 in this direction. On the other hand if an upstream provider were 418 misconfigured (by a local AS) with the Customer role, this may result 419 in propagating routes that are received from other Providers or 420 Peers. But the BGP Role negotiation and the resulting confirmation 421 of Roles make such misconfigurations unlikely. 423 Setting the strict mode of operation for BGP Role negotiation as the 424 default may result in a situation where the eBGP session will not 425 come up after a software update. Such an implementation of this 426 document is strongly discouraged. 428 Removing the OTC Attribute or changing its value can limit the 429 opportunity of route leak detection. Such activity can be done on 430 purpose as part of a Man in the Middle (MITM) attack. For example, 431 an AS can remove the OTC Attribute on a received route and then leak 432 the route to its transit provider. Such malicious activity cannot be 433 prevented without cryptographically signing the BGP UPDATE [RFC8205] 434 or out of band detection [I-D.ietf-sidrops-aspa-verification], but 435 such schemes are beyond the scope of this document. 437 Adding an OTC Attribute when the route is advertised from Customer to 438 Provider will limit the propagation of the route. Such a route may 439 be considered as ineligible by the immediate Provider or its Peers or 440 upper layer Providers. This kind of OTC Attribute addition is 441 unlikely to happen on the Provider side because it will limit the 442 traffic volume towards its Customer. On the Customer side, adding an 443 OTC Attribute for traffic engineering purposes is also discouraged 444 because it will limit route propagation in an unpredictable way. 446 8. References 448 8.1. Normative References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 456 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 457 DOI 10.17487/RFC4271, January 2006, 458 . 460 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 461 RFC 4272, DOI 10.17487/RFC4272, January 2006, 462 . 464 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 465 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 466 2009, . 468 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 469 Patel, "Revised Error Handling for BGP UPDATE Messages", 470 RFC 7606, DOI 10.17487/RFC7606, August 2015, 471 . 473 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 474 and B. Dickson, "Problem Definition and Classification of 475 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 476 2016, . 478 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 479 Writing an IANA Considerations Section in RFCs", BCP 26, 480 RFC 8126, DOI 10.17487/RFC8126, June 2017, 481 . 483 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 485 May 2017, . 487 8.2. Informative References 489 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without 490 global coordination", IEEE/ACM Transactions on 491 Networking, Volume 9, Issue 6, pp 689-692, DOI 492 10.1109/90.974523, December 2001, 493 . 495 [I-D.ietf-sidrops-aspa-verification] 496 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 497 Snijders, "Verification of AS_PATH Using the Resource 498 Certificate Public Key Infrastructure and Autonomous 499 System Provider Authorization", draft-ietf-sidrops-aspa- 500 verification-07 (work in progress), February 2021. 502 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 503 Specification", RFC 8205, DOI 10.17487/RFC8205, September 504 2017, . 506 Acknowledgements 508 The authors wish to thank Alvaro Retana, Andrei Robachevsky, Daniel 509 Ginsburg, Jeff Haas, Ruediger Volk, Pavel Lunin, Gyan Mishra, Ignas 510 Bagdonas, Sue Hares, and John Scudder for comments, suggestions, and 511 critique. 513 Contributors 514 Brian Dickson 515 Independent 516 Email: brian.peter.dickson@gmail.com 518 Doug Montgomery 519 USA National Institute of Standards and Technology 520 Email: dougm@nist.gov 522 Authors' Addresses 524 Alexander Azimov 525 Qrator Labs & Yandex 526 Ulitsa Lva Tolstogo 16 527 Moscow 119021 528 Russian Federation 530 Email: a.e.azimov@gmail.com 532 Eugene Bogomazov 533 Qrator Labs 534 1-y Magistralnyy tupik 5A 535 Moscow 123290 536 Russian Federation 538 Email: eb@qrator.net 540 Randy Bush 541 Internet Initiative Japan & Arrcus, Inc. 542 5147 Crystal Springs 543 Bainbridge Island, Washington 98110 544 United States of America 546 Email: randy@psg.com 548 Keyur Patel 549 Arrcus 550 2077 Gateway Place, Suite #400 551 San Jose, CA 95119 552 US 554 Email: keyur@arrcus.com 555 Kotikalapudi Sriram 556 USA National Institute of Standards and Technology 557 100 Bureau Drive 558 Gaithersburg, MD 20899 559 United States of America 561 Email: ksriram@nist.gov