idnits 2.17.1 draft-ietf-karp-threats-reqs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2011) is 4688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP Working Group G. Lebovitz 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Informational M. Bhatia 5 Expires: December 20, 2011 Alcatel-Lucent 6 R. White 7 Cisco Systems 8 June 18, 2011 10 The Threat Analysis and Requirements for Cryptographic Authentication of 11 Routing Protocols' Transports 12 draft-ietf-karp-threats-reqs-03 14 Abstract 16 Different routing protocols exist and each employs its own mechanism 17 for securing the protocol packets on the wire. While most already 18 have some method for accomplishing cryptographic message 19 authentication, in many cases the existing methods are dated, 20 vulnerable to attack, and employ cryptographic algorithms that have 21 been deprecated. The "Keying and Authentication for Routing 22 Protocols" (KARP) effort aims to overhaul and improve these 23 mechanisms. 25 This document has two main parts - the first describes the threat 26 analysis for attacks against routing protocols' transports and the 27 second enumerates the requirements for addressing the described 28 threats. This document, along with the KARP design guide will be 29 used by KARP design teams for specific protocol review and overhaul. 30 This document reflects the input of both the IETF's Security Area and 31 Routing Area in order to form a jointly agreed upon guidance. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 20, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 70 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1.4. Incremental Approach . . . . . . . . . . . . . . . . . . . 7 72 1.5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1.7. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 2.1. Threats In Scope . . . . . . . . . . . . . . . . . . . . . 13 78 2.2. Threats Out of Scope . . . . . . . . . . . . . . . . . . . 15 80 3. Requirements for Phase 1 of a Routing Protocol Transport's 81 Security Update . . . . . . . . . . . . . . . . . . . . . . . 17 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 95 1. Introduction 97 In March 2006 the Internet Architecture Board (IAB) held a workshop 98 on the topic of "Unwanted Internet Traffic". The report from that 99 workshop is documented in [RFC4948]. Section 8.1 of that document 100 states "A simple risk analysis would suggest that an ideal attack 101 target of minimal cost but maximal disruption is the core routing 102 infrastructure." Section 8.2 calls for "[t]ightening the security of 103 the core routing infrastructure." Four main steps were identified 104 for that tightening: 106 o More secure mechanisms and practices for operating routers. This 107 work is being addressed in the OPSEC Working Group. 109 o Cleaning up the Internet Routing Registry repository (IRR), and 110 securing both the database and the access, so that it can be used 111 for routing verifications. This work should be addressed through 112 liaisons with those running the IRR's globally. 114 o Specifications for cryptographic validation of routing message 115 content. This work will likely be addressed in the SIDR Working 116 Group. 118 o Securing the routing protocols' packets on the wire 120 This document addresses the last item in the list above, securing the 121 the transmission of routing protocol packets on the wire, or rather 122 securing routing protocol transport. This effort is referred to as 123 Keying and Authentication for Routing Protocols, or "KARP". This 124 document specifically addresses the threat analysis for per packet 125 routing protocol transport authentication, and the requirements for 126 protocols to mitigate those threats. 128 This document is one of two that together form the guidance and 129 instructions for KARP design teams working to overhaul routing 130 protocol transport security. The other document is the KARP Design 131 Guide [I-D.ietf-karp-design-guide]. 133 1.1. Terminology 135 Within the scope of this document, the following words, when 136 beginning with a capital letter, or spelled in all capitals, hold the 137 meanings described to the right of each term. If the same word is 138 used uncapitalized, then it is intended to have its common english 139 definition. 141 PSK (Pre-Shared Key) 143 A key used by both peers in a secure configuration. Usually 144 exchanged out-of-band prior to a first connection. 146 Routing Protocol 148 When used with capital "R" and "P" in this document the term 149 refers the Routing Protocol for which work is being done to 150 provide or enhance its peer authentication mechanisms. 152 PRF 154 In cryptography, a pseudorandom function family, abbreviated PRF, 155 is a collection of efficiently-computable functions which emulate 156 a random oracle in the following way: No efficient algorithm can 157 distinguish (with significant advantage) between a function chosen 158 randomly from the PRF family and a random oracle (a function whose 159 outputs are fixed completely at random). Informally, a PRF takes 160 a secret key and a set of input values and produces random-seeming 161 output values for each input value. 163 KDF (Key derivation function) 165 A KDF is a function in which an input key and other input data is 166 used to generate (or derive) keying material that can be employed 167 by cryptographic algorithms. The key that is input to a KDF is 168 called a key derivation key. KDFs can be used to generate one or 169 more keys from either (i) a uniformly random or pseudorandom seed 170 value or (ii) a Diffie-Hellman shared secret or (iii) a non- 171 uniform random source or (iv) a passphrase. 173 Identifier 175 The type and value used by one peer of an authenticated message 176 exchange to signify to the other peer who they are. The 177 Identifier is used by the receiver as a lookup index into a table 178 containing further information about the peer that is required to 179 continue processing the message, for example a Security 180 Association (SA) or keys. 182 Identity Proof 184 Once the form of identity is decided, then there must be a 185 cryptographic proof of that identity, that the peer really is who 186 they assert themselves to be. Proof of identity can be arranged 187 between the peers in a few ways, for example pre-shared keys, raw 188 assymetric keys, or a more user-friendly representation of 189 assymetric keys, such as a certificate. Certificates can be used 190 in a way requiring no additional supporting systems -- e.g. public 191 keys for each peer can be maintained locally for verification upon 192 contact. Certificate management can be made more simple and 193 scalable with the use of minor additional supporting systems, as 194 is the case with self-signed certificates and a flat file list of 195 "approved thumbprints". Self-signed certificates will have 196 somewhat lower security properties than Certificate Authority 197 signed certificates . The use of these different identity proofs 198 vary in ease of deployment, ease of ongoing management, startup 199 effort, ongoing effort and management, security strength, and 200 consequences from loss of secrets from one part of the system to 201 the rest of the system. For example, they differ in resistance to 202 a security breach, and the effort required to remediate the whole 203 system in the event of such a breach. The point here is that 204 there are options, many of which are quite simple to employ and 205 deploy. 207 SA (Security Association) 209 The parameters and keys that together form the required 210 information for processing secure sessions between peers. 211 Examples of items that may exist in an SA include: Identifier, 212 PSK, Traffic Key, cryptographic algorithms, key lifetimes. 214 KMP (Key Management Protocol) 216 A protocol used between peers for creation, distribution and 217 maintenance of secret keys. It determines how secret keys are 218 generated and made available to both the parties. If session or 219 traffic keys are being used, KMP is responsible for generating 220 them and determining when they should be renewed. 222 A KMP is helpful because it negotiates unique, pair wise, random 223 keys without administrator involvement. It also negotiates as 224 mentioned earlier several of the SA parameters required for the 225 secure connection, including key life times. It keeps track of 226 those lifetimes using counters, and negotiates new keys and 227 parameters before they expire, again, without administrator 228 interaction. Additionally, in the event of a breach, changing the 229 KMP key will immediately cause a rekey to occur for the Traffic 230 Key, and those new Traffic Keys will be installed and used in the 231 current connection. 233 KMP Function 234 Any actual KMP used in the general KARP solution framework 236 Peer Key 238 Keys that are used between peers as the identity proof. These 239 keys may or may not be connection specific, depending on how they 240 were established, and what form of identity and identity proof is 241 being used in the system. This would generally be given by the 242 KMP that would later be used to derive fresh traffic keys. 244 Traffic Key 246 The actual key (or set of keys) used for protecting the routing 247 protocol traffic. Since the traffic keys used in a particular 248 connection are not a fixed part of a device configuration no data 249 exists anywhere else in the operator's systems which can be 250 stolen, e.g. in the case of a terminated or turned employee. If a 251 server or other data store is stolen or compromised, the thieves 252 gain no access to current traffic keys. They may gain access to 253 key derivation material, like a PSK, but not current traffic keys 254 in use. 256 1.2. Requirements Language 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in RFC2119 [RFC2119]. 262 When used in lower case, these words convey their typical use in 263 common language, and are not to be interpreted as described in 264 RFC2119 [RFC2119]. 266 1.3. Scope 268 Three basic services (or techniques) may be employed in order to 269 secure any piece of data as it is transmitted over the wire: privacy, 270 authentication, and message integrity. The focus for this effort, 271 and the scope for this roadmap document, will be message 272 authentication and packet integrity only. This work explicitly 273 excludes, at this point in time, privacy services. Non-repudiation 274 is also excluded as a goal at this time. Since the objective of most 275 routing protocols is to broadly advertise the routing topology, 276 routing protocol packets are commonly sent in the clear; 277 confidentiality is not normally required for routing protocols. 278 However, ensuring that routing peers truly are the trusted peers 279 expected, and that no rogue peers or packets can compromise the 280 stability of the routing environment is critical, and thus our focus. 281 Privacy and non-repudiation may be addressed in future work. 283 OSPF [RFC5709], IS-IS [RFC5310], LDP [RFC5036], and RIP already have 284 existing mechanisms for cryptographically authenticating and 285 integrity checking the packets on the wire. Products with these 286 mechanisms have already been produced, code has already been written 287 and both have been optimized for the existing mechanisms. Rather 288 than turn away from these mechanisms, this document aims to enhance 289 them, updating them to modern and secure levels. 291 Therefore, the scope of this roadmap of work includes: 293 o Making use of existing routing protocol transport security 294 mechanisms, where they exist, and enhancing or updating them as 295 necessary for modern cryptographic best practices 297 o Developing a framework for using automatic key management in order 298 to ease deployment, lower cost of operation, and allow for rapid 299 responses to security breaches 301 o Specifying the automated key management protocol that may be 302 combined with the bits-on-the-wire mechanisms. 304 This document does not contain protocol specifications. Instead, it 305 defines the areas where protocol specification work is needed and 306 sets a direction, a set of requirements, and a relative priority for 307 addressing that specification work. 309 There are a set of threats to routing protocols that are considered 310 in-scope for this document, and a set considered out-of- scope. 311 These are described in detail in the Threats (Section 2) section 312 below. 314 1.4. Incremental Approach 316 The work also serves as an agreement between the Routing Area and the 317 Security Area about the priorities and work plan for incrementally 318 delivering the above work. The principle of crawl, walk, run will be 319 in place and routing protocol authentication mechanisms may not go 320 immediately from their current state to a state containing the best 321 possible, most modern security practices. This point is important as 322 there will be times when the best-security-possible will give way to 323 vastly- improved-over-current-security-but-admittedly-not-yet-best- 324 security- possible, in order that incremental progress toward a more 325 secure Internet may be achieved. As such, this document will call 326 out places where agreement has been reached on such trade offs. 328 Incremental steps will need to be taken for a few very practical 329 reasons. First, there are a considerable number of deployed routing 330 devices in operating networks that will not be able to run the most 331 modern cryptographic mechanisms without significant and unacceptable 332 performance penalties. The roadmap for any one routing protocol MUST 333 allow for incremental improvements on existing operational devices. 334 Second, current routing protocol performance on deployed devices has 335 been achieved over the last 20 years through extensive tuning of 336 software and hardware elements, and is a constant focus for 337 improvement by vendors and operators alike. The introduction of new 338 security mechanisms affects this performance balance. The 339 performance impact of any incremental step of security improvement 340 will need to be weighed by the community, and introduced in such a 341 way that allows the vendor and operator community a path to adoption 342 that upholds reasonable performance metrics. Therefore, certain 343 specification elements may be introduced carrying the "SHOULD" 344 guidance, with the intention that the same mechanism will carry a 345 "MUST" in the next release of the specification. 347 This gives the vendors and implementors the guidance they need to 348 tune their software and hardware appropriately over time. Last, some 349 security mechanisms require the build out of other operational 350 support systems, and this will take time. An example where these 351 three reasons are at play in an incremental improvement roadmap is 352 seen in the improvement of BGP's [RFC4271] security via the update of 353 the TCP Authentication Option (TCP-AO) [RFC5925] effort. It would be 354 ideal, and reflect best common security practice, to have a fully 355 specified key management protocol for negotiating TCP-AO's 356 authentication material, using certificates for peer authentication 357 in the keying. 359 However, in the spirit of incremental deployment, we will first 360 address issues like cryptographic algorithm agility, replay attacks, 361 TCP session resetting in the base TCP-AO protocol before we layer key 362 management on top of it. 364 1.5. Goals 366 The goals and general guidance for the KARP work follow: 368 1. Provide authentication and integrity protection for packets on 369 the wire of existing routing protocols 371 2. Deliver a path to incrementally improve security of the routing 372 infrastructure as explained in the earlier sections. 374 3. The deployability of the improved security solutions on currently 375 running routing infrastructure equipment. This begs the 376 consideration of the current state of processing power available 377 on routers in the network today. 379 4. Operational deployability - A solutions acceptability will also 380 be measured by how deployable the solution is by common operator 381 teams using common deployment processes and infrastructures. 382 I.e. We will try to make these solutions fit as well as possible 383 into current operational practices or router deployment. This 384 will be heavily influenced by operator input, to ensure that what 385 we specify can -- and, more importantly, will -- be deployed once 386 specified and implemented by vendors. Deployment of 387 incrementally more secure routing infrastructure in the Internet 388 is the final measure of success. Measurably, we would like to 389 see an increase in the number of surveyed respondents who report 390 deploying the updated authentication mechanisms anywhere across 391 their network, as well as a sharp rise in usage for the total 392 percentage of their network's routers. 394 Interviews with operators show several points about routing 395 security. First, over 70% of operators have deployed transport 396 connection protection via TCP-MD5 [RFC3562] on their EBGP 397 [ISR2008]. Over 55% also deploy MD5 on their IBGP connections, 398 and 50% deploy MD5 on some other IGP. The survey states that "a 399 considerable increase was observed over previous editions of the 400 survey for use of TCP MD5 with external peers (eBGP), internal 401 peers (iBGP) and MD5 extensions for IGPs." Though the data is 402 not captured in the report, the authors believe anecdotally that 403 of those who have deployed MD5 somewhere in their network, only 404 about 25-30% of the routers in their network are deployed with 405 the authentication enabled. None report using IPsec [RFC4301] to 406 protect the routing protocol, and this was a decline from the few 407 that reported doing so in the previous year's report. From my 408 personal conversations with operators, of those using MD5, almost 409 all report deploying with one single manual key throughout the 410 entire network. These same operators report that the one single 411 key has not been changed since it was originally installed, 412 sometimes five or more years ago. When asked why, particularly 413 for the case of BGP using TCP MD5, the following reasons are 414 often given: 416 A. Changing the keys triggers a TCP reset, and thus bounces the 417 links/adjacencies, undermining Service Level Agreements 418 (SLAs). 420 B. For external peers, difficulty of coordination with the other 421 organization is an issue. Once they find the correct contact 422 at the other organization (not always so easy), the 423 coordination function is serialized and on a per peer/AS 424 basis. The coordination is very cumbersome and tedious to 425 execute in practice. 427 C. Keys must be changed at precisely the same time, or at least 428 within 60 seconds (as supported by two major vendors) in order 429 to limit connectivity outage duration. This is incredibly 430 difficult to do, operationally, especially between different 431 organizations. 433 D. Relatively low priority compared to other operational issues. 435 E. Lack of staff to implement the changes device by device. 437 F. There are three use cases for operational peering at play 438 here: peers and interconnection with other operators, Internal 439 BGP and other routing sessions within a single operator, and 440 operator-to-customer-CPE devices. All three have very 441 different properties, and all are reported as cumbersome. One 442 operator reported that the same key is used for all customer 443 premise equipment. The same operator reported that if the 444 customer mandated, a unique key could be created, although the 445 last time this occurred it created such an operational 446 headache that the administrators now usually tell customers 447 that the option doesn't even exist, to avoid the difficulties. 448 These customer-unique keys are never changed, unless the 449 customer demands so. The main threat at play here is that a 450 terminated employee from such an operator who had access to 451 the one (or few) keys used for authentication in these 452 environments could easily wage an attack -- or offer the keys 453 to others who would wage the attack -- and bring down many of 454 the adjacencies, causing destabilization to the routing 455 system. 457 5. Whatever mechanisms we specify need to be easier than the current 458 methods to deploy, and should provide obvious operational 459 efficiency gains along with significantly better security and 460 threat protection. This combination of value may be enough to 461 drive much broader adoption. 463 6. Address the threats enumerated above in the "Threats" section 464 (Section 2) for each routing protocol, along a roadmap. Not all 465 threats may be able to be addressed in the first specification 466 update for any one protocol. Roadmaps will be defined so that 467 both the security area and the routing area agree on how the 468 threats will be addressed completely over time. 470 7. Create a re-usable architecture, framework, and guidelines for 471 various IETF working teams who will address these security 472 improvements for various Routing Protocols. The crux of the KARP 473 work is to re-use that framework as much as possible across 474 relevant Routing Protocols. For example, designers should aim to 475 re-use the key management protocol that will be defined for BGP's 476 TCP-AO key establishment for as many other routing protocols as 477 possible. This is but one example. 479 8. Bridge any gaps between IETF's Routing and Security Areas by 480 recording agreements on work items, roadmaps, and guidance from 481 the Area leads and Internet Architecture Board (IAB, 482 http://www.iab.org). 484 1.6. Non-Goals 486 The following two goals are considered out-of-scope for this effort: 488 o Privacy of the packets on the wire. Once this roadmap is 489 realized, we may revisit work on privacy. 491 o Message content validity (routing database validity). This work 492 is being addressed in other IETF efforts, like SIDR. 494 1.7. Audience 496 The audience for this document includes: 498 o Routing Area working group chairs and participants - These people 499 are charged with updates to the Routing Protocol specifications. 500 Any and all cryptographic authentication work on these 501 specifications will occur in Routing Area working groups, with 502 close partnership with the Security Area. Co- advisors from 503 Security Area may often be named for these partnership efforts. 505 o Security Area reviewers of routing area documents - These people 506 are delegated by the Security Area Directors to perform reviews on 507 routing protocol specifications as they pass through working group 508 last call or IESG review. They will pay particular attention to 509 the use of cryptographic authentication and corresponding security 510 mechanisms for the routing protocols. They will ensure that 511 incremental security improvements are being made, in line with 512 this roadmap. 514 o Security Area engineers - These people partner with routing area 515 authors/designers on the security mechanisms in routing protocol 516 specifications. Some of these security area engineers will be 517 assigned by the Security Area Directors, while others will be 518 interested parties in the relevant working groups. 520 o Operators - The operators are a key audience for this work, as the 521 work is considered to have succeeded if the operators deploy the 522 technology, presumably due to a perception of significantly 523 improved security value coupled with relative similarity to 524 deployment complexity and cost. Conversely, the work will be 525 considered a failure if the operators do not care to deploy it, 526 either due to lack of value or perceived (or real) over- 527 complexity of operations. And as such, the GROW and OPSEC WGs 528 should be kept squarely in the loop as well. 530 2. Threats 532 In RFC4949 [RFC4949], a threat is defined as a potential for 533 violation of security, which exists when there is a circumstance, 534 capability, action, or event that could breach security and cause 535 harm. This section defines the threats that are in scope for this 536 roadmap, and those that are explicitly out of scope. This document 537 leverages the "Generic Threats to Routing Protocols" model, RFC 4593 538 [RFC4593], capitalizes terms from that document, and offers a terse 539 definition of those terms. (More thorough description of routing 540 protocol threats sources, motivations, consequences and actions can 541 be found in RFC 4593 [RFC4593] itself). The threat listings below 542 expand upon these threat definitions. 544 2.1. Threats In Scope 546 The threats that will be addressed in this roadmap are those from 547 OUTSIDERS, attackers that may reside anywhere in the Internet, have 548 the ability to send IP traffic to the router, may be able to observe 549 the router's replies, and may even control the path for a legitimate 550 peer's traffic. These are not legitimate participants in the routing 551 protocol. Message authentication and integrity protection 552 specifically aims to identify packets originating from OUTSIDERS. 554 The concept of OUTSIDERS can be further refined to include attackers 555 who are terminated employees, and those sitting on-path. 557 o On-Path - attackers with control of a network resource or a tap 558 along the path of packets between two routers. An on-path 559 outsider can attempt a man-in-the-middle attack, in addition to 560 several other attack classes. A man-in-the-middle (MitM) attack 561 occurs when an attacker who has access to packets flowing between 562 two peers tampers with those packets in such a way that both peers 563 think they are talking to each other directly, when in fact they 564 are actually talking to the attacker only. Protocols conforming 565 to this roadmap will use cryptographic mechanisms to prevent a 566 man-in-the-middle attacker from situating himself undetected. 568 o Terminated Employees - in this context, those who had access 569 router configuration that included keys or keying material like 570 pre-shared keys used in securing the routing protocol. Using this 571 material, the attacker could send properly MAC'd spoofed packets 572 appearing to come from router A to router B, and thus impersonate 573 an authorized peer. The attacker could then send false traffic 574 that changes the network behavior from its operator's design. The 575 goal of addressing this source specifically is to call out the 576 case where new keys or keying material becomes necessary very 577 quickly, with little operational expense, upon the termination of 578 such an employee. This grouping could also refer to any attacker 579 who somehow managed to gain access to keying material, and said 580 access had been detected by the operators such that the operators 581 have an opportunity to move to new keys in order to prevent an 582 attack. 584 These attack actions are in scope for this roadmap: 586 o Spoofing - when an unauthorized device assumes the identity of an 587 authorized one. Spoofing can be used, for example, to inject 588 malicious routing information that causes the disruption of 589 network services. Spoofing can also be used to cause a neighbor 590 relationship to form that subsequently denies the formation of the 591 relationship with the legitimate router. 593 o Falsification - an action whereby an attacker sends false routing 594 information. To falsify the routing information, an attacker has 595 to be either the originator or a forwarder of the routing 596 information. Falsification may occur by an originator, or a 597 forwarder, and may involve overclaiming, misclaiming, or 598 mistatement of network resource reachability. We must be careful 599 to remember that in this work we are only targeting falsification 600 from outsiders as may occur from tampering with packets in flight. 601 Falsification from BYZANTINES (see the Threats Out of Scope 602 section (Section 2.2) below) are not addressed by the KARP effort. 604 o Interference - when an attacker inhibits the exchanges by 605 legitimate routers. The types of interference addressed by this 606 work include: 608 A. Adding noise 610 B. Replaying out-dated packets 612 C. Inserting protocol packets 614 D. Corrupting protocol packets 616 E. Breaking synchronization 618 F. Changing message content 620 o DoS attacks on transport sub-systems - This includes any other DoS 621 attacks specifically based on the above attack types. This is 622 when an attacker sends spoofed packets aimed at halting or 623 preventing the underlying protocol over which the routing protocol 624 runs. For example, BGP running over TLS will still not solve the 625 problem of being able to send a TCP FIN or TCP RST and causing the 626 peer session to go down. Since this attack depends on spoofing, 627 operators are encouraged to deploy proper authentication 628 mechanisms to prevent such attacks. Routing Protocols should thus 629 be made resilient to potential attacks on the layers above which 630 they run. 632 o DoS attacks using the authentication mechanism - This includes an 633 attacker sending packets which confuse or overwhelm a security 634 mechanism itself. An example is initiating an overwhelming load 635 of spoofed authenticated routing protocol packets so that the 636 receiver needs to process the MAC check, only to discard the 637 packet, sending CPU levels rising. Another example is when an 638 attacker sends an overwhelming load of keying protocol initiations 639 from bogus sources. All other possible DoS attacks are out of 640 scope (see next section). 642 o Brute Force Attacks Against Password/Keys - This includes either 643 online or offline attacks where attempts are made repeatedly using 644 different keys/passwords until a match is found. While it is 645 impossible to make brute force attacks on keys completely 646 unsuccessful, proper design can make such attacks much harder to 647 succeed. For example, the key length should be sufficiently long 648 so that covering the entire space of possible keys is improbable 649 using computational power expected to be available 10 years out or 650 more. Using per session keys is another widely used method for 651 reducing the number of brute force attacks as this would make it 652 difficult to guess the keys. 654 2.2. Threats Out of Scope 656 Threats from BYZANTINE sources -- faulty, misconfigured, or subverted 657 routers, i.e., legitimate participants in the routing protocol -- are 658 out of scope for this roadmap. Any of the attacks described in the 659 above section (Section 2.1) that may be levied by a BYZANTINE source 660 are therefore also out of scope. 662 In addition, these other attack actions are out of scope for this 663 work: 665 o Sniffing - passive observation of route message contents in flight 667 o Falsification by Byzantine sources - unauthorized message content 668 by a legitimate authorized source. 670 o Interference due to: 672 A. Not forwarding packets - cannot be prevented with 673 cryptographic authentication 675 B. Delaying protocol packets - cannot be prevented with 676 cryptographic authentication 678 C. Denial of receipt - cannot be prevented with cryptographic 679 authentication 681 D. Unauthorized message content - the work of the IETF's SIDR 682 working group 683 (http://www.ietf.org/html.charters/sidr-charter.html). 685 E. Any other type of DoS attack. For example, a flood of traffic 686 that fills the link ahead of the router, so that the router is 687 rendered unusable and unreachable by valid packets is NOT an 688 attack that this work will address. Many other such examples 689 could be contrived. 691 3. Requirements for Phase 1 of a Routing Protocol Transport's Security 692 Update 694 The following list of requirements SHOULD be addressed by a KARP Work 695 Phase 1 security update to any Routing Protocol (according to section 696 4.1 of the KARP Design Guide [I-D.ietf-karp-design-guide] document). 697 IT IS RECOMMENDED that any Phase 1 security update to a Rouing 698 Protocol contain a section of the specification document that 699 describes how each of these requirements are met. It is further 700 RECOMMENDED that textual justification be presented for any 701 requirements that are NOT addressed. 703 1. Clear definitions of which elements of the transmission (frame, 704 packet, segment, etc.) are protected by the authentication 705 mechanism 707 2. Strong algorithms, and defined and accepted by the security 708 community, MUST be specified. The option should use algorithms 709 considered accepted by the IETF's Security community, which are 710 considered appropriately safe. The use of non-standard or 711 unpublished algorithms SHOULD BE avoided. 713 3. Algorithm agility for the cryptographic algorithms used in the 714 authentication MUST be specified, i.e. more than one algorithm 715 MUST be specified and it MUST be clear how new algorithms MAY be 716 specified and used within the protocol. This requirement exists 717 in case one algorithm gets broken suddenly. Research to 718 identify weakness in algorithms is constant. Breaking a cipher 719 isn't a matter of if, but when it will occur. It's highly 720 unlikely that two different algorithms will be broken 721 simultaneously. So, if two are supported, and one gets broken, 722 we can use the other until we get a new one in place. Having 723 the ability within the protocol specification to support such an 724 event, having algorithm agility, is essential. Mandating two 725 algorithms provides both a redundancy, and a mechanism for 726 enacting that redundancy when needed. Further, the mechanism 727 MUST describe the generic interface for new cryptographic 728 algorithms to be used, so that implementers can use algorithms 729 other than those specified, and so that new algorithms may be 730 specified and supported in the future. 732 4. Secure use of simple PSKs, offering both operational convenience 733 as well as building something of a fence around stupidity, MUST 734 be specified. 736 5. Routing protocol packets replay shouldnt affect the routing 737 system. For non TCP based protocols like OSPF [RFC2328], IS-IS 738 [RFC1195] , etc., two routers are said to have a session up if 739 they are able to exchange protocol packets. Packets captured 740 from one session must not be able to be re-sent and accepted 741 during a later session. Additionally, replay mechanisms must 742 work correctly even in the presence of routing protocol packet 743 prioritization by the router. 745 6. A change of security parameters REQUIRES, and even forces, a 746 change of session traffic keys 748 7. Intra-connection re-keying which occurs without a break or 749 interruption to the current peering session, and, if possible, 750 without data loss, MUST be specified. Keys need to be changed 751 periodically, for operational privacey (e.g. when an 752 administrator who had access to the keys leaves an organization) 753 and for entropy purposes, and a re-keying mechanism enables the 754 deployers to execute the change without productivity loss. 756 8. Efficient re-keying SHOULD be provided. The specificaion SHOULD 757 support rekeying during a connection without the need to expend 758 undue computational resources. In particular, the specification 759 SHOULD avoid the need to try/compute multiple keys on a given 760 packet. 762 9. Prevent DoS attacks as those described as in-scope in the 763 threats section Section 2.1 above. 765 10. Default mechanisms and algorithms specified and defined are 766 REQUIRED for all implementations. 768 11. For backward compatibilty reasons manual keying MUST be 769 supported. 771 12. Architecture of the specification SHOULD consider and allow for 772 future use of a KMP. 774 13. The authentication mechanism in the Routing Protocol MUST be 775 decoupled from the key management system used. It MUST be 776 obvious how the keying material was obtained, and the process 777 for obtaining the keying material MUST exist outside of the 778 Routing Protocol. This will allow for the various key 779 generation methods, like manual keys and KMPs, to be used with 780 the same Routing Protocol mechanism. 782 14. Convergence times of the Routing Protocols SHOULD NOT be 783 materially affected. Materially here is defined as anything 784 greater than a 5% convergence time increase. Note that 785 convergence is different than boot time. Also note that 786 convergence time has a lot to do with the speed of processors 787 used on individual routing peers, and this processing power 788 increases by Moore's law over time, meaning that the same route 789 calculations and table population routines will decrease in 790 duration over time. Therefore, this requirement should be 791 considered only in terms of total number of protocol packets 792 that must be exchanged, and less for the computational intensity 793 of processing any one message. Alternatively this can be 794 simplified by saying that the new mechanisms should only result 795 in a minimal increase in the number of routing protocol packets 796 passed between the peers. 798 15. The changes or addition of security mechanisms SHOULD NOT cause 799 a refresh of route updates or cause additional route updates to 800 be generated. 802 16. Router implementations provide prioritized treatment to certain 803 protocol packets. For example, OSPF HELLO packets and ACKs are 804 prioritized for processing above other OSPF packets. The 805 authentication mechanism SHOULD NOT interfere with the ability 806 to observe and enforce such prioritization. Any effect on such 807 priority mechanisms MUST be explicitly documented and 808 justified.Replay mechanisms provided by the routing protocols 809 MUST work even if certain protocol packets are offered 810 prioritized treatment. 812 17. The authentication mechanism does not provide message 813 confidentiality, but SHOULD NOT preclude the possibility of 814 confidentiality support being added in the future. 816 18. Routing protocols MUST only send minimal information regarding 817 the authentication mechanisms and the parameters in its protocol 818 packets to avoid exposing the information to parties on the 819 path. 821 19. In most routing protocols (OSPF [RFC2328], IS-IS [RFC1195], BFD 822 [RFC5880], RIP [RFC2453], etc), all speakers share the same key 823 on a broadcast segment. Possession of the key itself is used 824 for identity validation and no other identity check is used. 825 This opens a window for an attack where the sender can 826 masquerade as some other neighbor. Routing protocols SHOULD 827 thus use some other information besides the key to validate a 828 neighbor. One could look at [RFC6039] for details on such 829 attacks. 831 20. Routing protocols that rely on the IP header (or information 832 beyond the routing protocol payload) to identify the neighbor 833 which originated the packet must either protect the IP header or 834 provide some other means to identify the neighbor. [RFC6039] 835 describes some attacks that are based on this. 837 21. The new security and authentication mechanisms MUST support 838 incremental deployment. It will not be feasible to deploy a new 839 Routing Protocol authentication mechanism throughout the network 840 instantaneously. It also may not be possible to deploy such a 841 mechanism to all routers in a large autonomous system (AS) at 842 one time. Proposed solutions SHOULD support an incremental 843 deployment method that provides some benefit for those who 844 participate. Because of this, there are several requirements 845 that any proposed KARP mechanism should consider. 847 A. The Routing Protocol security mechanism MUST enable each 848 router to configure use of the security mechanism on a per- 849 peer basis where the communication is one-on-one. 851 B. The new KARP mechanism MUST provide backward compatibility 852 in the message formatting, transmission, and processing of 853 routing information carried through a mixed security 854 environment. Message formatting in a fully secured 855 environment MAY be handled in a non-backward compatible 856 fashion though care must be taken to ensure that routing 857 protocol packets can traverse intermediate routers which 858 don't support the new format. 860 C. In an environment where both secured and non-secured systems 861 are interoperating a mechanism MUST exist for secured 862 systems to identify whether an originator intended the 863 information to be secured. 865 D. In an environment where secured service is in the process of 866 being deployed a mechanism MUST exist to support a 867 transition free of service interruption (caused by the 868 deployment per se). 870 22. The introduction of mechanisms to improve routing authentication 871 and security may increase the processing performed by a router. 872 Since most of the currently deployed routers do not have 873 hardware to accelerate cryptographic operations, these 874 operations could impose a significant processing burden under 875 some circumstances. Thus proposed solutions should be evaluated 876 carefully with regard to the processing burden they may impose, 877 since deployment may be impeded if network operators perceive 878 that a solution will impose a processing burden which either 879 provokes substantial capital expense, or threatens to 880 destabilize routers. 882 23. Given the high number of routers that would require the new 883 authentication mechanisms in a typical ISP deployment, solutions 884 can increase their appeal by minimizing the burden imposed on 885 all routers in favor of confining significant work loads to a 886 relatively small number of devices. Optional features or 887 increased assurance that provokes more pervasive processing load 888 MAY be made available for deployments where the additional 889 resources are economically justifiable. 891 24. The new authentication and security mechanisms should not rely 892 on systems external to the routing system (the equipment that is 893 performing forwarding). In order to ensure the rapid 894 initialization and/or return to service of failed nodes it is 895 important to reduce reliance on these external systems to the 896 greatest extent possible. Therefore, proposed solutions SHOULD 897 NOT require connections to external systems, beyond those 898 directly involved in peering relationships, in order to return 899 to full service. It is however acceptable for the proposed 900 solutions to require post initialization synchronization with 901 external systems in order to fully synchronize the security 902 information. 904 4. Security Considerations 906 This document is mostly about security considerations for the KARP 907 efforts, both threats and requirements for solving those threats. 908 More detailed security considerations were placed in the Security 909 Considerations section of the KARP Design Guide 910 [I-D.ietf-karp-design-guide] document. 912 5. IANA Considerations 914 This document has no actions for IANA. 916 6. Acknowledgements 918 The majority of the text for version -00 of this document was taken 919 from draft-lebovitz-karp-roadmap, authored by Gregory Lebovitz. 921 7. References 923 7.1. Normative References 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, March 1997. 928 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 929 Routing Protocols", RFC 4593, October 2006. 931 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 932 IAB workshop on Unwanted Traffic March 9-10, 2006", 933 RFC 4948, August 2007. 935 7.2. Informative References 937 [I-D.ietf-karp-design-guide] 938 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 939 Routing Protocols (KARP) Design Guidelines", 940 draft-ietf-karp-design-guide-02 (work in progress), 941 March 2011. 943 [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure 944 Security Report", October 2008, 945 . 947 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 948 dual environments", RFC 1195, December 1990. 950 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 952 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 953 November 1998. 955 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 956 Signature Option", RFC 3562, July 2003. 958 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 959 Protocol 4 (BGP-4)", RFC 4271, January 2006. 961 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 962 Internet Protocol", RFC 4301, December 2005. 964 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 965 RFC 4949, August 2007. 967 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 968 Specification", RFC 5036, October 2007. 970 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 971 and M. Fanto, "IS-IS Generic Cryptographic 972 Authentication", RFC 5310, February 2009. 974 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 975 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 976 Authentication", RFC 5709, October 2009. 978 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 979 (BFD)", RFC 5880, June 2010. 981 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 982 Authentication Option", RFC 5925, June 2010. 984 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 985 with Existing Cryptographic Protection Methods for Routing 986 Protocols", RFC 6039, October 2010. 988 Authors' Addresses 990 Gregory Lebovitz 991 Juniper Networks, Inc. 992 1194 North Mathilda Ave. 993 Sunnyvale, California 94089-1206 994 USA 996 Email: gregory.ietf@gmail.com 998 Manav Bhatia 999 Alcatel-Lucent 1000 Bangalore, 1001 India 1003 Phone: 1004 Email: manav.bhatia@alcatel-lucent.com 1006 Russ White 1007 Cisco Systems 1008 USA 1010 Phone: 1011 Email: russ@cisco.com