idnits 2.17.1 draft-ietf-karp-design-guide-10.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 13, 2011) is 4517 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 (~~), 3 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: June 16, 2012 Alcatel-Lucent 6 December 13, 2011 8 Keying and Authentication for Routing Protocols (KARP) 9 Design Guidelines 11 draft-ietf-karp-design-guide-10.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 June 2012. 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................................5 75 2.1. Category: Message Transaction Type.......................5 76 2.2. Category: Peer vs Group Keying...........................6 77 3. Consider the future existence of a Key Management Protocol....7 78 3.1. Consider Asymmetric Keys.................................7 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. Supporting Incremental Deployment............................17 85 7. Denial of Service Attacks....................................17 86 8. Gap Analysis.................................................18 87 9. Security Considerations......................................21 88 9.1. Use Strong Keys.........................................21 89 9.2. Internal vs. External Operation.........................22 90 9.3. Unique versus Shared Keys...............................23 91 9.4. Key Exchange Mechanism..................................24 92 10. Acknowledgments.............................................27 93 11. IANA Considerations.........................................27 94 12. References..................................................27 95 12.1. Normative References...................................27 96 12.2. Informative References.................................27 98 1. Introduction 100 In March 2006 the Internet Architecture Board (IAB) held a 101 workshop on the topic of "Unwanted Internet Traffic". The 102 report from that workshop is documented in RFC 4948 [RFC4948]. 103 Section 8.1 of that document states that "A simple risk 104 analysis would suggest that an ideal attack target of minimal 105 cost but maximal disruption is the core routing 106 infrastructure." Section 8.2 calls for "[t]ightening the 107 security of the core routing infrastructure." Four main steps 108 were identified for that tightening: 110 o Increased security mechanisms and practices for operating 111 routers. 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. 117 o Specifications for cryptographic validation of routing 118 message content. 120 o Securing the routing protocols' packets on the wire 122 The first bullet is being addressed in the OPSEC Working Group. 123 The second bullet should be addressed through liaisons with 124 those running the IRR's globally. The third bullet is being 125 addressed in the SIDR Working Group. 127 This document addresses the last bullet, securing the packets 128 on the wire of the routing protocol exchanges. Thus, it is 129 concerned with guidelines for describing issues and techniques 130 for protecting the messages between directly communicating 131 peers. This may overlap with, but is strongly distinct from, 132 protection designed to ensure that routing information is 133 properly authorized relative to sources of this information. 134 Such authorizations are provided by other mechanisms and are 135 outside the scope of this document and work that relies on it. 137 This document uses the terminology "on the wire" to talk about 138 the information used by routing systems. This term is widely 139 used in IETF RFCs, but is used in several different ways. In 140 this document, it is used to refer both to information 141 exchanged between routing protocol instances, and to underlying 142 protocols that may also need to be protected in specific 143 circumstances. Other documents that will analyze individual 144 protocols will need to indicate how they use the term "on the 145 wire". 147 The term "routing transport" is used to refer to the layer that 148 exchanges the routing protocols. This can be TCP, UDP, or even 149 direct link level messaging in the case of some routing 150 protocols. The term is used here to allow a referent for 151 discussing both common and disparate issues that affect or 152 interact with this dimension of the routing systems. The term 153 is used here to refer generally to the set of mechanisms and 154 exchanges underneath the routing protocol, whatever that is in 155 specific cases. 157 KARP will focus on an abstraction for keying information that 158 describes the interface between routing protocols, operators 159 and automated key management. Conceptually when routing 160 protocols send or receive messages they will look up the key to 161 use in this abstract key table. Conceptually, there will be an 162 interface for a routing protocol to make requests of automated 163 key management when it is being used; when keys become 164 available they will be made available in the key table. There 165 is no requirement that this abstraction be used for 166 implementation; the abstraction serves the needs of 167 standardization and management. Specifically as part of the 168 KARP work plan: 170 1) KARP will design the key table abstraction, the interface 171 between key management protocols and routing protocols and 172 possibly security protocols at other layers. 174 2) For each routing protocol, KARP will define the mapping 175 between how the protocol represents key material and the 176 protocol independent key table abstraction. When routing 177 protocols share a common mechanism for authentication, such as 178 the TCP Authentication Option, the same mapping is likely to be 179 reused between protocols. An implementation may be able to move 180 much of the keying logic into code related to this shared 181 authentication primitive rather than code specific to routing 182 protocols. 184 3) When designing automated key management for both symmetric 185 keys and group keys, we will only use the abstractions designed 186 in point 1 above to communicate between automated key 187 management and routing protocols. 189 Readers must refer to the [I-D.ietf-karp-threats-reqs] for a 190 clear definition of the scope, goals, non goals and the 191 audience for the design work being undertaken in KARP WG. 193 2. Categorizing Routing Protocols 195 This document places the routing protocols into two categories 196 according to their requirements for authentication. We hope 197 these categories will allow design teams to focus on security 198 mechanisms for a given category. Further, we hope that the each 199 protocol in the group will be able to reuse the authentication 200 mechanism. It is also hoped that, down the road we can create one 201 Key Management Protocol (KMP) per category (if not for several 202 categories) so that the work can be easily leveraged by for use 203 in the various Routing Protocol groupings. KMPs are useful for 204 allowing simple, automated updates of the traffic keys used in a 205 base protocol. KMPs replace the need for humans, or OSS 206 routines, to periodically replace keys on running systems. It 207 also removes the need for a chain of manual keys to be chosen or 208 configured on such systems. When configured properly, a KMP will 209 enforce the key freshness policy among peers by keeping track of 210 the key lifetime and negotiating a new key at the defined 211 interval. 213 2.1. Category: Message Transaction Type 215 The first category defines three types of messaging 216 transactions used on the wire by the base Routing Protocol. 217 They are: 219 One-to-One 221 One peer router directly and intentionally delivers a route 222 update specifically to one other peer router. Examples are 223 BGP [RFC4271], LDP [RFC5036], BFD [RFC5880] and RSVP-TE 224 [RFC3209] [RFC3473] [RFC4726] [RFC5151]. Point-to-point modes 225 of both IS-IS [RFC1195] and OSPF [RFC2328], when sent over 226 both traditional point-to-point links and when using multi- 227 access layers, may both also fall into this category. 229 One-to-Many 231 A router peers with multiple other routers on a single 232 network segment -- i.e. on link local -- such that it creates 233 and sends one route update message which is intended for 234 multiple peers. Examples would be OSPF and IS-IS in their 235 broadcast, non-point-to-point mode and Routing Information 236 Protocol (RIP) [RFC2453]. 238 Multicast 240 Multicast protocols have unique security properties because 241 they are inherently group-based protocols and thus have group 242 keying requirements at the routing level where link-local 243 routing messages are multicasted. Also, at least in the case 244 of PIM-SM [RFC4601], some messages are sent unicast to a 245 given peer(s), as is the case with router-close-to-sender and 246 the "Rendezvous Point". Some work for application layer 247 message security has been done in the Multicast Security 248 working group (MSEC) and may be helpful to review, but is not 249 directly applicable. 251 These categories affect both the routing protocol view of the 252 communication, and the actual message transfer. As a result, 253 some message transaction types for a few routing protocols, may 254 be mixtures, for example using broadcast where multicast might 255 be expected, or using unicast to deliver what looks to the 256 routing protocol like broadcast or multicast. 258 Protocol security analysis documents produced in KARP need to 259 pay attention both to the semantics of the communication, and 260 the techniques that are used for the message exchanges. 262 2.2. Category: Peer vs Group Keying 264 The second category is the keying mechanism that will be used 265 to distribute the session keys to the routing transports.They 266 are: 268 Peer keying 270 One router sends the keying messages only to one other router, 271 such that a one-to-one, uniquely keyed security association 272 (SA) is established between the two routers (e.g., BGP, BFD and 273 LDP). 275 Group Keying 277 One router creates and distributes a single keying message to 278 multiple peers. In this case a group SA will be established 279 and used among multiple peers simultaneously. Group keying 280 exists for protocols like OSPF [RFC2328], and also for 281 multicast protocols like PIM-SM [RFC4601]. 283 3. Consider the future existence of a Key Management Protocol 285 When it comes time for the KARP WG to design a re-usable model 286 for a Key Management Protocol (KMP), [RFC4107] should be 287 consulted. 289 When conducting the design work on a manually-keyed version of 290 a routing protocol's authentication mechanism, consideration 291 must be made for the eventual use of a KMP. In particular, 292 design teams must consider what parameters would need to be 293 handed to the routing protocols by a KMP. 295 Examples of parameters that might need to be passed are: a 296 security association identifier (e.g. IPsec SPI, or TCP-AO's 297 KeyID), a key lifetime (which may be represented either in 298 bytes or seconds), the cryptographic algorithms being used, the 299 keys themselves, and the directionality of the keys (i.e., 300 receive versus the sending keys) 302 3.1. Consider Asymmetric Keys 304 The use of asymmetric keys can be a very powerful way to 305 authenticate machine peers as used in routing protocol peer 306 exchanges. If generated on the machine, and never moved off the 307 machine, these keys will not need to be changed if an 308 administrator leaves the organization. Since the keys are 309 random they are far less susceptible to off-line dictionary and 310 guessing attacks. 312 An easy and simple way to use asymmetric keys is to start by 313 having the router generate a public/private key pair. At the 314 time of this writing, the recommended key size for algorithms 315 based on integer factorization cryptography like RSA is 1024 316 bits and 2048 bits for extremely valuable keys like the root 317 key pair used by a certification authority. It is believed that 318 a 1024-bit RSA key is equivalent in strength to 80-bit 319 symmetric keys and 2048-bit RSA keys to 112-bit symmetric keys 320 [RFC3766]. Elliptic Curve Cryptography [RFC4492] (ECC) appears 321 to be secure with shorter keys than those needed by other 322 asymmetric key algorithms. NIST guidelines [NIST-800-57] state 323 that ECC keys should be twice the length of equivalent strength 324 symmetric key algorithms. Thus, a 224-bit ECC key would roughly 325 have the same strength as a 112-bit symmetric key. 327 Many routers have the ability to be remotely managed using 328 Secure Shell (SSH) Protocol [RFC4252] and [RFC4253]. As such, 329 routers will also have the ability to generate and store an 330 asymmetric key pair, because this is the common authentication 331 method employed by SSH when an administrator connects to a 332 router for management sessions. 334 Once an asymmetric key pair is generated, the KMP generating 335 security association parameters and keys for routing protocol 336 may use the machine's asymmetric keys for the authentication 337 mechanism. The form of the identity proof could be raw keys, 338 the more easily administrable self-signed certificate format, 339 or a PKI-issued [RFC5280] certificate credential. 341 Regardless of which credential is standardized, the 342 authentication mechanism can be as simple as a strong hash over 343 a string of human readable and transferable form of ASCII 344 characters. More complex, but also more secure, the identity 345 proof could be verified through the use of a PKI system's 346 revocation checking mechanism, (e.g. Certificate Revocation 347 List (CRL) or OCSP responder). If the SHA-1 fingerprint is 348 used, the solution could be as simple as loading a set of 349 neighbor routers' peer ID strings into a table and listing the 350 associated fingerprint string for each ID string. In most 351 organizations or peering points, this list will not be longer 352 than a thousand or so routers, and often the list will be much 353 shorter. In other words, the entire list for a given 354 organization's router ID and hash could be held in a router's 355 configuration file, uploaded, downloaded and moved about at 356 will. And it doesn't matter who sees or gains access to these 357 fingerprints, because they can be distributed publicly as it 358 needn't be kept secret. 360 3.2. Cryptographic Keys Life Cycle 362 Cryptographic keys should have a limited lifetime and may need 363 to be changed when an operator who had access to them leaves. 364 Using a key chain, a set of keys derived from the same keying 365 material and used one after the other, also does not help as 366 one still has to change all the keys in the key chain when an 367 operator having access to all those keys leaves the company. 368 Additionally, key chains will not help if the routing transport 369 subsystem does not support rolling over to the new keys without 370 bouncing the routing sessions and adjacencies. So the first 371 step is to fix the routing stack so that routing protocols can 372 change keys without breaking or bouncing the adjacencies. 374 An often cited reason for limiting the lifetime of a key is to 375 minimize the damage from a compromised key. It could be argued 376 that it is likely a user will not discover an attacker has 377 compromised the key if the attacker remains "passive" and thus 378 relatively frequent key changes will limit any potential damage 379 from compromised keys. 381 Another threat against the long-lived key is that one of the 382 systems storing the key, or one of the users entrusted with the 383 key, will be subverted. So, while there may not be 384 cryptographic motivations of changing the keys, there could be 385 system security motivations for rolling the key. 387 Although manual key distribution methods are subject to human 388 error and frailty, more frequent manual key changes might 389 actually increase the risk of exposure as it is during the time 390 that the keys are being changed that they are likely to be 391 disclosed. In these cases, especially when very strong 392 cryptography is employed, it may be more prudent to have fewer, 393 well controlled manual key distributions rather than more 394 frequent, poorly controlled manual key distributions. In 395 general, where strong cryptography is employed, physical, 396 procedural, and logical access protection considerations often 397 have more impact on the key life than do algorithm and key size 398 factors. 400 For incremental deployments we could start by associating life 401 times with the send and the receive keys in the key chain for 402 the long-lived keys. This is an incremental approach that we 403 could use until the cryptographic keying material for 404 individual sessions is derived from the keying material stored 405 in a database of long-lived cryptographic keys as described in 406 [I-D.ietf-karp-crypto-key-table]. A key derivation function 407 (KDF) and its inputs are also specified in the database of 408 long-lived cryptographic keys; session-specific values based on 409 the routing protocol are input to the KDF. Protocol-specific 410 key identifiers may be assigned to the cryptographic keying 411 material for individual sessions if needed. 413 The long-lived cryptographic keys used by the routing protocols 414 can be either inserted manually in a database or can make use 415 of an automated key management protocol to do this. 417 4. RoadMap 419 4.1. Work Phases on any Particular Protocol 421 It is believed that improving security for any routing protocol 422 will be a two phase process. The first phase would be to modify 423 routing protocols to support modern cryptography algorithms and 424 key agility. The second phase would be to design and move to an 425 automated key management mechanism. This is like a crawl, walk 426 and run process. In order for operators to accept these phases, 427 we believe that the key management protocol should be clearly 428 separated from the routing transport. This would mean that the 429 routing transport subsystem is oblivious to how the keys are 430 derived, exchanged and downloaded as long as there is something 431 that it can use. It is like having a routing protocol 432 configuration switch that requests the security module for the 433 "KARP security parameters" so that it can refer to some module 434 written, maintained, and operated by security experts and 435 insert those parameters in the routing exchange. 437 The desired end state for the KARP work contains several items. 438 First, the people desiring to deploy securely authenticated and 439 integrity validated packets between routing peers have the 440 tools specified, implemented and shipping in order to deploy. 441 These tools should be fairly simple to implement, and not more 442 complex than the security mechanisms to which the operators are 443 already accustomed. (Examples of security mechanisms to which 444 router operators are accustomed include: the use of asymmetric 445 keys for authentication in SSH for router configuration, the 446 use of pre-shared keys (PSKs) in TCP MD5 for BGP protection, 447 the use of self-signed certificates for HTTPS access to device 448 Web-based user interfaces, the use of strongly constructed 449 passwords and/or identity tokens for user identification when 450 logging into routers and management systems.) While the tools 451 that we intend to specify may not be able to stop a deployment 452 from using "foobar" as an input key for every device across 453 their entire routing domain, we intend to make a solid, modern 454 security system that is not too much more difficult than that. 455 In other words, simplicity and deployability are keys to 456 success. The Routing Protocols will specify modern 457 cryptographic algorithms and security mechanisms. Routing 458 peers will be able to employ unique, pair-wise keys per peering 459 instance, with reasonable key lifetimes, and updating those 460 keys on a regular basis will be operationally easy, causing no 461 service interruption. 463 Achieving the above described end-state using manual keys may 464 be pragmatic only in very small deployments. However, manual 465 keying in larger deployments will be too burdensome for 466 operators. Thus, the second goal is to support key life cycle 467 management with a KMP. We expect that both manual and automated 468 key management will co-exist in the real world. 470 In accordance with the desired end state just described, we 471 define two main work phases for each Routing Protocol: 473 1. Enhance the Routing Protocol's current authentication 474 mechanism(s). This work involves enhancing a Routing 475 Protocol's current security mechanisms in order to achieve a 476 consistent, modern level of security functionality within its 477 existing key management framework. It is understood and 478 accepted that the existing key management frameworks are 479 largely based on manual keys. Since many operators have 480 already built operational support systems (OSS) around these 481 manual key implementations, there is some automation 482 available for an operator to leverage in that way, if the 483 underlying mechanisms are themselves secure. In this phase, 484 we explicitly exclude embedding or creating a KMP. Refer to 485 [I-D.ietf-karp-threats-reqs] for the list of the requirements 486 for Phase 1 work. 488 2. Develop an automated key management framework. The second 489 phase will focus on the development of an automated keying 490 framework to facilitate unique pair-wise (group-wise, where 491 applicable) keys per peering instance. This involves the use 492 of a KMP. The use of automatic key management mechanisms 493 offers a number of benefits over manual keying. Most 494 importantly it provides fresh traffic keying material for 495 each session, thus helping to prevent inter-connection replay 496 attacks. In an inter-connection replay attack protocol 497 packets from the earlier protocol session are replayed 498 affecting the current execution of the protocol. A KMP is 499 also helpful because it negotiates unique, pair wise, random 500 keys without administrator involvement. It negotiates 501 several SA parameters like algorithms, modes, and parameters 502 required for the secure connection, thus providing 503 interoperability between endpoints with disparate 504 capabilities and configurations. In addition it could also 505 include negotiating the key life times. The KMP can thus keep 506 track of those lifetimes using counters, and can negotiate 507 new keys and parameters before they expire, again, without 508 administrator interaction. Additionally, in the event of a 509 breach, changing the KMP key will immediately cause a rekey 510 to occur for the Traffic Key, and those new Traffic Keys will 511 be installed and used in the current connection. In summary, 512 a KMP provides a protected channel between the peers through 513 which they can negotiate and pass important data required to 514 exchange proof of identities, derive Traffic Keys, determine 515 re-keying, synchronize their keying state, signal various 516 keying events, notify with error messages, etc. 518 4.2. Work Items Per Routing Protocol 520 Each Routing Protocol will have a team (the [Routing_Protocol]- 521 KARP team) working on incrementally improving the security of a 522 Routing Protocol. These teams will have the following main work 523 items: 525 PHASE 1: 527 Characterize the RP 529 Assess the Routing Protocol to see what authentication and 530 integrity mechanisms it has today. Does it needs 531 significant improvement to its existing mechanisms or not? 532 This will include determining if modern, strong security 533 algorithms and parameters are present and if the protocol 534 supports key agility without bouncing adjacencies. 536 Define Optimal State 538 List the requirements for the Routing Protocol's session key 539 usage and format to contain modern, strong security 540 algorithms and mechanisms, per the Requirements document 541 [I-D.ietf-karp-threats-reqs]. The goal here is to determine 542 what is needed for the Routing Protocol to be used securely 543 with at least manual key management. 545 Gap Analysis 547 Enumerate the requirements for this protocol to move from 548 its current security state, the first bullet, to its optimal 549 state, as listed just above. 551 Transition and Deployment Considerations 553 Document the operational transition plan for moving from the 554 old to the new security mechanism. Will adjacencies need to 555 bounce? What new elements/servers/services in the 556 infrastructure will be required? What is an example work 557 flow that an operator will take? The best possible case is 558 if the adjacency does not break, but this may not always be 559 possible. 561 Define, Assign, Design 563 Create a deliverables list of the design and specification 564 work, with milestones. Define owners. Release one or more 565 documents. 567 PHASE 2: 569 KMP Analysis 571 Review requirements for KMPs. Identify any nuances for this 572 particular routing protocol's needs and its use cases for a 573 KMP. List the requirements that this Routing Protocol has 574 for being able to be used in conjunction with a KMP. Define 575 the optimal state and check how easily it can be decoupled 576 from the KMP. 578 Gap Analysis 580 Enumerate the requirements for this protocol to move from 581 its current security state to its optimal state, with 582 respect to the key management. 584 Define, Assign, Design 586 Create a deliverables list of the design and specification 587 work, with milestones. Define owners. Generate the design 588 and document work for a KMP to be able to generate the 589 Routing Protocol's session keys for the packets on the wire. 590 These will be the arguments passed in the API to the KMP in 591 order to bootstrap the session keys for the Routing 592 Protocol. 594 There will also be a team formed to work on the base 595 framework mechanisms for each of the main categories. 597 5. Routing Protocols in Categories 599 This section groups the Routing Protocols into categories, 600 according to attributes set forth in Categories Section 601 (Section 2). Each group will have a design team tasked with 602 improving the security of the Routing Protocol mechanisms and 603 defining the KMP requirements for their group, then rolling 604 both into a roadmap document upon which they will execute. 606 BGP, LDP, PCEP and MSDP 608 These Routing Protocols fall into the category of the one- 609 to-one peering messages, and will use peer keying protocols. 610 BGP [RFC4271], PCEP [RFC5440] and MSDP [RFC3618] messages 611 are transmitted over TCP, while LDP [RFC5036] uses both UDP 612 and TCP. A team will work on one mechanism to cover these 613 TCP unicast protocols. Much of the work on the Routing 614 Protocol update for its existing authentication mechanism 615 has already occurred in the TCPM Working Group, on the TCP- 616 AO [RFC5925] document, as well as its cryptography-helper 617 document, TCP-AO-CRYPTO [RFC5926]. However, TCP-AO cannot 618 be used for discovery exchanges carried in LDP as those are 619 carried over UDP. A separate team might want to look at LDP. 620 Another exception is the mode where LDP is used directly on 621 the LAN. The work for this may go into the Group keying 622 category (along with OSPF) as mentioned below. 624 OSPF, IS-IS, and RIP 626 The Routing Protocols that fall into the category Group 627 Keying *with one-to-many peering) includes OSPF [RFC2328], 628 IS-IS [RFC1195] and RIP [RFC2453]. Not surprisingly, all 629 these routing protocols have two other things in common. 630 First, they are run on a combination of the OSI datalink 631 layer 2, and the OSI network layer 3. By this we mean that 632 they have a component of how the routing protocol works 633 which is specified in Layer 2 as well as in Layer 3. 634 Second, they are all internal gateway protocols(IGPs). The 635 keying mechanisms will be much more complicated to define 636 for these than for a one-to-one messaging protocol. 638 BFD 640 Because it is less of a routing protocol, per se, and more 641 of a peer liveness detection mechanism, Bidirectional 642 Forwarding Detection (BFD) [RFC5880] will have its own team. 643 BFD is also different from the other protocols covered here 644 as it works on millisecond timers and would need separate 645 considerations to mitigate the potential for DoS attacks. It 646 also raises interesting issues [RFC6039] with respect to the 647 sequence number scheme that is generally deployed to protect 648 against replay attacks as this space can rollover quite 649 frequently because of the rate at which BFD packets are 650 generated. 652 RSVP and RSVP-TE 654 The Resource reSerVation Protocol [RFC2205] allows hop-by- 655 hop authentication of RSVP neighbors, as specified in 656 [RFC2747]. In this mode, an integrity object is attached to 657 each RSVP message to transmit a keyed message digest. This 658 message digest allows the recipient to verify the identity 659 of the RSVP node that sent the message, and to validate the 660 integrity of the message. Through the inclusion of a 661 sequence number in the scope of the digest, the digest also 662 offers replay protection. 664 [RFC2747] does not dictate how the key for the integrity 665 operation is derived. Currently, most implementations of 666 RSVP use a statically configured key, on a per interface or 667 per neighbor basis. 669 RSVP relies on a per peer authentication mechanism, where 670 each hop authenticates its neighbor using a shared key or a 671 certificate. 673 Trust in this model is transitive. Each RSVP node trusts 674 explicitly only its RSVP next hop peers, through the message 675 digest contained in the INTEGRITY object [RFC2747]. The next 676 hop RSVP speaker in turn trusts its own peers and so on. 677 See also the document "RSVP security properties" [RFC4230] 678 for more background. 680 The keys used for protecting the RSVP messages can be group 681 keys (for example distributed via GDOI [RFC3547], as 682 discussed in [I-D.weis-gdoi-mac-tek]). 684 The trust an RSVP node has to another RSVP node has an 685 explicit and an implicit component. Explicitly the node 686 trusts the other node to maintain the integrity (and, 687 optionally confidentiality) of RSVP messages depending on 688 whether authentication or encryption (or both) are used. 689 This means that the message has not been altered or its 690 contents seen by another, non-trusted node. Implicitly each 691 node trusts the other node to maintain the level of 692 protection specified within that security domain Note that 693 in any group key management scheme, like GDOI, each node 694 trusts all the other members of the group with regard to 695 data origin authentication. 697 RSVP TE [RFC3209] [RFC3473] [RFC4726] [RFC5151] is an 698 extension of the RSVP protocol for traffic engineering. It 699 supports the reservation of resources across an IP network 700 and is used for establishing MPLS label switch paths (LSPs), 701 taking into consideration network constraint parameters such 702 as available bandwidth and explicit hops. RSVP-TE signaling 703 is used to establish both intra and inter-domain TE LSPs. 705 When signaling an inter-domain RSVP-TE LSP, operators may 706 make use of the security features already defined for RSVP- 707 TE [RFC3209]. This may require some coordination between 708 domains to share keys ([RFC2747],[RFC3097]), and care is 709 required to ensure that the keys are changed sufficiently 710 frequently. Note that this may involve additional 711 synchronization, should the domain border nodes be protected 712 with Fast Reroute, since the merge point (MP) and point of 713 local repair (PLR) should also share the key. 715 For inter-domain signaling for MPLS-TE, the administrators 716 of neighboring domains must satisfy themselves as to the 717 existence of a suitable trust relationship between the 718 domains. In the absence of such a relationship, the 719 administrators should decide not to deploy inter-domain 720 signaling, and should disable RSVP-TE on any inter-domain 721 interfaces. 723 KARP will currently be working only on RSVP-TE as the native 724 RSVP lies outside the scope of the WG charter. 726 PIM-SM and PIM-DM 728 Finally, the multicast protocols PIM-SM [RFC4601] and PIM-DM 729 [RFC3973] will be grouped together. PIM-SM multicasts 730 routing information (Hello, Join/Prune, Assert) on a link- 731 local basis, using a defined multicast address. In 732 addition, it specifies unicast communication for exchange of 733 information (Register, Register-Stop) between the router 734 closest to a group sender and the "rendezvous point" (RP). 735 The RP is typically not "on-link" for a particular router. 736 While much work has been done on multicast security for 737 application-layer groups, little has been done to address 738 the problem of managing hundreds or thousands of small one- 739 to-many groups with link-local scope. Such an 740 authentication mechanism should be considered along with the 741 router-to-Rendezvous Point authentication mechanism. The 742 most important issue is ensuring that only the "authorized 743 neighbors" get the keys for (S,G), so that rogue routers 744 cannot participate in the exchanges. Another issue is that 745 some of the communication may occur intra-domain, e.g. the 746 link-local messages in an enterprise, while others for the 747 same (*,G) may occur inter-domain, e.g. the router-to- 748 Rendezvous Point messages may be from one enterprise's 749 router to another. 751 One possible solution proposes a region-wide "master" key 752 server (possibly replicated), and one "local" key server per 753 speaking router. There is no issue with propagating the 754 messages outside the link, because link-local messages, by 755 definition, are not forwarded. This solution is offered only 756 as an example of how work may progress; further discussion 757 should occur in this work team. Specification of a link- 758 local protection mechanism for PIM-SM is defined in 759 [RFC4601], and this mechanism has been updated in PIM-SM- 760 LINKLOCAL [RFC5796]. However, the KMP part is completely 761 unspecified, and will require work outside the expertise of 762 the PIM working group to accomplish, another example of why 763 this roadmap is being created. 765 6. Supporting Incremental Deployment 767 It is imperative that the new authentication and security 768 mechanisms defined support incremental deployment, as it is not 769 feasible to deploy a new routing protocol authentication 770 mechanism throughout the network instantaneously. One of the 771 goals of KARP WG is to add incremental security to existing 772 mechanisms rather than replacing them. Delivering better 773 deployable solutions to which vendors and operators can migrate 774 to is more important than getting a perfect security solution. 775 It may also not be possible to deploy such a mechanism to all 776 routers in a large AS at one time. This means that the 777 designers must work on this aspect of authentication mechanism 778 for the routing protocol that they are working on. The 779 mechanisms must provide backward compatibility in the message 780 formatting, transmission, and processing of routing information 781 carried through a mixed security environment. 783 7. Denial of Service Attacks 785 Denial of Service (DoS) attacks must be kept in mind when 786 designing KARP solutions. [I-D.ietf-karp-threats-reqs] 787 describes DoS attacks that are in scope for the KARP work. 788 Protocol designers should ensure that the new cryptographic 789 validation mechanisms must not provide an attacker with an 790 opportunity for DoS attacks. Cryptographic validation, while 791 typically cheaper than signing, is still an incremental cost. 792 If an attacker can force a system to validate many packets 793 multiple times then this could be a potential DoS attack 794 vector. On the other hand, if the authentication procedure is 795 itself quite CPU intensive, then overwhelming the CPU with 796 multiple bogus packets can bring down the system. In this case, 797 the authentication procedure itself aids the DoS attack. 799 There are some known techniques to reduce the cryptographic 800 computation load. Packets can include non cryptographic 801 consistency checks. For example, [RFC5082] provides a mechanism 802 that uses the IP header to limit the attackers that can inject 803 packets that will be subject to cryptographic validation. In 804 the design phase II, once an automated key management protocol 805 is developed, it may be possible to determine the peer IP 806 addresses that are valid participants. Only the packets from 807 the verified sources could be subject to cryptographic 808 validation. 810 Protocol designers must ensure that device never needs to check 811 incoming protocol packets using multiple keys, as this can 812 overwhelm the CPU, leading to a DoS attack. KARP solutions 813 should indicate the checks that are appropriate prior to 814 performing cryptographic validation. KARP solutions should 815 indicate where information about valid neighbors can be used to 816 limit the scope of the attacks. 818 Particular care needs to be paid to design of automated key 819 management schemes. It is often desirable to force a party 820 attempting to authenticate to do work and to maintain state 821 until that work is done. That is, the initiator of the 822 authentication should maintain the cost of any state required 823 by the authentication for as long as possible. This also helps 824 when an attacker send an overwhelming load of keying protocol 825 initiations from bogus sources. 827 Another important class of attack is denial of service against 828 the routing protocol where an attacker can manipulate either 829 the routing protocol or cryptographic authentication mechanism 830 to disrupt routing adjacencies. 832 Without KARP solutions, many routing protocols are subject to 833 disruption simply by injecting an invalid packet or a packet 834 for the wrong state. Even with cryptographic validation, replay 835 attacks are often a vector where a previously valid packet can 836 be injected to create a denial of service. KARP solutions 837 should prevent all cases where packet replays or other packet 838 injections by an outsider can disrupt routing sessions. 840 Some residual denial of service risk is always likely. If an 841 attacker can generate a large enough number of packets, the 842 routing protocol can get disrupted. Even if the routing 843 protocol is not disrupted, the loss rate on a link may rise to 844 a point where claiming that traffic can successfully be routed 845 across the link will be inaccurate. 847 8. Gap Analysis 849 The [I-D.ietf-karp-threats-reqs] document lists the generic 850 requirements for the security mechanisms that must exist for 851 the various routing protocols that come under the purview of 852 KARP. There will be different design teams working for each of 853 the categories of routing protocols defined. 855 To start, design teams must review the "Threats and 856 Requirements for Authentication of Routing Protocols" document 857 [I-D.ietf-karp-threats-reqs]. This document contains detailed 858 descriptions of the threat analysis for routing protocol 859 authentication and integrity in general. Note that it will not 860 contain all the authentication-related threats for any one 861 routing protocol, or category of routing protocols. The design 862 team must conduct a protocol-specific threat analysis to 863 determine if threats beyond those in the [I-D.ietf-karp- 864 threats-reqs] document arise in the context of the protocol 865 (group), and to describe those threats. 867 The [I-D.ietf-karp-threats-reqs] document also contains many 868 security requirements. Each routing protocol design team must 869 walk through each section of the requirements and determine one 870 by one how its protocol either does or does not relate to each 871 requirement. 872 Examples include modern, strong cryptographic algorithms, with 873 at least one such algorithm listed as a MUST; algorithm 874 agility; secure use of simple PSKs; intra-connection replay 875 protection; inter-connection replay protection, etc. 877 When doing the gap analysis we must first identify the elements 878 of each routing protocol that we wish to protect. In case of 879 protocols riding on top of IP, we might want to protect the IP 880 header and the protocol headers, while for those that work on 881 top of TCP, it will be the TCP header and the protocol payload. 882 There is patently value in protecting the IP header and the TCP 883 header if the routing protocols rely on these headers for some 884 information (for example, identifying the neighbor which 885 originated the packet). 887 Then there will be a set of Cryptography requirements that we 888 might want to look at. For example, there must be at least on 889 set of cryptographic algorithms (MD5, SHA, etc.) or 890 constructions (HMAC, etc.) whose use is supported by all 891 implementations and can be safely assumed to be supported by 892 any implementation of the authentication option. The design 893 teams should look for this for the protocol that they are 894 working on. If such algorithms or constructions are not 895 available then some should be defined to support 896 interoperability by having a single default. 898 Design teams must ensure that the default cryptographic 899 algorithms and constructions supported by the routing protocols 900 are accepted by the community. This means that the protocols 901 must not rely on non-standard or ad-hoc hash functions, keyed- 902 hash constructions, signature schemes, or other functions, and 903 must use published and standard schemes. 905 Care should also be taken to ensure that the routing protocol 906 authentication scheme has algorithm agility (i.e., it is 907 capable of supporting algorithms other than its defaults). 909 Ideally, the authentication mechanism should not be affected by 910 packet loss and reordering. 912 Design teams should ensure that their protocols authentication 913 mechanism is able to accommodate rekeying. This is essential 914 since it is well known that keys must periodically be changed. 915 Also what the designers must ensure is that this rekeying event 916 should not affect the functioning of the routing protocol. For 917 example, OSPF rekeying requires coordination among the adjacent 918 routers, while IS-IS requires coordination among routers in the 919 entire domain. 921 If new authentication and security mechanisms are needed then 922 the design teams must design in such a manner that the routing 923 protocol authentication mechanism remains oblivious to how the 924 keying material is derived. This decouples the authentication 925 mechanism from the key management system that is employed. 927 Design teams should also note that many routing protocols 928 require prioritized treatment of certain protocol packets and 929 authentication mechanisms should honor this. 931 Not all routing protocol authentication mechanisms provide 932 support for replay attacks, and the design teams should 933 identify such authentication mechanisms and work on them so 934 that this can get fixed. The design teams must look at the 935 protocols that they are working on and see if packets captured 936 from the previous/stale sessions can be replayed. 938 What might also influence the design is the rate at which the 939 protocol packets are originated. In case of protocols like BFD, 940 where packets are originated at millisecond intervals, there 941 are some special considerations that must be kept in mind when 942 defining the new authentication and security mechanisms. 944 The designers should also consider whether the current 945 authentication mechanisms impose considerable processing 946 overhead on a router that's doing authentication. Most 947 currently deployed routers do not have hardware accelerators 948 for cryptographic processing and these operations can impose a 949 significant processing burden under some circumstances. The 950 proposed solutions should be evaluated carefully with regard to 951 the processing burden that they will impose, since deployment 952 may be impeded if network operators perceive that a solution 953 will impose a processing burden which either entails 954 substantial capital expenses or threatens to destabilize the 955 routers. 957 9. Security Considerations 959 As mentioned in the Introduction, RFC4948 [RFC4948] identifies 960 additional steps needed to achieve the overall goal of 961 improving the security of the core routing infrastructure. 962 Those include validation of route origin announcements, path 963 validation, cleaning up the IRR databases for accuracy, and 964 operational security practices that prevent routers from 965 becoming compromised devices. The KARP work is but one step 966 needed to improve core routing infrastructure. 968 The security of cryptographic-based systems depends on both the 969 strength of the cryptographic algorithms chosen and the 970 strength of the keys used with those algorithms. The security 971 also depends on the engineering of the protocol used by the 972 system to ensure that there are no non-cryptographic ways to 973 bypass the security of the overall system. 975 9.1. Use Strong Keys 977 Care should be taken to ensure that the selected key is 978 unpredictable, avoiding any keys known to be weak for the 979 algorithm in use. [RFC4086] contains helpful information on 980 both key generation techniques and cryptographic randomness. 982 Care should also be taken when choosing the length of the key. 983 [RFC3766] provides some additional information on asymmetric 984 and symmetric key sizes and how they related to system 985 requirements for attack resistance. 987 In addition to using a key of appropriate length and 988 randomness, deployers of KARP protocols should use different 989 keys between different routing peers whenever operationally 990 possible. This is especially true when the Routing Protocol 991 takes a static Traffic Key as opposed to a Traffic Key derived 992 on a per-connection basis using a KDF. The burden for doing so 993 is understandably much higher than for using the same static 994 Traffic Key across all peering routers. Depending upon the 995 specific KMP it can be argued that generally using a KMP 996 network-wide increases peer-wise security. Consider an attacker 997 that learns or guesses the Traffic Key used by two peer- 998 routers: if the Traffic key is only used between those two 999 routers, then the attacker has only compromised that one 1000 connection not the entire network. 1002 However, whenever using manual keys, it is best to design a 1003 system where a given pre-shared key (PSK) will be used in a 1004 KDF, mixed with connection-specific material, in order to 1005 generate session unique -- and therefore peer-wise -- Traffic 1006 Keys. Doing so has the following advantages: the Traffic Keys 1007 used in the per-message authentication mechanism are peer-wise 1008 unique, it provides inter-connection replay protection, and, if 1009 the per-message authentication mechanism covers some connection 1010 counter, intra-connection replay protection. 1012 Note that certain key derivation functions (e.g. 1013 KDF_AES_128_CMAC, as used in TCP-AO [RFC5926], the pseudorandom 1014 function (PRF) used in the KDF may require a key of a certain 1015 fixed size as an input. 1017 For example, AES_128_CMAC requires a 128 bit (16 byte) key as 1018 the seed. However, for convenience to the administrators, a 1019 specification may not want to require the entry of a PSK of 1020 exactly 16 bytes. Instead, a specification may call for a key 1021 prep routine that could handle a variable length PSK, one that 1022 might be less or more than 16 bytes (see [RFC4615], section 3, 1023 as an example). That key prep routine would derive a key of 1024 exactly the required length and thus suitable as a seed to the 1025 PRF. This does NOT mean that administrators are safe to use 1026 weak keys. Administrators are encouraged to follow [RFC4086] 1027 [NIST-800-118]. We simply attempted to "put a fence around 1028 stupidity", as much as possible as its hard to imagine 1029 administrators putting in a password that is, say 16 bytes in 1030 length. 1032 A better option, from a security perspective, is to use some 1033 representation of a device-specific asymmetric key pair as the 1034 identity proof, as described in section "Unique versus Shared 1035 Keys" section. 1037 9.2. Internal vs. External Operation 1039 Design teams must consider whether the protocol is an internal 1040 routing protocol or an external one, i.e. does it primarily run 1041 between peers within a single domain of control or between two 1042 different domains of control? Some protocols may be used in 1043 both cases, internally and externally, and as such various 1044 modes of authentication operation may be required for the same 1045 protocol. While it is preferred that all routing exchanges run 1046 with the best security mechanisms enabled in all deployment 1047 contexts, this exhortation is greater for those protocols 1048 running on inter-domain point-to-point links, and greatest for 1049 those on shared access link layers with several different 1050 domains interchanging together, because the volume of attackers 1051 are greater from the outside. Note however that the 1052 consequences of internal attacks maybe no less severe -- in 1053 fact they may be quite a bit more severe -- than an external 1054 attack. An example of this internal versus external 1055 consideration is BGP which has both EBGP and IBGP modes. 1056 Another example is a multicast protocol where the neighbors are 1057 sometimes within a domain of control and sometimes at an inter- 1058 domain exchange point. In the case of PIM-SM running on an 1059 internal multi-access link, it would be acceptable to give up 1060 some security to get some convenience by using a group key 1061 among the peers on the link. On the other hand, in the case of 1062 PIM-SM running over a multi-access link at a public exchange 1063 point, operators may favor security over convenience by using 1064 unique pair-wise keys for every peer. Designers must consider 1065 both modes of operation and ensure the authentication 1066 mechanisms fit both. 1068 Operators are encouraged to run cryptographic authentication on 1069 all their adjacencies, but to work from the outside in, i.e. 1070 EBGP links are a higher priority than the IBGP links because 1071 they are externally facing, and, as a result, more likely to be 1072 targeted in an attack. 1074 9.3. Unique versus Shared Keys 1076 This section discusses security considerations regarding when 1077 it is appropriate to use the same authentication key inputs for 1078 multiple peers and when it is not. This is largely a debate of 1079 convenience versus security. It is often the case that the best 1080 secured mechanism is also the least convenient mechanism. For 1081 example, an air gap between a host and the network absolutely 1082 prevents remote attacks on the host, but having to copy and 1083 carry files using the "sneaker net" is quite inconvenient and 1084 does not scale. 1086 Operators have erred on the side of convenience when it comes 1087 to securing routing protocols with cryptographic 1088 authentication. Many do not use it at all. Some use it only on 1089 external links, but not on internal links. Those that do use it 1090 often use the same key for all peers in a network. It is common 1091 to see the same key in use for years, e.g., the key was entered 1092 when authentication mechanisms were originally configured, or 1093 the routing gear was deployed. 1095 One goal for designers is to create authentication and 1096 integrity mechanisms that are easy for operators to deploy and 1097 manage, and still use unique keys between peers (or small 1098 groups on multi-access links), and for different sessions among 1099 the same peers. Operators have the impression that they NEED 1100 one key shared across the network, when in fact they do not. 1101 What they need is the relative convenience they experience from 1102 deploying cryptographic authentication with one key (or a few 1103 keys), compared to the inconvenience they would experience if 1104 they deployed the same authentication mechanism using unique 1105 pairwise keys. An example is BGP Route Reflectors. Here 1106 operators often use the same authentication key between each 1107 client and the route reflector. The roadmaps defined from this 1108 guidance document should allow for unique keys to be used 1109 between each client and the peer, without sacrificing much 1110 convenience. Designers should strive to deliver peer-wise 1111 unique keying mechanisms with similar ease-of-deployment 1112 properties as today's one-key method. 1114 Operators must understand the consequences of using the same 1115 key across many peers. One argument against using the same key 1116 is that if the same key that is used in multiple devices then a 1117 compromise of any one of the devices will expose the key. Also 1118 since the same key is supported on many devices this is known 1119 by many people which affects its distribution to all of the 1120 devices. 1122 Consider also the attack consequence size, the amount of 1123 routing adjacencies that can be negatively affected once a 1124 breach has occurred, i.e., once the keys have been acquired by 1125 the attacker. 1127 Again, if a shared key is used across the internal domain, then 1128 the consequence size is the whole network. Ideally, unique key 1129 pairs would be used for each adjacency. 1131 In some cases use of shared keys is needed because of the 1132 problem space. For example, a multicast packet is sent once but 1133 then consumed by several routing neighbors. If unique keys were 1134 used per neighbor, the benefit of multicast would be erased 1135 because sender would have to create a different announcement 1136 packet for each receiver. Though this may be desired and 1137 acceptable in some small number of use cases, it is not the 1138 norm. Shared (i.e., group) keys are an acceptable solution 1139 here, and much work has been done already in this area (see 1140 MSEC working group). 1142 9.4. Key Exchange Mechanism 1144 This section discusses the security and use case considerations 1145 for key exchange for routing protocols. Two options exist: an 1146 out-of-band mechanism or a KMP. An out-of-band mechanism 1147 involves operators configuring keys in the device through a 1148 configuration tool or management method (e.g., SNMP, NETCONF). 1149 A KMP is an automated protocol that exchanges key without 1150 operator intervention. KMPs can occur either in-band to the 1151 routing protocol or out-of-band to the routing protocol (i.e., 1152 a different protocol). 1154 An example of an out-of-band configuration mechanism could be 1155 an administrator who makes a remote management connection (e.g. 1156 using SSH) to a router and manually enters the keying 1157 information, e.g., the algorithm, the key(s), the key 1158 lifetimes, etc. Another example could be an OSS system that 1159 inputs the same information using a script over an SSH 1160 connection, or by pushing configuration through some other 1161 management connection, standard (Netconf-based) or proprietary. 1163 The drawbacks of an out-of-band configuration mechanism 1164 include: lack of scaleability, complexity, and speed of 1165 changing if a security breach is suspected. For example, if an 1166 employee who had access to keys was terminated, or if a machine 1167 holding those keys was believed to be compromised, then the 1168 system would be considered insecure and vulnerable until new 1169 keys were generated and distributed. Those keys then need to be 1170 placed into the OSS system, and the OSS system then needs to 1171 push the new keys -- often during a very limited change window 1172 -- into the relevant devices. If there are multiple 1173 organizations involved in these connections, because the 1174 protected connections are inter-domain, this process is very 1175 complicated. 1177 The principle benefit of out-of-band configuration mechanism is 1178 that once the new keys/parameters are set in OSS system, they 1179 can be pushed automatically to all devices within the OSS's 1180 domain. Operators have mechanisms in place for this already for 1181 managing other router configuration data. In small environments 1182 with few routers, a manual system is not difficult to employ. 1184 We further define a peer-to-peer KMP as using cryptographically 1185 protected identity verification, session key negotiation, and 1186 security association parameter negotiation between the two 1187 routing peers. The KMP among peers may also include the 1188 negotiation of parameters, like cryptographic algorithms, 1189 cryptographic inputs (e.g. initialization vectors), key life- 1190 times, etc. 1192 There are several benefits of a peer-to-peer KMP versus 1193 centrally managed and distributing keys. It results in key(s) 1194 that are privately generated, and need not be recorded 1195 permanently anywhere. Since the traffic keys used in a 1196 particular connection are not a fixed part of a device 1197 configuration no security sensitive data exists anywhere else 1198 in the operator's systems which can be stolen, e.g. in the case 1199 of a terminated or turned employee. If a server or other data 1200 store is stolen or compromised, the thieves gain limited or no 1201 access to current traffic keys. They may gain access to key 1202 derivation material, like a PSK, but may not be able to access 1203 the current traffic keys in use. In this example, these PSKs 1204 can be updated in the device configurations (either manually or 1205 through an OSS) without bouncing or impacting the existing 1206 session at all. In the case of using raw asymmetric keys or 1207 certificates, instead of PSKs, the data theft (from the data 1208 store) would likely not result in any compromise, as the key 1209 pairs would have been generated on the routers, and never leave 1210 those routers. In such a case no changes are needed on the 1211 routers; the connections will continue to be secure, 1212 uncompromised. Additionally, with a KMP regular rekey 1213 operations occur without any operator involvement or oversight. 1214 This keeps keys fresh. 1216 There are a few drawbacks to using a KMP. First, a KMP requires 1217 more cryptographic processing for the router at the beginning 1218 of a connection. This will add some minor start-up time to 1219 connection establishment versus a purely manual key management 1220 approach. Once a connection with traffic keys has been 1221 established via a KMP, the performance is the same in the KMP 1222 and the out-of-band configuration case. KMPs also add another 1223 layer of protocol and configuration complexity which can fail 1224 or be misconfigured. This was more of an issue when these KMPs 1225 were first deployed, but less so as these implementations and 1226 operational experience with them has matured. 1228 One of the goals for KARP is to develop a KMP; an out-of-band 1229 configuration protocol for key exchange is out of scope. 1231 Within this constraint there are two approaches for a KMP: 1233 The first, is to use a KMP that runs independent of the routing 1234 and the signaling protocols. It would run on its own port and 1235 use its own transport (to avoid interfering with the routing 1236 protocol that it is serving). When a routing protocol needs a 1237 key, it would contact the local instance of this key management 1238 protocol and request a key. The KMP generates a key that is 1239 delivered to the routing protocol for it to use for 1240 authenticating and integrity verification of the routing 1241 protocol packets. This KMP could either be an existing key 1242 management protocol like ISAKMP/IKE, GKMP, etc., extended for 1243 the routing protocols, or it could be a new KMP, designed for 1244 the routing protocol context. 1246 The second approach is to define an In-band KMP extension for 1247 existing routing protocols putting the key management 1248 mechanisms inside the protocol itself. In this case, the key 1249 management messages would be carried within the routing 1250 protocol packets, resulting in very tight coupling between the 1251 routing protocols and the key management protocol. 1253 10. Acknowledgments 1255 Much of the text for this document came originally from draft- 1256 lebovitz-karp-roadmap, authored by Gregory M. Lebovitz. 1258 We would like to thank Sam Hartman, Eric Rescorla, Russ White, 1259 Sean Turner, Stephen Kent, Stephen Farrell, Adrian Farrel, Russ 1260 Housley, Michael Barnes and Vishwas Manral for their comments 1261 on the draft. 1263 11. IANA Considerations 1265 This document places no requests to IANA. 1267 12. References 1269 12.1. Normative References 1271 [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate 1272 Requirement Levels", BCP 14, RFC 2119, March 1997. 1274 [RFC4948] Andersson, L., et. al, "Report from the IAB workshop 1275 on Unwanted Traffic March 9-10, 2006", RFC 4948, 1276 August 2007. 1278 12.2. Informative References 1280 [RFC1195] Callon, R. , "Use of OSI IS-IS for Routing in TCP/IP 1281 and Dual Environments", RFC 1195, December 1990. 1283 [RFC2205] Braden, R., et. al, "Resource ReSerVation Protocol 1284 (RSVP) Version 1 Functional Specification", RFC 2205, 1285 September 1197. 1287 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1289 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. 1291 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP 1292 Cryptographic Authentication", RFC 2747, January 1293 2000. 1295 [RFC3097] Braden, R, and Zhang, L., "RSVP Cryptographic 1296 Authentication -- Updated Message Type Value", RFC 1297 3097, April 2001 1299 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 1300 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 1301 LSP Tunnels", RFC 3209, December 2001. 1303 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 1304 Switching (GMPLS) Signaling Resource ReserVation 1305 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1306 RFC 3473, January 2003. 1308 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, 1309 "The Group Domain of Interpretation", RFC 3547, July 1310 2003. 1312 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1313 Protocol (MSDP)", RFC 3618, October 2003. 1315 [RFC3766] Orman, H. and Hoffman, P., "Determining Strengths For 1316 Public Keys Used For Exchanging Symmetric Keys", RFC 1317 3766, April 2004. 1319 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1320 Independent Multicast - Dense Mode (PIM-DM): Protocol 1321 Specification (Revised)", RFC 3973, January 2005. 1323 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, 1324 Randomness Requirements for Security", BCP 106, 1325 RFC 4086, June 2005. 1327 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for 1328 Cryptographic Key Management", BCP 107, RFC 4107, 1329 June 2005. 1331 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 1332 Properties", RFC 4230, December 2005. 1334 [RFC4252] Ylonen, T., et. al, "The Secure Shell (SSH) 1335 Authentication Protocol", RFC 4252, January 2006. 1337 [RFC4253] Ylonen, T., et. al, "The Secure Shell (SSH) Transport 1338 Layer Protocol", RFC 4253, January 2006 1340 [RFC4271] Rekhter, Y., Li, T. and Hares, S.,"A Border Gateway 1341 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1343 [RFC4492] Blake-Wilson, S., "Elliptical Curve Cryptography 1344 (ECC) Cipher Suites for Transport Layer Security 1345 (TLS)", RFC 4492, May 2006 1347 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. 1348 Kouvelas,"Protocol Independent Multicast - Sparse 1349 Mode (PIM-SM): Protocol Specification (Revised)", RFC 1350 4601, August 2006. 1352 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 1353 Advanced Encryption Standard-Cipher-based Message 1354 Authentication Code-Pseudo-Random Function-128 (AES- 1355 CMAC-PRF-128) Algorithm for the Internet Key Exchange 1356 Protocol (IKE)", RFC 4615, August 2006. 1358 [RFC4726] Farrel, A., et. al.,"A Framework for Inter-Domain 1359 Multiprotocol Label Switching Traffic Engineering", 1360 RFC 4726, November 2006. 1362 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1363 Specification", RFC 5036, October 2007. 1365 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P. and 1366 Pignataro, C.,"The Generalized TTL Security Mechanism 1367 (GTSM)" , RFC 5082, October 2007 1369 [RFC5151] Farrel, A., et. al.,"Inter-Domain MPLS and GMPLS 1370 Traffic Engineering -- Resource Reservation Protocol- 1371 Traffic Engineering (RSVP-TE) Extensions", RFC 5151, 1372 February 2008. 1374 [RFC5280] Cooper, D., et. al.,"Internet X.509 Public Key 1375 Infrastructure Certificate and Certificate Revocation 1376 List (CRL) Profile", RFC 5280, May 2008 1378 [RFC5440] Vasseur, J.P. and Le Roux, J.L., "Path Computation 1379 Element (PCE) Communication Protocol (PCEP)", RFC 1380 5440, March 2009 1382 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication 1383 and Confidentiality in PIM-SM Link-local Messages", 1384 RFC 5796, March 2010. 1386 [RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding 1387 Detection", RFC 5880, June 2010. 1389 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1390 Authentication Option", RFC 5925, June 2010. 1392 [RFC5926] Lebovitz, G., "Cryptographic Algorithms, Use and 1393 Implementation Requirements for TCP Authentication 1394 Option", RFC 5926, June 2010. 1396 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J. and White, 1397 R.,"Issues with Existing Cryptographic Protection 1398 Methods for Routing Protocols", RFC 6039, October 1399 2010 1401 [I-D.ietf-karp-threats-reqs] Lebovitz, G., "KARP Threats and 1402 Requirements", Work in Progress, October 2010. 1404 [I-D.ietf-karp-crypto-key-table] Housley, R. and Polk, T., 1405 "Database of Long-Lived Symmetric Cryptographic Keys" 1406 , Work in Progress, May 2011 1408 [I-D.weis-gdoi-mac-tek] Weis, B. and S. Rowles, "GDOI Generic 1409 Message Authentication Code Policy", Work in 1410 Progress, June 2010. 1412 [IRR] Merit Network Inc , "Internet Routing Registry Routing 1413 Assets Database", 2006, http://www.irr.net/. 1415 [NIST-800-57] US National Institute of Standards & Technology, 1416 "Recommendation for Key Management Part 1: General 1417 (Revised)", March 2007 1419 [NIST-800-118] US National Institute of Standards & Technology, 1420 "Guide to Enterprise Password Management (Draft)", 1421 April 2009 1423 Author's Addresses 1424 Gregory M. Lebovitz 1425 California 1426 USA 95003 1428 Phone: 1429 Email: gregory.ietf@gmail.com 1431 Manav Bhatia 1432 Alcatel-Lucent 1433 Bangalore 1434 India 1436 Phone: 1437 Email: manav.bhatia@alcatel-lucent.com