idnits 2.17.1 draft-acee-rtg-yang-key-chain-07.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 (July 3, 2015) is 3213 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: January 4, 2016 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 July 3, 2015 14 Key Chain YANG Data Model 15 draft-acee-rtg-yang-key-chain-07.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 January 4, 2016. 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 . . . . . . . . . . . . . . . 5 70 3.2. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5 71 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8 72 5. Relationship to other Work . . . . . . . . . . . . . . . . . 15 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 8.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 This document describes the key chain YANG data model. A key chain 84 is a list of elements each containing a key, send lifetime, accept 85 lifetime, and algorithm. By properly overlapping the send and accept 86 lifetimes of multiple key chain elements, keys and algorithms may be 87 gracefully updated. By representing them in a YANG data model, key 88 distribution can be automated. Key chains are commonly used for 89 routing protocol authentication and other applications. In some 90 applications, the protocols do not use the key chain element key 91 directly, but rather a key derivation function is used to derive a 92 short-lived key from the key chain element key. 94 1.1. Requirements Notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC-KEYWORDS]. 100 2. Problem Statement 102 This document describes a YANG [YANG] data model for key chains. Key 103 chains have been implemented and deployed by a large percentage of 104 network equipment vendors. Providing a standard YANG model will 105 facilitate automated key distribution and non-disruptive key 106 rollover. This will aid in tightening the security of the core 107 routing infrastructure as recommended in [IAB-REPORT]. 109 A key chain is a list containing one or more elements containing a 110 Key ID, key, send/accept lifetimes, and the associated authentication 111 or encryption algorithm. A key chain can be used by any service or 112 application requiring authentication or encryption. In essence, the 113 key-chain is a reusable key policy that can be referenced where ever 114 it is required. The key-chain construct has been been implemented by 115 most networking vendors and deployed in many networks. 117 A conceptual representation of a crypto key table is described in 118 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 119 as their corresponding lifetimes and algorithms. Additionally, the 120 key table includes key selection criteria and envisions a deployment 121 model where the details of the applications or services requiring 122 authentication or encryption permeate into the key database. The 123 YANG key-chain model described herein doesn't include key selection 124 criteria or support this deployment model. At the same time, it does 125 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 126 augmentations to the key chain YANG model in support of key selection 127 criteria. 129 2.1. Graceful Key Rollover using Key Chains 131 Key chains may be used to gracefully update the key and/or algorithm 132 used by an application for authentication or encryption. This MAY be 133 accomplished by accepting all the keys that have a valid accept 134 lifetime and sending the key with the most recent send lifetime. One 135 scenario for facilitating key rollover is to: 137 1. Distribute a key chain with a new key to all the routers or other 138 network devices in the domain of that key chain. The new key's 139 accept lifetime should be such that it is accepted during the key 140 rollover period. The send lifetime should be a time in the 141 future when it can be assured that all the routers in the domain 142 of that key are upgraded. This will have no immediate impact on 143 the keys used for transmission. 145 2. Assure that all the network devices have been updated with the 146 updated key chain and that their system times are roughly 147 synchronized. The system times of devices within an 148 administrative domain are commonly synchronized (e.g., using 149 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 150 automated. 152 3. When the send lifetime of the new key becomes valid, the network 153 devices within the domain of key chain will start sending the new 154 key. 156 4. At some point in the future, a new key chain with the old key 157 removed may be distributed to the network devices within the 158 domain of the key chain. However, this may be deferred until the 159 next key rollover. If this is done, the key chain will always 160 include two keys; either the current and future key (during key 161 rollovers) or the current and previous keys (between key 162 rollovers). 164 3. Design of the Key Chain Model 166 The ietf-keychain module contains a list of one or more keys indexed 167 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 168 Key-Id is used to identify the key chain entry to be used. In 169 addition to the Key-ID, each key chain entry includes a key-string 170 and a cryptographic algorithm. Optionally, the key chain entries 171 include send/accept lifetimes. If the send/accept lifetime is 172 unspecified, the key is always considered valid. 174 Note that asymmetric keys, i.e., a different key value used for 175 transmission versus acceptance, may be supported with multiple key 176 chain elements where the accept-lifetime or send-lifetime is not 177 valid (e.g., has an end-time equal to the start-time). 179 Due to the differences in key chain implementations across various 180 vendors, some of the data elements are optional. Additionally, the 181 key-chain is made a grouping so that an implementation could support 182 scoping other than at the global level. Finally, the crypto- 183 algorithm-types grouping is provided for reuse when configuring 184 legacy authentication and encryption not using key-chains. 186 A key-chain is identified by a unique name within the scope of the 187 network device. The "key-chain-ref" typedef SHOULD be used by other 188 YANG modules when they need to reference a configured key-chain. 190 3.1. Key Chain Operational State 192 The key chain operational state is maintained in the key-chain 193 entries along with the configuration state. The key string itself is 194 omitted from the operational state to minimize visibilty similar to 195 what was done with keys in SNMP MIBs. This is an area for further 196 discussion. Additionally, the operational state includes an 197 indication of whether or not a key chain entry is valid for sending 198 or acceptance. 200 3.2. Key Chain Model Tree 202 +--rw key-chains 203 +--rw key-chain-list* [name] 204 +--rw name string 205 +--ro name-state? string 206 +--rw accept-tolerance {accept-tolerance}? 207 | +--rw duration? uint32 208 +--ro accept-tolerance-state 209 | +--ro duration? uint32 210 +--rw key-chain-entry* [key-id] 211 +--rw key-id uint64 212 +--ro key-id-state? uint64 213 +--rw key-string 214 | +--rw (key-string-style)? 215 | +--:(keystring) 216 | | +--rw keystring? string 217 | +--:(hexadecimal) {hex-key-string}? 218 | +--rw hexadecimal-string? yang:hex-string 219 +--rw lifetime 220 | +--rw (lifetime)? 221 | +--:(send-and-accept-lifetime) 222 | | +--rw send-accept-lifetime 223 | | +--rw (lifetime)? 224 | | +--:(always) 225 | | | +--rw always? empty 226 | | +--:(start-end-time) 227 | | +--rw start-date-time? 228 | | | yang:date-and-time 229 | | +--rw (end-time)? 230 | | +--:(infinite) 231 | | | +--rw no-end-time? empty 232 | | +--:(duration) 233 | | | +--rw duration? uint32 234 | | +--:(end-date-time) 235 | | +--rw end-date-time? 236 | | yang:date-and-time 237 | +--:(independent-send-accept-lifetime) 238 | | {independent-send-accept-lifetime}? 239 | +--rw send-lifetime 240 | | +--rw (lifetime)? 241 | | +--:(always) 242 | | | +--rw always? empty 243 | | +--:(start-end-time) 244 | | +--rw start-date-time? 245 | | | yang:date-and-time 246 | | +--rw (end-time)? 247 | | +--:(infinite) 248 | | | +--rw no-end-time? empty 249 | | +--:(duration) 250 | | | +--rw duration? uint32 251 | | +--:(end-date-time) 252 | | +--rw end-date-time? 253 | | yang:date-and-time 254 | +--rw accept-lifetime 255 | +--rw (lifetime)? 256 | +--:(always) 257 | | +--rw always? empty 258 | +--:(start-end-time) 259 | +--rw start-date-time? 260 | | yang:date-and-time 261 | +--rw (end-time)? 262 | +--:(infinite) 263 | | +--rw no-end-time? empty 264 | +--:(duration) 265 | | +--rw duration? uint32 266 | +--:(end-date-time) 267 | +--rw end-date-time? 268 | yang:date-and-time 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? 276 | | yang:date-and-time 277 | | +--ro (end-time)? 278 | | +--:(infinite) 279 | | | +--ro no-end-time? empty 280 | | +--:(duration) 281 | | | +--ro duration? uint32 282 | | +--:(end-date-time) 283 | | +--ro end-date-time? 284 | | yang:date-and-time 285 | +--ro send-valid? boolean 286 | +--ro accept-lifetime 287 | | +--ro (lifetime)? 288 | | +--:(always) 289 | | | +--ro always? empty 290 | | +--:(start-end-time) 291 | | +--ro start-date-time? yang:date-and-time 292 | | +--ro (end-time)? 293 | | +--:(infinite) 294 | | | +--ro no-end-time? empty 295 | | +--:(duration) 296 | | | +--ro duration? uint32 297 | | +--:(end-date-time) 298 | | +--ro end-date-time? 299 | | yang:date-and-time 300 | +--ro accept-valid? boolean 301 +--rw crypto-algorithm 302 | +--rw (algorithm)? 303 | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 304 | | +--rw hmac-sha1-12? empty 305 | +--:(md5) 306 | | +--rw md5? empty 307 | +--:(sha-1) 308 | | +--rw sha-1? empty 309 | +--:(hmac-sha-1) 310 | | +--rw hmac-sha-1? empty 311 | +--:(hmac-sha-256) 312 | | +--rw hmac-sha-256? empty 313 | +--:(hmac-sha-384) 314 | | +--rw hmac-sha-384? empty 315 | +--:(hmac-sha-512) 316 | +--rw hmac-sha-512? empty 317 +--ro crypto-algorithm-state 318 +--ro (algorithm)? 319 +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 320 | +--ro hmac-sha1-12? empty 321 +--:(md5) 322 | +--ro md5? empty 323 +--:(sha-1) 324 | +--ro sha-1? empty 325 +--:(hmac-sha-1) 326 | +--ro hmac-sha-1? empty 327 +--:(hmac-sha-256) 328 | +--ro hmac-sha-256? empty 329 +--:(hmac-sha-384) 330 | +--ro hmac-sha-384? empty 331 +--:(hmac-sha-512) 332 +--ro hmac-sha-512? empty 334 4. Key Chain YANG Model 336 file "ietf-key-chain@2015-07-04.yang" 337 module ietf-key-chain { 338 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 339 // replace with IANA namespace when assigned 340 prefix "key-chain"; 342 import ietf-yang-types { 343 prefix "yang"; 344 } 346 organization 347 "IETF RTG (Routing) Working Group"; 348 contact 349 "Acee Lindem - acee@cisco.com"; 351 description 352 "This YANG module defines the generic configuration 353 data for key-chain. It is intended that the module 354 will be extended by vendors to define vendor-specific 355 key-chain configuration parameters. 357 Copyright (c) 2015 IETF Trust and the persons identified as 358 authors of the code. All rights reserved. 360 Redistribution and use in source and binary forms, with or 361 without modification, is permitted pursuant to, and subject 362 to the license terms contained in, the Simplified BSD License 363 set forth in Section 4.c of the IETF Trust's Legal Provisions 364 Relating to IETF Documents 365 (http://trustee.ietf.org/license-info). 367 This version of this YANG module is part of RFC XXXX; see 368 the RFC itself for full legal notices."; 370 revision 2015-07-04 { 371 description 372 "Updated version. Added Operation State following 373 draft-openconfig-netmod-opstate-00."; 374 reference 375 "RFC XXXX: A YANG Data Model for key-chain"; 376 } 377 revision 2015-02-24 { 378 description 379 "Initial revision."; 380 reference 381 "RFC XXXX: A YANG Data Model for key-chain"; 383 } 385 typedef key-chain-ref { 386 type leafref { 387 path "/key-chain:key-chains/key-chain:key-chain-list/" 388 + "key-chain:name"; 389 } 390 description 391 "This type is used by data models that need to reference 392 configured key-chains."; 393 } 395 feature hex-key-string { 396 description 397 "Support hexadecimal key string."; 398 } 400 feature accept-tolerance { 401 description 402 "To specify the tolerance or acceptance limit."; 403 } 405 feature independent-send-accept-lifetime { 406 description 407 "Support for independent send and accept key lifetimes."; 408 } 410 feature crypto-hmac-sha-1-12 { 411 description 412 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 413 } 415 grouping lifetime { 416 description 417 "Key lifetime specification."; 418 choice lifetime { 419 default always; 420 description 421 "Options for specifying key accept or send lifetimes"; 422 case always { 423 leaf always { 424 type empty; 425 description 426 "Indicates key lifetime is always valid."; 427 } 428 } 429 case start-end-time { 430 leaf start-date-time { 431 type yang:date-and-time; 432 description "Start time."; 433 } 434 choice end-time { 435 default infinite; 436 description 437 "End-time setting."; 438 case infinite { 439 leaf no-end-time { 440 type empty; 441 description 442 "Indicates key lifetime end-time in infinite."; 443 } 444 } 445 case duration { 446 leaf duration { 447 type uint32 { 448 range "1..2147483646"; 449 } 450 units seconds; 451 description "Key lifetime duration, in seconds"; 452 } 453 } 454 case end-date-time { 455 leaf end-date-time { 456 type yang:date-and-time; 457 description "End time."; 458 } 459 } 460 } 461 } 462 } 463 } 465 grouping crypto-algorithm-types { 466 description "Cryptographic algorithm types."; 467 choice algorithm { 468 description 469 "Options for crytographic algorithm specification."; 470 case hmac-sha-1-12 { 471 if-feature crypto-hmac-sha-1-12; 472 leaf hmac-sha1-12 { 473 type empty; 474 description "The HMAC-SHA1-12 algorithm."; 475 } 476 } 477 case md5 { 478 leaf md5 { 479 type empty; 480 description "The MD5 algorithm."; 481 } 482 } 483 case sha-1 { 484 leaf sha-1 { 485 type empty; 486 description "The SHA-1 algorithm."; 487 } 488 } 489 case hmac-sha-1 { 490 leaf hmac-sha-1 { 491 type empty; 492 description "HMAC-SHA-1 authentication algorithm."; 493 } 494 } 495 case hmac-sha-256 { 496 leaf hmac-sha-256 { 497 type empty; 498 description "HMAC-SHA-256 authentication algorithm."; 499 } 500 } 501 case hmac-sha-384 { 502 leaf hmac-sha-384 { 503 type empty; 504 description "HMAC-SHA-384 authentication algorithm."; 505 } 506 } 507 case hmac-sha-512 { 508 leaf hmac-sha-512 { 509 type empty; 510 description "HMAC-SHA-512 authentication algorithm."; 511 } 512 } 513 } 514 } 516 grouping key-chain { 517 description 518 "key-chain specification grouping."; 519 leaf name { 520 type string; 521 description "Name of the key-chain."; 522 } 524 leaf name-state { 525 type string; 526 config false; 527 description "Configured name of the key-chain."; 528 } 530 container accept-tolerance { 531 if-feature accept-tolerance; 532 description 533 "Tolerance for key lifetime acceptance (seconds)."; 534 leaf duration { 535 type uint32; 536 units seconds; 537 default "0"; 538 description 539 "Tolerance range, in seconds."; 540 } 541 } 543 container accept-tolerance-state { 544 config false; 545 description 546 "Configured tolerance for key lifetime 547 acceptance (seconds)."; 548 leaf duration { 549 type uint32; 550 description 551 "Configured tolerance range, in seconds."; 552 } 553 } 555 list key-chain-entry { 556 key "key-id"; 557 description "One key."; 558 leaf key-id { 559 type uint64; 560 description "Key id."; 561 } 562 leaf key-id-state { 563 type uint64; 564 config false; 565 description "Configurd key id."; 566 } 567 container key-string { 568 description "The key string."; 569 choice key-string-style { 570 description 571 "Key string styles"; 572 case keystring { 573 leaf keystring { 574 type string; 575 description "Key string in ASCII format."; 576 } 577 } 578 case hexadecimal { 579 if-feature hex-key-string; 580 leaf hexadecimal-string { 581 type yang:hex-string; 582 description 583 "Key in hexadecimal string format."; 584 } 585 } 586 } 587 } 588 container lifetime { 589 description "Specify a key's lifetime."; 590 choice lifetime { 591 description 592 "Options for specification of send and accept 593 lifetimes."; 594 case send-and-accept-lifetime { 595 description 596 "Send and accept key have the same lifetime."; 597 container send-accept-lifetime { 598 uses lifetime; 599 description 600 "Single lifetime specification for both send and 601 accept lifetimes."; 602 } 603 } 604 case independent-send-accept-lifetime { 605 if-feature independent-send-accept-lifetime; 606 description 607 "Independent send and accept key lifetimes."; 608 container send-lifetime { 609 uses lifetime; 610 description 611 "Separate lifetime specification for send 612 lifetime."; 613 } 614 container accept-lifetime { 615 uses lifetime; 616 description 617 "Separate lifetime specification for accept 618 lifetime."; 619 } 620 } 621 } 622 } 623 container lifetime-state { 624 config false; 625 description "Configured key's lifetime."; 626 container send-lifetime { 627 uses lifetime; 628 description 629 "Configured send-lifetime."; 630 } 631 leaf send-valid { 632 type boolean; 633 description 634 "Status of send-lifetime."; 635 } 636 container accept-lifetime { 637 uses lifetime; 638 description 639 "Configured accept-lifetime."; 640 } 641 leaf accept-valid { 642 type boolean; 643 description 644 "Status of accept-lifetime."; 645 } 646 } 647 container crypto-algorithm { 648 uses crypto-algorithm-types; 649 description "Cryptographic algorithm associated with key."; 650 } 651 container crypto-algorithm-state { 652 config false; 653 uses crypto-algorithm-types; 654 description "Configured cryptographic algorithm."; 655 } 656 } 657 } 659 container key-chains { 660 list key-chain-list { 661 key "name"; 662 description 663 "List of key-chains."; 664 uses key-chain; 665 } 666 description "All configured key-chains for the device."; 667 } 668 } 669 671 5. Relationship to other Work 673 6. Security Considerations 675 This document enables the automated distribution of industry standard 676 key chains using the NETCONF [NETCONF] protocol. As such, the 677 security considerations for the NETCONF protocol are applicable. 678 Given that the key chains themselves are sensitive data, it is 679 RECOMMENDED that the NETCONF communication channel be encrypted. One 680 way to do accomplish this would be to invoke and run NETCONF over SSH 681 as described in [NETCONF-SSH]. 683 The key strings themselves are not included in the operatational 684 state. This is a practice carried over from SNMP MIB modules and is 685 an are for further discussion. 687 7. IANA Considerations 689 This document registers a URI in the IETF XML registry 690 [XML-REGISTRY]. Following the format in RFC 3688, the following 691 registration is requested to be made: 693 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 695 Registrant Contact: The IESG. 697 XML: N/A, the requested URI is an XML namespace. 699 This document registers a YANG module in the YANG Module Names 700 registry [YANG]. 702 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 703 chain prefix: ietf-key-chain reference: RFC XXXX 705 8. References 707 8.1. Normative References 709 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 710 Bierman, "Network Configuration Protocol (NETCONF)", RFC 711 6241, June 2011. 713 [NETCONF-SSH] 714 Wasserman, M., "Using NETCONF Protocol over Secure Shell 715 (SSH)", RFC 6242, June 2011. 717 [RFC-KEYWORDS] 718 Bradner, S., "Key words for use in RFC's to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [XML-REGISTRY] 722 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 723 January 2004. 725 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 726 Network Configuration Protocol (NETCONF)", RFC 6020, 727 October 2010. 729 8.2. Informative References 731 [CRYPTO-KEYTABLE] 732 Housley, R., Polk, T., Hartman, S., and D. Zhang, 733 "Table of Cryptographic Keys", RFC 7210, April 2014. 735 [IAB-REPORT] 736 Andersson, L., Davies, E., and L. Zhang, "Report from the 737 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 738 4948, August 2007. 740 [NTP-PROTO] 741 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 742 Time Protocol Version 4: Protocol and Algorithms 743 Specification", RFC 5905, June 2010. 745 [OSPFV3-AUTH] 746 Bhatia, M., Manral, V., and A. Lindem, "Supporting 747 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 749 [YANG-CRYPTO-KEYTABLE] 750 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 751 chen-rtg-key-table-yang-00.txt (work in progress), March 752 2015. 754 Appendix A. Acknowledgments 756 The RFC text was produced using Marshall Rose's xml2rfc tool. 758 Authors' Addresses 759 Acee Lindem (editor) 760 Cisco Systems 761 301 Midenhall Way 762 Cary, NC 27513 763 USA 765 Email: acee@cisco.com 767 Yingzhen Qu 768 Cisco Systems 769 170 West Tasman Drive 770 San Jose, CA 95134 771 USA 773 Email: yiqu@cisco.com 775 Derek Yeung 776 Cisco Systems 777 170 West Tasman Drive 778 San Jose, CA 95134 779 USA 781 Email: myeung@cisco.com 783 Ing-Wher Chen 784 Ericsson 786 Email: ing-wher.chen@ericsson.com 788 Jeffrey Zhang 789 Juniper Networks 790 10 Technology Park Drive 791 Westford, MA 01886 792 USA 794 Email: zzhang@juniper.net 795 Yi Yang 796 Cisco Systems 797 7025 Kit Creek Road 798 Research Triangle Park, NC 27709 799 USA 801 Email: yiya@cisco.com