idnits 2.17.1 draft-acee-rtg-yang-key-chain-04.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 15, 2015) is 3292 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem, Ed. 3 Internet-Draft Y. Qu 4 Intended status: Standards Track D. Yeung 5 Expires: October 17, 2015 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 April 15, 2015 14 Key Chain YANG Data Model 15 draft-acee-rtg-yang-key-chain-04.txt 17 Abstract 19 This document describes the key chain YANG data model. A key chain 20 is a list of elements each containing a key, send lifetime, accept 21 lifetime, and algorithm. By properly overlapping the send and accept 22 lifetimes of multiple key chain elements, keys and algorithms may be 23 gracefully updated. By representing them in a YANG data model, key 24 distribution can be automated. Key chains are commonly used for 25 routing protocol authentication and other applications. In some 26 applications, the protocols do not use the key chain element key 27 directly, but rather a key derivation function is used to derive a 28 short-lived key from the key chain element key. 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 17, 2015. 47 Copyright Notice 49 Copyright (c) 2015 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 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3 68 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4 69 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 4 70 3.2. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5 71 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 7.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 This document describes the key chain YANG data model. A key chain 83 is a list of elements each containing a key, send lifetime, accept 84 lifetime, and algorithm. By properly overlapping the send and accept 85 lifetimes of multiple key chain elements, keys and algorithms may be 86 gracefully updated. By representing them in a YANG data model, key 87 distribution can be automated. Key chains are commonly used for 88 routing protocol authentication and other applications. In some 89 applications, the protocols do not use the key chain element key 90 directly, but rather a key derivation function is used to derive a 91 short-lived key from the key chain element key. 93 1.1. Requirements Notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC-KEYWORDS]. 99 2. Problem Statement 101 This document describes a YANG [YANG] data model for key chains. Key 102 chains have been implemented and deployed by a large percentage of 103 network equipment vendors. Providing a standard YANG model will 104 facilitate automated key distribution and non-disruptive key 105 rollover. This will aid in tightening the security of the core 106 routing infrastructure as recommended in [IAB-REPORT]. 108 A key chain is a list of containing one or more elements containing a 109 Key ID, key, send/accept lifetimes, and the associated authentication 110 or encryption algorithm. A conceptual representation of a crypto key 111 table is described in [CRYPTO-KEYTABLE]. The key chain model 112 presented herein represents a practical implementation of the crypto 113 key table. However, the key selection is left to the applications 114 requiring authentication or encryption. This is more inline with the 115 current operational model. 117 2.1. Graceful Key Rollover using Key Chains 119 Key chains may be used to gracefully update the key and/or algorithm 120 used by an application for authentication or encryption. This MAY be 121 accomplished by accepting all the keys that have a valid accept 122 lifetime and sending the key with the most recent send lifetime. One 123 scenario for facilitating key rollover is to: 125 1. Distribute a key chain with a new key to all the routers or other 126 network devices in the domain of that key chain. The new key's 127 accept lifetime should be such that it is accepted during the key 128 rollover period. The send lifetime should be a time in the 129 future when it can be assured that all the routers in the domain 130 of that key are upgraded. This will have no immediate impact on 131 the keys used for transmission. 133 2. Assure that all the network devices have been updated with the 134 updated key chain and that their system times are roughly 135 synchronized. The system times of devices within an 136 administrative domain are commonly synchronized (e.g., using 137 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 138 automated. 140 3. When the send lifetime of the new key becomes valid, the network 141 devices within the domain of key chain will start sending the new 142 key. 144 4. At some point in the future, a new key chain with the old key 145 removed may be distributed to the network devices within the 146 domain of the key chain. However, this may be deferred until the 147 next key rollover. If this is done, the key chain will always 148 include two keys; either the current and future key (during key 149 rollovers) or the current and previous keys (between key 150 rollovers). 152 3. Design of the Key Chain Model 154 The ietf-keychain module contains a list of one or more keys indexed 155 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 156 Key-Id is used to identify the key chain entry to be used. In 157 addition to the Key-ID, each key chain entry includes a key-string 158 and a cryptographic algorithm. Optionally, the key chain entries 159 include send/accept lifetimes. If the send/accept lifetime is 160 unspecified, the key is always considered valid. 162 Note that asymmetric keys, i.e., a different key value used for 163 transmission versus acceptance, may be supported with multiple key 164 chain elements where the accept-lifetime or send-lifetime is not 165 valid (e.g., has an end-time equal to the start-time). 167 Due to the differences in key chain implementations across various 168 vendors, some of the data elements are optional. Additionally, the 169 key-chain is made a grouping so that an implementation could support 170 scoping other than at the global level. Finally, the crypto- 171 algorithm-types grouping is provided for reuse when configuring 172 legacy authentication and encryption not using key-chains. 174 A key-chain is identified by a unique name within the scope of the 175 network device. The "key-chain-ref" typedef SHOULD be used by other 176 YANG modules when they need to reference a configured key-chain. 178 3.1. Key Chain Operational State 180 The key chain operational state is maintained in a separate tree. In 181 addition the configuration state, it includes an indication of 182 whether or not a key chain entry is valid for sending or acceptance. 184 3.2. Key Chain Model Tree 186 +--rw key-chains 187 | +--rw key-chain-list* [name] 188 | +--rw name string 189 | +--rw accept-tolerance {accept-tolerance}? 190 | | +--rw duration? uint32 191 | +--rw key-chain-entry* [key-id] 192 | +--rw key-id uint64 193 | +--rw key-string 194 | | +--rw (key-string-style)? 195 | | +--:(keystring) 196 | | | +--rw keystring? string 197 | | +--:(hexadecimal) {hex-key-string}? 198 | | +--rw hexadecimal-string? yang:hex-string 199 | +--rw lifetime 200 | | +--rw (lifetime)? 201 | | +--:(send-and-accept-lifetime) 202 | | | +--rw send-accept-lifetime 203 | | | +--rw (lifetime)? 204 | | | +--:(always) 205 | | | | +--rw always? empty 206 | | | +--:(start-end-time) 207 | | | +--rw start-date-time? yang:date-and-time 208 | | | +--rw (end-time)? 209 | | | +--:(infinite) 210 | | | | +--rw no-end-time? empty 211 | | | +--:(duration) 212 | | | | +--rw duration? uint32 213 | | | +--:(end-date-time) 214 | | | +--rw end-date-time? 215 | | | yang:date-and-time 216 | | +--:(independent-send-accept-lifetime) 217 | | | {independent-send-accept-lifetime}? 218 | | +--rw send-lifetime 219 | | | +--rw (lifetime)? 220 | | | +--:(always) 221 | | | | +--rw always? empty 222 | | | +--:(start-end-time) 223 | | | +--rw start-date-time? yang:date-and-time 224 | | | +--rw (end-time)? 225 | | | +--:(infinite) 226 | | | | +--rw no-end-time? empty 227 | | | +--:(duration) 228 | | | | +--rw duration? uint32 229 | | | +--:(end-date-time) 230 | | | +--rw end-date-time? 231 | | | yang:date-and-time 232 | | +--rw accept-lifetime 233 | | +--rw (lifetime)? 234 | | +--:(always) 235 | | | +--rw always? empty 236 | | +--:(start-end-time) 237 | | +--rw start-date-time? yang:date-and-time 238 | | +--rw (end-time)? 239 | | +--:(infinite) 240 | | | +--rw no-end-time? empty 241 | | +--:(duration) 242 | | | +--rw duration? uint32 243 | | +--:(end-date-time) 244 | | +--rw end-date-time? 245 | | yang:date-and-time 246 | +--rw crypto-algorithm 247 | +--rw (algorithm)? 248 | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 249 | | +--rw hmac-sha1-12? empty 250 | +--:(md5) 251 | | +--rw md5? empty 252 | +--:(sha-1) 253 | | +--rw sha-1? empty 254 | +--:(hmac-sha-1) 255 | | +--rw hmac-sha-1? empty 256 | +--:(hmac-sha-256) 257 | | +--rw hmac-sha-256? empty 258 | +--:(hmac-sha-384) 259 | | +--rw hmac-sha-384? empty 260 | +--:(hmac-sha-512) 261 | +--rw hmac-sha-512? empty 262 +--ro key-chains-state 263 +--ro key-chain-list-state* 264 +--ro name-state? string 265 +--ro accept-tolerance-state 266 | +--ro duration? uint32 267 +--ro key-chain-entry* [key-id] 268 +--ro key-id uint64 269 +--ro lifetime-state 270 | +--ro send-lifetime 271 | | +--ro (lifetime)? 272 | | +--:(always) 273 | | | +--ro always? empty 274 | | +--:(start-end-time) 275 | | +--ro start-date-time? yang:date-and-time 276 | | +--ro (end-time)? 277 | | +--:(infinite) 278 | | | +--ro no-end-time? empty 279 | | +--:(duration) 280 | | | +--ro duration? uint32 281 | | +--:(end-date-time) 282 | | +--ro end-date-time? yang:date-and-time 283 | +--ro send-valid? boolean 284 | +--ro accept-lifetime 285 | | +--ro (lifetime)? 286 | | +--:(always) 287 | | | +--ro always? empty 288 | | +--:(start-end-time) 289 | | +--ro start-date-time? yang:date-and-time 290 | | +--ro (end-time)? 291 | | +--:(infinite) 292 | | | +--ro no-end-time? empty 293 | | +--:(duration) 294 | | | +--ro duration? uint32 295 | | +--:(end-date-time) 296 | | +--ro end-date-time? yang:date-and-time 297 | +--ro accept-valid? boolean 298 +--ro crypto-algorithm-state 299 +--ro (algorithm)? 300 +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 301 | +--ro hmac-sha1-12? empty 302 +--:(md5) 303 | +--ro md5? empty 304 +--:(sha-1) 305 | +--ro sha-1? empty 306 +--:(hmac-sha-1) 307 | +--ro hmac-sha-1? empty 308 +--:(hmac-sha-256) 309 | +--ro hmac-sha-256? empty 310 +--:(hmac-sha-384) 311 | +--ro hmac-sha-384? empty 312 +--:(hmac-sha-512) 313 +--ro hmac-sha-512? empty 315 4. Key Chain YANG Model 317 318 module ietf-key-chain { 319 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 320 // replace with IANA namespace when assigned 321 prefix "key-chain"; 323 import ietf-yang-types { 324 prefix "yang"; 325 } 326 organization 327 "Cisco Systems 328 170 West Tasman Drive 329 San Jose, CA 95134-1706 330 USA"; 331 contact 332 "Acee Lindem - acee@cisco.com"; 334 description 335 "This YANG module defines the generic configuration 336 data for key-chain. It is intended that the module 337 will be extended by vendors to define vendor-specific 338 key-chain configuration parameters. 339 "; 341 revision 2015-02-24 { 342 description 343 "Initial revision."; 344 reference 345 "RFC XXXX: A YANG Data Model for key-chain"; 346 } 348 typedef key-chain-ref { 349 type leafref { 350 path "/key-chain:key-chains/key-chain-list/key-chain:name"; 351 } 352 description 353 "This type is used by data models that need to reference 354 configured key-chains."; 355 } 357 feature hex-key-string { 358 description 359 "Support hexadecimal key string."; 360 } 362 feature accept-tolerance { 363 description 364 "To specify the tolerance or acceptance limit."; 365 } 367 feature independent-send-accept-lifetime { 368 description 369 "Support for independent send and accept key lifetimes."; 370 } 372 feature crypto-hmac-sha-1-12 { 373 description 374 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 375 } 377 grouping lifetime { 378 description 379 "Key lifetime specification."; 380 choice lifetime { 381 default always; 382 description 383 "Options for specifying key accept or send lifetimes"; 384 case always { 385 leaf always { 386 type empty; 387 description 388 "Indicates key lifetime is always valid."; 389 } 390 } 391 case start-end-time { 392 leaf start-date-time { 393 type yang:date-and-time; 394 description "Start time."; 395 } 396 choice end-time { 397 default infinite; 398 description 399 "End-time setting."; 400 case infinite { 401 leaf no-end-time { 402 type empty; 403 description 404 "Indicates key lifetime end-time in infinite."; 405 } 406 } 407 case duration { 408 leaf duration { 409 type uint32 { 410 range "1..2147483646"; 411 } 412 units seconds; 413 description "Key lifetime duration, in seconds"; 414 } 415 } 416 case end-date-time { 417 leaf end-date-time { 418 type yang:date-and-time; 419 description "End time."; 420 } 421 } 423 } 424 } 425 } 426 } 428 grouping crypto-algorithm-types { 429 description "Cryptographic algorithm types."; 430 choice algorithm { 431 description 432 "Options for crytographic algorithm specification."; 433 case hmac-sha-1-12 { 434 if-feature crypto-hmac-sha-1-12; 435 leaf hmac-sha1-12 { 436 type empty; 437 description "The HMAC-SHA-1-12 algorithm."; 438 } 439 } 440 case md5 { 441 leaf md5 { 442 type empty; 443 description "The MD5 algorithm."; 444 } 445 } 446 case sha-1 { 447 leaf sha-1 { 448 type empty; 449 description "The SHA-1 algorithm."; 450 } 451 } 452 case hmac-sha-1 { 453 leaf hmac-sha-1 { 454 type empty; 455 description "HMAC-SHA-1 authentication algorithm."; 456 } 457 } 458 case hmac-sha-256 { 459 leaf hmac-sha-256 { 460 type empty; 461 description "HMAC-SHA-256 authentication algorithm."; 462 } 463 } 464 case hmac-sha-384 { 465 leaf hmac-sha-384 { 466 type empty; 467 description "HMAC-SHA-384 authentication algorithm."; 468 } 469 } 470 case hmac-sha-512 { 471 leaf hmac-sha-512 { 472 type empty; 473 description "HMAC-SHA-512 authentication algorithm."; 474 } 475 } 476 } 477 } 479 grouping key-chain { 480 description 481 "key-chain specification grouping."; 482 leaf name { 483 type string; 484 description "Name of the key-chain."; 485 } 487 container accept-tolerance { 488 if-feature accept-tolerance; 489 description 490 "Tolerance for key lifetime acceptance (seconds)."; 491 leaf duration { 492 type uint32; 493 units seconds; 494 default "0"; 495 description 496 "Tolerance range, in seconds."; 497 } 498 } 500 list key-chain-entry { 501 key "key-id"; 502 description "One key."; 503 leaf key-id { 504 type uint64; 505 description "Key id."; 506 } 507 container key-string { 508 description "The key string."; 509 choice key-string-style { 510 description 511 "Key string styles"; 512 case keystring { 513 leaf keystring { 514 type string; 515 description "Key string in ASCII format."; 516 } 517 } 518 case hexadecimal { 519 if-feature hex-key-string; 520 leaf hexadecimal-string { 521 type yang:hex-string; 522 description 523 "Key in hexadecimal string format."; 524 } 525 } 526 } 527 } 528 container lifetime { 529 description "Specify a key's lifetime."; 530 choice lifetime { 531 description 532 "Options for specification of send and accept 533 lifetimes."; 534 case send-and-accept-lifetime { 535 description 536 "Send and accept key have the same lifetime."; 537 container send-accept-lifetime { 538 uses lifetime; 539 description 540 "Single lifetime specification for both send and 541 accept lifetimes."; 542 } 543 } 544 case independent-send-accept-lifetime { 545 if-feature independent-send-accept-lifetime; 546 description 547 "Independent send and accept key lifetimes."; 548 container send-lifetime { 549 uses lifetime; 550 description 551 "Separate lifetime specification for send 552 lifetime."; 553 } 554 container accept-lifetime { 555 uses lifetime; 556 description 557 "Separate lifetime specification for accept 558 lifetime."; 559 } 560 } 561 } 562 } 563 container crypto-algorithm { 564 uses crypto-algorithm-types; 565 description "Cryptographic algorithm associated with key."; 566 } 568 } 569 } 570 container key-chains { 571 list key-chain-list { 572 key "name"; 573 description 574 "List of key-chains."; 575 uses key-chain; 576 } 577 description "All configured key-chains for the device."; 578 } 580 container key-chains-state { 581 config "false"; 582 description "All configured key-chains state."; 583 list key-chain-list-state { 584 description "One key-chain state."; 585 leaf name-state { 586 type string; 587 description "Configured name of the key-chain."; 588 } 590 container accept-tolerance-state { 591 description 592 "Configured tolerance for key lifetime 593 acceptance (seconds)."; 594 leaf duration { 595 type uint32; 596 description 597 "Configured tolerance range, in seconds."; 598 } 599 } 601 list key-chain-entry { 602 key "key-id"; 603 description "One key."; 604 leaf key-id { 605 type uint64; 606 description "Configurd key id."; 607 } 608 container lifetime-state { 609 description "Configured key's lifetime."; 610 container send-lifetime { 611 uses lifetime; 612 description 613 "Configured send-lifetime."; 614 } 615 leaf send-valid { 616 type boolean; 617 description 618 "Status of send-lifetime."; 619 } 620 container accept-lifetime { 621 uses lifetime; 622 description 623 "Configured accept-lifetime."; 624 } 625 leaf accept-valid { 626 type boolean; 627 description 628 "Status of accept-lifetime."; 629 } 630 } 631 container crypto-algorithm-state { 632 uses crypto-algorithm-types; 633 description "Configured cryptographic algorithm."; 634 } 635 } 636 } 637 } 638 } 639 641 5. Security Considerations 643 This document enables the automated distribution of industry standard 644 key chains using the NETCONF [NETCONF] protocol. As such, the 645 security considerations for the NETCONF protocol are applicable. 646 Given that the key chains themselves are sensitive data, it is 647 RECOMMENDED that the NETCONF communication channel be encrypted. One 648 way to do accomplish this would be to invoke and run NETCONF over SSH 649 as described in [NETCONF-SSH]. 651 6. IANA Considerations 653 This document registers a URI in the IETF XML registry 654 [XML-REGISTRY]. Following the format in RFC 3688, the following 655 registration is requested to be made: 657 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 659 Registrant Contact: The IESG. 661 XML: N/A, the requested URI is an XML namespace. 663 This document registers a YANG module in the YANG Module Names 664 registry [YANG]. 666 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 667 chain prefix: ietf-key-chain reference: RFC XXXX 669 7. References 671 7.1. Normative References 673 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 674 Bierman, "Network Configuration Protocol (NETCONF)", RFC 675 6241, June 2011. 677 [NETCONF-SSH] 678 Wasserman, M., "Using NETCONF Protocol over Secure Shell 679 (SSH)", RFC 6242, June 2011. 681 [RFC-KEYWORDS] 682 Bradner, S., "Key words for use in RFC's to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 [XML-REGISTRY] 686 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 687 January 2004. 689 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 690 Network Configuration Protocol (NETCONF)", RFC 6020, 691 October 2010. 693 7.2. Informative References 695 [CRYPTO-KEYTABLE] 696 Housley, R., Polk, T., Hartman, S., and D. Zhang, 697 "Table of Cryptographic Keys", RFC 7210, April 2014. 699 [IAB-REPORT] 700 Andersson, L., Davies, E., and L. Zhang, "Report from the 701 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 702 4948, August 2007. 704 [NTP-PROTO] 705 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 706 Time Protocol Version 4: Protocol and Algorithms 707 Specification", RFC 5905, June 2010. 709 [OSPFV3-AUTH] 710 Bhatia, M., Manral, V., and A. Lindem, "Supporting 711 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 713 Appendix A. Acknowledgments 715 The RFC text was produced using Marshall Rose's xml2rfc tool. 717 Authors' Addresses 719 Acee Lindem (editor) 720 Cisco Systems 721 301 Midenhall Way 722 Cary, NC 27513 723 USA 725 Email: acee@cisco.com 727 Yingzhen Qu 728 Cisco Systems 729 170 West Tasman Drive 730 San Jose, CA 95134 731 USA 733 Email: yiqu@cisco.com 735 Derek Yeung 736 Cisco Systems 737 170 West Tasman Drive 738 San Jose, CA 95134 739 USA 741 Email: myeung@cisco.com 743 Ing-Wher Chen 744 Ericsson 746 Email: ing-wher.chen@ericsson.com 747 Jeffrey Zhang 748 Juniper Networks 749 10 Technology Park Drive 750 Westford, MA 01886 751 USA 753 Email: zzhang@juniper.net 755 Yi Yang 756 Cisco Systems 757 7025 Kit Creek Road 758 Research Triangle Park, NC 27709 759 USA 761 Email: yiya@cisco.com