idnits 2.17.1 draft-ietf-savi-framework-06.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 27, 2011) is 4502 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 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 Jianping Wu 3 Internet-Draft Jun Bi 4 Intended status: Informational Tsinghua Univ. 5 Expires: July 24, 2012 Marcelo Bagnulo 6 UC3M 7 Fred Baker 8 Cisco 9 Christian Vogt, Ed. 10 Ericsson 11 December 27, 2011 13 Source Address Validation Improvement Framework 14 draft-ietf-savi-framework-06 16 Abstract 18 Source Address Validation Improvement methods were developed to 19 prevent nodes attached to the same IP link from spoofing each other's 20 IP addresses, so as to complement ingress filtering with finer- 21 grained, standardized IP source address validation. This document is 22 a framework document, which describes and motivates the design of the 23 SAVI methods. Particular SAVI methods are described in other 24 documents. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 24, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 75 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8 76 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10 77 6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10 78 7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 11.1. Informative References . . . . . . . . . . . . . . . . . 13 84 11.2. Normative References . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Since IP source addresses are used by hosts and network entities to 90 determine the origin of a packet and as a destination for return 91 data, spoofing of IP source addresses can enable impersonation, 92 concealment, and malicious traffic redirection. Unfortunately, the 93 Internet architecture does not prevent IP source address spoofing 94 [draft-ietf-savi-threat-scope]. Since the IP source address of a 95 packet generally takes no role in forwarding the packet, it can be 96 selected arbitrarily by the sending host without jeopardizing packet 97 delivery. Extra methods are necessary for IP source address 98 validation, to augment packet forwarding with an explicit check of 99 whether a given packet's IP source address is legitimate. 101 IP source address validation can happen at different granularity: 102 Ingress filtering [BCP38] [BCP84], a widely deployed standard for IP 103 source address validation, functions at the coarse granularity of 104 networks. It verifies that the prefix of an IP source address routes 105 to the network from which the packet was received. An advantage of 106 ingress filtering is simplicity: the decision of whether to accept 107 or to reject an IP source address can be made solely based on the 108 information available from routing protocols. However, the 109 simplicity comes at the cost of not being able to validate IP source 110 addresses at a finer granularity, due to the aggregated nature of the 111 information available from routing protocols. Finer-grained IP 112 source address validation would ensure that source address 113 information is accurate, reduce the ability to launch denial-of- 114 service attacks, and help with localizing hosts and identify 115 misbehaving hosts. Partial solutions [BA2007] exist for finer- 116 grained IP source address validation, but are proprietary and hence 117 often unsuitable for corporate procurement. 119 The Source Address Validation Improvement method was developed to 120 complement ingress filtering with standardized IP source address 121 validation at the maximally fine granularity of individual IP 122 addresses: It prevents hosts attached to the same link from spoofing 123 each other's IP addresses. To facilitate deployment in networks of 124 various kinds, the SAVI method was designed to be modular and 125 extensible. This document describes and motivates the design of the 126 SAVI method. 128 2. Model 130 To enable network operators to deploy fine-grained IP source address 131 validation without a dependency on supportive functionality on hosts, 132 the SAVI method was designed to be purely network-based. A SAVI 133 instance enforces the hosts' use of legitimate IP source addresses 134 according to the following three-step model: 136 1. Identify which IP source addresses are legitimate for a host, 137 based on monitoring packets exchanged by the host. 139 2. Bind a legitimate IP address to a link layer property of the 140 host's network attachment. This property, called a "binding 141 anchor", must be verifiable in every packet that the host sends, 142 and harder to spoof than the host's IP source address itself. 144 3. Enforce that the IP source addresses in packets match the binding 145 anchors to which they were bound. 147 This model allows SAVI functionality (a SAVI instance) to be located 148 anywhere on the link to which the hosts attach, hence enabling 149 different locations for a SAVI instance. One way to locate a SAVI 150 instance is in the hosts' default router. IP source addresses are 151 then validated in packets traversing the default router, yet the IP 152 source addresses in packets exchanged locally on the link may bypass 153 validation. Another way to locate a SAVI instance is in a switch 154 between the hosts and their default router. Thus, packets may 155 undergo IP source address validation even if exchanged locally on the 156 link. 158 The closer a SAVI instance is located to the hosts, the more 159 effective the SAVI method is. This is because each of the three 160 steps of the SAVI model can best be accomplished in a position close 161 to the host: 163 o Identifying a host's legitimate IP source addresses is most 164 efficient close to the host, because the likelihood that the 165 host's packets bypass a SAVI instance, and hence cannot be 166 monitored, increases with the topological distance between the 167 SAVI instance and the host. 169 o Selecting a binding anchor for a host's IP source address is 170 easiest close to the host, because many link layer properties are 171 unique for a given host only on a link segment directly attaching 172 to the host. 174 o Enforcing a host's use of a legitimate IP source address is most 175 reliable when pursued close to the host, because the likelihood 176 that the host's packets bypass a SAVI instance, and hence do not 177 undergo IP source address validation, increases with the 178 topological distance between the SAVI instance and the host. 180 The preferred location of SAVI instances is therefore close to hosts, 181 such as in switches that directly attach to the hosts whose IP source 182 addresses are being validated. 184 Nevertheless, it is useful for SAVI mechanisms to be able to handle 185 situations where hosts are not directly attached to the SAVI-capable 186 device. For instance, deployments with both SAVI-capable and legacy 187 switches could be supported. In general, a SAVI solution needs to 188 specify how it deals with a number of deployment scenarios and 189 exceptional situations, including interaction with legacy devices, 190 hosts moving between wireless attachment points, network partitions, 191 and so on. 193 Besides, in the case of legacy switches, the security level is lower, 194 as there is no full protection for the hosts connected to the legacy 195 server. 197 3. Deployment Options 199 The model of the SAVI method, as explained in Section 2, is 200 deployment-specific in two ways: 202 o The identification of legitimate IP source addresses is dependent 203 on the IP address assignment method in use on a link, since it is 204 through assignment that a host becomes the legitimate user of an 205 IP source address. 207 o Binding anchors are dependent on the technology used to build the 208 link on which they are used, as binding anchors are link layer 209 properties of a host's network attachment. 211 To facilitate the deployment of the SAVI method in networks of 212 various kinds, the SAVI method is designed to support different IP 213 address assignment methods, and to function with different binding 214 anchors. Naturally, both the IP address assignment methods in use on 215 a link and the available binding anchors have an impact on the 216 functioning and the strength of IP source address validation. The 217 following two sub-sections explain this impact, and describe how the 218 SAVI method accommodates this. 220 3.1. IP Address Assignment Methods 222 Since the SAVI method traces IP address assignment packets, it 223 necessarily needs to incorporate logic that is specific to particular 224 IP address assignment methods. However, developing SAVI method 225 variants for each IP address assignment method is alone not 226 sufficient, since multiple IP address assignment methods may co-exist 227 on a given link. The SAVI method hence comes in multiple variants, 228 e.g. for links with DHCP [rfc2131] [rfc3315], Stateless Address 229 Autoconfiguration [rfc4862] with or without Secure Neighbor Discovery 230 [rfc3971], IKEv2 [rfc5996] [rfc5739] [rfc5026] and combinations 231 thereof. 233 The reason to develop SAVI method variants for each single IP address 234 configuration method, in addition to the variant that handles all IP 235 address assignment methods, is to minimize the complexity of the 236 common case: many link deployments today either are constrained to a 237 single IP address assignment methods or, equivalently from the 238 perspective of the SAVI method, separate IP address assignment 239 methods into different IP address prefixes. The SAVI method for such 240 links can be simpler than the SAVI method for links with multiple IP 241 address assignment methods per IP address prefix. 243 3.2. Binding Anchors 245 The SAVI method supports a range of binding anchors: 247 o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's 248 interface. 250 o The port on an Ethernet switch to which a host attaches. 252 o The security association between a host and the base station on 253 wireless links. 255 o The combination of a host interface's link-layer address and a 256 customer relationship in cable modem networks. 258 o An ATM virtual channel, a PPP session identifier, or an L2TP 259 session identifier in a DSL network. 261 o A tunnel that connects to a single host, such as an IP-in-IP 262 tunnel, a GRE tunnel, or an MPLS label-switched path. 264 The various binding anchors differ significantly in the security they 265 provide. IEEE extended unique identifiers, for example, fail to 266 render a secure binding anchor because they can be spoofed with 267 little effort. And switch ports alone may be insufficient because 268 they may connect to more than a single host, such as in the case of 269 concatenated switches. 271 Given this diversity in the security provided, one could define a set 272 of possible binding anchors, and leave it up to the administrator to 273 choose one or more of them. Such a selection of binding anchors 274 would, of course, have to be accompanied by an explanation of the 275 pros and cons of the different binding anchors. In addition, SAVI 276 devices may have a default binding anchor depending on the lower 277 layers. Such a default could be to use switch ports when available, 278 and MAC addresses otherwise. Or to use MAC addresses, and switch 279 ports in addition if available. 281 4. Scalability Optimizations 283 The preference to locate a SAVI instance close to hosts implies that 284 multiple SAVI instances must be able to co-exist in order to support 285 large links. Although the model of the SAVI method is independent of 286 the number of SAVI instances per link, co-existence of multiple SAVI 287 instances without further measures can lead to higher-than-necessary 288 memory requirements: since a SAVI instance creates bindings for the 289 IP source addresses of all hosts on a link, bindings are replicated 290 if multiple SAVI instances co-exist on the link. High memory 291 requirements, in turn, increase the cost of a SAVI instance. This is 292 problematic in particular for SAVI instances that are located on a 293 switch, since it may significantly increase the cost of such a 294 switch. 296 To reduce memory requirements for SAVI instances that are located on 297 a switch, the SAVI method enables the suppression of binding 298 replication on links with multiple SAVI instances. This requires 299 manual disabling of IP source address validation on switch ports that 300 connect to other switches running a SAVI instance. Each SAVI 301 instance is then responsible for validating IP source addresses only 302 on those ports to which hosts attach either directly, or via switches 303 without a SAVI instance. On ports towards other switches running a 304 SAVI instance, IP source addresses are not validated. The switches 305 running SAVI instances thus form a "protection perimeter". The IP 306 source addresses in packets passing the protection perimeter are 307 validated by the ingress SAVI instance, but no further validation 308 takes place as long as the packets remain within, or leave the 309 protection perimeter. 311 .............. 312 protection perimeter --> : +--------+ : 313 +---+ +---+ : | SAVI | : 314 | A | | B | <-- hosts : | switch | : 315 +---+ +---+ : +--------+ : 316 ...|......|.............................: | : 317 : +--------+ +--------+ +--------+ : 318 : | SAVI |----------| legacy | | SAVI | : 319 : | switch | | switch |----------| switch | : 320 : +--------+ +--------+ +--------+ : 321 : | ...............................|........: 322 : +--------+ : +--------+ 323 : | SAVI | : | legacy | 324 : | switch | : | switch | 325 : +--------+ : +--------+ 326 :............: | | 327 +---+ +---+ 328 hosts --> | C | | D | 329 +---+ +---+ 331 Figure 1: Protection perimeter concept 333 Figure 1 illustrates the concept of the protection perimeter. The 334 figure shows a link with six switches, of which four, denoted "SAVI 335 switch", run a SAVI instance. The protection perimeter created by 336 the four SAVI instances is shown as a dotted line in the figure. IP 337 source address validation is enabled on all switch ports on the 338 protection perimeter, and it is disabled on all other switch ports. 339 Four hosts, denoted A through D in the figure, attach to the 340 protection perimeter. 342 In the example of figure Figure 1, the protection perimeter 343 encompasses one of the legacy switches, located in the middle of the 344 depicted link topology. This enables a single, unpartitioned 345 protection perimeter. A single protection perimeter minimizes memory 346 requirements for the SAVI instances because every binding is kept 347 only once, namely, by the SAVI instance that attaches to the host 348 being validated. Excluding the legacy switch from the protection 349 perimeter would result in two smaller protection perimeters to the 350 left and to the right of the depicted link topology. The memory 351 requirements for the SAVI instances would then be higher: since IP 352 source address validation would be activated on the two ports 353 connecting to the legacy switch, the SAVI instances adjacent to the 354 legacy switch would replicate all bindings from the respectively 355 other protection perimeter. The reason why it is possible to include 356 the legacy switch in the protection perimeter is because the depicted 357 link topology guarantees that packets cannot enter the protection 358 perimeter via this legacy switch. Without this guarantee, the legacy 359 switch would have to be excluded from the protection perimeter in 360 order to ensure that packets entering the protection perimeter 361 undergo IP source address validation. 363 5. Reliability Optimizations 365 The explicit storage of legitimate IP addresses in the form of 366 bindings implies that failure to create a binding, or the premature 367 removal of bindings, can lead to loss of legitimate packets. There 368 are three situations in which this can happen: 370 o Legitimate IP address configuration packets, which should trigger 371 the creation of a binding in a SAVI instance, are lost before 372 reaching the SAVI instance. 374 o A SAVI instance loses a binding, for example, due to a restart. 376 o The link topology changes, resulting in hosts to communicate 377 through SAVI instances that do not have a binding for those hosts' 378 IP addresses. 380 To limit the disruption that missing bindings for legitimate IP 381 addresses can have, the SAVI method includes a mechanism for reactive 382 binding creation based on regular packets. This mechanism 383 supplements the proactive binding creation based on IP address 384 configuration packets. Reactive binding creation occurs when a SAVI 385 instances recognizes excessive drops of regular packets originating 386 from the same IP address. The SAVI instance then verifies whether 387 said IP address is unique on the link. How the verification is 388 carried out depends on the IP address configuration method that the 389 SAVI instance supports: the SAVI method variant for Stateless 390 Address Autoconfiguration and for Secure Neighbor Discovery verifies 391 an IP address through the Duplicate Address Detection procedure. The 392 SAVI method variant for DHCP verifies an IP address through a DHCP 393 Lease Query message exchange with the DHCP server. If verification 394 indicates that the IP address is unique on the link, the SAVI 395 instance creates a binding for the IP address. Otherwise, no binding 396 is created, and packets sent from the IP address continue to be 397 dropped. These reliability issues should be addressed in all the 398 SAVI protocols describing particular SAVI methods. 400 6. Scenario with Multiple Assignment Methods 402 While multiple assignment methods can be used on the same link, the 403 SAVI device may have to deal with a mix of binding discovery methods. 405 If the address prefix used for each assignment method is different, 406 mix scenario can handle the same as scenario with only one assignment 407 method. If different address assignment methods are used to assign 408 addresses from the same prefix, additional considerations are needed 409 because one binding mechanism may create a binding violating an 410 existing binding from another binding mechanism, e.g., binding from 411 SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp]. 412 Thus, the collision between different SAVI mechanisms in mix scenario 413 must be handled in case more than one address assignment method is 414 used to assign addresses from the same prefix. 416 Prioritization relationship between different address assignment 417 methods is used as the basis to solve possible collisions. Current 418 standard documents of address assignment methods have implied the 419 prioritization relationship in general cases. However, considering 420 in some scenarios, default prioritization level may not be quite 421 suitable. Configurable prioritization level should be supported in a 422 document of SAVI solution for the mix scenario. 424 7. Prefix Configuration 426 Before setting up a host-level granularity binding, it is important 427 to configure correct prefixes on the SAVI device. This document 428 suggests set 3 prefix configuration mechanisms at SAVI device: 430 o Manual Prefix Configuration: The allowed prefix scope of IPv4 431 Addresses, IPv6 static addresses, IPv6 addresses assigned by 432 SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually 433 at SAVI device. FE80::/64 is always a feasible prefix in IPv6. 435 o Prefix Configuration by RA Snooping: The allowed prefix scope of 436 IPv6 static addresses and IPv6 addresses assigned by Stateless 437 Address Autoconfiguration (SLAAC) can be set at SAVI device 438 through snooping RA message at SAVI device. 440 o Prefix Configuration by DHCP Prefix Delegation (DHCP-PD) Snooping: 441 The allowed prefix scope of IPv6 static addresses, IPv6 addresses 442 assigned by SLAAC, and IPv6 addresses assigned by DHCPv6 can be 443 set through snooping DHCP-PD message at SAVI device. 445 If some of the prefix scopes is set to have no prefix, it implies 446 corresponding address assignment method is not allowed in the 447 network. 449 There is no need to explicitly present these prefix scopes, but these 450 restrictions should be used as premier check in binding set up. 452 When SAVI is partially deployed, binding may fail as RA messages and 453 DHCP-PD can be spoofed. So it is recommended that Manual Prefix 454 Configuration is used unless SAVI gets fully deployed. 456 8. Acknowledgment 458 The authors would like to thank the SAVI working group for a thorough 459 technical discussion on the design and the framework of the SAVI 460 method, as captured in this document, in particular Erik Nordmark, 461 Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to 462 Torben Melsen for reviewing this document. 464 This document was generated using the xml2rfc tool. 466 9. IANA Considerations 468 This memo asks the IANA for no new parameters. 470 Note to RFC Editor: This section will have served its purpose if it 471 correctly tells IANA that no new assignments or registries are 472 required, or if those assignments or registries are created during 473 the RFC publication process. From the authors' perspective, it may 474 therefore be removed upon publication as an RFC at the RFC Editor's 475 discretion. 477 10. Security Considerations 479 This document only discusses the possible methods to mitigate the 480 usage of forged IP addresses. Some such methods may rely on 481 cryptographic methods, but not all do. As a result, it is generally 482 not possible to prove address ownership in any strong sense. If 483 binding anchor is not exclusive for each IP address, or is without 484 strong security, addresses can still be forged. Besides, the binding 485 may not accord with the address management requirement, which can be 486 more specified for each client. However, given no new protocol is 487 introduced, the improvements are still acceptable. If there is 488 requirement the usage of IP address must be of strong security, the 489 only way is using cryptographic based authentication. 491 11. References 492 11.1. Informative References 494 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 495 Internet draft (work in progress), November 2007. 497 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 498 Defeating Denial of Service Attacks which employ IP Source 499 Address Spoofing", RFC 2827, BCP 38, May 2000. 501 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 502 Networks", RFC 3704, BCP 84, March 2004. 504 11.2. Normative References 506 [draft-ietf-savi-threat-scope] 507 McPherson, D., Baker, F., and J. Halpern, "SAVI Threat 508 Scope", draft-ietf-savi-threat-scope-04 (work in 509 progress), March 2011. 511 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 512 RFC 2131, March 1997. 514 [rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 515 and M. Carney, "Dynamic Host Configuration Protocol for 516 IPv6 (DHCPv6)", RFC 3315, July 2003. 518 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 519 Neighbor Discovery (SEND)", RFC 3971, March 2005. 521 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 522 Address Autoconfiguration", RFC 4862, September 2007. 524 [rfc5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 525 Bootstrapping in Split Scenario", RFC 5026, October 2007. 527 [rfc5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 528 Configuration in Internet Key Exchange Protocol Version 2 529 (IKEv2)", RFC 5739, February 2010. 531 [rfc5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 532 "Internet Key Exchange Protocol Version 2 (IKEv2)", 533 RFC 5996, September 2010. 535 [savi-dhcp] 536 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 537 DHCP", draft-ietf-savi-dhcp-07 (work in progress), 538 November 2010. 540 [savi-fcfs] 541 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 542 SAVI: First-Come First-Serve Source-Address Validation for 543 Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work 544 in progress), October 2010. 546 Authors' Addresses 548 Jianping Wu 549 Tsinghua University 550 Computer Science, Tsinghua University 551 Beijing 100084 552 China 554 Email: jianping@cernet.edu.cn 556 Jun Bi 557 Tsinghua University 558 Network Research Center, Tsinghua University 559 Beijing 100084 560 China 562 Email: junbi@tsinghua.edu.cn 564 Marcelo Bagnulo 565 Universidad Carlos III de Madrid 566 Avenida de la Universidad 30 567 Leganes, Madrid 28911 568 Spain 570 Email: marcelo@it.uc3m.es 572 Fred Baker 573 Cisco Systems 574 Santa Barbara, CA 93117 575 United States 577 Email: fred@cisco.com 578 Christian Vogt (editor) 579 Ericsson 580 200 Holger Way 581 San Jose, CA 95134 582 United States 584 Email: christian.vogt@ericsson.com