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