idnits 2.17.1 draft-ietf-bfd-generic-crypto-auth-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 date (April 17, 2014) is 3661 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) == Unused Reference: 'RFC1321' is defined on line 512, but no explicit reference was found in the text 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 M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track V. Manral 5 Expires: October 19, 2014 Hewlett-Packard Co. 6 D. Zhang 7 Huawei 8 M. Jethanandani 9 Ciena Corporation 10 April 17, 2014 12 BFD Generic Cryptographic Authentication 13 draft-ietf-bfd-generic-crypto-auth-06 15 Abstract 17 This document proposes an extension to Bidirectional Forwarding 18 Detection (BFD) to allow the use of arbitrary cryptographic 19 authentication algorithms in addition to the already-documented 20 authentication schemes described in the base specification. This 21 document adds the basic infrastructure that is required for 22 supporting algorithm and key agility for BFD. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 19, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. BFD Security Association . . . . . . . . . . . . . . . . . . 4 66 3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5 67 3.1. Authentication Types . . . . . . . . . . . . . . . . . . 5 68 3.2. Authentication Section Format . . . . . . . . . . . . . . 5 69 3.3. Procedures at the Sending Side . . . . . . . . . . . . . 6 70 3.4. Procedure at the Receiving Side . . . . . . . . . . . . . 7 71 3.5. Key Selection for BFD Packet Transmission . . . . . . . . 8 72 3.6. Replay Protection using Extended Sequence Numbers . . . . 9 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The base specification of Bidirectional Forwarding Detection 84 [RFC5880] defines five authentication schemes: Simple Password, Keyed 85 MD5, Meticulous Keyed MD5, Keyed SHA-1, and Meticulous SHA-1. In 86 Simple Password, passwords are transferred in plain text. An 87 attacker with physical access to the network can easily eavesdrop on 88 the password and compromise the security of the BFD packet exchanges. 89 In Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both 90 sides of a BFD session share a secret key which is used to generate a 91 keyed MD5 digest for each packet, and a monotonically increasing 92 sequence number scheme is used to prevent replay attacks. Keyed 93 SHA-1 and Meticulous SHA-1 modes are similar to MD5, and it uses 94 SHA-1 instead of MD5 to generate a digest for each packet. 96 The security strength of the cryptographic algorithms adopted in the 97 authentication schemes are relatively weak. Both the MD5 algorithm 98 and the SHA-1 algorithm are known to be vulnerable to collision 99 attacks. In MD5-attack [MD5-attack] and Dobb96a [Dobb96a], Dobb96b 100 [Dobb96b], several methods of generating hash collisions for some 101 applications of MD5 are proposed. Similar security vulnerabilities 102 of SHA-1 are introduced in SHA-1-attack1 [SHA-1-attack1] and 103 SHA-1-attack2 [SHA-1-attack2]. It is therefore desired that BFD must 104 support newer algorithms that have not yet been broken. 105 Additionally, the transition mechanism from one algorithm to the 106 other must be seamless. 108 The other issue with the existing authentication schemes is the 109 vulnerability to replay attacks. In non-meticulous authentication 110 schemes, sequence numbers are only increased occasionally. This 111 behavior can be taken advantage of by an attacker to perform intra- 112 session replay attacks. In meticulous authentication schemes, 113 sequence numbers are required to monotonically increase with each 114 successive packet, which eliminates the possibility of intra-session 115 replay attacks. 117 BFD session timers are often defined with the granularity of 118 microseconds. Although in practice BFD devices send packets at 119 millisecond intervals, they can potentially send packets at a much 120 higher rate. Since the cryptographic sequence number space is only 121 32 bits, when using Meticulous Authentication, a sequence number used 122 in a BFD session can reach its maximum value and roll over within a 123 short period. For instance, if the value of a sequence number is 124 increased by one every millisecond, then it will reach its maximum in 125 less than 8 weeks. This can potentially be exploited to launch 126 inter-session replay attacks. 128 In order to address the issues mentioned above, this document 129 proposes two new authentication types that can be used to secure the 130 BFD packets. The two authentication types are - Cryptographic 131 Authentication (CRYPTO_AUTH) and Meticulous Cryptographic 132 Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication 133 types that were defined in BFD, the proposed authentication types are 134 not tied to any particular authentication algorithm or construct. 135 These can use different authentication algorithms and constructs like 136 MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide 137 authentication and data integrity protection for BFD control packets. 139 The packet replay mechanism has also been enhanced to improve its 140 capability in handling inter and intra-session replay attacks. 142 It should be noted that this document attempts to fix the security 143 issues raised by the manual key management procedure that currently 144 exists within BFD, as part of the Phase One described in KARP Design 145 Guidelines [RFC6518]. Therefore, only the pre-shared keys is 146 considered in this document. However, the solution described in this 147 document is generic and does not preclude the possibility of 148 supporting keys derived from an automated key management protocol. 150 2. BFD Security Association 152 The BFD protocol does not include an in-band mechanism to create or 153 manage BFD Security Associations (BFD SA). A BFD SA contains a set 154 of shared parameters between any two legitimate BFD devices. 156 The parameters associated with a BFD SA are listed as follows: 158 o Authentication Algorithm : This indicates the authentication 159 algorithm to be used with the BFD SA. This information SHOULD 160 never be sent in plain text over the wire. 162 o Authentication Key : This indicates the cryptographic key 163 associated with this BFD SA. The length of this key is variable 164 and depends upon the authentication algorithm specified by the BFD 165 SA. Operators MUST ensure that this is never sent over the 166 network in clear-text via any protocol. Care should also be taken 167 to ensure that the selected key is unpredictable, avoiding any 168 keys known to be weak for the algorithm in use. Randomness 169 Requirements for Security [RFC4086] contains helpful information 170 on both key generation techniques and cryptographic randomness. 172 o Authentication Key Identifier (Key ID) : This is a two octet 173 unsigned integer used to uniquely identify the BFD SA. This ID 174 could be manually configured by the network operator (or, in the 175 future, possibly by some key management protocol specified by the 176 IETF). The receiver determines the active SA by looking at this 177 field in the incoming packet. The sender puts this Key ID in the 178 BFD packet based on the active configuration. Using Key IDs makes 179 changing keys while maintaining protocol operation convenient. 180 Normally, an implementation would allow the network operator to 181 configure a set of keys in a key chain, with each key in the chain 182 having fixed lifetime. The actual operation of these mechanisms 183 is outside the scope of this document. A key ID indicates a tuple 184 of an authentication key and an associated authentication 185 algorithm. If a key is expected to be applied with different 186 algorithms, different Key IDs must be used to identify the 187 associations of the key with its authentication algorithms 188 respectively. However, the application of a key for different 189 purposes must be very careful, since it may make an adversary 190 easier to collect more material to compromise the key. 192 o Not Before Time : The time point before which the key should not 193 be used. 195 o Not After Time : The time point after which the key should not be 196 used. 198 3. Authentication Procedures 200 In the proposed authentication extension, an optional authentication 201 section (Generic Authentication Section) and two authentication types 202 (Generic Cryptographic Authentication and Generic Meticulous 203 Cryptographic Authentication) are specified. 205 3.1. Authentication Types 207 The Authentication section is only present in a BFD packet if the 208 Authentication Present (A) bit is set in the packet header. The Auth 209 Type in the Authentication section is set to TBD1 when Generic 210 Cryptographic Authentication is in use, while it is set to TBD2 when 211 Generic Meticulous Cryptographic Authentication is in use. 213 Both the authentication types use a monotonically increasing sequence 214 number to protect the BFD session against reply attacks. The only 215 difference between the two types is that the sequence number is 216 occasionally incremented in the Cryptographic Authentication mode, as 217 against the Meticulous Cryptographic Authentication mode, where it is 218 incremented on every packet. 220 As a result of this, in the Cryptographic Authentication scheme, a 221 replay attack is possible till the next sequence number is sent out. 223 3.2. Authentication Section Format 225 A new authentication type, TBD1 or TBD2, indicating the generic 226 cryptographic authentication mechanism in use, is inserted in the 227 first octet of Authentication Section of the BFD control packet. 229 For a BFD packet, if the Authentication Present (A) bit is set in the 230 header and the Authentication Type field is TBD1 (Generic 231 Cryptographic Authentication) or TBD2 (Generic Meticulous 232 Cryptographic Authentication), the Authentication Section has the 233 following format: 235 0 1 2 3 236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Auth Type | Auth Len | Auth Key ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Sequence Number (High Order 32 Bits) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Sequence Number (Low Order 32 Bits) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 | Authentication Data (Variable) | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 o Auth Type: The Authentication Type, which in this case is TBD1 250 (Cryptographic Authentication) or TBD2 (Meticulous Cryptographic 251 Authentication). 253 o Auth Len: The length of the Authentication Section. 255 o Auth Key ID: The Key ID of the authentication key used for this 256 packet, enabling multiple keys to be active simultaneously. 258 o Sequence Number: A 64-bit sequence number that is used to prevent 259 replay attacks. For Cryptographic Authentication this value is 260 incremented occasionally. For Meticulous Cryptographic 261 Authentication, this value is incremented for each successive 262 packet transmitted for a session. 264 o Authentication Data: This field carries the digest computed by 265 whatever Cryptographic Authentication algorithm is being used to 266 authenticate the BFD control packet. 268 3.3. Procedures at the Sending Side 270 Before a BFD device sends a BFD packet out, the device needs to 271 select an appropriate BFD SA from its local key database if a keyed 272 digest for the packet is required. If no appropriate SA is 273 available, the BFD packet MUST be discarded. 275 If an appropriate SA is available, the device then derives the key 276 and the associated authentication algorithm from the SA. 278 The device sets the Authentication Present (A) bit in the packet 279 header. 281 The device MUST fill the Auth Type, the Auth Len fields and the 282 Sequence Number field to bfd.XmitAuthSeq before the authentication 283 data is computed. 285 The Auth Len field in the Authentication section is set as per the 286 authentication algorithm that is being used. 288 The Key ID field is filled. 290 The computation of the digest is performed. The computing process 291 can be various when different algorithms are adopted and is out of 292 the scope of this document. 294 The generated digest is placed in the Authentication Data field. 296 3.4. Procedure at the Receiving Side 298 When a BFD Control packet is received, the following procedure MUST 299 be followed, in the order specified. 301 If the Authentication Present (A) bit is set in the packet header and 302 the Auth Type is TBD1 or TBD2, the receiver is to find an appropriate 303 BFD SA in its local key table to process the packet. The BFD SA is 304 identified by the Key ID field in the Authentication Section of the 305 incoming BFD packet. 307 If the Auth Key ID field does not match the ID of any configured 308 authentication key or the associated key is not in its valid period, 309 the received packet MUST be discarded. 311 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 312 Cryptographic Authentication, if the Sequence Number lies outside of 313 the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) 314 inclusive (when treated as an unsigned 64 bit circular number space), 315 the received packet MUST be discarded. For Meticulous Cryptographic 316 Authentication, if the Sequence Number lies outside of the range of 317 bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 318 treated as an unsigned 64 bit circular number space, the received 319 packet MUST be discarded. 321 The device then prepares for generating a digest of the packet. 322 First of all, the authentication data in the Authentication Value 323 field needs to be saved somewhere else. Then the Authentication 324 Value field is set with a pre-specified value (which may be various 325 in different security algorithms) according the authentication 326 algorithm indicated in the SA. After this, the device starts 327 performing the digest generating operations. The work of defining 328 actual digest generating operations is out of the scope of this 329 document. 331 The calculated data is compared with the received authentication data 332 in the packet and the packet MUST be discarded if the two do not 333 match. In such a case, an error event SHOULD be logged. 335 An implementation MAY have a transition mode where it includes 336 CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but 337 does not verify this information. This is provided as a transition 338 aid for networks in the process of migrating to the new CRYPTO_AUTH 339 and MET_CRYPTO_AUTH based authentication schemes. 341 3.5. Key Selection for BFD Packet Transmission 343 In [I-D.ietf-karp-crypto-key-table], a conceptual key database called 344 "key table" is introduced. A key table is located in the middle of 345 key management protocols and security protocols so that a security 346 protocol can derive long-term keys from the key table but does not 347 have to know the details of key management. This section describes 348 how the proposed security solution selects long-lived keys from key 349 tables [I-D.ietf-karp-crypto-key-table]. 351 Assume that a device R1 tries to send a unicast BFD packet from its 352 interface I1 to the interface R2 of a remote device R2 at time T. 353 Because the key should be shared by the by both R1 and R2 to protect 354 the communication between I1 and I2, R1 needs to provide a protocol 355 ("BFD"), an interface identifier (I1) and a peer identifier (R2) into 356 the key selection function. Any key that satisfies the following 357 conditions may be selected: 359 o The Peer field includes the device ID of R2. 361 o The Protocol field matches "BFD" 363 o The PeerKeyName field is not "unknown". 365 o The Interface field includes I1 or "all". 367 o The Direction field is either "out" or "both". 369 o SendNotBefore <= current time <= SendNotAfter. 371 After a set of keys are provided, a BFD implementation should support 372 selection of keys based on algorithm preference. 374 Upon reception of a BFD packet from R1, R2 provides the protocol 375 ("BFD"), the peer identifier (R1), the key identifier derived from 376 the incoming packet (L), and the interface (I2) to the key table. 377 Any key that satisfies the following conditions may be selected: 379 o The Peer field includes the device ID of R1. 381 o The Protocol field matches "BFD" 383 o The LocalKeyName is L 385 o The Interface field includes I2 or "all". 387 o The Direction field is either "out" or "both". 389 o SendNotBefore <= current time <= SendNotAfter. 391 3.6. Replay Protection using Extended Sequence Numbers 393 As described in Section 1, if the BFD packets in a session are 394 transferred with a high frequency, a 32-bit sequence number may reach 395 its maximum and have to roll back before the session finishes. A 396 attacker thus can replay the packets intercepted before the sequence 397 number wrapped without being detected. To address this problem, the 398 length of the sequence number in the proposed authentication section 399 has been extended to 64 bits. After the extension, the sequence 400 number space of a device will not be exhausted for half of a million 401 years even if the device sends out a BFD packet in every micro- 402 second. Therefore, the replay attack risks caused by the limited 403 sequence number space can be largely addressed. However, in Generic 404 Cryptographic Authentication, the sequence number is only required to 405 increase occasionally. Therefore, a replayed packet may be regarded 406 as a legal one until the packet with a larger sequence number is 407 received. This type of intra-session replay attack cannot be 408 addressed only by extending the length of sequence numbers. 410 An anti-replay solution for BFD also needs to consider the scenarios 411 where a BFD device loses its prior sequence number state (e.g., 412 system crash, loss of power). In such cases, a BFD device has to re- 413 initialize its sequence number. Otherwise, an attacker may be able 414 to replay a previously intercepted without being detected. 416 To address this problem, in the proposed solution, the most 417 significant 32-bit value of the sequence number is used to contain a 418 boot count, and the remainder 32-bit value is used as an ordinary 419 32-bit monotonically increasing sequence number. In Generic 420 Cryptographic Authentication, the remainder 32-bit value is required 421 to increase occasionally, while in Generic Meticulous Cryptographic 422 Authentication, the lower order 32-bit sequence number MUST be 423 incremented for every BFD packet sent by a BFD device. The BFD 424 implementations are required to retain the boot count in non-volatile 425 storage for the deployment life the BFD device. The boot count 426 increases each time when the BFD device loses its prior sequence 427 number state. The SNMPv3 snmpEngineBoots variable [RFC4222] MAY be 428 used for this purpose. However, maintaining a separate boot count 429 solely for BFD sequence numbers has the advantage of decoupling SNMP 430 re-initialization and BFD re-initialization. Also, in the rare event 431 that the lower order 32- bit sequence number wraps, the boot count 432 can be incremented to preserve the strictly increasing property of 433 the aggregate sequence number. Hence, a separate BFD boot count is 434 RECOMMENDED. 436 4. IANA Considerations 438 IANA is requested to assign two authentication types from the "BFD 439 Authentication Types" sub-registry within the "Bidirectional 440 Forwarding Detection (BFD) Parameters" registry. 442 +---------+-----------------------------------------+---------------+ 443 | Address | BFD Authentication Type Name | Reference | 444 +---------+-----------------------------------------+---------------+ 445 | TBD1 | Cryptographic Authentication | This document | 446 | TBD2 | Meticulous Cryptographic Authentication | This document | 447 +---------+-----------------------------------------+---------------+ 449 5. Security Considerations 451 The proposed sequence number extension offers most of the benefits of 452 more complicated mechanisms involving challenges. There are, 453 however, a couple drawbacks to this approach. 455 First, it requires the BFD implementation to be able to save its boot 456 count in non-volatile storage. If the non-volatile storage is ever 457 repaired or upgraded such that the contents are lost or the BFD 458 device is replaced with a model, the keys MUST be changed to prevent 459 replay attacks. 461 Second, if a device is taken out of service completely (either 462 intentionally or due to a persistent failure), the potential exists 463 for re-establishment of a BFD adjacency by replaying the entire BFD 464 session establishment. This scenario is however, extremely unlikely 465 and can be easily avoided. For instance, after recovering from a 466 system failure, a BFD device has to re-establish BFD sessions. At 467 this stage, if the device randomly selects its discriminators to 468 identify new BFD sessions, the possibility of re-establishing a BFD 469 session by replaying the entire BFD session establishment will be 470 eliminated. For the implementations in which discriminators are not 471 randomly selected, this issue can be largely mitigated by integrating 472 the boot count of the remote BFD router in the generation of the 473 authentication data for outgoing BFD packets. Of course, this attack 474 could also be thwarted by changing the relevant manual keys. 476 There is a transition mode suggested where devices can ignore the 477 CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the 478 packets. The operator must ensure that this mode is only used when 479 migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication 480 scheme as this leaves the device vulnerable to an attack. 482 6. Acknowledgements 484 7. References 486 7.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 492 (BFD)", RFC 5880, June 2010. 494 7.2. Informative References 496 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 498 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 499 CryptoBytes", 1996. 501 [I-D.ietf-karp-crypto-key-table] 502 Housley, R., Polk, T., Hartman, S., and D. Zhang, 503 "Database of Long-Lived Symmetric Cryptographic Keys", 504 draft-ietf-karp-crypto-key-table-10 (work in progress), 505 December 2013. 507 [MD5-attack] 508 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 509 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 510 2004. 512 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 513 April 1992. 515 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 516 Requirements for Security", BCP 106, RFC 4086, June 2005. 518 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 519 Version 2 Packets and Congestion Avoidance", BCP 112, RFC 520 4222, October 2005. 522 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 523 Routing Protocols (KARP) Design Guidelines", RFC 6518, 524 February 2012. 526 [SHA-1-attack1] 527 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 528 Full SHA-1", 2005. 530 [SHA-1-attack2] 531 Wang, X., Yao, A., and F. Yao, "New Collision Search for 532 SHA-1", 2005. 534 Authors' Addresses 536 Manav Bhatia 537 Alcatel-Lucent 538 Bangalore 539 India 541 Email: manav.bhatia@alcatel-lucent.com 543 Vishwas Manral 544 Hewlett-Packard Co. 545 19111 Pruneridge Ave. 546 Cupertino, CA 95014 547 USA 549 Email: vishwas.manral@hp.com 551 Dacheng Zhang 552 Huawei 553 Beijing 554 China 556 Email: zhangdacheng@huawei.com 557 Mahesh Jethanandani 558 Ciena Corporation 559 3939 North 1st Street 560 San Jose, CA 95110 561 USA 563 Phone: +1 (408) 904-2160 564 Fax: +1 (408) 944-9290 565 Email: mjethanandani@gmail.com