idnits 2.17.1 draft-lebovitz-karp-roadmap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4948]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Significant updates to Security Considerations section o Added a few references throughout to RFC3562 o 4.3 2nd to last P - added a comment to clarify that two parties (or an org) must discuss ahead of time what they want their connections' secruity properties to be. - dward o added to 4.4 Phase 1 - New Section: Transition and Deployment Considerations. ea wg must call out the operational transition plan from old to new security. Best if don't bounce link. - dward o added 3.3 (but not sure if this is right)- endpoint discovery mechanisms? endpoint discovery mechanism (L2VPN, L3VPN, etc). Discovery is much different security properties than passing Routing updates. - dward o More requirements: Added to 4.2: X - convergence SHOULD not be affected by what we choose; adding security SHOULD not cause a refresh of route updates or cause additional route updates to be generated; adding auth should not be an attack vector itself. AKA, the use of MD5 is so expensive that spoofing BGP packets w/ MD5 causes the control plane to be attacked because CPU went to 100% - dward o updated stats on MD5 usage, and cited [ISR2008]. - mchpherson -- The document date (January 13, 2010) is 5216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRR' is mentioned on line 131, but not defined == Unused Reference: 'RFC5226' is defined on line 1913, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-08 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP G. Lebovitz 3 Internet-Draft Juniper 4 Intended status: Informational January 13, 2010 5 Expires: July 17, 2010 7 Roadmap for Cryptographic Authentication of Routing Protocol Packets on 8 the Wire 9 draft-lebovitz-karp-roadmap-00 11 Abstract 13 In the March of 2006 the IAB held a workshop on the topic of 14 "Unwanted Internet Traffic". The report from that workshop is 15 documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for 16 "[t]ightening the security of the core routing infrastructure." Four 17 main steps were identified for improving the security of the routing 18 infrastructure. One of those steps was "securing the routing 19 protocols' packets on the wire." One mechanism for securing routing 20 protocol packets on the wire is the use of per-packet cryptographic 21 message authentication, providing both peer authentication and 22 message integrity. Many different routing protocols exist and they 23 employ a range of different transport subsystems. Therefore there 24 must necessarily be various methods defined for applying 25 cryptographic authentication to these varying protocols. Many 26 routing protocols already have some method for accomplishing 27 cryptographic message authentication. However, in many cases the 28 existing methods are dated, vulnerable to attack, and/or employ 29 cryptographic algorithms that have been deprecated. This document 30 creates a roadmap of protocol specification work for the use of 31 modern cryptogrpahic mechanisms and algorithms for message 32 authentication in routing protocols. It also defines the framework 33 for a key management protocol that may be used to create and manage 34 session keys for message authentication and integrity. This roadmap 35 reflects the input of both the security area and routing area in 36 order to form a jointly agreed upon and prioritized work list for the 37 effort. This version is actually the fourth version, but is recently 38 renamed from "-kmart-roadmap" to "-karp-roadmap" to follow the new 39 working group name. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt. 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 This Internet-Draft will expire on July 17, 2010. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 83 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 84 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 1.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1.6. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 2.1. Threats In Scope . . . . . . . . . . . . . . . . . . . . . 13 90 2.2. Threats Out of Scope . . . . . . . . . . . . . . . . . . . 15 91 3. Categorizing Routing Protocols . . . . . . . . . . . . . . . . 16 92 3.1. Category: Messaging Transaction Type . . . . . . . . . . . 16 93 3.2. Category: Peer vs. Group Keying . . . . . . . . . . . . . 17 94 3.3. Category: Update vs. Discovery Protocol . . . . . . . . . 18 95 3.4. Security Characterization Vectors . . . . . . . . . . . . 18 96 3.4.1. Internal vs. External Operation . . . . . . . . . . . 18 97 3.4.2. Unique versus Shared Keys . . . . . . . . . . . . . . 19 98 3.4.3. Out-of-Band vs. In-line Key Management . . . . . . . . 20 99 4. The Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 4.1. Work Phases on any Particular Protocol . . . . . . . . . . 22 101 4.2. Requirements for Phase 1 Routing Protocols' Security 102 Update . . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 4.3. Common Framework . . . . . . . . . . . . . . . . . . . . . 25 104 4.4. Work Items Per Routing Protocol . . . . . . . . . . . . . 31 105 4.5. Protocols in Categories . . . . . . . . . . . . . . . . . 33 106 4.6. Priorites . . . . . . . . . . . . . . . . . . . . . . . . 35 107 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 110 8. Change History (RFC Editor: Delete Before Publishing) . . . . 37 111 9. Needs Work in Next Draft (RFC Editor: Delete Before 112 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 40 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 115 10.2. Informative References . . . . . . . . . . . . . . . . . . 41 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 118 1. Introduction 120 In March 2006 the Internet Architecture Board (IAB) held a workshop 121 on the topic of "Unwanted Internet Traffic". The report from that 122 workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that 123 document states that "A simple risk analysis would suggest that an 124 ideal attack target of minimal cost but maximal disruption is the 125 core routing infrastructure." Section 8.2 calls for "[t]ightening 126 the security of the core routing infrastructure." Four main steps 127 were identified for that tightening: 129 o More secure mechanisms and practices for operating routers. This 130 work is being addressed in the OPSEC Working Group. 131 o Cleaning up the Internet Routing Registry repository [IRR], and 132 securing both the database and the access, so that it can be used 133 for routing verifications. This work should be addressed through 134 liaisons with those running the IRR's globally. 135 o Specifications for cryptographic validation of routing message 136 content. This work will likely be addressed in the SIDR Working 137 Group. 138 o Securing the routing protocols' packets on the wire 140 This document addresses the last bullet, securing the packets on the 141 wire of the routing protocol exchanges. The document addresses 142 Keying and Authentication for Routing Protocols, aka "KARP". 144 It is unlikely that this document, in its current form, will become 145 an RFC. More likely is that this document will be split up into 146 several smaller documents which may look something like: 148 o Scope & Goals sections will likely become part of the KARP WG 149 charter 150 o Threat document 151 o Requirements document (may be combined with Threat document) 152 o Framework document 153 o RoutingProtocol Design Team Work Plan document. This would 154 include sections like Work Phases, Priorities, Security 155 Considerations, etc. 156 For now, the document serves as the catch all for the set of thoughts 157 around the KARP effort. As a working group is formed, decisions will 158 be made about the creation of specific documents. 160 Editor's Note on "KMART" vs "KARP": The first few versions of this 161 document were called "draft-lebovitz-kmart-roadmap-xx". This went up 162 to -03. Upon the creation of the BoF for IETF76, the IESG requested 163 the name of the effort change so as to avoid any potential trademark 164 issues. The new name of the effort is KARP. Version -03 went out 165 titled "draft-lebovitz-kmart-roadmap-03", so as to avoid last minute 166 confusion at that IETF meeting. This version now changes the "kmart" 167 to "karp" in the title, changes the version counter back to -00, and 168 contains no other changes, and is published as 169 "draft-lebovitz-karp-roadmap-00". 171 1.1. Terminology 173 Within the scope of this document, the following words, when 174 beginning with a capital letter, or spelled in all capitals, hold the 175 meanings described to the right of each term. If the same word is 176 used uncapitalized, then it is intended to have its common english 177 definition. 179 PSK Pre-Shared Key. A key used by both peers in a secure 180 configuration. Usually exchanged out-of-band prior to 181 a first connection. 183 Routing Protocol When used with capital "R" and "P" in this document 184 the term refers the Routing Protocol for which work is 185 being done to provide or enhance its peer 186 authentication mechanisms. 188 PRF Pseudorandom number function, or sometimes called 189 pseudorandom number generator (PRNG). An algorithm 190 for generating a sequence of numbers that approximates 191 the properties of random numbers. The sequence is not 192 truly random, in that it is completely determined by a 193 relatively small set of initial values that are passed 194 into the function. An exmaple is SHA-256. 196 KDF Key derivation function. A particular specified use 197 of a PRF that takes a PSK, combines it with other 198 inputs to the PRF, and produces a result that is 199 suitable for use as a Traffic Key. 201 Identifier The type and value used by one peer of an 202 authenticated message exchange to signify to the other 203 peer who they are. The Identifier is used by the 204 receiver as a lookup index into a table containing 205 further information about the peer that is required to 206 continue processing the message, for example a 207 Security Association (SA) or keys. 209 Identity Proof A cryptographic proof for an asserted identity, that 210 the peer really is who they assert themselves to be. 211 Proof of identity can be arranged between the peers in 212 a few ways, for example PSK, raw assymetric keys, or a 213 more user-friendly representation of assymetric keys, 214 like a certificate. 216 Security Association or SA The parameters and keys that together 217 form the required information for processing secure 218 sessions between peers. Examples of items that may 219 exist in an SA include: Identifier, PSK, Traffic Key, 220 cryptographic algorithms, key lifetimes. 222 KMP Key Management Protocol. A protocol used between 223 peers to exchange SA parameters and Traffic Keys. 224 Examples of KMPs include IKE, TLS, and SSH. 226 KMP Function Any actual KMP used in the general KARP solution 227 framework 229 Peer Key Keys that are used between peers as the identity 230 proof. These keys may or may not be connection 231 specific, depending on who they were established, and 232 what form of identity and identity proof is being used 233 in the system. 235 Traffic Key The actual key used on each packet of a message. 237 Definitions of items specific to the general KARP framework are 238 described in more detail in the Framework section Section 4.3. 240 1.2. Requirements Language 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in RFC2119 [RFC2119]. 246 When used in lower case, these words convey their typical use in 247 common language, and are not to be interpreted as described in 248 RFC2119 [RFC2119]. 250 1.3. Scope 252 Four basic tactics may be employed in order to secure any piece of 253 data as it is transmitted over the wire: privacy (or encryption), 254 authentication, message integrity, and non-repudiation. The focus 255 for this effort, and the scope for this roadmap document, will be 256 message authentication and packet integrity only. This work 257 explicitly excludes, at this point in time, the other two tactics: 258 privacy and non-repudiation. Since the objective of most routing 259 protocols is to broadly advertise the routing topology, routing 260 messages are commonly sent in the clear; confidentiality is not 261 normally required for routing protocols. However, ensuring that 262 routing peers truly are the trusted peers expected, and that no roque 263 peers or messages can compromise the stability of the routing 264 environment is critical, and thus our focus. The other two 265 explicitly excluded tactics, privacy and non-repudiation, may be 266 addressed in future work. 268 It is possible for routing protocol packets to be transmitted 269 employing all four security tactics mentioned above using existing 270 standards. For example, one could run unicast, layer 3 or above 271 routing protocol packets through IPsec ESP [RFC4303]. This would 272 provide the added benefit of privacy, and non-repudiation. However, 273 router platforms and systems have been fine tuned over the years for 274 the specific processing necessary for routing protocols' non- 275 encapsulated formats. Operators are, therefore, quite reluctant to 276 explore new packet encapsulations for these tried and true protocols. 278 In addition, at least in the case of BGP and LDP, these protocols 279 already have existing mechanisms for cryptographically authenticating 280 and integrity checking the packets on the wire. Products with these 281 mechanisms have already been produced, code has already been written 282 and both have been optimized for the existing mechanisms. Rather 283 than turn away from these mechanisms, we want to enhance them, 284 updating them to modern and secure levels. 286 There are two main work phases for this roadmap, and for any Routing 287 Protocol work undertaken as part of this roadmap (discussed further 288 in the Work Phases (Section 4.1) section). The first is to enhance 289 the Routing Protocol's current authentication mechanism, ensuring it 290 employs modern cryptographic algorithms and methods for its basic 291 operational model, fulfilling the requirements defined in the 292 Requirements (Section 4.2) section, and protecting against as many of 293 the threats as possible as defined in the Threats (Section 2.1) 294 section. Many of the Routing Protocols' current mechanisms use 295 manual keys, so the first phase updates will focus on shoring up the 296 manual key mechanisms that exist. 298 The second work phase is to define the use of a key management 299 protocol (KMP) for creating and managing session keys used in the 300 Routing Protocols' message authentication and data integrity 301 functions. It is intended that a general KMP framework -- or a small 302 number of frameworks -- can be defined and leveraged for many Routing 303 Protocols. 305 Therefore, the scope of this roadmap of work includes: 307 o Making use of existing routing protocol security protocols, where 308 they exist, and enhancing or updating them as necessary for modern 309 cryptographic best practices, 311 o Developing a framework for using automatic key management in order 312 to ease deployment, lower cost of operation, and allow for rapid 313 responses to security breaches, and 315 o Specifying the automated key management protocol that may be 316 combined with the bits-on-the-wire mechanisms. 318 The work also serves as an agreement between the Routing Area and the 319 Security Area about the priorities and work plan for incrementally 320 delivering the above work. This point is important. There will be 321 times when the best-security-possible will give way to vastly- 322 improved-over-current-security-but-admittedly-not-yet-best-security- 323 possible, in order that incremental progress toward a more secure 324 Internet may be achieved. As such, this document will call out 325 places where agreement has been reached on such trade offs. 327 This document does not contain protocol specifications. Instead, it 328 defines the areas where protocol specification work is needed and 329 sets a direction, a set of requirements, and a relative priority for 330 addressing that specification work. 332 There are a set of threats to routing protocols that are considered 333 in-scope for this document/roadmap, and a set considered out-of- 334 scope. These are described in detail in the Threats (Section 2) 335 section below. 337 1.4. Goals 339 The goals and general guidance for this work roadmap follow: 341 1. Provide authentication and integrity protection for packets on the 342 wire of existing routing protocols 344 2. Deliver a path to incrementally improve security of the routing 345 infrastructure. The principle of crawl, walk, run will be in 346 place. Routing protocol authentication mechanisms may not go 347 immediately from their current state to a state containing the 348 best possible, most modern security practices. Incremental steps 349 will need to be taken for a few very practical reasons. First, 350 there are a considerable number of deployed routing devices in 351 operating networks that will not be able to run the most modern 352 cryptographic mechanisms without significant and unacceptable 353 performance penalties. The roadmap for any one routing protocol 354 MUST allow for incremental improvements on existing operational 355 devices. Second, current routing protocol performance on deployed 356 devices has been achieved over the last 20 years through extensive 357 tuning of software and hardware elements, and is a constant focus 358 for improvement by vendors and operators alike. The introduction 359 of new security mechanisms affects this performance balance. The 360 performance impact of any incremental step of security improvement 361 will need to be weighed by the community, and introduced in such a 362 way that allows the vendor and operator community a path to 363 adoption that upholds reasonable performance metrics. Therefore, 364 certain specification elements may be introduced carrying the 365 "SHOULD" guidance, with the intention that the same mechanism will 366 carry a "MUST" in the next release of the specification. This 367 gives the vendors and implementors the guidance they need to tune 368 their software and hardware appropriately over time. Last, some 369 security mechanisms require the build out of other operational 370 support systems, and this will take time. An example where these 371 three reasons are at play in an incremental improvement roadmap is 372 seen in the improvement of BGP's [RFC4271] security via the update 373 of the TCP Authentication Option (TCP-AO) 374 [I-D.ietf-tcpm-tcp-auth-opt] effort. It would be ideal, and 375 reflect best common security practice, to have a fully specified 376 key management protocol for negotiating TCP-AO's authentication 377 material, using certificates for peer authentication in the 378 keying. However, in the spirit of incremental deployment, we will 379 first address issues like cryptographic algorithm agility, replay 380 attacks, TCP session resetting in the base TCP-AO protocol before 381 we layer key management on top of it. 383 3. The deploy-ability of the improved security solutions on currently 384 running routing infrastructure equipment. This begs the 385 consideration of the current state of processing power available 386 on routers in the network today. 388 4. Operational deploy-ability - A solutions acceptability will also 389 be measured by how deployable the solution is by common operator 390 teams using common deployment processes and infrastructures. I.e. 391 We will try to make these solutions fit as well as possible into 392 current operational practices or router deployment. This will be 393 heavily influenced by operator input, to ensure that what we 394 specify can -- and, more importantly, will -- be deployed once 395 specified and implemented by vendors. Deployment of incrementally 396 more secure routing infrastructure in the Internet is the final 397 measure of success. Measurably, we would like to see an increase 398 in the number of surveyed respondents who report deploying the 399 updated authentication mechanisms anywhere across their network, 400 as well as a sharp rise in usage for the total percentage of their 401 network's routers. 403 Interviews with operators show several points about routing 404 security. First, over 70% of operators have deployed transport 405 connection protection via TCP-MD5 on their EBGP [ISR2008] . Over 406 55% also deploy MD5 on their IBGP connections, and 50% deploy MD5 407 on some other IGP. The survey states that "a considerable 408 increase was observed over previous editions of the survey for use 409 of TCP MD5 with external peers (eBGP), internal peers (iBGP) and 410 MD5 extensions for IGPs." Though the data is not captured in the 411 report, the authors believe anecdotally that of those who have 412 deployed MD5 somewhere in their network, only about 25-30% of the 413 routers in their network are deployed with the authentication 414 enabled. None report using IPsec to protect the routing protocol, 415 and this was a decline from the few that reported doing so in the 416 previous year's report. 417 From my personal conversations with operators, of those using MD5, 418 almost all report deploying with one single manual key throughout 419 the entire network. These same operators report that the one 420 single key has not been changed since it was originally installed, 421 sometimes five or more years ago. When asked why, particularly 422 for the case of BGP using TCP MD5, the following reasons are often 423 given: 425 A. Changing the keys triggers a TCP reset, and thus bounces the 426 links/adjacencies, undermining Service Level Agreements 427 (SLAs). 428 B. For external peers, difficulty of coordination with the other 429 organization is an issue. Once they find the correct contact 430 at the other organization (not always so easy), the 431 coordination function is serialized and on a per peer/AS 432 basis. The coordination is very cumbersome and tedious to 433 execute in practice. 434 C. Keys must be changed at precisely the same time, or at least 435 within 60 seconds (as supported by two major vendors) in order 436 to limit connectivity outage duration. This is incredibly 437 difficult to do, operationally, especially between different 438 organizations. 439 D. Relatively low priority compared to other operatoinal issues. 440 E. Lack of staff to implement the changes device by device. 441 F. There are three use cases for operational peering at play 442 here: peers and interconnection with other operators, Internal 443 BGP and other routing sessions within a single operator, and 444 operator-to-customer-CPE devices. All three have very 445 different properties, and all are reported as cumbersome. One 446 operator reported that the same key is used for all customer 447 premise equipment. The same operator reported that if the 448 customer mandated, a unique key could be created, although the 449 last time this occurred it created such an operational 450 headache that the administrators now usually tell customers 451 that the option doesn't even exist, to avoid the difficulties. 452 These customer-uniqe keys are never changed, unless the 453 customer demands so. 454 The main threat at play here is that a terminated employee from 455 such an operator who had access to the one (or few) keys used for 456 authentication in these environments could easily wage an attack 457 -- or offer the keys to others who would wage the attack -- and 458 bring down many of the adjacencies, causing destabilization to the 459 routing system. 461 Whatever mechanisms we specify need to be easier than the current 462 methods to deploy, and should provide obvious operational 463 efficiency gains along with significantly better security and 464 threat protection. This combination of value may be enough to 465 drive much broader adoption. 467 5. Address the threats enumerated above in the "Threats" section 468 (Section 2) for each routing protocol, along a roadmap. Not all 469 threats may be able to be addressed in the first specification 470 update for any one protocol. Roadmaps will be defined so that 471 both the security area and the routing area agree on how the 472 threats will be addressed completely over time. 474 6. Create a re-usable architecture, framework, and guidelines for 475 various IETF working teams who will address these security 476 improvements for various Routing Protocols. The crux of the KARP 477 work is to re-use that framework as much as possible across 478 relevant Routing Protocols. For example, designers should aim to 479 re-use the key management protocol that will be defined for BGP's 480 TCP-AO key establishment for as many other routing protocols as 481 possible. This is but one example. 483 7. Bridge any gaps between IETF's Routing and Security Areas by 484 recording agreements on work items, roadmaps, and guidance from 485 the Area leads and Internet Architecture Board (IAB, www.iab.org). 487 1.5. Non-Goals 489 The following two goals are considered out-of-scope for this effort: 491 o Privacy of the packets on the wire, at this point in time. Once 492 this roadmap is realized, we may revisit work on privacy. 494 o Message content security. This work is being addressed in other 495 IETF efforts, like SIDR. 497 1.6. Audience 499 The audience for this roadmap includes: 501 o Routing Area working group chairs and participants - These 502 people are charged with updates to the Routing Protocol 503 specifications. Any and all cryptographic authentication work 504 on these specifications will occur in Routing Area working 505 groups, with close partnership with the Security Area. Co- 506 advisors from Security Area may often be named for these 507 partnership efforts. 509 o Security Area reviewers of routing area documents - These people 510 are delegated by the Security Area Directors to perform reviews 511 on routing protocol specifications as they pass through working 512 group last call or IESG review. They will pay particular 513 attention to the use of cryptographic authentication and 514 corresponding security mechanisms for the routing protocols. 515 They will ensure that incremental security improvements are 516 being made, in line with this roadmap. 518 o Security Area engineers - These people partner with routing area 519 authors/designers on the security mechanisms in routing protocol 520 specifications. Some of these security area engineers will be 521 assigned by the Security Area Directors, while others will be 522 interested parties in the relevant working groups. 524 o Operators - The operators are a key audience for this work, as 525 the work is considered to have succeeded if the operators deploy 526 the technology, presumably due to a perception of significantly 527 improved security value coupled with relative similarity to 528 deployment complexity and cost. Conversely, the work will be 529 considered a failure if the operators do not care to deploy it, 530 either due to lack of value or perceived (or real) over- 531 complexity of operations. And as such, the GROW and OPSEC WGs 532 should be kept squarely in the loop as well. 534 2. Threats 536 In RFC4949[RFC4949], a threat is defined as a potential for violation 537 of security, which exists when there is a circumstance, capability, 538 action, or event that could breach security and cause harm. This 539 section defines the threats that are in scope for this roadmap, and 540 those that are explicitly out of scope. This document leverages the 541 "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] , 542 capitalizes terms from that document, and offers a terse definition 543 of those terms. (More thorough description of routing protocol 544 threats sources, motivations, consequences and actions can be found 545 in RFC 4593 [RFC4593] itself). The threat listings below expand upon 546 these threat definitions. 548 2.1. Threats In Scope 550 The threats that will be addressed in this roadmap are those from 551 OUTSIDERS, attackers that may reside anywhere in the Internet, have 552 the ability to send IP traffic to the router, may be able to observe 553 the router's replies, and may even control the path for a legitimate 554 peer's traffic. These are not legitimate participants in the routing 555 protocol. Message authentication and integrity protection 556 specifically aims to identify messages originating from OUTSIDERS. 558 The concept of OUTSIDERS can be further refined to include attackers 559 who are terminated employees, and those sitting on-path. 561 o On-Path - attackers with control of a network resource or a tap 562 along the path of packets between two routers. An on-path 563 outsider can attempt a man-in-the-middle attack, in addition to 564 several other attack classes. A man-in-the-middle (MitM) attack 565 occurs when an attacker who has access to packets flowing between 566 two peers tampers with those packets in such a way that both peers 567 think they are talking to each other directly, when in fact they 568 are actually talking to the attacker only. Protocols conforming 569 to this roadmap will use cryptographic mechanisms to prevent a 570 man-in-the-middle attacker from situating himself undetected. 572 o Terminated Employees - in this context, those who had access 573 router configuration that included keys or keying material like 574 pre-shared keys used in securing the routing protocol. Using this 575 material, the attacker could send properly MAC'd spoofed packets 576 appearing to come from router A to router B, and thus impersonate 577 an authorized peer. The attacker could then send false traffic 578 that changes the network behavior from its operator's design. The 579 goal of addressing this source specifically is to call out the 580 case where new keys or keying material becomes necessary very 581 quickly, with little operational expense, upon the termination of 582 such an employee. This grouping could also refer to any attacker 583 who somehow managed to gain access to keying material, and said 584 access had been detected by the operators such that the operators 585 have an opportunity to move to new keys in order to prevent an 586 attack. 588 These ATTACK ACTIONS are in scope for this roadmap: 590 o SPOOFING - when an unauthorized device assumes the identity of an 591 authorized one. Spoofing can be used, for example, to inject 592 malicious routing information that causes the disruption of 593 network services. Spoofing can also be used to cause a neighbor 594 relationship to form that subsequently denies the formation of the 595 relationship with the legitimate router. 597 o FALSIFICATION - an action whereby an attacker sends false routing 598 information. To falsify the routing information, an attacker has 599 to be either the originator or a forwarder of the routing 600 information. Falsification may occur by an ORIGINATOR, or a 601 FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or 602 MISTATEMENT of network resource reachability. We must be careful 603 to remember that in this work we are only targeting falsification 604 from outsiders as may occur from tampering with packets in flight. 605 Falsification from BYZANTINES (see the Threats Out of Scope 606 section (Section 2.2) below) are not addressed by the KARP effort. 608 o INTERFERENCE - when an attacker inhibits the exchanges by 609 legitimate routers. The types of interference addressed by this 610 work include: 611 * ADDING NOISE 612 * REPLAYING OUT-DATED PACKETS 613 * INSERTING MESSAGES 614 * CORRUPTING MESSAGES 615 * BREAKING SYNCHRONIZATION 616 * Changing message content 618 o DoS attacks on transport sub-systems - This includes any other DoS 619 attacks specifically based on the above attack types. This is 620 when an attacker sends spoofed packets aimed at halting or 621 preventing the underlying protocol over which the routing protocol 622 runs, for example halting a BGP session by sending a TCP FIN or 623 RST packet. Since this attack depends on spoofing, operators are 624 encouraged to deploy 626 o DoS attacks using the authentication mechanism - This includes an 627 attacker sending packets which confuse or overwhelm a security 628 mechanism itself. An example is initiating an overwhelming load 629 of spoofed authenticated route messages so that the receiver needs 630 to process the MAC check, only to discard the packet, sending CPU 631 levels rising. Another example is when an attacker sends an 632 overwhelming load of keying protocol initiations from bogus 633 sources. All other possible DoS attacks are out of scope (see 634 next section). 636 o Brute Foce Attacks Against Password/Keys - This includes either 637 online or offline attacks where attempts are made repeatedly using 638 different keys/passwords until a match is found. While it is 639 impossible to make brute force attacks on keys completely 640 unsuccessful, proper design can make such attacks much harder to 641 succeed. For exmaple, the key length should be sufficiently long 642 so that covering the entire space of possible keys is improbable 643 using computational power expected to be available 10 years out or 644 more. Also, frequently changing the keys may render useless a 645 successful guess some time in the future, as those keys may no 646 longer be in use. 648 2.2. Threats Out of Scope 650 Threats from BYZANTINE sources -- faulty, misconfigured, or subverted 651 routers, i.e., legitimate participants in the routing protocol -- are 652 out of scope for this roadmap. Any of the attacks described in the 653 above section (Section 2.1) that may be levied by a BYZANTINE source 654 are therefore also out of scope. 656 In addition, these other attack actions are out of scope for this 657 work: 659 o SNIFFING - passive observation of route message contents in flight 660 o FALSIFICATION by BYZANTINE sources - unauthorized message content 661 by a legitimate authorized source. 662 o INTERFERENCE due to: 663 * NOT FORWARDING PACKETS - cannot be prevented with cryptographic 664 authentication 665 * DELAYING MESSAGES - cannot be prevented with cryptographic 666 authentication 667 * DENIAL OF RECEIPT - cannot be prevented with cryptographic 668 authentication 669 * UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR 670 working group 671 (http://www.ietf.org/html.charters/sidr-charter.html). 672 * Any other type of DoS attack. For example, a flood of traffic 673 that fills the link ahead of the router, so that the router is 674 rendered unusable and unreachable by valid packets is NOT an 675 attack that this work will address. Many other such examples 676 could be contrived. 678 3. Categorizing Routing Protocols 680 For the purpose of this security roadmap definition, we will 681 categorize the routing protocols into groups and have design teams 682 focus on the specification work within those groupings. It is 683 believed that the groupings will have like requirements for their 684 authentication mechanisms, and that reuse of authentication 685 mechanisms will be greatest within these grouping. The work items 686 placed on the roadmap will be defined and assigned based on these 687 categorizations. It is also hoped that, down the road in the Phase 2 688 work, we can create one KMP per category (if not for several 689 categories) so that the work can be easily leveraged by the various 690 Routing Protocol teams. KMPs are useful for allowing simple, 691 automated updates of the traffic keys used in a base protocol. KMPs 692 replace the need for humans, or OSS routines, to periodically replace 693 keys on running systems. It also removes the need for a chain of 694 manual keys to be chosen or configured. When configured properly, a 695 KMP will enforce the key freshness policy of two peers by keeping 696 track of the key lifetime and negotiating a new key at the defined 697 interval. 699 3.1. Category: Messaging Transaction Type 701 The first categorization defines four types of messaging transactions 702 used on the wire by the base Routing Protocol. They are: 704 One-to-One One peer router directly and intentionally delivers a 705 route update specifically to one other peer router. 706 Examples are BGP and LDP. Point-to-point modes of 707 both IS-IS and OSPF, when sent over both traditional 708 point-to-point links and when using multi-access 709 layers, may both also fall into this category. 710 [question to reviewers: Should we list all protocols 711 into these categories right here, or just give a few 712 examples?] 714 One-to-Many A router peers with multiple other routers on a single 715 network segment -- i.e. on link local -- such that it 716 creates and sends one route update message which is 717 intended for consumption by multiple peers. Examples 718 would be OSPF and IS-IS in their broadcast, non-point- 719 to-point modes. 721 Client-Server A client-server routing protocol is one where one 722 router initiates a request for route information from 723 another router, who then formulates a response to that 724 request, and replies with the requested data. 725 Examples are a BGP Route Reflector and [???? Are 726 there other examples? Is this the right example? Do 727 discovery protocols fall under this category?]. 729 Multicast Multicast protocols have unique security properties 730 because of the fact that they are inherently group- 731 based protocols and thus have group keying 732 requirements at the routing level where link-local 733 routing messages are multicasted. Also, at least in 734 the case of PIM-SM, some messages are are sent unicast 735 to a given peer(s), as is the case with router-close- 736 to-sender and the "Rendezvous Point". Some work for 737 application layer message security has been done in 738 the Multicast Security working group (MSEC, 739 http://www.ietf.org/html.charters/msec-charter.html) 740 and may be helpful to review, but is not directly 741 applicable. 743 [author's note: I think the above definitions need clean up. Routing 744 area folks, especially ADs, PLEASE suggest new text.] 746 3.2. Category: Peer vs. Group Keying 748 The second axis of categorization groups protocols by the keying 749 mechanism that will be necessary for distributing session keys to the 750 actual Routing Protocol transports. They are: 752 Peer keying One router sends the keying messages directly and only 753 to one other router, such that a one-to-one, unique 754 keying security association (SA) is established 755 between the two routers 757 Group Keying One router creates and distributes a single keying 758 message to multiple peers. In this case an group SA 759 will be established and used between multiple peers 760 simultaneously. Group keying exists for protocols 761 like OSPF [RFC2328] , and also for multicast protocols 762 like PIM-SM [RFC4601]. 764 3.3. Category: Update vs. Discovery Protocol 766 The third category group considers protocols by the contents of the 767 messages being exchanged in the Routing Protocol. They are: 769 Updates Messages that carry route advertisements or update 770 information from peer to peer 772 Discovery Messages sent as part of a policy, peer, or service 773 discovery process. These messages are normally 774 exchanged prior to any adjacency being formed, and 775 before any updates are sent. For example, end-point 776 discovery mechanisms are common in L2VPN and L3VPN 777 solutions. 779 [QUESTION TO REVIEWERS: is this really just what's described in 3.1 780 as "Client-Server" and/or "One-to-One"? Is there really such a 781 different in discovery protocols that they need their own category to 782 figure out how to authenticate them? Can someone provide a few 783 examples? 785 3.4. Security Characterization Vectors 787 A few more considerations must be made about the protocol and its use 788 when initially categorizing the protocol and scoping the 789 authentication work. 791 3.4.1. Internal vs. External Operation 793 The designers must consider whether the protocol is an internal 794 routing protocol or an external one, i.e. Does it primarily run 795 between peers within a single domain of control or between two 796 different domains of control? Some protocols may be used in both 797 cases, internally and externally, and as such various modes of 798 authentication operation may be required for the same protocol. 799 While it is preferred that all routing exchanges run with the utmost 800 security mechanisms enabled in all deployments, this exhortation is 801 greater for those protocols running on inter-domain point-to-point 802 links, and greatest for those on shared access link layers with 803 several different domains interchanging together, because the volume 804 of attackers are greater from the outside. Note however that the 805 consequences of internal attacks maybe no less severe -- in fact they 806 may be quite a bit more severe -- than an external attack. An 807 example of this internal versus external consideration is BGP which 808 has both EBGP and IBGP modes. Another example is a multicast 809 protocol where the neighbors are sometimes within a domain of control 810 and sometimes at an inter-domain exchange point. In the case of 811 PIM-SM running on an internal multi-access link, It would be 812 acceptable to give up some security to get some convenience by using 813 a group key between the peers on the link. On the other hand, in the 814 case of PIM-SM running over a multi-access link at a public exchange 815 point, operators may favor security over convenience by using unique 816 pair-wise keys for every peer. Designers must consider both modes of 817 operation and ensure the authentication mechanisms fit both. 819 Operators are encouraged to run cryptographic authentication on all 820 their adjacencies, but to work from the outside in, i.e. The EBGP 821 links are a higher priority than the IBGP links because they are 822 externally facing, and, as a result, more likely to be targeted in an 823 attack. 825 3.4.2. Unique versus Shared Keys 827 This section discusses security considerations regarding when it is 828 appropriate to use the same authentication key inputs for multiple 829 peers and when it is not. This is largely a debate of convenience 830 versus security. It is often the case that the best secured 831 mechanism is also the least convenient mechanism. For example, an 832 air gap between a host and the network absolutely prevents remote 833 attacks on the host, but having to copy and carry files using the 834 "sneaker net" is quite inconvenient and unscalable. 836 Operators have erred on the side of convenience when it comes to 837 securing routing protocols with cryptographic authentication. Many 838 do not use it at all. Some use it only on external links, but not on 839 internal links. Those that do use it often use the same key for all 840 peers across their entire network. It is common to see the same key 841 in use for years, and that being the same key that was entered when 842 authentication was originally configured, or the routing gear 843 deployed. 845 The goal for designers is to create authentication mechanisms that 846 are easy for the operators to deploy and manage, and still use unique 847 keys between peers (or small groups on multi-access links), and 848 within between sessions. Operators have the impression that they 849 NEED one key shared across the network, when in fact they do not. 850 What they need is the relative convenience they experience from 851 deploying cryptographic authentication with one (or few) key, 852 compared to the inconvenience they would experience if they deployed 853 the same authentication mechanism using unique pair-wise keys. An 854 example is BGP Route Reflectors. Here operators often use the same 855 authentication key between each client and the route reflector. The 856 roadmaps defined from this guidance document will allow for unique 857 keys to be used between each client and the peer, without sacrificing 858 much convenience. Designers should strive to deliver peer-wise 859 unique keying mechanisms with similar ease-of-deployment properties 860 as today's one-key method. 862 Operators must understand the consequences of using the same keys 863 across many peers. Unique keys are more secure than shared keys 864 because they reduce both the attack target size and the attack 865 consequence size. In this context, the attack target size represents 866 the number of unique routing exchanges across a network that an 867 attacker may be able to observe in order to gain security association 868 credentials, i.e. crack the keys. If a shared key is used across the 869 entire internal domain of control, then the attack target size is 870 very large. The larger the attack target, the easier it is for the 871 attacker to gain access to analysis data, and greater the volume of 872 analysis data he can access in a given time frame, both of which make 873 his job easier. Using the same key across the network makes the 874 attack vulnerability surface more penetrable than unique keys. 875 Consider also the attack consequence size, the amount of routing 876 adjacencies that can be negatively affected once a breach has 877 occurred, i.e. once the keys have been acquired by the attacker. 878 Again, if a shared key is used across the internal domain, then the 879 consequence size is the whole network. Ideally, unique key pairs 880 would be used for each adjacency. 882 In some cases designers may need to use shared keys in order to solve 883 the given problem space. For example, a multicast packet is sent 884 once but then observed and consumed by several routing neighbors. If 885 unique keys were used per neighbor, the benefit of multicast would be 886 erased because the casting peer would have to create a different 887 announcement packet/stream for each listening peer. Though this may 888 be desired and acceptable in some small amount of use cases, it is 889 not the norm. Shared group keys are an acceptable solution here, and 890 much work has been done already in this area (see MSEC working 891 group). 893 3.4.3. Out-of-Band vs. In-line Key Management 895 This section discusses the security and use case considerations for 896 keys placed on devices through out-of-band configurations versus 897 through one routing peer-to-peer key management protocol exchanges. 898 Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to 899 the Routing Protocol. Instead, we mean that the exchange occurs in- 900 line, over IP, between the two routing peers directly. In in-line 901 KMP the peers themselves handle the key and security association 902 negotiation between themselves directly, whereas in an out-of-band 903 system the keys are placed onto the device through some other 904 configuration or management method or interface. 906 An example of an out-of-band mechanism could be an administrator who 907 makes a remote management connection (e.g. using SSH) to a router and 908 manually enters the keying information -- like the algorithm, the 909 key(s), the lifetimes, etc. Another example could be an OSS system 910 which inputs the same information via a script over an SSH 911 connection, or by pushing configuration through some other management 912 connection, standard (Netconf-based) or proprietary. 914 The drawbacks of an out-of-band mechanism include: lack of scale- 915 ability, complexity and speed of changing if a breach is suspected. 916 For example, if an employee who had access to keys was was 917 terminated, or if a machine holding those keys was belived 918 compromised, then the system would be considered insecure and 919 vulnerable until new keys were defined by a human. Those keys then 920 need to be placed into the OSS system, manually, and the OSS system 921 then needs to push the change -- often during a very limited change 922 window -- into the relevant devices. If there are multiple 923 organizations involved in these connections, this process is greatly 924 complicated. 926 The benefits of out-of-band mechanism is that once the new keys/ 927 parameters are set in OSS system they can be pushed automatically to 928 all devices within the OSS's domain of control. Operators have 929 mechanisms in place for this already. In small environments with few 930 routers, a manual system is not difficult to employ. 932 We further define an in-line key exchange as using cryptographicly 933 protected identity verification, session key negotiation, and 934 security association parameter negotiation between the two routing 935 peers. The KMP between the two peers may also include the 936 negotiation of parameters, like algorithms, cryptographic inputs 937 (e.g. initialization vectors), key life-times, etc. 939 The benefits an in-line KMP are several. An in-line KMP results in 940 key(s) that are privately generated, and not recorded permanently 941 anywhere. Since the traffic keys used in a particular connection are 942 not a fixed part of a device configuration no steal-able data exists 943 anywhere else in the operator's systems which can be stolen, e.g. in 944 the case of a terminated or turned employee. If a server or other 945 data store is stolen or compromised, the thieves gain no access to 946 current traffic keys. They may gain access to key derivation 947 material, like a PSK, but not current traffic keys in use. In this 948 example, these PSKs can be updated into the device configurations 949 (either manually or through an OSS) without bouncing or impacting the 950 existing session at all. In the case of using raw assymetric keys or 951 certificates, instead of PSKs, the data theft would likely not even 952 result in any compromise, as the key pairs would have been generated 953 on the routers, and never leave those routers. In such a case no 954 changes are needed on the routers; the connections will continue to 955 be secure, uncompromised. Additionally, with a KMP regular re-keys 956 operations occur without any operator involvement or oversight. This 957 keeps keys fresh. 959 The drawbacks to using a KMP are few. First, a KMP requires more 960 cryptographic processing for the router at the very beginning of a 961 connection. This will add some minor start-up time to connection 962 establishment versus a purely manual key approach. Once a connection 963 with traffic keys have been established via a KMP, the performance is 964 the same in the KMP and the out-of-band case. KMPs also add another 965 layer of protocol and configuration complexity which can fail or be 966 misconfigured. This was more of an issue when these KMPs were first 967 deployed, but less so as these implementaitons and operational 968 experience with them has matured. 970 The desired end goal is in-line KMPs. 972 4. The Roadmap 974 4.1. Work Phases on any Particular Protocol 976 The desired endstate for the KARP work contains several items. 977 First, the people desiring to deploy securely authenticated and 978 integrity validated packets between routing peers have the tools 979 specified, implemented and shipping in order to deploy. These tools 980 should be fairly simple to implement, and not more complex than the 981 security mechanisms to which the operators are already accustomed. 982 (Examples of security mechanisms to which router operators are 983 accustomed include: the use of assymetric keys for authentication in 984 SSH for router configuration, the use of pre-shared keys (PSKs) in 985 TCP MD5 for BGP protection, the use of self-signed certificates for 986 HTTPS access to device Web-based user interfaces, the use of strongly 987 constructed passwords and/or identity tokens for user identification 988 when logging into routers and management systems.) While the tools 989 that we intend to specify may not be able to stop a deployment from 990 using "foobar" as an input key for every device across their entire 991 routing domain, we intend to make a solid, modern security system 992 that is not too much more difficult than that. In other words, 993 simplicity and deployability are keys to success. The Routing 994 Protocols will specify modern cryptographic algorithms and security 995 mechanisms. Routing peers will be able to employ unique, pair-wise 996 keys per peering instance, with reasonable key lifetimes, and 997 updating those keys on a somewhat regular basis will be operationally 998 easy, causing no service interruption. 1000 Achieving the above described end-state using manual keys may only be 1001 pragmatic in very small deployments. In larger deployments, this end 1002 state will be much more operationally difficult to reach with only 1003 manual keys. Thus, there will be a need for key life cycle 1004 management, in the form of a key management protocol, or KMP. We 1005 expect that the two forms, manual key usage and KMP usage, will co- 1006 exist in the real world. For example, a provider's edge router at a 1007 public exchange peering point will want to use a KMP for ensuring 1008 unique and fresh keys with external peers, while a manual key may be 1009 used between a provider's access edge router and each of the same 1010 provider's customer premise routers with which it peers. 1012 In accordance with the desired end state just described, we define 1013 two main work phases for each Routing Protocol: 1015 1. Enhance the Routing Protocol's current authentication mechanism. 1016 This work involves enhancing a Routing Protocol's current 1017 security mechanisms in order to achieve a consistent, modern 1018 level of security functionality within its existing keying 1019 framework. It is understood and accepted that the existing 1020 keying frameworks are largely based on manual keys. Since many 1021 operators have already built operational support systems (OSS) 1022 around these manual key implementations, there is some automation 1023 available for an operator to leverage in that way, if the 1024 underlying mechanisms are themselves secure. In this phase, we 1025 explicitly exclude embedding or creating a KMP. A list of the 1026 requirements for Phase 1 work are below in the section 1027 "Requirements for Phase 1 Routing Protocols' Security Updates 1028 (Section 4.2). 1030 2. Develop an automated keying framework. The second phase will 1031 focus on the development of an automated keying framework to 1032 faciliate unique pair-wise (or perhaps group-wise, where 1033 applicable) keys per peering instance. This involves the use of 1034 a KMP. A KMP is helpful because it negotiates unique, pair wise, 1035 random keys without administrator involvement. It also 1036 negotiates several of the SA parameters required for the secure 1037 connection, including key life times. It keeps track of those 1038 lifetimes using counters, and negotiates new keys and parameters 1039 before they expire, again, without administrator interaction. 1040 Additionally, in the event of a breach, changing the KMP key will 1041 immediately cause a rekey to occur for the Traffic Key, and those 1042 new Traffic Keys will be installed and used in the current 1043 connection. In summary, a KMP provides a protected channel 1044 between the peers through which they can negotiate and pass 1045 important data required to exchange proof of key identifiers, 1046 derive Traffic Keys, determine re-keying, synchronize their 1047 keying state, signal various keying events, notify with error 1048 messages, etc. To address brute force attacks [RFC3562] 1049 recommends a key management practice to minimize the possibility 1050 of successful attack-- frequent key rotation, limited key 1051 sharing, key length restrictions, etc. Advances in computational 1052 power due to Moore's law are making that management burden 1053 untenable-- keys must be of a size and composition that makes 1054 configuration and maintance difficult or keys must be rotated 1055 with an unreasonable frequency. A KMP will help immensely with 1056 this growing problem. 1058 The framework for any one Routing Protocol will fall under, and 1059 be able to leverage, the generic framework described below in 1060 section Section 4.3. 1062 4.2. Requirements for Phase 1 Routing Protocols' Security Update 1064 Here is a proposed list of requirements that SHOULD be addressed by 1065 Phase 1 (according to "1." above) security updates to Routing 1066 Protocols [to be reviewed after -01 is released]: 1068 1. Clear definitions of which elements of the transmission (frame, 1069 packet, segment, etc.) are protected by the authentication 1070 mechanism 1071 2. Strong algorithms, and defined and accepted by the security 1072 community, MUST be specified. The option should use algorithms 1073 considered accepted by the security community, which are 1074 considered appropriately safe. The use of non-standard or 1075 unpublished algorithms SHOULD BE avoided. 1076 3. Algorithm agility for the cryptograhpic algorithms used in the 1077 authentication MUST be specified, i.e. more than one algorithm 1078 MUST be specified and it MUST be clear how new algorithms MAY be 1079 specified and used within the protocol. This requirement exists 1080 in case one algorithm gets broken suddenly. Research to 1081 identify weakness in algorithms is constant. Breaking a cipher 1082 isn't a matter of if, but when it will occur. t's highly 1083 unlikely that two different algorithms will be broken 1084 simultaneously. So, if two are supported, and one gets broken, 1085 we can use the other until we get a new one in place. Having 1086 the ability within the protocol specification to support such an 1087 event, having algorithm agility, is essential. Mandating two 1088 algorithms provides both a redundancy, and a mechanism for 1089 enacting that redundancy when needed. 1090 4. Secure use of simple PSKs, offering both operational convenience 1091 as well as building something of a fence around stupidity, MUST 1092 be specified. 1093 5. Inter-connection replay protection. Packets captured from one 1094 connection MUST NOT be able to be re-sent and accepted during a 1095 later connection. 1097 6. Intra-connection replay protection. Packets captured during a 1098 connection MUST NOT be able to be re-sent and accepted during 1099 that same connection, to deal with long-lived connections. 1100 7. A change of security parameters REQUIRES, and even forces, a 1101 change of session traffic keys 1102 8. Intra-connection re-keying which occurs without a break or 1103 interruption to the current peering session, and, if possible, 1104 without data loss, MUST be specified. 1105 9. Efficient re-keying SHOULD be provided. The specificaion SHOULD 1106 support rekeying during a connection without the need to expend 1107 undue computational resources. In particular, the specification 1108 SHOULD avoid the need to try/compute multiple keys on a given 1109 packet. 1110 10. Prevent DoS attacks as those described as in-scope in the 1111 threats section Section 2.1 above. 1112 11. Default mechanisms and algorithms specified and defined as 1113 REQUIRED for all implementations 1114 12. Manual keying MUST be supported. 1115 13. Convergence times of the Routing Protocols SHOULD NOT be 1116 materially affected. Materially here is defined as anything 1117 greater than a 5% convergence time increase. Note that 1118 convergence is different than boot time. Also note that 1119 convergence time has a lot to do with the speed of processors 1120 used on individual routing peers, and this increases by Moore's 1121 law over time. Therefore, this requirement should be considered 1122 only in terms of total number of messages that must be 1123 exchanged, and less for the computational intensity of 1124 processing any one message. 1125 14. The changes or addition of security mechanisms SHOULD NOT cause 1126 a refresh of route updates or cause additional route updates to 1127 be generated 1128 15. Architecture of the specification MUST consider and allow for 1129 future use of a KMP. 1131 4.3. Common Framework 1133 Each of the categories of routing protocols above will require unique 1134 designs for authenticating and integrity checking their protocols. 1135 However, a single underlying framework for delivering automatic 1136 keying to those solutions will be pursued. Providing such a single 1137 framework will significantly reduce the complexity of each step of 1138 the overall roadmap. For example, if each Routing Protocol needed to 1139 define it's own key management protocol this would balloon the total 1140 amount of different sockets that are needed to be opened and 1141 processes that are needed to be simultaneously running on an 1142 implementation. It would also significantly increase the run-time 1143 complexity and memory requirements of such systems running multiple 1144 Routing Protocols, causing perhaps slower performance of such 1145 systems. However, if we can land on a very small set (perhaps one or 1146 two) of automatic key management protocols, KMPs, that the various 1147 Routing Protocols can use, then we can reduce this implementation and 1148 run-time complexity. We can also decrease the total amount of time 1149 implementers need to deliver the KMPs for the Routing Protocols that 1150 will provide better threat protection. 1152 The components for the framework are listed here, and described 1153 below: 1155 o Routing Protocol security mechanism 1156 o KMP 1157 o KeyStore 1158 o Traffic Key 1159 o RoutingProtocol-to-KMP API 1160 o RoutingProtocol-to-KeyStore API 1161 o KMP-to-KeyStore API 1162 o Common Routing Protocol mechanisms 1163 o Identifiers 1164 o Proof of identity 1165 o Profiles 1167 The framework is modularized for how keys and security association 1168 (SA) parameters generally get passed from a KMP to a transport 1169 protocol. It contains three main blocks and APIs. 1171 +------------+ +--------------------+ 1172 | | | | Check +-----------+ 1173 | Identifier +-->| +---------->| | 1174 | | | KMP Function | | Identity | 1175 +----------- + | |<----------+ Proof | 1176 | | Approve | | 1177 +-+--------------+---+ +-----------+ 1178 | | 1179 KMP-to-KeyStore | | 1180 API | | 1181 \|/ | 1182 +-------+-------+ | 1183 | | | KMP-to-RoutingProtocol 1184 | | | API 1185 | KeyStore | | 1186 | | | 1187 +-------+-------+ | 1188 | | 1189 | | 1190 KeyStore-to- | | 1191 RoutingProtocol API | | 1192 | \|/ 1193 +--------------------------+-------------+ 1194 | | | 1195 | \|/ Common RtgProto | 1196 | +-------+-------+ Authentication | 1197 | | | Mechanisms | 1198 +---| Traffic |-----+--------------+ 1199 | | Key(s) | | 1200 | | | | 1201 | +---------------+ Specific | 1202 | RoutingProtocol | 1203 | Authentication | 1204 | Security | 1205 | Mechanism | 1206 +----------------------------------------+ 1208 Figure 1: Automatic Key Management Framework 1210 Each element of the framework is described here: 1212 o Routing Protocol - Routing protocol security mechanism - In each 1213 case, the Routing Protocol will contain a mechanism for using 1214 session keys in their security option. When the Routing 1215 Protocol uses a transport substrate, e.g. the way BGP, LDP 1216 and MSDP use TCP, then this applies to the security mechanism 1217 the includes that substrate. 1219 o KeyStore - Each implementation will also contain a protocol 1220 independent mechanism for storing keys, called KeyStore. The 1221 KeyStore will have multiple different logical containers, one 1222 container for each session key that any given Routing 1223 Protocol will need. Keys stored here may be a Peer Key or a 1224 Traffic Key. There may also be associated parameters as 1225 required by the SA for any given Routing Protocol. 1227 o Peer Key A key used between peers from which a traffic key is 1228 derived. An example is a PSK. 1230 o Traffic Key The actual key used on each packet of a message. 1231 This key may be derived from the key existing in the 1232 KeyStore. This will depend on whether the key in KeyStore 1233 was a manual PSK for the peers, or whether a connection-aware 1234 KMP created the key. Further, it will be connection 1235 specific, so as to provide inter- and intra-connection replay 1236 protection. 1238 o RoutingProtocol-KeyStore API - There will be an API for Routing 1239 Protocol to retrieve (or receive; it could be a push or a 1240 pull) the keys from the KeyStore. This will enable 1241 implementers to reuse the same API calls for all their 1242 Routing Protocols. The API will necessarily include facility 1243 to retrieve other SA parameters required for the construction 1244 of the Routing Protocol's packets, like key IDs or key 1245 lifetimes, etc. 1247 o KMP - There will be an automated key management protocol, KMP. 1248 This KMP will run between the peers. The KMP serves as a 1249 protected channel between the peers, through which they can 1250 negotiate and pass important data required to exchange proof 1251 of key identifiers, derive session keys, determine re-keying, 1252 synchronize their keying state, signal various keying events, 1253 notify with error messages, etc. As an analogy, in the IPsec 1254 protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306 1255 [RFC4306]) IKEv2 is the KMP that runs between the two peers, 1256 while AH and ESP are two different base protocols that take 1257 session keys from IKEv2 and use them in their transmissions. 1258 In the analogy, the Routing Protocol, say BGP and LDP, are 1259 analogous to ESP and AH, while the KMP is analogous to IKEv2 1260 itself. 1262 o RoutingProtocol-KMP API - There will be an API for the Routing 1263 Protocol to request a session key of the KMP, and be notified 1264 when the keys are available for it. The API will also 1265 contain a mechanism for the KMP to notify the Routing 1266 Protocol that there are new keys that it must now use, even 1267 if it didn't request those keys. The API will also include a 1268 mechanism for the KMP to receive requests for session keys 1269 and other parameters from the routing protocol. The KMP will 1270 also be aware of the various Routing Protocols and each of 1271 their unique parameters that need to be negotiated and 1272 returned. 1274 o KMP-KeyStore API - There will be an API for the KMP to place 1275 keys and parameters into the KeyStore after their negotiation 1276 and derivation with the other peer. This will enable the 1277 implementers to reuse the same calls for multiple KMPs that 1278 may be needed to address the various categories of Routing 1279 Protocols as described in the section definingcategories 1280 (Section 3). 1282 [after writing this all up, I'm not sure we really need the key_store 1283 in the middle. As long as we standardize fully all the calls needed 1284 from any Routing Protocol to any KMP, then there can be a generic 1285 hand-down function from the KMP to the Routing Protocol when the key 1286 and parameters are ready. Let's sleep on it.] 1288 [will need state machines and function calls for these APIs, as one 1289 of the work items. In essence, there is a need for a core team to 1290 develop the APIs out completely in order for the Routing Protocol 1291 teams to use them. Need to get this team going asap.] 1293 o Identifiers - A KMP is fed by identities. The identities are 1294 text strings used by the peers to indicate to each other that 1295 each are known to the other, and authorized to establish 1296 connections. Those identities must be represented in some 1297 standard string format, e.g. an IP address -- either v4 or 1298 v6, an FQDN, an RFC 822 email address, a Common Name [RFC 1299 PKI], etc. Note that even though routers do not normally 1300 have email addresses, one could use an RFC 822 email address 1301 string as a formatted identifier for a router. They would do 1302 so simply by putting the router's reference number or name- 1303 code as the "NAME" part of the address, left of the "@" 1304 symbol. They would then place some locational context in the 1305 "DOMAIN" part of the string, right of the "@" symbol. An 1306 example would be "rtr0210@sf.ca.us.company.com". This 1307 document does not suggest this string value at all. Instead, 1308 the concept is used only to clarify that the type of string 1309 employed does not matter. It also does not matter what 1310 specific text you chose to place in that string type. It 1311 only matters that the type of string -- and it's format -- 1312 must be agreed upon by the two endpoints. Further, the 1313 string can be used as an identifier in this context, even if 1314 the string is not actually provisioned in it's source domain. 1315 For example, the email address "rtr0210@sf.ca.us.company.com" 1316 may not actually exist as an email address in that domain, 1317 but that string of characters may still be used as an 1318 identifier type(s) in the routing protocol security context. 1319 What is important is that the community decide on a small but 1320 flexible set of Identifiers they will all support, and that 1321 they decide on the exact format of those string. The formats 1322 that will be used must be standardized and must be sensible 1323 for the routing infrastructure. 1325 o Identity Proof - Once the form of identity is decided, then 1326 there must be a cryptographic proof of that identity, that 1327 the peer really is who they assert themselves to be. Proof 1328 of identity can be arranged between the peers in a few ways, 1329 for example pre-shared keys, raw assymetric keys, or a more 1330 user-friendly representation of assymetric keys, like a 1331 certificate. Certificates can be used in a way requiring no 1332 additional supporting systems -- e.g. public keys for each 1333 peer can be maintained locally for verification upon contact. 1334 Certificate management can be made more simple and scalable 1335 with the use minor additional supporting systems, as is the 1336 case with self-signed certificates and a flat file list of 1337 "approved thumbprints". Self-signed certificates will have 1338 somewhat lower security properties than Certificate Authority 1339 signed certificates [RFC Certs]. The use of these different 1340 identity proofs vary in ease of deployment, ease of ongoing 1341 management, startup effort, ongoing effort and management, 1342 security strength, and consequences from loss of secrets from 1343 one part of the system to the rest of the system. For 1344 example, they differ in resistance to a security breach, and 1345 the effort required to remediate the whole system in the 1346 event of such a breach. The point here is that there are 1347 options, many of which are quite simple to employ and deploy. 1349 o Profiles - Once the KMP, Identifiers and Proofs mechanisms are 1350 converged upon, they must be clearly profiled for each 1351 Routing Protocol, so that implementors and deployers alike 1352 understand the different pieces of the solution, and can have 1353 similar configurations and interoperability across multiple 1354 vendors' devices, so as to reduce management difficulty. The 1355 profiles SHOULD also provide guidance on when to use which 1356 various combinations of options. This will, again, simplify 1357 use and interoperability. 1359 In addition to other business, administrative, and operational terms 1360 they must already exchange prior to forming first adjacencies, it is 1361 assumed that two parties deploying message authentication on their 1362 routing protocol will also need to decide upon acceptable security 1363 parameters for the connection. This will include the form and 1364 content of the identity each use to represent the other. It will 1365 also include the type of keys to be used, e.g. PSK, raw assymetric 1366 keys, certificate. And it will include the acceptable cryptographic 1367 algorithms, or algorithm suite. This agreement is necessary in order 1368 for each to properly configure the connection on their respective 1369 devices. The manner in which they agree upon and exchange this 1370 policy information is normally via phone call or written exchange, 1371 and is outside the scope of the KARP effort, but assumed to have 1372 occured. We take as a given that each party knows the identity types 1373 and values, key types and values, and acceptable cryptographic 1374 algorithms for both their own device and the peer that form the 1375 security policy for configuration on their device. 1377 Common Mechanisms - In as much as they exist, the framework will 1378 capture mechanisms that can be used commonly not only within a 1379 particular category of Routing Protocol and Routing Protocol to KMP, 1380 but also between Routing Protocol categories. Again, the goal here 1381 is simplifying the implementations and runtime code and resource 1382 requirements. There is also a goal here of favoring well vetted, 1383 reviewed, operationally proven security mechanisms over newly brewed 1384 mechanisms that are less well tried in the wild. 1386 4.4. Work Items Per Routing Protocol 1388 Each Routing Protocol will have a team (the [Routing_Protocol]-KARP 1389 team) working on incrementally improving their Routing Protocol's 1390 security, These teams will have the following main work items: 1392 PHASE 1: 1394 Characterize the RP 1395 Assess the Routing Protocol to see what authentication mechanisms 1396 it has today. Does it needs significant improvement to its 1397 existing mechanisms or not? This will include determining if 1398 modern, strong security algorithms and parameters are present. 1400 Define Optimal State 1401 List the requirements for the Routing Protocol's session key usage 1402 and format to contain to modern, strong security algorithms and 1403 mechanisms, per the Requirements (Section 4.2) section above. The 1404 goal here is to determine what is needed for they Routing Protocol 1405 alone to be used securely with at least manual keys. 1407 Gap Analysis 1408 Enumerate the requirements for this protocol to move from its 1409 current security state, the first bullet, to its optimal state, as 1410 listed just above. 1412 Transition and Deployment Considerations Document the operational 1413 transition plan for moving from the old to the new security 1414 mechanism. Will adjacencies need to bounce? What new elements/ 1415 servers/services in the infrastructure will be required? What is 1416 an example work flow that an operator will take? The best 1417 possible case is if the adjacency does not break, but this may not 1418 always be possible. 1420 Define, Assign, Design 1421 Create a deliverables list of the design and specification work, 1422 with milestones. Define owners. Release a document(s) 1424 PHASE 2: 1426 KMP Analysis 1427 Review requirements for KMPs [RFC????]. Identify any nuances for 1428 this particular protocol's needs and its use cases for KMP. List 1429 the requirements that this Routing Protocol has for being able to 1430 be use in conjunctions with a KMP. Define the optimal state. 1432 Gap Analysis 1433 Enumerate the requirements for this protocol to move from its 1434 current security state to its optimal state. 1436 Define, Assign, Design 1437 Create a deliverabels list of the design and specification work, 1438 with miletsones. Define owners. Do the design and document work 1439 for a KMP to be able to generate the Routing Protocol's session 1440 keys for the packets on the wire. These will be the arguments 1441 passed in the API to the KMP in order to bootstrap the session 1442 keys to the Routing Protocol. 1444 There will also be a team formed to work on the base framework 1445 mechanisms for each of the main categories, i.e. the blocks and API's 1446 represented in figure 1 (Figure 1). 1448 4.5. Protocols in Categories 1450 This section groups the Routing Protocols into like categories, 1451 according to attributes set forth in Categories Section (Section 3). 1452 Each group will have a design team tasked with improving the security 1453 of the Routing Protocol mechanisms and defining the KMP requirements 1454 for their group, then rolling both into a roadmap document upon which 1455 they will execute. 1457 BGP, LDP and MSDP 1458 The Routing Protocol's that fall into the category of the one-to- 1459 one peering messages, and will use peer keying protocols, AND are 1460 all transmitted over TCP include BGP RFC 4271 [RFC4271], LDP 1461 [RFC5036] and MSDP [RFC3618]. A team will work on one mechanism 1462 to cover these three protocols. Much of the work on the Routing 1463 Protocol update for its existing authentication mechanism is 1464 already occuring in the TCPM Working Group, on the TCP-AO 1465 [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its 1466 cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto]. The 1467 exception is the mode where LDP is used directly on the LAN 1468 [RFC????]. The work for this may go into the Group keying 1469 category (w/ OSPF) mentioned below. 1471 OSPF, ISIS, and RIP 1472 The Routing Protocols that fall into the category Group keying 1473 with one-to-many peering messages includes OSPF [RFC2328], ISIS 1474 [RFC1195] and RIP [RFC2453]. Not surprisingly, all these routing 1475 protocols have two other things in common. First, they are run 1476 on a combination of the OSI datalink layer 2, and the OSI network 1477 layer 3. By this we mean that they have a component of how the 1478 routing protocol works which is specified in Layer 2 as well as 1479 in Layer 3. Second, they are all internal gateway protocols, or 1480 IGPs. The keying mechanisms and use will be much more 1481 complicated to define for these than for a one-to-one messaging 1482 protocol. 1484 BFD 1485 Because it is less of a routing protocol, per se, and more of a 1486 peer aliveness detection mechanism, Bidirectional Forwarding 1487 Detection (BFD) [RFC????] will have its own team. 1489 RSVP [RFC????], RSVP-TE [RFC????], and PCE 1490 These three protocols will be handled together. [what more 1491 characterisation should we give here? Routing AD's, provide text 1492 pls?] 1494 PIM-SM and PIM-DM 1495 Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM 1496 [RFC3973] will be handled together. PIM-SM multicasts routing 1497 information (Hello, Join/Prune, Assert) on a link-local basis, 1498 using a defined multicast address. In addition, it specifies 1499 unicast communication for exchange of information (Register, 1500 Register-Stop) between the router closest to a group sender and 1501 the "rendezvous point" (RP). The RP is typically not "on-link" 1502 for a particular router. While much work has been done on 1503 multicast security for application-layer groups, little has been 1504 done to address the problem of managing hundreds or thousands of 1505 small one-to-many groups with link-local scope. Such an 1506 authentication mechanism should be considered along with the 1507 router-to-Rendezvous Point authentication mechanism. The most 1508 important issue is ensuring that only the "authorized neighbors" 1509 get the keys for (S,G), so that rogue routers cannot participate 1510 in the exchanges. Another issue is that some of the 1511 communication may occur intra-domain, e.g. the link-local 1512 messages in an enterprise, while others for the same (*,G) may 1513 occur inter-domain, e.g. the router-to-Rendezvous Point messges 1514 may be from one enterprise's router to another. One possible 1515 solution proposes a region-wide "master" key server (possibly 1516 replicated), and one "local" key server per speaking router. 1517 There is no issue with propagating the messages outside the link, 1518 because link-local messages, by definition, are not forwarded. 1519 This solution is offered only as an example of how work may 1520 progress; further discussion should occur in this work team. 1521 Specification of a link-local protection mechanism for PIM-SM 1522 occurred in RFC 4601 [RFC4601], and this work is being updated in 1523 PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal]. However, the KMP 1524 part is completely unspecified, and will require work outside the 1525 expertise of the PIM working group to accomplish, which is why 1526 this roadmap is being created. 1528 These protocols are deemed out-of-scope for this current iteration of 1529 the work roadmap. Once all of the protocols listed above have had 1530 their work completed, or are clearly within site of completion, then 1531 the community will revisit the need and interest for working on 1532 these: 1534 o MANET 1535 o FORCES 1537 [need text from routing ADs on why these are out of scope] 1539 4.6. Priorites 1541 Resources from both the routing area and the security area will be 1542 applied to work on these problem spaces as quickly as possible. 1543 Realizing that such resources are far from unlimited, a rank order 1544 priority for addressing the work of incrementally securing these 1545 groups of routing protocols is provided: 1547 o Priority 1 - BGP / LDP / MSDP - almost done with Phase 1 on these, 1548 via TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] . 1549 o Priority 2 - PIM-SM 1550 o Priority 3 - OSPF / ISIS / RIP 1551 o Priority 4 - BFD 1552 o Priority 5 - RSVP and RSVP-TE 1554 By far the most important group is the Priority 1 group as these are 1555 the protocols used on the most public and exposed segments of the 1556 networks, at the peering points between operators and between 1557 operators and their customers. BFD, as a detection mechanism 1558 underlying the Priority 1 protocols is therefore second. 1560 5. Security Considerations 1562 As mentioned in the Introduction , RFC4948 identifies additional 1563 steps needed to achieve the overall goal of improving the security of 1564 the core routing infrastructure. Those include validation of route 1565 origin announcements, path validation, cleaning up the IRR databases 1566 for accuracy, and operational security practicies that prevent 1567 routers from being compromised devices. The KARP work is but one 1568 step in a necessary system of security improvements. 1570 The security of cryptographic-based systems depends on both the 1571 strength of the cryptographic algorithms chosen and the strength of 1572 the keys used with those algorithms. The security also depends on 1573 the engineering of the protocol used by the system to ensure that 1574 there are no non-cryptographic ways to bypass the security of the 1575 overall system. 1577 Care should also be taken to ensure that the selected key is 1578 unpredictable, avoiding any keys known to be weak for the algorithm 1579 in use. [RFC4086] contains helpful information on both key 1580 generation techniques and cryptographic randomness. 1582 In addition to using a stong key/PSK of appropriate length and 1583 randomness, deployers of KARP protocols SHOULD use different keys 1584 between different routing peers whenever operationally possible. 1585 RFC3562 [RFC3562] provides some very sound guidance. It was meant 1586 specifically for the use of TCP MD5 for BGP, but it is more or less 1587 applicable to Routing Protocol authentication work that would result 1588 from KARP. It states three main points: (1) key lengths SHOULD be 1589 between 12 and 24 bytes (this will vary depending on the MAC/KDF in 1590 use), with larger keys having effectively zero additional 1591 computational costs when compared to shorter keys, (2) key sharing 1592 SHOULD be limited so that keys aren't shared among multiple BGP 1593 peering arrangements, and (3) Keys SHOULD be changed at least every 1594 90 days (this could be longer for stronger MAC algorithms, but it is 1595 generally a wise idea). 1597 This is especially true when the Routing Protocol takes a static 1598 Traffic Key as opposed to a Traffic Key derived per-connection by a 1599 KDF. The burdon for doing so is understandable much higher than for 1600 using the same static Traffic Key across all peering routers. This 1601 is why use of a KMP network-wide increases peer-wise security so 1602 greatly, because now each set of peers can enjoys a unique Traffic 1603 Key, and if an attacker sitting between two routers learns or guesses 1604 the Traffic Key for that connection, she doesn't gain access to all 1605 the other connections as well. 1607 However, whenever using manual keys, it is best to design a system 1608 where a given PSK will be used in a KDF, mixed with connection 1609 specific material, in order to generate session unique -- and 1610 therefore peer-wise -- Traffic Keys. Doing so has the following 1611 advantages: the Traffic Keys used in the per-message MAC operation 1612 are peer-wise unique, it provides inter-connection replay protection, 1613 and, if the per-message MAC covers some connection counter, intra- 1614 connection replay protection. 1616 Note that in the composition of certain key derivation functions 1617 (e.g. KDF_AES_128_CMAC, as used in TCP-AO [I-D.ao-crypto]), the 1618 pseudorandom function (PRF) used in the KDF may require a key of a 1619 certain fixed size as an input. For example, AES_128_CMAC requires a 1620 128 bit (16 byte) key as the seed. However, for convenience to the 1621 administrators/deployers, a specification may not want to force the 1622 deployer to enter a PSK of exactly 16 bytes. Instead, a 1623 specification may call for a sub-key routine that could handle a 1624 variable length PSK, one that might be less than 16 bytes (see 1625 [RFC4615], section 3, as an example). That sub-key routine would act 1626 as a key extractor to derive a second key of exactly the required 1627 length, and thus suitable as a seed to the PRF. This does NOT mean 1628 that administrators are safe to use weak keys. Administrators are 1629 encouraged to follow [RFC4086] as listed above. We simply attempted 1630 to "put a fence around stupidity", in as much as possible. 1632 A better option, from a security perspective, is to use some 1633 representation of a device-specific assymetric key pair as the 1634 identity proof, as described in Section 3.4.2. 1636 When it comes time for the KARP WG to design the re-usable model for 1637 a KMP, The Guidelines for Cryptographic Key Management, RFC4107 1638 [RFC4107] should be will be consulted. 1640 [[QUESTION TO REVIEWERS: it may be worthwhile to pull the last few 1641 paragraphs, along with some guidance along the same lines, into 1642 section 4, in a new sub-section with a title something like "Security 1643 tips for KARP design teams working on Routing Protocol reviews and 1644 updates". Or maybe even into its own info document, "Security 1645 Guidelines for KARP Design Teams".Thoughts?]] 1647 The mechanisms that will be defined under this roadmap aim to improve 1648 the security, better protect against more threats, and provider far 1649 greater operational efficiencies than the state of things at the time 1650 of this writing. However, none of these changes will improve 1651 Internet security unless they are implemented and deployed. Other 1652 influences must be brought to bare upon operators and organizations 1653 to create incentives for deployment. Such incentives may take the 1654 form of PCI-like industry compliance/certifications, well advertised 1655 BCPs profiling the use of this roadmap's output, end-user demand or 1656 insistance. 1658 6. IANA Considerations 1660 This document has no actions for IANA. 1662 7. Acknowledgements 1664 The outline for this draft was created from discussions and 1665 agreements with Routing AD's Ross Callon and Dave Ward, Security AD's 1666 Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory 1667 Lebovitz. 1669 Mat Ford and Bill Atwood provided reviews to -00. 1671 Danny McPherson provided an extremely detailed and useful review of 1672 -01. 1674 8. Change History (RFC Editor: Delete Before Publishing) 1676 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 1677 Please remove before publishing as RFC.] 1678 kmart-00-00 original rough rough rough draft for review by routing 1679 and security AD's 1681 kmart-00- original submission 1683 o adds new category = multicast protocols in category section and 1684 mentions mcast in group keying category description. 1685 o add a lot of references where they did not exist before, or where 1686 there were only place holders. Still more work needed on this. 1687 o abstract filled in 1688 o changed from standards track to informational (this was an 1689 oversight in last draft). 1690 o filled out threats section with detailed descriptions, and linked 1691 to RPsec threats RFC 1692 o made ascii art for the basic KMP framework 1693 o added section on internal versus external peering and the 1694 requirements decisions for them 1695 o added security characterization section in sect 2, added sections 1696 discussing internal vs external protocols, shared vs unique keys, 1697 oob vs in-band keying 1698 o incorporates all D Ward's feedback from his initial skim of the 1699 document. 1701 kmart-01 - 1703 o Updated framework (Figure 1) diagram to include all listed and 1704 described elements. Needs review and honing. Gregory Lebovitz 1705 (GL). 1706 o Added comment in protocols (Section 4.5) section that much of the 1707 BGP/LDP Phase 1 work is already being done in tcp-ao and ao- 1708 crypto. GL. 1709 o Updated Scope making the 2 work phases more clear earlier in the 1710 document. GL. 1711 o Broke work items (Section 4.4) section into two Phases, 1 for 1712 manual key update, and second for KMP work. GL. 1713 o Re-org'd doc. Brought Threats (Section 2) section out into its 1714 own top-level section. Did same with Categorization (Section 3) 1715 section, leaving Roadmap section more focused. Moved ToDo list 1716 and Change History to end of doc, after Acknowledgements. GL. 1717 o added new sect 2.3 (Section 4.1) on main roadmap phases. Previous 1718 section Common Framework (Section 4.3) moved to 2.4. Tim Polk 1719 (TP). 1720 o Added Section 2.3.1 Requirements for Phase 1 Routing Protocols' 1721 Security Update (Section 4.2). This provides a nice starter set 1722 of requirements for any work team. GL. 1723 o Filled out text for Out vs In-band Key Mgmt (Section 3.4.3) 1724 section, significantly. Changed the term from "in-band" to "in- 1725 line". 1727 o Section Threats (Section 2) Clarified DoS threats in and out of 1728 scope better. We are not preventing all DoS attacks. Just those 1729 we can reasonably via authentication. TP. 1730 o Sect In-band vs Out-of-Band (Section 3.4.3)clarified that In-band 1731 does not mean in-band to Routing Protocol, but rather over IP 1732 between the Routing Protocols, rather than pushed down by some 1733 external management entity. TP. 1734 o In roadmap (Section 3) section, added "it is also hoped that we 1735 can create one kmp per category..." Also explained value of a 1736 KMP. TP. 1737 o Added "operators" to audience (Section 1.6) list. Matt Ford (MF). 1738 o Described why BGP (and LDP) security is not deployed very often. 1739 Added this Scope (Section 1.3) section, point 4. If mechanisms 1740 aren't being deployed, why is that? What, if anything, could be 1741 done to improve deployment? Tried to address these. Need 1742 references (see To Do list below). MF. 1743 o Added some text to security section to address this from MF: say 1744 something here about the limitations of this approach, if any - 1745 and refer back to the need for other pieces of the puzzle. May 1746 need more work. 1747 o Cleaned up text for multicast part of Message Type (Section 3.1) 1748 section and Protocols (Section 4.5) section, clarifying PIM's two 1749 message types, mcast and unicast, in both places. Bill Atwood 1750 (BA). 1751 o In section Protocols (Section 4.5), added references to 4601 and 1752 PIM-SM-LINKLOCAL. BA. 1753 o Editorial changes pointed out various folks. 1755 kmart-02 - 1757 o Re-submitted due to expiration. Text did not change. Substantive 1758 update coming shortly. 1759 o 1760 o 1762 kmar-03 - 1764 o changed "BaseRP" to "Routing Protocol" throughout the doc - man 1765 o filled out the Terminology section 1766 o changed "KMART" to "KARP" in everything but the title, since the 1767 -00 deadline had long since passed. Will change the title of the 1768 doc to KARP as soon as the window re-opens. 1769 o priorities in sect 4.6 changed. Added PIM-SM. Lowered OSPF and 1770 BFD, based on feedback by a few people. 1771 o many edits resulting from Danny McPherson's review. 1772 o added "Brute Foce Attacks Against Password/Keys" to Threats 1773 Section 2.1 section. 1775 o Significant updates to Security Considerations section 1776 o Added a few references throughout to RFC3562 1777 o 4.3 2nd to last P - added a comment to clarify that two parties 1778 (or an org) must discuss ahead of time what they want their 1779 connections' secruity properties to be. - dward 1780 o added to 4.4 Phase 1 - New Section: Transition and Deployment 1781 Considerations. ea wg must call out the operational transition 1782 plan from old to new security. Best if don't bounce link. - dward 1783 o added 3.3 (but not sure if this is right)- endpoint discovery 1784 mechanisms? endpoint discovery mechanism (L2VPN, L3VPN, etc). 1785 Discovery is much different security properties than passing 1786 Routing updates. - dward 1787 o More requirements: Added to 4.2: X - convergence SHOULD not be 1788 affected by what we choose; adding security SHOULD not cause a 1789 refresh of route updates or cause additional route updates to be 1790 generated; adding auth should not be an attack vector itself. 1791 AKA, the use of MD5 is so expensive that spoofing BGP packets w/ 1792 MD5 causes the control plane to be attacked because CPU went to 1793 100% - dward 1794 o updated stats on MD5 usage, and cited [ISR2008]. - mchpherson 1796 karp-00 - 1798 o changes title from "kmart" to "karp" and the version from "-03" to 1799 "00". No other changes. 1801 9. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 1803 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 1804 Please remove before publishing as RFC.] 1806 List of stuff that still needs work 1807 o RTG AD's or delegates: clean up the three definitions of route 1808 message type categories. Need RTG Area folks input on this. 1809 o More clarity on the work items for those defining and specifying 1810 the framework elements and API's themselves. 1811 o RTG AD's or delegates: text justifying RSVP and RSVP-TE and what 1812 we think solving that problem may look like 1813 o RTG AD's or delegates: more justification for why MANET and FORCES 1814 are out of scope. Need ref for those RFCs. 1815 o Danny McPherson: Get reference for BGP auth usage stats in Scope 1816 (Section 1.3) section, item 4. 1817 o 1818 o security section: pull out security guidance to routing protocol 1819 design teams stuff and place into its own section? 1821 o 1822 o 1824 10. References 1826 10.1. Normative References 1828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1829 Requirement Levels", BCP 14, RFC 2119, March 1997. 1831 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1832 Routing Protocols", RFC 4593, October 2006. 1834 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1835 IAB workshop on Unwanted Traffic March 9-10, 2006", 1836 RFC 4948, August 2007. 1838 10.2. Informative References 1840 [I-D.ao-crypto] 1841 Lebovitz, G., "Cryptographic Algorithms, Use and 1842 Implementation Requirements for TCP Authentication 1843 Option", March 2009, . 1846 [I-D.ietf-pim-sm-linklocal] 1847 Atwood, W., Islam, S., and M. Siami, "Authentication and 1848 Confidentiality in PIM-SM Link-local Messages", 1849 draft-ietf-pim-sm-linklocal-10 (work in progress), 1850 December 2009. 1852 [I-D.ietf-tcpm-tcp-auth-opt] 1853 Touch, J., Mankin, A., and R. Bonica, "The TCP 1854 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08 1855 (work in progress), October 2009. 1857 [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure 1858 Security Report", October 2008, 1859 . 1861 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1862 dual environments", RFC 1195, December 1990. 1864 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1866 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1867 November 1998. 1869 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1870 Signature Option", RFC 3562, July 2003. 1872 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1873 Protocol (MSDP)", RFC 3618, October 2003. 1875 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1876 Independent Multicast - Dense Mode (PIM-DM): Protocol 1877 Specification (Revised)", RFC 3973, January 2005. 1879 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1880 Requirements for Security", BCP 106, RFC 4086, June 2005. 1882 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1883 Key Management", BCP 107, RFC 4107, June 2005. 1885 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1886 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1888 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1889 Internet Protocol", RFC 4301, December 2005. 1891 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1892 RFC 4303, December 2005. 1894 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1895 RFC 4306, December 2005. 1897 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1898 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1899 Protocol Specification (Revised)", RFC 4601, August 2006. 1901 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 1902 Advanced Encryption Standard-Cipher-based Message 1903 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 1904 PRF-128) Algorithm for the Internet Key Exchange Protocol 1905 (IKE)", RFC 4615, August 2006. 1907 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1908 RFC 4949, August 2007. 1910 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1911 Specification", RFC 5036, October 2007. 1913 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1914 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1915 May 2008. 1917 Authors' Addresses 1919 Gregory Lebovitz 1920 Juniper Networks, Inc. 1921 1194 North Mathilda Ave. 1922 Sunnyvale, CA 94089-1206 1923 US 1925 Phone: 1926 Email: gregory.ietf@gmail.com 1928 Phone: 1929 Email: