idnits 2.17.1 draft-ietf-karp-design-guide-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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 (September 2011) is 4601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP Working Group G. Lebovitz 3 Internet Draft 4 Intended status: Informational M. Bhatia 5 Expires: January, 2012 Alcatel-Lucent 6 September 2011 8 Keying and Authentication for Routing Protocols (KARP) 9 Design Guidelines 11 draft-ietf-karp-design-guide-05.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance 16 with the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months 25 and may be updated, replaced, or obsoleted by other documents 26 at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed 34 at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described 51 in Section 4.e of the Trust Legal Provisions and are provided 52 without warranty as described in the Simplified BSD License. 54 Abstract 56 This document is one of a series concerned with defining a 57 roadmap of protocol specification work for the use of modern 58 cryptographic mechanisms and algorithms for message 59 authentication in routing protocols. In particular, it defines 60 the framework for a key management protocol that may be used to 61 create and manage session keys for message authentication and 62 integrity. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 67 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 68 "OPTIONAL" in this document are to be interpreted as described 69 in RFC 2119. [RFC2119] 71 Table of Contents 73 1. Introduction..................................................3 74 2. Categorizing Routing Protocols................................4 75 2.1. Category: Message Transaction Type.......................4 76 2.2. Category: Peer vs Group Keying...........................6 77 3. Consider the future existence of a Key Management Protocol....6 78 3.1. Consider Asymmetric Keys.................................6 79 3.2. Cryptographic Keys Life Cycle............................8 80 4. RoadMap.......................................................9 81 4.1. Work Phases on any Particular Protocol...................9 82 4.2. Work Items Per Routing Protocol.........................11 83 5. Routing Protocols in Categories..............................13 84 6. Gap Analysis.................................................16 85 7. Security Considerations......................................19 86 7.1. Use Strong Keys.........................................19 87 7.2. Internal vs. External Operation.........................20 88 7.3. Unique versus Shared Keys...............................21 89 7.4. Out-of-Band External Configuration vs. Peer-to-Peer Key 90 Management...................................................23 91 8. Acknowledgments..............................................25 92 9. IANA Considerations..........................................25 93 10. References..................................................25 94 10.1. Normative References...................................25 95 10.2. Informative References.................................26 97 1. Introduction 99 In March 2006 the Internet Architecture Board (IAB) held a 100 workshop on the topic of "Unwanted Internet Traffic". The 101 report from that workshop is documented in RFC 4948 [RFC4948]. 102 Section 8.1 of that document states that "A simple risk 103 analysis would suggest that an ideal attack target of minimal 104 cost but maximal disruption is the core routing 105 infrastructure." Section 8.2 calls for "[t]ightening the 106 security of the core routing infrastructure." Four main steps 107 were identified for that tightening: 109 o Increased security mechanisms and practices for operating 110 routers. This work is being addressed in the OPSEC Working 111 Group. 113 o Cleaning up the Internet Routing Registry repository [IRR], 114 and securing both the database and the access, so that it 115 can be used for routing verifications. This work should be 116 addressed through liaisons with those running the IRR's 117 globally. 119 o Specifications for cryptographic validation of routing 120 message content. This work is being addressed in the 121 SIDR Working Group. 123 o Securing the routing protocols' packets on the wire 125 This document addresses the last bullet, securing the packets 126 on the wire of the routing protocol exchanges. Thus, it is 127 concerned with guidelines for describing issues and techniques 128 for protecting the messages between directly communicating 129 peers. This may overlap with, but is strongly distinct from, 130 protection designed to ensure that routing information is 131 properly authorized relative to sources of this information. 132 Such assurances are provided by other mechanisms and are 133 outside the scope of this document and work that relies on it. 135 This document uses the terminology "on the wire" to talk about 136 the information used by routing systems. This term is widely 137 used in IETF RFCs, but is used in several different ways. In 138 this document, it is used to refer both to information 139 exchanged between routing protocol instances, and to underlying 140 protocols that may also need to be protected in specific 141 circumstances. Individual protocol analysis documents will 142 need to be more specific in their usage. 144 This document refers to routing transport in order to provide a 145 common referent for the varied ways that routing protocols 146 exchange messages. This can be TCP, UDP, or even direct link 147 level messaging in the case of some routing protocols. The 148 term is used here to allow a referent for discussing both 149 common and disparate issues that affect or interact with this 150 dimension of the routing systems. The term is used here to 151 refer generally to the set of mechanisms and exchanges 152 underneath the routing protocol, whatever that is in specific 153 cases. 155 Readers must refer to the [I-D.ietf-karp-threats-reqs] for a 156 clear definition of the scope, goals, non goals and the 157 audience for the design work being undertaken in KARP WG. 159 2. Categorizing Routing Protocols 161 For the purpose of this security roadmap definition, we categorize 162 routing protocols into groups and anticipate that design teams will 163 focus on the specification of security mechanisms within each 164 group. The protocols will be grouped according to the requirements 165 for authentication mechanisms that they are believed to have, and 166 it is assumed that reuse of authentication mechanisms will be 167 possible and desirable within each group. The work items placed on 168 the roadmap will be defined and assigned based on these 169 categorizations. It is also hoped that, down the road we can 170 create one Key Management Protocol (KMP) per category (if not for 171 several categories) so that the work can be easily leveraged by for 172 use in the various Routing Protocol groupings. KMPs are useful for 173 allowing simple, automated updates of the traffic keys used in a 174 base protocol. KMPs replace the need for humans, or OSS routines, 175 to periodically replace keys on running systems. It also removes 176 the need for a chain of manual keys to be chosen or configured on 177 such systems. When configured properly, a KMP will enforce the key 178 freshness policy among peers by keeping track of the key lifetime 179 and negotiating a new key at the defined interval. 181 2.1. Category: Message Transaction Type 183 The first categorization defines three types of messaging 184 transactions used on the wire by the base Routing Protocol. 185 They are: 187 One-to-One 189 One peer router directly and intentionally delivers a route 190 update specifically to one other peer router. Examples are 191 BGP [RFC4271], LDP [RFC5036], BFD [RFC5880] and RSVP-TE 193 [RFC3209] [RFC3473] [RFC4726] [RFC5151]. Point-to-point modes 194 of both IS-IS [RFC1195] and OSPF [RFC2328], when sent over 195 both traditional point-to-point links and when using multi- 196 access layers, may both also fall into this category. 198 One-to-Many 200 A router peers with multiple other routers on a single 201 network segment -- i.e. on link local -- such that it creates 202 and sends one route update message which is intended for 203 consumption by multiple peers. Examples would be OSPF and 204 IS-IS in their broadcast, non-point-to-point mode and Routing 205 Information Protocol (RIP) [RFC2453]. 207 Multicast 209 Multicast protocols have unique security properties because 210 of the fact that they are inherently group-based protocols 211 and thus have group keying requirements at the routing level 212 where link-local routing messages are multicasted. Also, at 213 least in the case of PIM-SM [RFC4601], some messages are sent 214 unicast to a given peer(s), as is the case with router-close- 215 to-sender and the "Rendezvous Point". Some work for 216 application layer message security has been done in the 217 Multicast Security working group (MSEC, 218 http://www.ietf.org/html.charters/msec-charter.html) and may 219 be helpful to review, but is not directly applicable. 221 These categories affect both the routing protocol view of the 222 communication, and the actual message transfer. As a result, 223 some mechanisms for a few routing protocols, may be mixtures, 224 for example using broadcast where multicast might be expected, 225 or using unicast to deliver what looks to the routing protocol 226 like broadcast or multicast. 228 This may include any semantics of the communication that impact 229 the routing protocol, such as when source identity or path 230 properties of the communication path are used by the routing 231 algorithm, e.g., as when BGP infers routing table entry quality 232 from the persistence of the TCP connection over which they are 233 received. 235 Protocol security analysis documents produced in KARP need to 236 pay attention both to the semantics of the communication, and 237 the techniques that are used for the message exchanges. 239 2.2. Category: Peer vs Group Keying 241 The second axis of categorization groups protocols is by the 242 keying mechanism that will be necessary for distributing 243 session keys to the actual Routing Protocol transports. They 244 are: 246 Peer keying 248 One router sends the keying messages only to one other router, 249 such that a one-to-one, uniquely keyed security association 250 (SA) is established between the two routers. This would be 251 employed by protocols like BGP, BFD and LDP. 253 Group Keying 255 One router creates and distributes a single keying message to 256 multiple peers. In this case a group SA will be established 257 and used among multiple peers simultaneously. Group keying 258 exists for protocols like OSPF [RFC2328], and also for 259 multicast protocols like PIM-SM [RFC4601]. 261 3. Consider the future existence of a Key Management Protocol 263 When it comes time for the KARP WG to design a re-usable model 264 for a Key Management Protocol (KMP), [RFC4107] should be 265 consulted. 267 When conducting the design work on a manually-keyed version of 268 a routing protocol's authentication mechanism, consideration 269 must be made for the eventual use of a KMP. In particular, 270 design teams must consider what parameters would need to be 271 handed to the routing protocols by a KMP. 273 Examples of parameters that might need to be passed are: a 274 security association identifier (e.g. IPsec SPI, or TCP-AO's 275 KeyID), a key lifetime (which may be represented either in 276 bytes or seconds), the cryptographic algorithms being used, the 277 keys themselves, and the directionality of the keys (i.e., 278 receive versus the sending keys) 280 3.1. Consider Asymmetric Keys 282 The use of asymmetric keys can be a very powerful way to 283 authenticate machine peers as used in routing protocol peer 284 exchanges. If generated on the machine, and never moved off the 285 machine, these keys will not need to be changed if an 286 administrator leaves the organization. Since the keys are 287 random, and long, they are far less susceptible to off-line 288 dictionary and guessing attacks. 290 An easy and simple way to use asymmetric keys is to start by 291 having the router generate a public/private key pair. At the 292 time of this writing, the recommended key size for algorithms 293 based on integer factorization cryptography like RSA is 1024 294 bits and 2048 for extremely valuable keys like the root key 295 pair used by a certification authority. It is believed that a 296 1024-bit RSA key is equivalent in strength to 80-bit symmetric 297 keys and 2048-bit RSA keys to 112-bit symmetric keys. Elliptic 298 Curve Cryptography [RFC4492] (ECC) appears to be secure with 299 shorter keys than those needed by other asymmetric key 300 algorithms. NIST guidelines [NIST-800-57] state that ECC keys 301 should be twice the length of equivalent strength symmetric key 302 algorithms. Thus, a 224-bit ECC key would roughly have the same 303 strength as a 112-bit symmetric key. 305 Many routers have the ability to be remotely managed using SSH 306 [RFC4252] and [RFC4253]. As such, routers will also have the 307 ability to generate and store an asymmetric key pair, because 308 this is the common authentication method employed to by SSH 309 when a user connects to a router for management sessions. 311 Once an asymmetric key pair is generated, the KMP generating 312 security association parameters and keys for routing protocol 313 may use the machine's asymmetric keys for the identity proof. 314 The form of the identity proof could be raw keys, the more 315 easily administrable self-signed certificate format, or a PKI- 316 issued [RFC5280] certificate credential. 318 Regardless which form we eventually standardize, the proof of 319 this identity presentation can be as simple as a strong hash, 320 which could be represented in a human readable and transferable 321 form of some pairs of ASCII characters. More complex, but also 322 more secure, the identity proof could be verified through the 323 use of a PKI system's revocation checking mechanism, (e.g. 324 Certificate Revocation List (CRL) or OCSP responder). If the 325 SHA-1 fingerprint is used, the solution could be as simple as 326 loading a set of neighbor routers' peer ID strings into a table 327 and listing the associated fingerprint string for each ID 328 string. In most organizations or peering points, this list will 329 not be longer than a thousand or so routers, and often the list 330 will be much shorter. In other words, the entire list for a 331 given organization's router ID & hash could easily be held in a 332 router's configuration file, uploaded, downloaded and move 333 about at will. And it doesn't matter who sees or gains access 334 to these fingerprints, because they can be distributed publicly 335 as it needn't be kept secret. 337 3.2. Cryptographic Keys Life Cycle 339 Cryptographic keys should have a limited lifetime and may need 340 to be changed when an operator who had access to them leaves. 341 Using a key chain also does not help as one still has to change 342 all the keys in the key chain when an operator having access to 343 all those keys leaves the company. Additionally, key chains 344 will not help if the routing transport subsystem does not 345 support rolling over to the new keys without bouncing the 346 routing sessions and adjacencies. So the first step is to fix 347 the routing stack so that routing protocols can change keys 348 without breaking or bouncing the adjacencies. 350 An often cited reason for limiting the lifetime of a key is to 351 minimize the damage from a compromised key. It could be argued 352 that it is likely a user will not discover an attacker has 353 compromised the key if the attacker remains "passive" and thus 354 relatively frequent key changes will limit any potential damage 355 from compromised keys. 357 Another threat against the long-lived key is that one of the 358 systems storing the key, or one of the users entrusted with the 359 key, will be subverted. So, while there may not be 360 cryptographic motivations of changing the keys, there could be 361 a system security motivations for doing the same. 363 Although manual key distribution methods are subject to human 364 error and frailty, more frequent manual key changes might 365 actually increase the risk of exposure as it is during the time 366 that the keys are being changed that they are likely to get 367 disclosed. In these cases, especially when very strong 368 cryptography is employed, it may be more prudent to have fewer, 369 well controlled manual key distributions rather than more 370 frequent, poorly controlled manual key distributions. In 371 general, where strong cryptography is employed, physical, 372 procedural, and logical access protection considerations often 373 have more impact on the key life than do algorithm and key size 374 factors. 376 For incremental deployments we could start by associating life 377 times with the send and the receive keys in the key chain for 378 the long-lived keys. This is an incremental approach that we 379 could use until the cryptographic keying material for 380 individual sessions is derived from the keying material stored 381 in a database of long-lived cryptographic keys as described in 382 [I-D.ietf-saag-crypto-key-table]. A key derivation function 383 (KDF) and its inputs are also specified in the database of 384 long-lived cryptographic keys; session-specific values based on 385 the routing protocol are input to the KDF. Protocol-specific 386 key identifiers may be assigned to the cryptographic keying 387 material for individual sessions if needed. 389 The long-lived cryptographic keys used by the routing protocols 390 can be either inserted manually in a database or can make use 391 of an automated key management protocol to do this. 393 4. RoadMap 395 4.1. Work Phases on any Particular Protocol 397 It is believed that improving security for any routing protocol 398 will be a two step process or could be said to involve two 399 phases. The first would be to fix the manual key management 400 procedures that currently exist within the routing protocols 401 today using modern cryptography algorithms and key agility. The 402 second phase would be to design and move to an automated key 403 management mechanism. This is like a crawl, walk and run 404 process. In order to deliver that to the operators in a way 405 that we could complete these action items a little bit a time 406 and make some incremental advance over what is currently 407 deployed in the wild, we believe that it is therefore useful to 408 cleanly separate the key management protocol from the routing 409 transport subsystem mechanism. This would mean that the routing 410 transport subsystem is oblivious to how the keys are derived, 411 exchanged and downloaded as long as there is something that it 412 can use. It is like having a routing protocol configuration 413 switch that requests the security module for the "KARP security 414 parameters" so that it can refer to some module written by 415 people good in security and who will be maintaining it over the 416 time and insert those parameters in the routing exchange. 418 The desired end state for the KARP work contains several items. 419 First, the people desiring to deploy securely authenticated and 420 integrity validated packets between routing peers have the 421 tools specified, implemented and shipping in order to deploy. 422 These tools should be fairly simple to implement, and not more 423 complex than the security mechanisms to which the operators are 424 already accustomed. (Examples of security mechanisms to which 425 router operators are accustomed include: the use of asymmetric 426 keys for authentication in SSH for router configuration, the 427 use of pre-shared keys (PSKs) in TCP MD5 for BGP protection, 428 the use of self-signed certificates for HTTPS access to device 429 Web-based user interfaces, the use of strongly constructed 430 passwords and/or identity tokens for user identification when 431 logging into routers and management systems.) While the tools 432 that we intend to specify may not be able to stop a deployment 433 from using "foobar" as an input key for every device across 434 their entire routing domain, we intend to make a solid, modern 435 security system that is not too much more difficult than that. 436 In other words, simplicity and deployability are keys to 437 success. The Routing Protocols will specify modern 438 cryptographic algorithms and security mechanisms. Routing 439 peers will be able to employ unique, pair-wise keys per peering 440 instance, with reasonable key lifetimes, and updating those 441 keys on a regular basis will be operationally easy, causing no 442 service interruption. 444 Achieving the above described end-state using manual keys may 445 be pragmatic only in very small deployments. In larger 446 deployments, this end state will be much more operationally 447 difficult to reach with only manual keys. Thus, there will be 448 a need for key life cycle management, in the form of a key 449 management protocol, or KMP. We expect that the two forms, 450 manual key usage and KMP usage, will co-exist in the real 451 world. 453 In accordance with the desired end state just described, we 454 define two main work phases for each Routing Protocol: 456 1. Enhance the Routing Protocol's current authentication 457 mechanism(s). This work involves enhancing a Routing 458 Protocol's current security mechanisms in order to achieve a 459 consistent, modern level of security functionality within its 460 existing key management framework. It is understood and 461 accepted that the existing key management frameworks are 462 largely based on manual keys. Since many operators have 463 already built operational support systems (OSS) around these 464 manual key implementations, there is some automation 465 available for an operator to leverage in that way, if the 466 underlying mechanisms are themselves secure. In this phase, 467 we explicitly exclude embedding or creating a KMP. Refer to 468 [I-D.ietf-karp-threats-reqs] for the list of the requirements 469 for Phase 1 work. 471 2. Develop an automated key management framework. The second 472 phase will focus on the development of an automated keying 473 framework to facilitate unique pair-wise (group-wise, where 474 applicable) keys per peering instance. This involves the use 475 of a KMP. The use of automatic key management mechanisms 476 offers a number of benefits over manual keying. Most 477 importantly it provides fresh traffic keying material for 478 each session, thus helping to prevent inter-connection replay 479 attacks. A KMP is also helpful because it negotiates unique, 480 pair wise, random keys without administrator involvement. It 481 negotiates several SA parameters like algorithms, modes, and 482 parameters required for the secure connection, thus providing 483 interoperability between endpoints with disparate 484 capabilities and configurations. In addition it could also 485 include negotiating the key life times. The KMP can thus keep 486 track of those lifetimes using counters, and can negotiate 487 new keys and parameters before they expire, again, without 488 administrator interaction. Additionally, in the event of a 489 breach, changing the KMP key will immediately cause a rekey 490 to occur for the Traffic Key, and those new Traffic Keys will 491 be installed and used in the current connection. In summary, 492 a KMP provides a protected channel between the peers through 493 which they can negotiate and pass important data required to 494 exchange proof of identities, derive Traffic Keys, determine 495 re-keying, synchronize their keying state, signal various 496 keying events, notify with error messages, etc. 498 4.2. Work Items Per Routing Protocol 500 Each Routing Protocol will have a team (the [Routing_Protocol]- 501 KARP team) working on incrementally improving the security of a 502 Routing Protocol. These teams will have the following main work 503 items: 505 PHASE 1: 507 Characterize the RP 509 Assess the Routing Protocol to see what authentication and 510 integrity mechanisms it has today. Does it needs 511 significant improvement to its existing mechanisms or not? 512 This will include determining if modern, strong security 513 algorithms and parameters are present and if the protocol 514 supports key agility without bouncing adjacencies. 516 Define Optimal State 517 List the requirements for the Routing Protocol's session key 518 usage and format to contain modern, strong security 519 algorithms and mechanisms, per the Requirements document 520 [I-D.ietf-karp-threats-reqs]. The goal here is to determine 521 what is needed for the Routing Protocol to be used securely 522 with at least manual key management. 524 Gap Analysis 526 Enumerate the requirements for this protocol to move from 527 its current security state, the first bullet, to its optimal 528 state, as listed just above. 530 Transition and Deployment Considerations 532 Document the operational transition plan for moving from the 533 old to the new security mechanism. Will adjacencies need to 534 bounce? What new elements/servers/services in the 535 infrastructure will be required? What is an example work 536 flow that an operator will take? The best possible case is 537 if the adjacency does not break, but this may not always be 538 possible. 540 Define, Assign, Design 542 Create a deliverables list of the design and specification 543 work, with milestones. Define owners. Release one or more 544 documents. 546 PHASE 2: 548 KMP Analysis 550 Review requirements for KMPs. Identify any nuances for this 551 particular routing protocol's needs and its use cases for a 552 KMP. List the requirements that this Routing Protocol has 553 for being able to be used in conjunction with a KMP. Define 554 the optimal state and check how easily it can be decoupled 555 from the KMP. 557 Gap Analysis 559 Enumerate the requirements for this protocol to move from 560 its current security state to its optimal state, with 561 respect to the key management. 563 Define, Assign, Design 564 Create a deliverables list of the design and specification 565 work, with milestones. Define owners. Generate the design 566 and document work for a KMP to be able to generate the 567 Routing Protocol's session keys for the packets on the wire. 568 These will be the arguments passed in the API to the KMP in 569 order to bootstrap the session keys for the Routing 570 Protocol. 572 There will also be a team formed to work on the base 573 framework mechanisms for each of the main categories. 575 5. Routing Protocols in Categories 577 This section groups the Routing Protocols into categories, 578 according to attributes set forth in Categories Section 579 (Section 2). Each group will have a design team tasked with 580 improving the security of the Routing Protocol mechanisms and 581 defining the KMP requirements for their group, then rolling 582 both into a roadmap document upon which they will execute. 584 BGP, LDP, PCEP and MSDP 586 These Routing Protocols fall into the category of the one- 587 to-one peering messages, and will use peer keying protocols. 588 BGP [RFC4271], PCEP [RFC5440] and MSDP [RFC3618] messages 589 are transmitted over TCP, while LDP [RFC5036] uses both UDP 590 and TCP. A team will work on one mechanism to cover these 591 TCP unicast protocols. Much of the work on the Routing 592 Protocol update for its existing authentication mechanism 593 has already occurred in the TCPM Working Group, on the TCP- 594 AO [RFC5925] document, as well as its cryptography-helper 595 document, TCP-AO-CRYPTO [RFC5926]. However, TCP-AO cannot 596 be used for discovery exchanges carried in LDP as those are 597 carried over UDP. A separate team might want to look at LDP. 598 Another exception is the mode where LDP is used directly on 599 the LAN. The work for this may go into the Group keying 600 category (along with OSPF) as mentioned below. 602 OSPF, ISIS, and RIP 604 The Routing Protocols that fall into the category Group 605 Keying *with one-to-many peering) includes OSPF [RFC2328], 606 ISIS [RFC1195] and RIP [RFC2453]. Not surprisingly, all 607 these routing protocols have two other things in common. 608 First, they are run on a combination of the OSI datalink 609 layer 2, and the OSI network layer 3. By this we mean that 610 they have a component of how the routing protocol works 611 which is specified in Layer 2 as well as in Layer 3. 612 Second, they are all internal gateway protocols(IGPs). The 613 keying mechanisms will be much more complicated to define 614 for these than for a one-to-one messaging protocol. 616 BFD 618 Because it is less of a routing protocol, per se, and more 619 of a peer liveness detection mechanism, Bidirectional 620 Forwarding Detection (BFD) [RFC5880] will have its own team. 621 BFD is also different from the other protocols covered here 622 as it works on millisecond timers and would need separate 623 considerations to mitigate the potential for DoS attacks. It 624 also raises interesting issues [RFC6039] with respect to the 625 sequence number scheme that is generally deployed to protect 626 against replay attacks as this space can rollover quite 627 frequently because of the rate at which BFD packets are 628 generated. 630 RSVP and RSVP-TE 632 The Resource reSerVation Protocol [RFC2205] allows hop-by- 633 hop authentication of RSVP neighbors, as specified in 634 [RFC2747]. In this mode, an integrity object is attached to 635 each RSVP message to transmit a keyed message digest. This 636 message digest allows the recipient to verify the identity 637 of the RSVP node that sent the message, and to validate the 638 integrity of the message. Through the inclusion of a 639 sequence number in the scope of the digest, the digest also 640 offers replay protection. 642 [RFC2747] does not dictate how the key for the integrity 643 operation is derived. Currently, most implementations of 644 RSVP use a statically configured key, on a per interface or 645 per neighbor basis. 647 RSVP relies on a per peer authentication mechanism, where 648 each hop authenticates its neighbor using a shared key or a 649 certificate. 651 Trust in this model is transitive. Each RSVP node trusts 652 explicitly only its RSVP next hop peers, through the message 653 digest contained in the INTEGRITY object [RFC2747. The next 654 hop RSVP speaker in turn trusts its own peers and so on. 655 See also the document "RSVP security properties" [RFC4230] 656 for more background. 658 The keys used for protecting the RSVP messages can be group 659 keys (for example distributed via GDOI [RFC3547], as 660 discussed in [I-D.weis-gdoi-mac-tek]). 662 The trust an RSVP node has to another RSVP node has an 663 explicit and an implicit component. Explicitly the node 664 trusts the other node to maintain the integrity (and, 665 optionally confidentiality) of RSVP messages depending on 666 whether authentication or encryption (or both) are used. 667 This means that the message has not been altered or its 668 contents seen by another, non-trusted node. Implicitly each 669 node trusts the other node to maintain the level of 670 protection specified within that security domain Note that 671 in any group key management scheme, like GDOI, each node 672 trusts all the other members of the group with regard to 673 data origin authentication. 675 RSVP TE [RFC3209] [RFC3473] [RFC4726] [RFC5151] is an 676 extension of the RSVP protocol for traffic engineering. It 677 supports the reservation of resources across an IP network 678 and is used for establishing MPLS label switch paths (LSPs), 679 taking into consideration network constraint parameters such 680 as available bandwidth and explicit hops. RSVP-TE signaling 681 is used to establish both intra and inter-domain TE LSPs. 683 When signaling an inter-domain RSVP-TE LSP, operators may 684 make use of the security features already defined for RSVP- 685 TE [RFC3209]. This may require some coordination between 686 domains to share keys ([RFC2747],[RFC3097]), and care is 687 required to ensure that the keys are changed sufficiently 688 frequently. Note that this may involve additional 689 synchronization, should the domain border nodes be protected 690 with Fast Reroute, since the merge point (MP) and point of 691 local repair (PLR) should also share the key. 693 For inter-domain signaling for MPLS-TE, the administrators 694 of neighboring domains must satisfy themselves as to the 695 existence of a suitable trust relationship between the 696 domains. In the absence of such a relationship, the 697 administrators should decide not to deploy inter-domain 698 signaling, and should disable RSVP-TE on any inter-domain 699 interfaces. 701 KARP will currently be working only on RSVP-TE as the native 702 RSVP lies outside the scope of the WG charter. 704 PIM-SM and PIM-DM 705 Finally, the multicast protocols PIM-SM [RFC4601] and PIM-DM 706 [RFC3973] will be grouped together. PIM-SM multicasts 707 routing information (Hello, Join/Prune, Assert) on a link- 708 local basis, using a defined multicast address. In 709 addition, it specifies unicast communication for exchange of 710 information (Register, Register-Stop) between the router 711 closest to a group sender and the "rendezvous point" (RP). 712 The RP is typically not "on-link" for a particular router. 713 While much work has been done on multicast security for 714 application-layer groups, little has been done to address 715 the problem of managing hundreds or thousands of small one- 716 to-many groups with link-local scope. Such an 717 authentication mechanism should be considered along with the 718 router-to-Rendezvous Point authentication mechanism. The 719 most important issue is ensuring that only the "authorized 720 neighbors" get the keys for (S,G), so that rogue routers 721 cannot participate in the exchanges. Another issue is that 722 some of the communication may occur intra-domain, e.g. the 723 link-local messages in an enterprise, while others for the 724 same (*,G) may occur inter-domain, e.g. the router-to- 725 Rendezvous Point messages may be from one enterprise's 726 router to another. 728 One possible solution proposes a region-wide "master" key 729 server (possibly replicated), and one "local" key server per 730 speaking router. There is no issue with propagating the 731 messages outside the link, because link-local messages, by 732 definition, are not forwarded. This solution is offered only 733 as an example of how work may progress; further discussion 734 should occur in this work team. Specification of a link- 735 local protection mechanism for PIM-SM is defined in 736 [RFC4601], and this mechanism has been updated in PIM-SM- 737 LINKLOCAL [RFC5796]. However, the KMP part is completely 738 unspecified, and will require work outside the expertise of 739 the PIM working group to accomplish, another example of why 740 this roadmap is being created. 742 6. Gap Analysis 744 The [I-D.ietf-karp-threats-reqs] document lists the generic 745 requirements for the security mechanisms that must exist for 746 the various routing protocols that come under the purview of 747 KARP. There will be different design teams working for each of 748 the categories of routing protocols defined. 750 To start, design teams must review the "Threats and 751 Requirements for Authentication of Routing Protocols" document 752 [I-D.ietf-karp-threats-reqs]. This document contains detailed 753 descriptions of the threat analysis for routing protocol 754 authentication and integrity in general. Note that it will not 755 contain all the authentication-related threats for any one 756 routing protocol, or category of routing protocols. The design 757 team must conduct a protocol-specific threat analysis to 758 determine if threats beyond those in the [I-D.ietf-karp- 759 threats-reqs] document arise in the context of the protocol 760 (group), and to describe those threats. 762 The [I-D.ietf-karp-threats-reqs] document also contains many 763 security requirements. Each routing protocol design team must 764 walk through each section of the requirements and determine one 765 by one how its protocol either does or does not relate to each 766 requirement. Examples include modern, strong cryptographic 767 algorithms, with at least one such algorithm listed as a MUST; 768 algorithm agility; secure use of simple PSKs; intra-connection 769 replay protection; inter-connection replay protection, etc. 771 When doing the gap analysis we must first identify the elements 772 of each routing protocol that we wish to protect. In case of 773 protocols riding on top of IP, we might want to protect the IP 774 header and the protocol headers, while for those that work on 775 top of TCP, it will be the TCP header and the protocol payload. 776 There is patently value in protecting the IP header and the TCP 777 header if the routing protocols rely on these headers for some 778 information (for example, identifying the neighbor which 779 originated the packet). 781 Then there will be a set of Cryptography requirements that we 782 might want to look at. For example, there MUST be at least on 783 set of cryptography algorithms or constructions whose use is 784 supported by all implementations and can be safely assumed to 785 be supported by any implementation of the authentication 786 option. The design teams should look for this for the protocol 787 that they are working on. If such algorithms or constructions 788 are not available then some should be defined to support 789 interoperability by having a single default. 791 Design teams MUST ensure that the default cryptographic 792 algorithms and constructions supported by the routing protocols 793 are accepted by the community. This means that the protocols 794 MUST NOT rely on non-standard or ad-hoc hash functions, keyed- 795 hash constructions, signature schemes, or other functions, and 796 MUST use published and standard schemes. 798 Care should also be taken to ensure that the routing protocol 799 authentication scheme is capable of supporting algorithms other 800 than its defaults, in order to adapt to future discoveries. 802 Ideally, authentication MUST be performed on routing protocols 803 packets oblivious to the order in which they have arrived, so 804 that it does not get influenced by packets loss and reordering. 806 Design teams should ensure that their protocols authentication 807 mechanism is able to accommodate rekeying. This is essential 808 since its well known that keys must periodically be changed. 809 Also what the designers must ensure is that this rekeying event 810 MUST NOT affect the functioning of the routing protocol. For 811 example, OSPF rekeying requires coordination among the adjacent 812 routers, while ISIS requires coordination among routers in the 813 entire domain. 815 If new authentication and security mechanisms are needed then 816 the design teams must design in such a manner that the routing 817 protocol authentication mechanism remains oblivious of how the 818 keying material is derived. This decouples the authentication 819 mechanism from the key management system that is employed. 821 Design teams should also note that many routing protocols 822 require prioritized treatment of certain protocol packets and 823 authentication mechanisms should honor this. 825 Not all routing protocol authentication mechanisms provide 826 support for replay attacks, and the design teams should 827 identify such authentication mechanisms and work on them so 828 that this can get fixed. The design teams must look at the 829 protocols that they are working on and see if packets captured 830 from the previous/stale sessions can be replayed. 832 What might also influence the design is the rate at which the 833 protocol packets are originated. In case of protocols like BFD, 834 where packets are originated at millisecond intervals, there 835 are some special considerations that must be kept in mind when 836 defining the new authentication and security mechanisms. 838 It is imperative that the new authentication and security 839 mechanisms defined support incremental deployment, as it is not 840 feasible to deploy a new routing protocol authentication 841 mechanism throughout the network instantaneously. It may also 842 not be possible to deploy such a mechanism to all routers in a 843 large AS at one time. This means that the designers must work 844 on this aspect of authentication mechanism for the routing 845 protocol that they are working on. The mechanisms must provide 846 backward compatibility in the message formatting, transmission, 847 and processing of routing information carried through a mixed 848 security environment. 850 The designers should also consider whether the current 851 authentication mechanisms impose considerable processing 852 overhead on a router that's doing authentication. Most 853 currently deployed routers do not have hardware accelerators 854 for cryptographic processing and these operations can impose a 855 significant processing burden under some circumstances. The 856 proposed solutions should be evaluated carefully with regard to 857 the processing burden that they will impose, since deployment 858 may be impeded if network operators perceive that a solution 859 will impose a processing burden which either entails 860 substantial capital expenses or threatens to destabilize the 861 routers. 863 7. Security Considerations 865 As mentioned in the Introduction, RFC4948 [RFC4948] identifies 866 additional steps needed to achieve the overall goal of 867 improving the security of the core routing infrastructure. 868 Those include validation of route origin announcements, path 869 validation, cleaning up the IRR databases for accuracy, and 870 operational security practices that prevent routers from 871 becoming compromised devices. The KARP work is but one step in 872 a necessary system of security improvements. 874 The security of cryptographic-based systems depends on both the 875 strength of the cryptographic algorithms chosen and the 876 strength of the keys used with those algorithms. The security 877 also depends on the engineering of the protocol used by the 878 system to ensure that there are no non-cryptographic ways to 879 bypass the security of the overall system. 881 7.1. Use Strong Keys 883 Care should be taken to ensure that the selected key is 884 unpredictable, avoiding any keys known to be weak for the 885 algorithm in use. [RFC4086] contains helpful information on 886 both key generation techniques and cryptographic randomness. 888 In addition to using a key of appropriate length and 889 randomness, deployers of KARP protocols SHOULD use different 890 keys between different routing peers whenever operationally 891 possible. This is especially true when the Routing Protocol 892 takes a static Traffic Key as opposed to a Traffic Key derived 893 on a per-connection basis using a KDF. The burden for doing so 894 is understandably much higher than for using the same static 895 Traffic Key across all peering routers. Depending upon the 896 specific KMP it can be argued that generally using a KMP 897 network-wide increases peer-wise security. This is because if 898 attackers sitting between two routers learn or guess the 899 Traffic Key for that connection, it still does not gain them 900 access to the Traffic key being used in other connections. 901 However, whenever using manual keys, it is best to design a 902 system where a given pre-shared key (PSK) will be used in a 903 KDF, mixed with connection-specific material, in order to 904 generate session unique -- and therefore peer-wise -- Traffic 905 Keys. Doing so has the following advantages: the Traffic Keys 906 used in the per-message MAC operation are peer-wise unique, it 907 provides inter-connection replay protection, and, if the per- 908 message MAC covers some connection counter, intra-connection 909 replay protection. 911 Note that certain key derivation functions (e.g. 912 KDF_AES_128_CMAC, as used in TCP-AO [RFC5926], the pseudorandom 913 function (PRF) used in the KDF may require a key of a certain 914 fixed size as an input. For example, AES_128_CMAC requires a 915 128 bit (16 byte) key as the seed. However, for convenience to 916 the administrators, a specification may not want to require the 917 entry of a PSK of exactly 16 bytes. Instead, a specification 918 may call for a key prep routine that could handle a variable 919 length PSK, one that might be less or more than 16 bytes (see 920 [RFC4615], section 3, as an example). That key prep routine 921 would derive a key of exactly the required length and thus 922 suitable as a seed to the PRF. This does NOT mean that 923 administrators are safe to use weak keys. Administrators are 924 encouraged to follow [RFC4086. We simply attempted to "put a 925 fence around stupidity", in as much as possible. 927 A better option, from a security perspective, is to use some 928 representation of a device-specific asymmetric key pair as the 929 identity proof, as described in section "Unique versus Shared 930 Keys" section. 932 7.2. Internal vs. External Operation 934 Design teams must consider whether the protocol is an internal 935 routing protocol or an external one, i.e. does it primarily run 936 between peers within a single domain of control or between two 937 different domains of control? Some protocols may be used in 938 both cases, internally and externally, and as such various 939 modes of authentication operation may be required for the same 940 protocol. While it is preferred that all routing exchanges run 941 with the best security mechanisms enabled in all deployment 942 contexts, this exhortation is greater for those protocols 943 running on inter-domain point-to-point links, and greatest for 944 those on shared access link layers with several different 945 domains interchanging together, because the volume of attackers 946 are greater from the outside. Note however that the 947 consequences of internal attacks maybe no less severe -- in 948 fact they may be quite a bit more severe -- than an external 949 attack. An example of this internal versus external 950 consideration is BGP which has both EBGP and IBGP modes. 951 Another example is a multicast protocol where the neighbors are 952 sometimes within a domain of control and sometimes at an inter- 953 domain exchange point. In the case of PIM-SM running on an 954 internal multi-access link, it would be acceptable to give up 955 some security to get some convenience by using a group key 956 among the peers on the link. On the other hand, in the case of 957 PIM-SM running over a multi-access link at a public exchange 958 point, operators may favor security over convenience by using 959 unique pair-wise keys for every peer. Designers must consider 960 both modes of operation and ensure the authentication 961 mechanisms fit both. 963 Operators are encouraged to run cryptographic authentication on 964 all their adjacencies, but to work from the outside in, i.e. 965 EBGP links are a higher priority than the IBGP links because 966 they are externally facing, and, as a result, more likely to be 967 targeted in an attack. 969 7.3. Unique versus Shared Keys 971 This section discusses security considerations regarding when 972 it is appropriate to use the same authentication key inputs for 973 multiple peers and when it is not. This is largely a debate of 974 convenience versus security. It is often the case that the best 975 secured mechanism is also the least convenient mechanism. For 976 example, an air gap between a host and the network absolutely 977 prevents remote attacks on the host, but having to copy and 978 carry files using the "sneaker net" is quite inconvenient and 979 does not scale. 981 Operators have erred on the side of convenience when it comes 982 to securing routing protocols with cryptographic 983 authentication. Many do not use it at all. Some use it only on 984 external links, but not on internal links. Those that do use it 985 often use the same key for all peers in a network. It is common 986 to see the same key in use for years, e.g., the key was entered 987 when authentication mechanisms were originally configured, or 988 the routing gear was deployed. 990 The goal for designers is to create authentication and 991 integrity mechanisms that are easy for operators to deploy and 992 manage, and still use unique keys between peers (or small 993 groups on multi-access links), and for different sessions among 994 the same peers. Operators have the impression that they NEED 995 one key shared across the network, when in fact they do not. 997 What they need is the relative convenience they experience from 998 deploying cryptographic authentication with one key (or a few 999 keys), compared to the inconvenience they would experience if 1000 they deployed the same authentication mechanism using unique 1001 pairwise keys. An example is BGP Route Reflectors. Here 1002 operators often use the same authentication key between each 1003 client and the route reflector. The roadmaps defined from this 1004 guidance document should allow for unique keys to be used 1005 between each client and the peer, without sacrificing much 1006 convenience. Designers should strive to deliver peer-wise 1007 unique keying mechanisms with similar ease-of-deployment 1008 properties as today's one-key method. 1010 Operators must understand the consequences of using the same 1011 key across many peers. Unique keys are more secure than shared 1012 keys because they reduce both the attack target size and the 1013 attack consequence size. In this context, the attack target 1014 size represents the number of unique routing exchanges across a 1015 network that an attacker may be able to observe in order to 1016 gain security association credentials, i.e. crack the keys. If 1017 a shared key is used across the entire internal domain of 1018 control, then the attack target size is very large. The larger 1019 the attack target, the easier it is for the attacker to gain 1020 access to analysis data, and greater the volume of analysis 1021 data he can access in a given time frame, both of which make 1022 the job easier. Using the same key across the network makes the 1023 attack vulnerability surface more penetrable than unique keys. 1025 The above attack can be mitigated to a certain extent by using 1026 strong keys. Another argument against using the same key is 1027 that if the same key that is used in multiple devices then a 1028 compromise of any one of the devices will expose the key. Also 1029 since the same key is supported on many devices this is known 1030 by many people which affects its distribution to all of the 1031 devices. 1033 Consider also the attack consequence size, the amount of 1034 routing adjacencies that can be negatively affected once a 1035 breach has occurred, i.e., once the keys have been acquired by 1036 the attacker. 1038 Again, if a shared key is used across the internal domain, then 1039 the consequence size is the whole network. Ideally, unique key 1040 pairs would be used for each adjacency. 1042 In some cases use of shared keys is needed because of the 1043 problem space. For example, a multicast packet is sent once but 1044 then consumed by several routing neighbors. If unique keys were 1045 used per neighbor, the benefit of multicast would be erased 1046 because sender would have to create a different announcement 1047 packet for each receiver. Though this may be desired and 1048 acceptable in some small number of use cases, it is not the 1049 norm. Shared (i.e., group) keys are an acceptable solution 1050 here, and much work has been done already in this area (see 1051 MSEC working group). 1053 7.4. Out-of-Band External Configuration vs. Peer-to-Peer Key 1054 Management 1056 This section discusses the security and use case considerations 1057 for keys placed on devices through out-of-band configuration 1058 versus through peer-to-peer key management protocol exchanges. 1059 Note, when we say here "Peer-to-Peer KMP" we do not mean in- 1060 band to the Routing Protocol. Instead, we mean that the 1061 exchange occurs in-line, over IP, between the two routing 1062 peers. In peer-to-peer KMP the peers handle the key and 1063 security association negotiation between themselves, whereas in 1064 an out-of-band configuration system the keys are placed in the 1065 device through some other configuration or management method or 1066 interface, via a third party. 1068 An example of an out-of-band external mechanism could be an 1069 administrator who makes a remote management connection (e.g. 1070 using SSH) to a router and manually enters the keying 1071 information, e.g., the algorithm, the key(s), the key 1072 lifetimes, etc. Another example could be an OSS system that 1073 inputs the same information using a script over an SSH 1074 connection, or by pushing configuration through some other 1075 management connection, standard (Netconf-based) or proprietary. 1077 The drawbacks of an out-of-band mechanism include: lack of 1078 scaleability, complexity, and speed of changing if a security 1079 breach is suspected. For example, if an employee who had access 1080 to keys was terminated, or if a machine holding those keys was 1081 believed to be compromised, then the system would be considered 1082 insecure and vulnerable until new keys were generated and 1083 distributed. Those keys then need to be placed into the OSS 1084 system, and the OSS system then needs to push the new keys -- 1085 often during a very limited change window -- into the relevant 1086 devices. If there are multiple organizations involved in these 1087 connections, because the protected connections are inter- 1088 domain, this process is very complicated. 1090 The principle benefit of out-of-band configuration mechanism is 1091 that once the new keys/parameters are set in OSS system, they 1092 can be pushed automatically to all devices within the OSS's 1093 domain. Operators have mechanisms in place for this already for 1094 managing other router configuration data. In small environments 1095 with few routers, a manual system is not difficult to employ. 1097 We further define a peer-to-peer key exchange as using 1098 cryptographically protected identity verification, session key 1099 negotiation, and security association parameter negotiation 1100 between the two routing peers. The KMP among peers may also 1101 include the negotiation of parameters, like cryptographic 1102 algorithms, cryptographic inputs (e.g. initialization vectors), 1103 key life-times, etc. 1105 There are several benefits of a peer-to-peer KMP versus 1106 centrally managed and distributing keys. It results in key(s) 1107 that are privately generated, and need not be recorded 1108 permanently anywhere. Since the traffic keys used in a 1109 particular connection are not a fixed part of a device 1110 configuration no security sensitive data exists anywhere else 1111 in the operator's systems which can be stolen, e.g. in the case 1112 of a terminated or turned employee. If a server or other data 1113 store is stolen or compromised, the thieves gain limited or no 1114 access to current traffic keys. They may gain access to key 1115 derivation material, like a PSK, but may not be able to access 1116 the current traffic keys in use. In this example, these PSKs 1117 can be updated in the device configurations (either manually or 1118 through an OSS) without bouncing or impacting the existing 1119 session at all. In the case of using raw asymmetric keys or 1120 certificates, instead of PSKs, the data theft (from the data 1121 store) would likely not result in any compromise, as the key 1122 pairs would have been generated on the routers, and never leave 1123 those routers. In such a case no changes are needed on the 1124 routers; the connections will continue to be secure, 1125 uncompromised. Additionally, with a KMP regular rekey 1126 operations occur without any operator involvement or oversight. 1127 This keeps keys fresh. 1129 There are a few drawbacks to using a KMP. First, a KMP requires 1130 more cryptographic processing for the router at the beginning 1131 of a connection. This will add some minor start-up time to 1132 connection establishment versus a purely manual key management 1133 approach. Once a connection with traffic keys has been 1134 established via a KMP, the performance is the same in the KMP 1135 and the out-of-band case. KMPs also add another layer of 1136 protocol and configuration complexity which can fail or be 1137 misconfigured. This was more of an issue when these KMPs were 1138 first deployed, but less so as these implementations and 1139 operational experience with them has matured. 1141 The desired end goal for KARP WG is to develop a strong peer- 1142 to-peer KMP; an Out-of-and external Key Management protocol is 1143 out of scope. 1145 Within this constraint there are two approaches for a KMP: 1147 The first, is to use an Out-of-band Key Management protocol 1148 that runs independent of the routing and the signaling 1149 protocols. It would run on its own port and use its own 1150 transport (to avoid interfering with the routing protocol that 1151 it is serving). When a routing protocols needs a key, it would 1152 contact the local instance of this key management protocol and 1153 request a key. The KMP generates a key that is delivered to the 1154 routing protocol for it to use for authenticating and integrity 1155 verification of the routing protocol packets. This KMP could 1156 either be an existing key management protocol like ISAKMP/IKE, 1157 GKMP, etc., extended for the routing protocols, or it could be 1158 a new KMP, designed for the routing protocol context. 1160 The second approach is to define an In-band KMP extension for 1161 existing routing protocols putting the key management 1162 mechanisms inside the protocol itself. In this case, the key 1163 management messages would be carried within the routing 1164 protocol packets, resulting in very tight coupling between the 1165 routing protocols and the key management protocol. 1167 8. Acknowledgments 1169 Much of the text for this document came originally from draft- 1170 lebovitz-karp-roadmap, authored by Gregory M. Lebovitz. 1172 We would like to thank Sam Hartman, Eric Rescorla, Russ White, 1173 Stephen Kent, Stephen Farrell, Adrian Farrel, Michael Barnes 1174 and Vishwas Manral for their comments on the draft. 1176 9. IANA Considerations 1178 This document places no requests to IANA. 1180 10. References 1182 10.1. Normative References 1184 [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, March 1997. 1187 [RFC4948] Andersson, L., et. al, "Report from the IAB workshop 1188 on Unwanted Traffic March 9-10, 2006", RFC 4948, 1189 August 2007. 1191 10.2. Informative References 1193 [RFC1195] Callon, R. , "Use of OSI IS-IS for Routing in TCP/IP 1194 and Dual Environments", RFC 1195, December 1990. 1196 [RFC2205] Braden, R., et. al, "Resource ReSerVation Protocol 1197 (RSVP) Version 1 Functional Specification", RFC 2205, 1198 September 1197. 1200 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1202 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. 1204 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP 1205 Cryptographic Authentication", RFC 2747, January 1206 2000. 1208 [RFC3097] Braden, R, and Zhang, L., "RSVP Cryptographic 1209 Authentication -- Updated Message Type Value", RFC 1210 3097, April 2001 1212 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 1213 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 1214 LSP Tunnels", RFC 3209, December 2001. 1216 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 1217 Switching (GMPLS) Signaling Resource ReserVation 1218 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1219 RFC 3473, January 2003. 1221 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, 1222 "The Group Domain of Interpretation", RFC 3547, July 1223 2003. 1225 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1226 Protocol (MSDP)", RFC 3618, October 2003. 1228 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1229 Independent Multicast - Dense Mode (PIM-DM): Protocol 1230 Specification (Revised)", RFC 3973, January 2005. 1232 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, 1233 Randomness Requirements for Security", BCP 106, 1234 RFC 4086, June 2005. 1236 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for 1237 Cryptographic Key Management", BCP 107, RFC 4107, 1238 June 2005. 1240 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 1241 Properties", RFC 4230, December 2005. 1243 [RFC4252] Ylonen, T., et. al, "The Secure Shell (SSH) 1244 Authentication Protocol", RFC 4252, January 2006. 1246 [RFC4253] Ylonen, T., et. al, "The Secure Shell (SSH) Transport 1247 Layer Protocol", RFC 4253, January 2006 1249 [RFC4271] Rekhter, Y., Li, T. and Hares, S.,"A Border Gateway 1250 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1252 [RFC4492] Blake-Wilson, S., "Elliptical Curve Cryptography 1253 (ECC) Cipher Suites for Transport Layer Security 1254 (TLS)", RFC 4492, May 2006 1256 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. 1257 Kouvelas,"Protocol Independent Multicast - Sparse 1258 Mode (PIM-SM): Protocol Specification (Revised)", RFC 1259 4601, August 2006. 1261 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 1262 Advanced Encryption Standard-Cipher-based Message 1263 Authentication Code-Pseudo-Random Function-128 (AES- 1264 CMAC-PRF-128) Algorithm for the Internet Key Exchange 1265 Protocol (IKE)", RFC 4615, August 2006. 1267 [RFC4726] Farrel, A., et. al.,"A Framework for Inter-Domain 1268 Multiprotocol Label Switching Traffic Engineering", 1269 RFC 4726, November 2006. 1271 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1272 Specification", RFC 5036, October 2007. 1274 [RFC5151] Farrel, A., et. al.,"Inter-Domain MPLS and GMPLS 1275 Traffic Engineering -- Resource Reservation Protocol- 1276 Traffic Engineering (RSVP-TE) Extensions", RFC 5151, 1277 February 2008. 1279 [RFC5280] Cooper, D., et. al.,"Internet X.509 Public Key 1280 Infrastructure Certificate and Certificate Revocation 1281 List (CRL) Profile", RFC 5280, May 2008 1283 [RFC5440] Vasseur, J.P. and Le Roux, J.L., "Path Computation 1284 Element (PCE) Communication Protocol (PCEP)", RFC 1285 5440, March 2009 1287 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication 1288 and Confidentiality in PIM-SM Link-local Messages", 1289 RFC 5796, March 2010. 1291 [RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding 1292 Detection", RFC 5880, June 2010. 1294 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1295 Authentication Option", RFC 5925, June 2010. 1297 [RFC5926] Lebovitz, G., "Cryptographic Algorithms, Use and 1298 Implementation Requirements for TCP Authentication 1299 Option", RFC 5926, June 2010. 1301 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J. and White, 1302 R.,"Issues with Existing Cryptographic Protection 1303 Methods for Routing Protocols", RFC 6039, October 1304 2010 1306 [I-D.ietf-karp-threats-reqs] Lebovitz, G., "KARP Threats and 1307 Requirements", Work in Progress, October 2010. 1309 [I-D.ietf-saag-crypto-key-table] Housley, R. and Polk, T., 1310 "Database of Long-Lived Cryptographic Keys" , Work in 1311 Progress, September 2009 1313 [I-D.weis-gdoi-mac-tek] Weis, B. and S. Rowles, "GDOI Generic 1314 Message Authentication Code Policy", Work in 1315 Progress, June 2010. 1317 [IRR] Merit Network Inc , "Internet Routing Registry Routing 1318 Assets Database", 2006, http://www.irr.net/. 1320 [NIST-800-57] US National Institute of Standards & Technology, 1321 "Recommendation for Key Management Part 1: General 1322 (Revised)", March 2007 1324 Author's Addresses 1326 Gregory M. Lebovitz 1327 California 1328 USA 95003 1330 Phone: 1331 Email: gregory.ietf@gmail.com 1333 Manav Bhatia 1334 Alcatel-Lucent 1335 Bangalore 1336 India 1338 Phone: 1339 Email: manav.bhatia@alcatel-lucent.com