idnits 2.17.1 draft-ietf-sidrops-rpkimaxlen-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 35 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2019) is 1829 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 6480 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gilad 3 Internet-Draft S. Goldberg 4 Intended status: Best Current Practice Boston University 5 Expires: October 26, 2019 K. Sriram 6 USA NIST 7 J. Snijders 8 NTT 9 B. Maddison 10 Workonline Communications 11 April 24, 2019 13 The Use of Maxlength in the RPKI 14 draft-ietf-sidrops-rpkimaxlen-02 16 Abstract 18 This document recommends ways to reduce forged-origin attack surface 19 by prudently limiting the address space that is included in Route 20 Origin Authorizations (ROAs). One recommendation is to avoid using 21 the maxLength attribute in ROAs except in some specific cases. The 22 recommendations complement and extend those in RFC 7115. The 23 document also discusses creation of ROAs for facilitating Distributed 24 Denial of Service (DDoS) mitigation services. Considerations related 25 to ROAs and origin validation for the case of destination-based 26 Remote Triggered Black Hole (RTBH) filtering are also highlighted. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 26, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Forged-Origin Subprefix Hijack . . . . . . . . . . . . . . . 4 66 4. Measurements of Today's RPKI . . . . . . . . . . . . . . . . 6 67 5. Recommendations about Minimal ROAs and Maxlength . . . . . . 6 68 5.1. Creation of ROAs Facilitating DDoS Mitigation Service . . 7 69 6. ROAs and Origin Validation for RTBH Filtering Scenario . . . 9 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create 79 a cryptographically verifiable mapping from an IP prefix to a set of 80 autonomous systems (ASes) that are authorized to originate this 81 prefix. Each ROA contains a set of IP prefixes, and an AS number of 82 an AS authorized originate all the IP prefixes in the set [RFC6482]. 83 The ROA is cryptographically signed by the party that holds a 84 certificate for the set of IP prefixes. 86 The ROA format also supports a maxLength attribute. According to 87 [RFC6482], "When present, the maxLength specifies the maximum length 88 of the IP address prefix that the AS is authorized to advertise." 89 Thus, rather than requiring the ROA to list each prefix the AS is 90 authorized to originate, the maxLength attribute provides a shorthand 91 that authorizes an AS to originate a set of IP prefixes. 93 However, measurements of current RPKI deployments have found that use 94 of the maxLength in ROAs tends to lead to security problems. 95 Specifically, as of June 2017, 84% of the prefixes specified in ROAs 96 that use the maxLength attribute, are vulnerable to a forged-origin 97 subprefix hijack [HARMFUL]. The forged-origin prefix or subprefix 98 hijack involves inserting the legitimate AS (as specified in the ROA) 99 as the origin AS, and can be launched against any IP prefix/subprefix 100 that has a ROA. Consider a prefix/subprefix that has a ROA but is 101 unused, i.e., not announced in BGP by a legitimate AS. A forged- 102 origin hijack involving such a prefix/subprefix can propagate widely 103 throughout the Internet. On the other hand, if the prefix/subprefix 104 were announced by the legitimate AS, then the propagation of the 105 forged-origin hijack is somewhat limited because of its increased 106 path length relative to the legitimate announcement. Of course, 107 forged-origin hijacks are harmful in both cases but the extent of 108 harm is greater for unannounced prefixes. 110 For this reason, this document recommends that, whenever possible, 111 operators SHOULD use "minimal ROAs" that include only those IP 112 prefixes that are actually originated in BGP, and no other prefixes. 113 Further, it recommends ways to reduce forged-origin attack surface by 114 prudently limiting the address space that is included in Route Origin 115 Authorizations (ROAs). One recommendation is to avoid using the 116 maxLength attribute in ROAs except in some specific cases. The 117 recommendations complement and extend those in RFC 7115. The 118 document also discusses creation of ROAs for facilitating Distributed 119 Denial of Service (DDoS) mitigation services. Considerations related 120 to ROAs and origin validation for the case of destination-based 121 Remote Triggered Black Hole (RTBH) filtering are also highlighted. 123 One ideal place to implement the ROA related recommendations is in 124 the user interfaces for configuring ROAs. Thus, this document 125 further recommends that designers and/or providers of such user 126 interfaces SHOULD provide warnings to draw the user's attention to 127 the risks of using the maxLength attribute. 129 Best current practices described in this document require no changes 130 to the RPKI specification and will not increase the number of signed 131 ROAs in the RPKI, because ROAs already support lists of IP prefixes 132 [RFC6482]. 134 1.1. Requirements 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2. Suggested Reading 142 It is assumed that the reader understands BGP [RFC4271], RPKI 143 [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based 144 Prefix Validation [RFC6811], and BGPsec [RFC8205]. 146 3. Forged-Origin Subprefix Hijack 148 A detailed description and discussion of forged-origin subprefix 149 hijack are presented here, especially considering the case when the 150 subprefix is not announced in BGP. The forged-origin subprefix 151 hijack is relevant to a scenario in which (1) the RPKI [RFC6480] is 152 deployed, and (2) routers use RPKI origin validation to drop invalid 153 routes [RFC6811], but (3) BGPsec [RFC8205] (or any similar method to 154 validate the truthfulness of the BGP AS_PATH attribute) is not 155 deployed. 157 We describe the forged-origin subprefix hijack [RFC7115] [GCHSS] 158 using a running example. 160 Consider the IP prefix 168.122.0.0/16 which is allocated to an 161 organization that also operates AS 64496. In BGP, AS 64496 162 originates the IP prefix 168.122.0.0/16 as well as its subprefix 163 168.122.225.0/24. Therefore, the RPKI should contain a ROA 164 authorizing AS 64496 to originate these two IP prefixes. That is, 165 the ROA should be 167 ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) 169 This ROA is "minimal" because it includes only those IP prefixes that 170 AS 64496 originates in BGP, but no other IP prefixes [RFC6907]. 172 Now suppose an attacking AS 64511 originates a BGP announcement for a 173 subprefix 168.122.0.0/24. This is a standard "subprefix hijack". 175 In the absence of the minimal ROA above, AS 64511 could intercept 176 traffic for the addresses in 168.122.0.0/24. This is because routers 177 perform a longest-prefix match when deciding where to forward IP 178 packets, and 168.122.0.0/24 originated by AS 64511 is a longer prefix 179 than 168.122.0.0/16 originated by AS 64496. 181 However, the minimal ROA renders AS 64511's BGP announcement invalid, 182 because (1) this ROA "covers" the attacker's announcement (since 183 168.122.0.0/24 is a subprefix of 168.122.0.0/16), and (2) there is no 184 ROA "matching" the attacker's announcement (there is no ROA for AS 185 64511 and IP prefix 168.122.0.0/24) [RFC6811]. If routers ignore 186 invalid BGP announcements, the minimal ROA above ensures that the 187 subprefix hijack will fail. 189 Now suppose that the "minimal ROA" was replaced with a "loose ROA" 190 that used maxLength as a shorthand for set of IP prefixes that AS 191 64496 is authorized to originate. The "loose ROA" would be: 193 ROA:(168.122.0.0/16-24, AS 64496) 195 This "loose ROA" authorizes AS 64496 to originate any subprefix of 196 168.122.0.0/16, up to length /24. That is, AS 64496 could originate 197 168.122.225.0/24 as well as all of 168.122.0.0/17, 168.122.128.0/17, 198 ..., 168.122.255.0/24 but not 168.122.0.0/25. 200 However, AS 64496 only originates two prefixes in BGP: 168.122.0.0/16 201 and 168.122.255.0/24. This means that all other prefixes authorized 202 by the "loose ROA" (for instance, 168.122.0.0/24), are vulnerable to 203 the following forged-origin subprefix hijack [RFC7115] [GCHSS]: 205 The hijacker AS 64511 sends a BGP announcement "168.122.0.0/24: AS 206 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 207 AS 64496 and falsely claiming that AS 64496 originates the IP 208 prefix 168.122.0.0/24. In fact, the IP prefix 168.122.0.0/24 is 209 not originated by AS 64496. 211 The hijacker's BGP announcement is valid according to the RPKI, since 212 the ROA (168.122.0.0/16-24, AS 64496) authorizes AS 64496 to 213 originate BGP routes for 168.122.0.0/24. Because AS 64496 does not 214 actually originate a route for 168.122.0.0/24, the hijacker's route 215 is the *only* route to the 168.122.0.0/24. Longest-prefix-match 216 routing ensures that the hijacker's route to the subprefix 217 168.122.0.0/24 is always preferred over the legitimate route to 218 168.122.0.0/16 originated by AS 64496. Thus, the hijacker's route 219 propagates through the Internet, the traffic destined for IP 220 addresses in 168.122.0.0/24 will be delivered to the hijacker. 222 The forged-origin *subprefix* hijack would have failed if the 223 "minimal ROA" described above was used instead of the "loose ROA". 224 If the "minimal ROA" had been used instead, the attacker would be 225 forced to launch a forged-origin *prefix* hijack in order to attract 226 traffic, as follows: 228 The hijacker AS 64511 sends a BGP announcement "168.122.0.0/16: AS 229 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 230 AS 64496. 232 This forged-origin *prefix* hijack is significantly less damaging 233 than the forged-origin *subprefix* hijack. AS 64496 legitimately 234 originates 168.122.0.0/16 in BGP, so the hijacker AS 64511 is not 235 presenting the *only* route to 168.122.0.0/16. Moreover, the path 236 originated by AS 64511 is one hop longer than the path originated by 237 the legitimate origin AS 64496. As discussed in [LSG16], this means 238 that the hijacker will attract less traffic than he would have in the 239 forged-origin *subprefix* hijack, where the hijacker presents the 240 *only* route to the hijacked subprefix. 242 In summary, a forged-origin subprefix hijack has the same impact as a 243 regular subprefix hijack. A forged-origin *subprefix* hijack is also 244 more damaging than forged-origin *prefix* hijack. 246 4. Measurements of Today's RPKI 248 Network measurements from June 1, 2017 show that 12% of the IP 249 prefixes authorized in ROAs have a maxLength longer than their prefix 250 length. The vast majority of these (84%) are vulnerable to forged- 251 origin subprefix hijacks. These subprefixes are not announced in BGP 252 by the legitimate AS. Even large providers are vulnerable to these 253 attacks. See [GSG17] for details. 255 These measurements suggest that operators commonly misconfigure the 256 maxLength attribute, and unwittingly open themselves up to forged- 257 origin subprefix hijacks. That is, they are exposing a much larger 258 attack surface for forged-origin hijacks than necessary. 260 5. Recommendations about Minimal ROAs and Maxlength 262 Operators SHOULD avoid using the maxLength attribute in their ROAs 263 except in some special cases. One such exception may be when all 264 more specific prefixes permitted by the maxLength are actually 265 announced by the AS in the ROA. Another exception for use of 266 maxLength is when (a) the maxLength is substantially larger compared 267 to the specified prefix length in the ROA, and (b) a large number of 268 more specific prefixes in that range is announced by the AS in the 269 ROA. This case should occur rarely in practice (if at all). 270 Operator discretion is necessary in this case. 272 Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA 273 contains only those IP prefixes that are actually originated by an AS 274 in BGP, and no other IP prefixes. (See Section 3 for an example.) 276 This practice requires no changes to the RPKI specification and will 277 not increase the number of signed ROAs in the RPKI, because ROAs 278 already support lists of IP prefixes [RFC6482]. See also [GSG17] for 279 further discussion of why this practice will have minimal impact on 280 the performance of the RPKI ecosystem. 282 5.1. Creation of ROAs Facilitating DDoS Mitigation Service 284 Sometimes, it is not possible to use a "minimal ROA", because an 285 operator wants to issue a ROA that includes an IP prefix that is 286 sometimes (but not always) originated in BGP. 288 In this case, the ROA SHOULD include (1) the set of IP prefixes that 289 are always originated in BGP, and (2) the set IP prefixes that are 290 sometimes, but not always, originated in BGP. The ROA SHOULD NOT 291 include any IP prefixes that the operator knows will not be 292 originated in BGP. Whenever possible, the ROA SHOULD also avoid the 293 use of the maxLength attribute. 295 We now extend our running example to illustrate one situation where 296 where it is not possible to issue a minimal ROA. 298 Consider the following scenario prior to deployment of RPKI. Suppose 299 AS 64496 announced 168.122.0.0/16 and has a contract with a 300 Distributed Denial of Service (DDoS) mitigation service provider that 301 holds AS 64500. Further, assume that the DDoS mitigation service 302 contract applies to all IP addresses covered by 168.122.0.0/22. When 303 a DDoS attack is detected and reported by AS 64496, AS 64500 304 immediately originates 168.122.0.0/22, thus attracting all the DDoS 305 traffic to itself. The traffic is scrubbed at AS 64500 and then sent 306 back to AS 64496 over a backhaul data link. Notice that, during a 307 DDoS attack, the DDoS mitigation service provider AS 64500 originates 308 a /22 prefix that is longer than AS 64496's /16 prefix, and so all 309 the traffic (destined to addresses in 168.122.0.0/22) that normally 310 goes to AS 64496 goes to AS 64500 instead. 312 First, suppose the RPKI only had the minimal ROA for AS 64496, as 313 described in Section 3. But, if there is no ROA authorizing AS 64500 314 to announce the /22 prefix, then the DDoS mitigation (and traffic 315 scrubbing) scheme would not work. That is, if AS 64500 originates 316 the /22 prefix in BGP during DDoS attacks, the announcement would be 317 invalid [RFC6811]. 319 Therefore, the RPKI should have two ROAs: one for AS 64496 and one 320 for AS 64500. 322 ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) 324 ROA:(168.122.0.0/22, AS 64500) 326 Neither ROA uses the maxLength attribute. But, the second ROA is not 327 "minimal" because it contains a /22 prefix that is not originated by 328 anyone in BGP during normal operations. The /22 prefix is only 329 originated by AS 64500 as part of its DDoS mitigation service during 330 a DDoS attack. 332 Notice, however, that this scheme does not come without risks. 333 Namely, all IP addresses in 168.122.0.0/22 are vulnerable to a 334 forged-origin subprefix hijack during normal operations, when the /22 335 prefix is not originated. (The hijacker AS 64511 would send the BGP 336 announcement "168.122.0.0/22: AS 64511, AS 64500", falsely claiming 337 that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 338 64500 originates 168.122.0.0/22.) 340 In some situations, the DDoS mitigation service at AS 64500 might 341 want to limit the amount of DDoS traffic that it attracts and scrubs. 342 Suppose that a DDoS attack only targets IP addresses in 343 168.122.0.0/24. Then, the DDoS mitigation service at AS 64500 only 344 wants to attract the traffic designated for the /24 prefix that is 345 under attack, but not the entire /22 prefix. To allow for this, the 346 RPKI should have two ROAs: one for AS 64496 and one for AS 64500. 348 ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) 350 ROA:(168.122.0.0/22-24, AS 64500) 352 The second ROA uses the maxLength attribute because it is designed to 353 explicitly enable AS 64500 to originate *any* /24 subprefix of 354 168.122.0.0/22. 356 As before, the second ROA is not "minimal" because it contains 357 prefixes that are not originated by anyone in BGP during normal 358 operations. As before, all IP addresses in 168.122.0.0/22 are 359 vulnerable to a forged-origin subprefix hijack during normal 360 operations, when the /22 prefix is not originated. 362 The use of maxLength in this second ROA also comes with an additional 363 risk. While it permits the DDoS mitigation service at AS 64500 to 364 originate prefix 168.122.0.0/24 during a DDoS attack in that space, 365 it also makes the *other* /24 prefixes covered by the /22 prefix 366 (i.e., 168.122.1.0/24, 168.122.2.0/24, 168.122.3.0/24) vulnerable to 367 a forged-origin subprefix attacks. 369 There is another entirely different way of managing ROAs for DDoS 370 mitigation service. In this scheme, ROAs are not pre-created for the 371 DDoS mitigation service but are created on the fly when the DDoS 372 mitigation service request is made. Further, the BGP announcements 373 for actuating the DDoS mitigation service will not be made until the 374 ROAs propagate fully through the RPKI system. Hence, there would be 375 a latency involved in DDoS mitigation service going into effect. 376 This method would be effective only if the latency is guaranteed to 377 be within some acceptable limit. This calls for mechanisms to be in 378 place for RPKI data propagation to occur very fast. Thus, this 379 scheme of managing ROAs for DDoS mitigation service helps with 380 eliminating the attack surface for prefixes requiring this service. 381 However, the viability of this scheme depends on future work related 382 to achieving fast ROA propagation in the global RPKI system. 384 6. ROAs and Origin Validation for RTBH Filtering Scenario 386 Considerations related to ROAs and origin validation [RFC6811] for 387 the case of destination-based Remote Triggered Black Hole (RTBH) 388 filtering are addressed here. In RTBH, highly specific prefixes 389 (greater than /24 in IPv4 and greater than /48 in IPv6; possibly even 390 /32 (IPv4) and /128 (IPv6)) are announced in BGP. These 391 announcements are tagged with a BLACKHOLE Community [RFC7999]. It is 392 obviously not desirable to use large maxlength or include any such 393 highly specific prefixes in the ROAs to accommodate destination-based 394 RTBH filtering. Therefore, operators SHOULD accommodate this 395 scenario by accepting BGP announcements tagged with BLACKHOLE 396 Community only if the following conditions are met: (1) the 397 announcement is received on a BGP session on which there is agreement 398 to honor BLACKHOLE Community, and (2) the prefix in the announcement 399 is covered by a ROA that has an AS number matching with the AS number 400 of the peer on that BGP session. 402 7. Acknowledgments 404 The authors would like to thank the following people for their review 405 and contributions to this document: Omar Sagga (Boston University) 406 and Aris Lambrianidis (AMS-IX). 408 8. References 410 8.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 418 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 419 DOI 10.17487/RFC4271, January 2006, 420 . 422 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 423 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 424 February 2012, . 426 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 427 Origin Authorizations (ROAs)", RFC 6482, 428 DOI 10.17487/RFC6482, February 2012, 429 . 431 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 432 Austein, "BGP Prefix Origin Validation", RFC 6811, 433 DOI 10.17487/RFC6811, January 2013, 434 . 436 8.2. Informative References 438 [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. 439 Shulman, "Are We There Yet? On RPKI's Deployment and 440 Security", in NDSS 2017, February 2017, 441 . 443 [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength 444 Considered Harmful to the RPKI", in ACM CoNEXT 2017, 445 December 2017, . 447 [HARMFUL] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength 448 Considered Harmful to the RPKI", 2017, 449 . 451 [LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking 452 Security for Internet Routing", in Communications of the 453 ACM, October 2016, . 457 [RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and 458 Interpretations of Resource Public Key Infrastructure 459 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 460 DOI 10.17487/RFC6907, March 2013, 461 . 463 [RFC7115] Bush, R., "Origin Validation Operation Based on the 464 Resource Public Key Infrastructure (RPKI)", BCP 185, 465 RFC 7115, DOI 10.17487/RFC7115, January 2014, 466 . 468 [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. 469 Hankins, "BLACKHOLE Community", RFC 7999, 470 DOI 10.17487/RFC7999, October 2016, 471 . 473 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 474 Specification", RFC 8205, DOI 10.17487/RFC8205, September 475 2017, . 477 Authors' Addresses 479 Yossi Gilad 480 Boston University 481 111 Cummington St, MCS135 482 Boston, MA 02215 483 USA 485 EMail: yossigi@bu.edu 487 Sharon Goldberg 488 Boston University 489 111 Cummington St, MCS135 490 Boston, MA 02215 491 USA 493 EMail: goldbe@cs.bu.edu 495 Kotikalapudi Sriram 496 USA National Institute of Standards and Technology 497 100 Bureau Drive 498 Gaithersburg, MD 20899 499 USA 501 EMail: kotikalapudi.sriram@nist.gov 503 Job Snijders 504 NTT Communications 505 Theodorus Majofskistraat 100 506 Amsterdam 1065 SZ 507 The Netherlands 509 EMail: job@ntt.net 510 Ben Maddison 511 Workonline Communications 512 30 Waterkant St 513 Cape Town 8001 514 South Africa 516 EMail: benm@workonline.co.za