idnits 2.17.1 draft-ietf-karp-threats-reqs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2012) is 4369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 4 Intended status: Informational M. Bhatia 5 Expires: November 11, 2012 Alcatel-Lucent 6 May 10, 2012 8 Keying and Authentication for Routing Protocols (KARP) Overview, 9 Threats, and Requirements 10 draft-ietf-karp-threats-reqs-05 12 Abstract 14 Different routing protocols exist and each employs its own mechanism 15 for securing the protocol packets on the wire. While most already 16 have some method for accomplishing cryptographic message 17 authentication, in many cases the existing methods are dated, 18 vulnerable to attack, and employ cryptographic algorithms that have 19 been deprecated. The "Keying and Authentication for Routing 20 Protocols" (KARP) effort aims to overhaul and improve these 21 mechanisms. 23 This document does not contain protocol specifications. Instead, it 24 defines the areas where protocol specification work is needed and a 25 set of requirements for KARP design teams to follow. RFC 6518, 26 "Keying and Authentication for Routing Protocols (KARP) Design 27 Guidelines" is a companion to this document; KARP design teams will 28 use them together to review and overhaul routing protocols. These 29 two documents reflect the input of both the IETF's Security Area and 30 Routing Area in order to form a mutually agreeable work plan. 32 This document has three main parts. The first part provides an 33 overview of the KARP effort. The second part lists the threats from 34 RFC 4593, Generic Threats To Routing Protocols, that are in scope for 35 attacks against routing protocols' transport systems, including any 36 mechanisms built into the routing protocols themselves, which 37 accomplish packet authentication. The third part enumerates the 38 requirements that routing protocol specifications must meet when 39 addressing those threats for RFC 6518's "Work Phase 1", the update to 40 a routing protocol's existing transport security. 42 Status of this Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on November 11, 2012. 59 Copyright Notice 61 Copyright (c) 2012 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 78 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 8 80 2. KARP Effort Overview . . . . . . . . . . . . . . . . . . . . . 9 81 2.1. KARP Scope . . . . . . . . . . . . . . . . . . . . . . . . 9 82 2.2. Incremental Approach . . . . . . . . . . . . . . . . . . . 10 83 2.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 2.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 85 2.5. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 3.1. Threat Sources . . . . . . . . . . . . . . . . . . . . . . 15 89 3.1.1. OUTSIDERS . . . . . . . . . . . . . . . . . . . . . . 15 90 3.1.2. Stolen Keys . . . . . . . . . . . . . . . . . . . . . 16 91 3.1.2.1. Terminated Employee . . . . . . . . . . . . . . . 17 92 3.2. Threat Actions In Scope . . . . . . . . . . . . . . . . . 18 93 3.3. Threat Actions Out of Scope . . . . . . . . . . . . . . . 19 95 4. Requirements for KARP Work Phase 1, the Update to a 96 Routing Protocol's Existing Transport Security . . . . . . . 21 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 102 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 105 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 106 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 110 1. Introduction 112 In March 2006 the Internet Architecture Board (IAB) held a workshop 113 on the topic of "Unwanted Internet Traffic". The report from that 114 workshop is documented in [RFC4948]. Section 8.1 of that document 115 states "A simple risk analysis would suggest that an ideal attack 116 target of minimal cost but maximal disruption is the core routing 117 infrastructure." Section 8.2 calls for "[t]ightening the security of 118 the core routing infrastructure." Four main steps were identified 119 for that tightening: 121 o Create secure mechanisms and practices for operating routers. 123 o Clean up the Internet Routing Registry repository (IRR), and 124 securing both the database and the access, so that it can be used 125 for routing verification. 127 o Create specifications for cryptographic validation of routing 128 message content. 130 o Secure the routing protocols' packets on the wire 132 The first bullet is being addressed in the OPSEC working group. The 133 second bullet should be addressed through liaisons with those running 134 the IRR's globally. The third bullet is being addressed in the SIDR 135 working group. 137 This document addresses the last item in the list above, securing the 138 transmission of routing protocol packets on the wire, or rather 139 securing the routing protocols' transport systems, including any 140 mechanisms built into the routing protocols themselves which 141 accomplish packet authentication. This effort is referred to as 142 Keying and Authentication for Routing Protocols, or "KARP". KARP is 143 concerned with issues and techniques for protecting the messages and 144 their contents between directly communicating peers. This may 145 overlap with, but is strongly distinct from, protection designed to 146 ensure that routing information is properly authorized relative to 147 sources of information. Such assurances are provided by other 148 mechanisms and are outside the scope of this document and work that 149 relies on it. 151 This document is one of two that together form the guidance and 152 instructions for KARP design teams working to overhaul routing 153 protocol transport security. The other document is the KARP Design 154 Guide [RFC6518]. 156 This document does not contain protocol specifications. Instead, its 157 goal is to define the areas where protocol specification work is 158 needed and to provide a set of requirements for KARP design teams to 159 follow as they tackle [RFC6518], Section 4.1's "Work Phase 1", the 160 update to a routing protocol's existing transport security. 162 This document has three main parts. The first part, found in Section 163 2, provides an overview of the KARP effort. Section 3 lists the 164 threats from [RFC4593], Generic Threats To Routing Protocols, that 165 are in scope for routing protocols' transport systems' per packet 166 authentication. Therefore, this document does not contain a complete 167 threat model; it simply points to the parts of the governing threat 168 model that KARP design teams must address, and explicitly states 169 which parts are out of scope for KARP design teams. Section 4 170 enumerates the requirements that routing protocol specifications must 171 meet when addressing those threats related to KARP's "Work Phase 1", 172 the update to a routing protocol's existing transport security. 173 ("Work Phase 2", a framework and usage of a KMP, will be addressed in 174 a future document[s]). 176 This document uses the terminology "on the wire" to refer to the 177 information used by routing protocols' transport systems. This term 178 is widely used in IETF RFCs, but is used in several different ways. 179 In this document, it is used to refer both to information exchanged 180 between routing protocol instances, and to underlying protocols that 181 may also need to be protected in specific circumstances. Individual 182 protocol analysis documents will need to be more specific in their 183 usage." 185 1.1. Terminology 187 Within the scope of this document, the following words, when 188 beginning with a capital letter, or spelled in all capitals, hold the 189 meanings described to the right of each term. If the same word is 190 used uncapitalized, then it is intended to have its common English 191 definition. 193 Identifier 195 The type and value used by a peer of an authenticated message 196 exchange to signify who it is to another peer. The Identifier is 197 used by the receiver as an index into a table containing further 198 information about the peer that is required to continue processing 199 the message, for example a Security Association (SA) or keys. 201 Identity Authentication 202 Once the identity is decided, then there must be a cryptographic 203 proof of that identity, that the peer really is who it asserts to 204 be. Proof of identity can be arranged among peers in a few ways, 205 for example symmetric and asymmetric pre-shared keys, or an 206 assymetric key containted in a certificate. Certificates can be 207 used in ways that requires no additional supporting systems 208 external to the routers themselves. An example of this would be 209 using self signed certificates and a flat file list of "approved 210 thumbprints". The use of these different identity authentication 211 mechanisms vary in ease of deployment, ease of ongoing management, 212 startup effort, ongoing effort and management, security strength, 213 and consequences from loss of secrets from one part of the system 214 to the rest of the system. For example, they differ in resistance 215 to a security breach, and the effort required to remediate the 216 whole system in the event of such a breach. The point here is 217 that there are options, many of which are quite simple to employ 218 and deploy. 220 KDF (Key derivation function) 222 A KDF is a function in which an input key and other input data is 223 used to generate (or derive) keying material that can be employed 224 by cryptographic algorithms. The key that is input to a KDF is 225 called a key derivation key. KDFs can be used to generate one or 226 more keys from either (i) a truly random or pseudorandom seed 227 value or (ii) result of the Diffie-Hellman exchange or (iii) a 228 non-uniform random source or (iv) a pre-shared key which may or 229 may not be memorable by a human. 231 KMP (Key Management Protocol) 233 A protocol to establish a shared symmetric key between a pair (or 234 a group) of users. It determines how secret keys are generated 235 and made available to both the parties. If session or traffic 236 keys are being used, KMP is responsible for generating them and 237 determining when they should be renewed. 239 A KMP is helpful because it negotiates unique, random keys without 240 administrator involvement. It also negotiates, as mentioned 241 earlier, several of the SA parameters required for the secure 242 connection, including key life times. It keeps track of those 243 lifetimes, and negotiates new keys and parameters before they 244 expire, again, without administrator interaction. Additionally, 245 in the event of a security breach, changing KMP authentication 246 credentials will immediately cause a rekey to occur for the 247 Traffic Keys, and new Traffic Keys will be installed and used in 248 the current connection. 250 KMP Function 252 Any actual KMP used in the general KARP solution framework 254 Peer Key 256 Keys that are used among peers as a basis for identifying one 257 another. These keys may or may not be connection-specific, 258 depending on how they were established, and what forms of identity 259 and identity authentication mechanism used in the system. A peer 260 key generally would be provided by a KMP that would later be used 261 to derive fresh traffic keys. 263 PRF 265 In cryptography, a pseudorandom function, abbreviated PRF, is a 266 collection of efficiently-computable functions which emulate a 267 random oracle in the following way: No efficient algorithm can 268 distinguish (with significant advantage) between a function chosen 269 randomly from the PRF family and a random oracle (a function whose 270 outputs are determined at random). Informally, a PRF takes a 271 secret key and a set of input values and produces random-seeming 272 output values for each input value. 274 PSK (Pre-Shared Key) 276 A key used to communicate with one or more peers in a secure 277 configuration. Always distributed out-of-band prior to a first 278 connection. 280 Routing Protocol 282 When used with capital "R" and "P" in this document the term 283 refers the Routing Protocol for which work is being done to 284 provide or enhance its peer authentication mechanisms. 286 SA (Security Association) 288 A relationship established between two or more entities to enable 289 them to protect data they exchange. Examples of items that may 290 exist in an SA include: Identifier, PSK, Traffic Key, 291 cryptographic algorithms, key lifetimes. 293 Traffic Key 294 The key (or one of a set of keys) used for protecting the routing 295 protocol traffic. Since the traffic keys used in a particular 296 connection are not a fixed part of a device configuration no data 297 exists anywhere else in the operator's systems which can be 298 stolen, e.g. in the case of a terminated or turned employee. If a 299 server or other data store is stolen or compromised, the thieves 300 gain no access to current traffic keys. They may gain access to 301 key derivation material, like a PSK, but not current traffic keys 302 in use. 304 1.2. Requirements Language 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 307 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 308 document are to be interpreted as described in RFC2119 [RFC2119]. 310 When used in lower case, these words convey their typical use in 311 common language, and are not to be interpreted as described in 312 RFC2119 [RFC2119]. 314 2. KARP Effort Overview 316 2.1. KARP Scope 318 Three basic services may be employed in order to secure any piece of 319 data as it is transmitted over the wire: confidentiality, 320 authenticity, or integrity. The focus for the KARP working group 321 will be message authentication and message integrity only. This work 322 explicitly excludes, at this point in time, privacy services. Non- 323 repudiation is also excluded as a goal at this time. Since the 324 objective of most routing protocols is to broadly advertise the 325 routing topology, routing protocol packets are commonly sent in the 326 clear; confidentiality is not normally required for routing 327 protocols. However, ensuring that routing peers are authentically 328 identified, and that no rogue peers or unauthenticated packets can 329 compromise the stability of the routing environment is critical, and 330 thus our focus. Confidentiality and non-repudiation may be addressed 331 in future work. 333 OSPF [RFC5709], IS-IS [RFC5310], LDP [RFC5036], and RIP [RFC2453] 334 [RFC4822] already have existing mechanisms for cryptographically 335 authenticating and integrity checking the messages on the wire. 336 Products with these mechanisms have been produced, code has been 337 written, and both have been optimized for these existing security 338 mechanisms. Rather than turn away from these mechanisms, this 339 document aims to enhance them, updating them to modern and secure 340 levels. 342 Therefore, the scope of KARP's roadmap of work includes: 344 o Making use of existing routing protocol transport security 345 mechanisms, where they exist, and enhancing or updating them as 346 necessary for modern cryptographic best practices. [RFC6518], 347 Section 4.1 labels this KARP's "Work Phase 1." 349 o Developing a framework for using automatic key management in order 350 to ease deployment, lower cost of operation, and allow for rapid 351 responses to security breaches. [RFC6518], Section 4.1 labels 352 this KARP's "Work Phase 2." 354 o Specifying an automated key management protocol that may be 355 combined with the bits-on-the-wire mechanisms. [RFC6518], Section 356 4.1 labels this KARP's "Work Phase 2." 358 Neither this document nor [RFC6518] contain protocol specifications. 359 Instead, they define the areas where protocol specification work is 360 needed and set a direction, a set of requirements, and priorities for 361 addressing that specification work. 363 There are a set of threats to routing protocols that are considered 364 in-scope for KARP, and a set considered out-of- scope. These are 365 described in detail in the Threats (Section 3) section below. 367 2.2. Incremental Approach 369 The work also serves as an agreement between the Routing Area and the 370 Security Area about the priorities and work plan for incrementally 371 delivering the above work. The principle of "crawl, walk, run" will 372 be employed. Thus routing protocol authentication mechanisms may not 373 go immediately from their current state to a state reflecting the 374 best possible, most modern security practices. This point is 375 important as there will be times when the best-security-possible will 376 give way to vastly-improved-over-current-security-but-admittedly-not- 377 yet-best- security-possible, in order that incremental progress 378 toward a more secure Internet may be achieved. As such, this 379 document will call out places where agreement has been reached on 380 such trade offs. 382 Incremental steps will need to be taken for a few very practical 383 reasons. First, there are a considerable number of deployed routing 384 devices in operating networks that will not be able to run the most 385 modern cryptographic mechanisms without significant and unacceptable 386 performance penalties. The roadmap for any one routing protocol MUST 387 allow for incremental improvements on existing operational devices. 388 Second, current routing protocol performance on deployed devices has 389 been achieved over the last 20 years through extensive tuning of 390 software and hardware elements, and is a constant focus for 391 improvement by vendors and operators alike. The introduction of new 392 security mechanisms affects this performance balance. The 393 performance impact of any incremental step of security improvement 394 will need to be weighed by the community, and introduced in such a 395 way that allows the vendor and operator community a path to adoption 396 that upholds reasonable performance metrics. Therefore, certain 397 specification elements may be introduced carrying the "SHOULD" 398 guidance, with the intention that the same mechanism will carry a 399 "MUST" in a future release of the specification. This approach gives 400 the vendors and implementors the guidance they need to tune their 401 software and hardware appropriately over time. Last, some security 402 mechanisms require the build out of other operational support 403 systems, and this will take time. 405 An example where these three reasons were at play in an incremental 406 improvement roadmap was seen in the improvement of BGP's [RFC4271] 407 security via the TCP Authentication Option (TCP-AO) [RFC5925] effort. 408 It would have been ideal, and reflected best common security 409 practice, to have a fully specified key management protocol for 410 negotiating TCP-AO's keying material, e.g., using certificates for 411 peer authentication. However,in the spirit of incremental 412 deployment, we first addressed issues like cryptographic algorithm 413 agility, replay attacks, and TCP session resetting in the base TCP-AO 414 protocol, and then later began work to layer key management on top of 415 it. 417 2.3. Goals 419 The goals and general guidance for the KARP work follow. 421 1. Provide authentication and integrity protection for messages on 422 the wire of existing routing protocols. 424 2. Define a path to incrementally improve security of the routing 425 infrastructure as explained in the earlier sections. 427 3. Ensure that the improved security solutions on currently running 428 routing infrastructure equipment are deployable. This begs the 429 consideration of the current state of processing power available 430 on routers in the network today. 432 4. Operational deployability - A solution's acceptability will also 433 be measured by how deployable the solution is by common operator 434 teams using common deployment processes and infrastructures. 435 Specifically, we will try to make these solutions fit as well as 436 possible into current operational practices and router 437 deployment. This will be heavily influenced by operator input, 438 to ensure that what we specify can -- and, more importantly, will 439 -- be deployed once specified and implemented by vendors. 440 Deployment of incrementally more secure routing infrastructure in 441 the Internet is the final measure of success. Measurably, we 442 would like to see an increase in the number of surveyed 443 respondents who report deploying the updated authentication and 444 integrity mechanisms in their networks, as well as a sharp rise 445 in usage for the total percentage of their network's routers. 447 Interviews with operators show several points about routing 448 security. First, over 70% of operators have deployed transport 449 connection protection via TCP-MD5 [RFC3562] on their exterior 450 Border Gateway Protocol (eBGP) [ISR2008] sessions. Over 55% also 451 deploy TCP-MD5 on their interior Border Gateway Protoco (iBGP 452 connections, and 50% make use of TCP-MD5 offered on some other 453 internal gateway protocol (IGP). The survey states that "a 454 considerable increase was observed over previous editions of the 455 survey for use of TCP MD5 with external peers (eBGP), internal 456 peers (iBGP) and MD5 extensions for IGPs." Though the data is 457 not captured in the report, the authors believe anecdotally that 458 of those who have deployed TCP-MD5 somewhere in their network, 459 only about 25-30% of the routers in their network are deployed 460 with the authentication enabled. None report using IPsec 461 [RFC4301] to protect the routing protocol, and this was a decline 462 from the few that reported doing so in the previous year's 463 report. From our personal conversations with operators, of those 464 using MD5, almost all report using one, manually-distributed key 465 throughout the entire network. These same operators report that 466 the single key has not been changed since it was originally 467 installed, sometimes five or more years ago. When asked why, 468 particularly for the case of protecting BGP sessions using TCP 469 MD5, the following reasons are often given: 471 A. Changing the keys triggers a TCP reset, and thus bounces the 472 links/adjacencies, undermining Service Level Agreements 473 (SLAs). 475 B. For external peers, the difficulty of coordination with the 476 other organization is an issue. Once they find the correct 477 contact at the other organization (not always so easy), the 478 coordination function is serialized and on a per peer/AS 479 basis. The coordination is very cumbersome and tedious to 480 execute in practice. 482 C. Keys must be changed at precisely the same time, or at least 483 within 60 seconds (as supported by two major vendors) in order 484 to limit connectivity outage duration. This is incredibly 485 difficult to do, operationally, especially between different 486 organizations. 488 D. Key change is perceived as a relatively low priority compared 489 to other operational issues. 491 E. Lack of staff to implement the changes on a device-by-device 492 basis. 494 F. There are three use cases for operational peering at play 495 here: peers and interconnection with other operators, iBGP, 496 and other routing sessions within a single operator, and 497 operator-to-customer devices. All three have very different 498 properties, and all are reported as cumbersome. One operator 499 reported that the same key is used for all customer premise 500 equipment (CPE). The same operator reported that if the 501 customer mandated it, a unique key could be created, although 502 the last time this occurred it created such an operational 503 headache that the administrators now usually tell customers 504 that the option doesn't even exist, to avoid the difficulties. 505 These customer-unique keys are never changed, unless the 506 customer demands so. The main threat at play here is that a 507 terminated employee from such an operator who had access to 508 the one (or several) keys used for authentication in these 509 environments could easily wage an attack. Alternatively, the 510 operator could offer the keys to others who would wage the 511 attack. In either case, the attacker could then bring down 512 many of the adjacencies, causing destabilization to the 513 routing system. 515 5. Whatever mechanisms KARP specifies need to be easier to deploy 516 than the current methods, and should provide obvious operational 517 efficiency gains along with significantly better security and 518 threat protection. This combination of value may be enough to 519 drive much broader adoption. 521 6. Address the threats enumerated below in the "Threats" section 522 (Section 3) for each routing protocol. Not all threats may be 523 able to be addressed in the first specification update for any 524 one protocol. Roadmaps will be defined so that both the security 525 area and the routing area agree on how the threats will be 526 addressed completely over time. 528 7. Create a re-usable architecture, framework, and guidelines for 529 various IETF working groups who will address these security 530 improvements for various Routing Protocols. The crux of the KARP 531 work is to re-use the architecture, guidelines and the framework 532 as much as possible across relevant Routing Protocols. For 533 example, designers should aim to re-use the key management 534 protocol that will be defined for BGP's TCP-AO key establishment 535 for as many other routing protocols as possible. 537 8. Bridge any gaps between IETF's Routing and Security Areas by 538 recording agreements on work items, roadmaps, and guidance from 539 the cognizant Area Directors and the Internet Architecture Board 540 (IAB). 542 2.4. Non-Goals 544 The following two goals are considered out-of-scope for this effort: 546 o Confidentiality of the packets on the wire. Once this roadmap is 547 realized, we may revisit work on privacy. 549 o Message content validity (routing database validity). This work 550 is being addressed in other IETF efforts, like SIDR. 552 2.5. Audience 554 The audience for this document includes: 556 o Routing Area working group chairs and participants - These people 557 are charged with updates to the Routing Protocol specifications. 558 Any and all cryptographic authentication work on these 559 specifications will occur in Routing Area working groups, with 560 close partnership with the Security Area. Co-advisors from the 561 Security Area may often be named for these partnership efforts. 563 o Security Area reviewers of routing area documents - These people 564 are delegated by the Security Area Directors to perform reviews on 565 routing protocol specifications as they pass through working group 566 last call or IESG review. They will pay particular attention to 567 the use of cryptographic authentication and newly specified 568 security mechanisms for the routing protocols. They will ensure 569 that incremental security improvements are being made, in line 570 with this roadmap. 572 o Security Area engineers - These people partner with routing area 573 authors/designers on the security mechanisms in routing protocol 574 specifications. Some of these security area engineers will be 575 assigned by the Security Area Directors, while others will be 576 interested parties in the relevant working groups. 578 o Operators - The operators are a key audience for this work, as the 579 work is considered to have succeeded only if operators deploy the 580 technology, presumably due to a perception of significantly 581 improved security value coupled with relative similarity to 582 deployment complexity and cost. Conversely, the work will be 583 considered a failure if the operators do not care to deploy it, 584 either due to lack of value or perceived (or real) over- 585 complexity of operations. As a result, the GROW and OPSEC WGs 586 should be kept squarely in the loop as well. 588 3. Threats 590 In this document we will use the definition of "threat" as defined in 591 RFC4949 [RFC4949]: "a potential for violation of security, which 592 exists when there is a circumstance, capability, action, or event 593 that could breach security and cause harm." 595 This section defines the threats that are in scope for the KARP 596 effort. It also lists those threats that are explicitly out of scope 597 for the KARP effort. 599 This document leverages the "Generic Threats to Routing Protocols" 600 model, [RFC4593]. Specifically, the threats below were derived by 601 reviewing [RFC4593], analyzing the KARP problem space relative to it, 602 and simply listing the threats that are applicable to the KARP design 603 teams' work. This document categorizes [RFC4593] threats into those 604 in scope and those out of scope for KARP. Each in-scope threat is 605 discussed below, and its applicability to the KARP problem space is 606 described. As such, the below text intentionally does not constitute 607 a self-standing, complete threat analysis, but rather describes the 608 applicability of the existing threat analysis [RFC4593]relevant to 609 KARP. 611 Note: terms from [RFC4593] appear capitalized below -- e.g. 612 OUTSIDERS -- so as to make explicit the term's origin, and to enable 613 rapid cross referencing to the source RFC. 615 For convenience, a terse definition of most [RFC4593] terms is 616 offered here. Those interested in a more thorough description of 617 routing protocol threat sources, motivations, consequences and 618 actions will want to read [RFC4593] before continuing here. 620 3.1. Threat Sources 622 3.1.1. OUTSIDERS 624 One of the threats that will be addressed in this roadmap are those 625 where the source is an OUTSIDER. An OUTSIDER attacker may reside 626 anywhere in the Internet, have the ability to send IP traffic to the 627 router, may be able to observe the router's replies, and may even 628 control the path for a legitimate peer's traffic. OUTSIDERS are not 629 legitimate participants in the routing protocol. The use of message 630 authentication and integrity protection specifically aims to identify 631 packets originating from OUTSIDERS. 633 KARP design teams will consider two specific use cases of OUTSIDERS: 634 those on-path, and those off-path. 636 o On-Path - These sources have control of a network resource or a 637 tap that sits along the path of packets between the two routing 638 peers. A "Man-in-the-Middle" (MitM) is an on-path attacker. From 639 this vantage point, the attacker can conduct either active or 640 passive attacks. An active attack occurs when the attacker 641 actually places packets on the network as part of the attack. One 642 active MitM attack relevant to KARP, an active wiretapping attack, 643 occurs when the attacker tampers with packets moving between two 644 legitimate router peers in such a way that both peers think they 645 are talking to each other directly, when in fact they are actually 646 talking to the attacker only. Protocols conforming to this 647 roadmap will use cryptographic mechanisms to detect MitM attacks 648 and reject packets from such attacks (i.e. treat them as not 649 authentic). Passive on-path attacks occur when the attacker 650 silently gathers data and analyses it to gain advantage. Passive 651 activity by an on-path attacker may often eventually lead to an 652 active attack. 654 o Off-Path - These sources sit on some network outside of that over 655 which runs the packets between two routing peers. The source may 656 be one or several hops away. Off-path attackers can launch active 657 attacks, such as SPOOFING or denial-of-service (DoS) attacks, to 658 name a few. 660 3.1.2. Stolen Keys 662 This threat source exists when an unauthorized entity somehow manages 663 to gain access to keying material. Using this material, the attacker 664 could send packets that pass the authenticity checks based on message 665 authentication codes (MACs). The resulting traffic might appear to 666 come from router A to router B, and thus the attacker could 667 impersonate an authorized peer. The attacker could then adversely 668 affect network behavior by sending bogus messages that appear to be 669 authentic. The attack source possessing the stolen keys could be on- 670 path, off-path, or both. 672 The obvious mitigation for stolen keys is to change the keys 673 currently in use by the legitimate routing peers. This mitigation 674 can be either reactive or pro-active. Reactive mitigation occurs 675 when keys are changed only after having discovered that the previous 676 keys fell into the possession of unauthorized users. The stolen 677 keys, reactive mitigation case is highlighted here in order to 678 explain a common operational situation where new keying material will 679 become necessary with little or no advanced warning. In such a case 680 new keys must be able to be installed and put into use very quickly, 681 and with little operational expense. Pro-active mitigation occurs 682 when an operator assumes that unauthorized possession will occur from 683 time to time without being discovered, and the operator moves to new 684 keying material in order to cut short, or make nonexistent, an 685 attacker's window of opportunity to use the stolen keys effectively. 687 In KARP, we can address the attack source with stolen keys by 688 creating specifications that make it practical for the operator to 689 quickly change keys without disruption to the routing system, and 690 with minimal operational overhead. Operators can further mitigate 691 the stolen keys case by habitually changing keys. 693 3.1.2.1. Terminated Employee 695 A terminated employee is an important example of a "stolen keys" 696 threat source to consider. Staff attrition is a reality in routing 697 operations, and so regularly causes the potential for a threat 698 source. The threat source risk arises when a network operator who 699 had been granted access to keys ceases to be an employee. If new 700 keys are deployed immediately, the situation of a terminated employee 701 can become a "stolen keys, pro-active" case, as described above, 702 rather than a "stolen keys, reactive" case. 704 On one hand, terminated employees could be considered INSIDERS rather 705 than OUTSIDERS, because at one point in time they were authorized to 706 have the keys. On the other hand, they aren't really a BYZANTINE 707 attacker, which is defined to be an attack from an INSIDER, a 708 legitimate router. Further, once terminated, the authorization 709 granted to the terminated employee regarding the keys is revoked. If 710 they maintain possession of the keys they are acting in an 711 unauthorized way. If they go on to use those keys to launch an 712 attack they are definitely acting in an unauthorized way. In this 713 way the terminated employee becomes an OUTSIDER at the point of 714 termination, they cease to be legitimate participants in the routing 715 system. It behooves the operator to change the keys, to enforce the 716 revocation of authorization of the old keys, in order to minimize the 717 threat source's window of opportunity. 719 Regardless of whether one considers a terminated employee an 720 "insider" or an OUTSIDER, it is important to consider them a threat 721 source, study the use case, and address the threats therein. In such 722 a case within the KARP context, new keys must be able to be installed 723 and made operational in the routing protocols very quickly, with zero 724 impact to the routing system, and with little operational expense. 726 The threat source of the terminated employee and/or the detected- 727 stolen-keys drives the requirement for quick and easy key rollover. 728 The threat actions associated with these sources are mitigated if the 729 operator has mechanisms in place (both inherent in the protocol, as 730 well as built into their management systems) that allow them to roll 731 the keys quickly with minimal impact to the routing system, at low 732 operational cost. 734 3.2. Threat Actions In Scope 736 These ATTACK ACTIONS are in scope for KARP: 738 o SPOOFING - when an unauthorized device assumes the identity of an 739 authorized one. SPOOFING can be used, for example, to inject 740 malicious routing information that causes the disruption of 741 network services. SPOOFING can also be used to cause a neighbor 742 relationship to form that subsequently denies the formation of the 743 relationship with the legitimate router. 745 o DoS attacks at the transport layer - This is an example of 746 SPOOFING. It can also be an example of FALSIFICATION and 747 INTERFERENCE (see below). It occurs when an attacker sends 748 spoofed packets aimed at halting or preventing the underlying 749 protocol over which the routing protocol runs. For example, BGP 750 running over TLS will still not solve the problem of being able to 751 send a spoofed TCP FIN or TCP RST and causing the BGP session to 752 go down. Since this attack depends on spoofing, operators are 753 encouraged to deploy proper authentication mechanisms to prevent 754 such attacks. Specification work should ensure that Routing 755 Protocols can operate over transport sub-systems in a fashion that 756 is resilient to such DoS attacks. 758 o FALSIFICATION - an action whereby an attacker sends false routing 759 information. To falsify the routing information, an attacker has 760 to be either the originator or a forwarder of the routing 761 information. FALSIFICATION may occur by an ORIGINATOR, or a 762 FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or 763 MISTATEMENT of network resource reachability. We must be careful 764 to remember that in this work we are only targeting FALSIFICATION 765 from OUTSIDERS as may occur from tampering with packets in flight, 766 or sending entirely false messages. FALSIFICATION from BYZANTINES 767 (see the Threats Out of Scope section below) are not addressed by 768 the KARP effort. 770 o INTERFERENCE - when an attacker inhibits the exchanges by 771 legitimate routers. The types of INTERFERENCE addressed by this 772 work include: 774 A. ADDING NOISE 776 B. REPLAYING OUT-DATED PACKETS 778 C. INSERTING MESSAGES 779 D. CORRUPTING MESSAGES 781 E. BREAKING SYNCHRONIZATION 783 F. Changing message content 785 o DoS attacks using the authentication mechanism - This includes an 786 attacker sending packets that confuse or overwhelm a security 787 mechanism itself. An example is initiating an overwhelming load 788 of spoofed routing protocol packets that contain a MAC, so that 789 the receiver needs to spend the processing cycles to check the 790 MAC, only to discard the spoofed packet, consuming substantial CPU 791 resources. Another example is when an attacker sends an 792 overwhelming load of keying protocol initiations from bogus 793 sources. 795 o Brute Force Attacks Against Password/Keys - This includes either 796 online or offline attacks where attempts are made repeatedly using 797 different keys/passwords until a match is found. While it is 798 impossible to make brute force attacks on keys completely 799 unsuccessful, proper design can make such attacks much harder to 800 succeed. For example, the key length should be sufficiently long 801 so that covering the entire space of possible keys is improbable 802 using computational power expected to be available 10 years out or 803 more. Using per session keys is another widely used method for 804 reducing the number of brute force attacks as this would make it 805 difficult to guess the keys. 807 3.3. Threat Actions Out of Scope 809 Threats from BYZANTINE sources -- faulty, misconfigured, or subverted 810 routers, i.e., legitimate participants in the routing protocol -- are 811 out of scope for this roadmap. Any of the attacks described in the 812 above section (Section 2.1) that may be levied by a BYZANTINE source 813 are therefore also out of scope, e.g. FALSIFICATION, or unauthorized 814 message content by a legitimate authorized peer. 816 In addition, these other attack actions are out of scope for this 817 work: 819 o SNIFFING - passive observation of route message contents in 820 flight. Data privacy, as achieved by data encryption, is the 821 common mechanism for preventing SNIFFING. While useful, 822 especially to prevent the gathering of data needed to perform an 823 off-path packet injection attack, data encryption is out-of-scope 824 for KARP. 826 o INTERFERENCE due to: 828 A. NOT FORWARDING PACKETS - cannot be prevented with 829 cryptographic authentication. Note: If sequence numbers with 830 sliding windows are used in the solution (as is done, for 831 example, in IPsec's ESP [RFC4303]and BFD [RFC5880], a receiver 832 can at least detect the occurrence of this attack. 834 B. DELAYING MESSAGES - cannot be prevented with cryptographic 835 authentication. Note: Timestamps can be used to detect 836 delays. 838 C. DENIAL OF RECEIPT - cannot be prevented with cryptographic 839 authentication 841 D. UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR 842 working group 843 (http://www.ietf.org/html.charters/sidr-charter.html). 845 E. DoS attacks not involving the routing protocol. For example, 846 a flood of traffic that fills the link ahead of the router, so 847 that the router is rendered unusable and unreachable by valid 848 packets is NOT an attack that KARP will address. Many such 849 examples could be contrived. 851 4. Requirements for KARP Work Phase 1, the Update to a Routing 852 Protocol's Existing Transport Security 854 The KARP Design Guide [RFC6518], Section 4.1 describes two distinct 855 work phases for the KARP effort. This section addresses requirements 856 for the first work phase only, "Work Phase 1", the update to a 857 routing protocol's existing transport security. "Work Phase 2", a 858 framework and usage of a KMP, will be addressed in a future 859 document(s)." 861 The following list of requirements SHOULD be addressed by a KARP Work 862 Phase 1 security update to any Routing Protocol (according to section 863 4.1 of the KARP Design Guide [RFC6518]document). IT IS RECOMMENDED 864 that any Work Phase 1 security update to a Routing Protocol contain a 865 section of the specification document that describes how each of the 866 below requirements are met. It is further RECOMMENDED that 867 justification be presented for any requirements that are NOT 868 addressed. 870 1. Clear definitions of which elements of the transmitted data 871 (frame, packet, segment, etc.) are protected by the 872 authentication mechanism 874 2. Strong cryptographic algorithms, as defined and accepted by the 875 IETF security community, MUST be specified. The use of non- 876 standard or unpublished algorithms SHOULD BE avoided. 878 3. Algorithm agility for the cryptographic algorithms used in the 879 authentication MUST be specified, i.e. more than one algorithm 880 MUST be specified and it MUST be clear how new algorithms MAY be 881 specified and used within the protocol. This requirement exists 882 because research identifying weaknesses in cryptographic 883 algorithms can cause the security community to reduce confidence 884 in some algorithms. Breaking a cipher isn't a matter of if, but 885 when it will occur. Having the ability to specify alternate 886 algorithms (algorithm agility) within the protocol specification 887 to support such an event is essential. Mandating two algorithms 888 provides both a redundancy, and a mechanism for enacting that 889 redundancy when needed. Further, the mechanism MUST describe 890 the generic interface for new cryptographic algorithms to be 891 used, so that implementers can use algorithms other than those 892 specified, and so that new algorithms may be specified and 893 supported in the future. 895 4. Secure use of PSKs, offering both operational convenience and a 896 baseline level of security, MUST be specified. 898 5. Routing protocols (or the transport or network mechanism 899 protecting routing protocols) should be able to detect and 900 reject replayed messages. For non TCP based protocols like OSPF 901 [RFC2328], IS-IS [RFC1195] , etc., two routers are said to have 902 a session up if they are able to exchange protocol packets. 903 Packets captured from one session must not be able to be re-sent 904 and accepted during a later session. Additionally, replay 905 mechanisms must work correctly even in the presence of routing 906 protocol packet prioritization by the router. 908 A. There is a specific case of replay attack combined with 909 spoofing that must be addressed. In several routing 910 protocols (e.g., OSPF [RFC2328], IS-IS [RFC1195], BFD 911 [RFC5880], RIP [RFC2453], etc.), all speakers share the same 912 key (K) on a broadcast segment. The ability to run a MAC 913 operation with K is used for identity validation, and 914 (currently) no other identity validation check is performed. 915 Assume there are four routers using authentication on a LAN, 916 R1 - R4. Also assume attacker "Z", who is NOT a legitimate 917 neighbor, is observing and recording packets on the same LAN 918 segment. Z captures a packet from R1, and changes the 919 source IP, spoofing it to that of R2, then sends the packet 920 on the LAN. Z does not have K, but in this case it does not 921 matter because R1 already performed the MAC operation, and Z 922 simply re-uses that MAC. R3 and R4 will process the packet 923 as if coming from R2, the MAC check will return valid, and 924 they will update their route tables accordingly. R3 and R4 925 have confirmed that the MAC was created by someone holding 926 K, but not that it was actually sent by R2. This is a well 927 known attack with known solutions. Some string must be 928 added into the MAC operation that uniquely identifies the 929 sender. Said string must also be located in the packet such 930 that if that string were to be altered after the MAC 931 operation, it would be detected by the receiver. Examples 932 of solutions used in other protocols include sequence 933 numbers with sliding acceptance windows, time stamps, IP 934 header info (SRC, DST), unique identifiers which are 935 temporarily bound to an IP Address. 937 6. A change of security parameters REQUIRES, and even forces, a 938 change of session traffic keys. The specific security 939 parameters for the various routing protocols will differ, and 940 will be defined by each protocols design team. Some examples 941 may include: master key, key lifetime, cryptographic algorithm, 942 etc. If one of these configured parameters changes, then a new 943 session traffic key must immediately be established using the 944 updated parameters. The routing protocol security mechanisms 945 MUST support this behavior. 947 7. Intra-session re-keying which occurs without a break or 948 interruption to the current routing session, and, if possible, 949 without data loss, MUST be specified. Keys need to be changed 950 periodically, for operational confidentiality (e.g. when an 951 administrator who had access to the keys leaves an organization) 952 and for entropy purposes, and a re-keying mechanism enables the 953 operators to execute the change without productivity loss. 955 8. Efficient re-keying SHOULD be provided. The specification 956 SHOULD support rekeying during a session without needing to try/ 957 compute multiple keys on a given packet. The rare exception 958 will occur if a routing protocols design team can find no other 959 way to re-key and still adhere to the other requirements in this 960 section. 962 9. New mechanisms must resist DoS attacks described as in-scope in 963 Section 3.2. Routers protect the control plane by implementing 964 mechanisms to filter completely or rate limit traffic not 965 required at the control plane level (i.e., unwanted traffic). 966 Typically line rate packet filtering capabilities look at 967 information at or below the IP and transport (TCP or UDP) 968 headers, but do not include higher layer information. Therefore 969 the new mechanisms shouldn't hide nor encrypt the information 970 carried in the IP and transport layers in control plane packets. 972 10. Mandatory cryptographic algorithms and mechanisms MUST be 973 specified for a routing protocol. Further, the protocol 974 specification MUST define default security mechanism settings 975 for all implementations to use when no explicit configuration is 976 provided. To understand the need for this requirement, consider 977 the case where a routing protocol mandates 3 different 978 cryptographic algorithms for a MAC operation. If company A 979 implements algorithm 1 as the default for this protocol, while 980 company B implements algorithm 2 as the default, then two 981 operators who enable the security mechanism with no explicit 982 configuration other than a PSK will experience a connection 983 failure. It is not enough that each implementation implement 984 the 3 mandatory algorithms; one default must further be 985 specified in order to gain maximum out-of-the-box 986 interoperability. 988 11. For backward compatibility reasons manual keying MUST be 989 supported. 991 12. Architecture of the specification SHOULD consider and allow for 992 future use of a KMP. 994 13. The authentication mechanism in the Routing Protocol MUST be 995 decoupled from the key management system used. It MUST be 996 obvious how the keying material was obtained, and the process 997 for obtaining the keying material MUST exist outside of the 998 Routing Protocol. This will allow for the various key 999 generation methods, like manual keys and KMPs, to be used with 1000 the same Routing Protocol mechanism. 1002 14. Convergence times of the Routing Protocols SHOULD NOT be 1003 materially affected. "Materially" is defined here as anything 1004 greater than a 5% increase in convergence time. Changes in the 1005 convergence time will be immediately verifiable by convergence 1006 performance test beds already in use by most router vendors and 1007 service providers. Note that convergence is different than boot 1008 time. Also note that convergence time has a lot to do with the 1009 speed of processors used on individual routing peers, and this 1010 processing power increases by Moore's law over time, meaning 1011 that the same route calculations and table population routines 1012 will decrease in duration over time. Therefore, this 1013 requirement should be considered only in terms of total number 1014 of protocol packets that must be exchanged, and less for the 1015 computational intensity of processing any one message. 1016 Alternatively this can be simplified by saying that the new 1017 mechanisms should only result in a minimal increase in the 1018 number of routing protocol packets passed between the peers. 1020 15. The changes to or addition of security mechanisms SHOULD NOT 1021 cause a refresh of route advertisements or cause additional 1022 route advertisments to be generated. 1024 16. Router implementations provide prioritized treatment for certain 1025 protocol packets. For example, OSPF HELLO packets and ACKs are 1026 prioritized for processing above other OSPF packets. The 1027 security mechanism SHOULD NOT interfere with the ability to 1028 observe and enforce such prioritization. Any effect on such 1029 priority mechanisms MUST be explicitly documented and justified. 1030 Replay protection mechanisms provided by the routing protocols 1031 MUST work even if certain protocol packets are offered 1032 prioritized treatment. 1034 17. Routing protocols MUST only send minimal information regarding 1035 the authentication mechanisms and the parameters in its protocol 1036 packets. One reason for this is to keep the Routing Protocols 1037 as clean and focused as possible, and load security negotiations 1038 into the future KMP as much as possible. Another reason is to 1039 avoid exposing any security negotiation information 1040 unnecessarily to possible attackers on the path. 1042 18. Routing protocols that rely on the IP header (or information 1043 seperate from routing protocol payload) to identify the neighbor 1044 that originated the packet, MUST either protect the IP header or 1045 provide some other means to authenticate the neighbor. 1046 [RFC6039] describes some attacks that are based on this. 1048 19. Every new KARP-developed security mechanisms MUST support 1049 incremental deployment. It will not be feasible to deploy a new 1050 Routing Protocol authentication mechanism throughout a network 1051 instantaneously. It also may not be possible to deploy such a 1052 mechanism to all routers in a large autonomous system (AS) at 1053 one time. Proposed solutions MUST support an incremental 1054 deployment method that provides some benefit for those who 1055 participate. Because of this, there are several requirements 1056 that any proposed KARP mechanism should consider. 1058 A. The Routing Protocol security mechanism MUST enable each 1059 router to configure use of the security mechanism on a per- 1060 peer basis where the communication is peer-to-peer 1061 (unicast). 1063 B. Every new KARP-developed security mechanism MUST provide 1064 backward compatibility in the message formatting, 1065 transmission, and processing of routing information carried 1066 through a mixed security environment. Message formatting in 1067 a fully secured environment MAY be handled in a non-backward 1068 compatible fashion though care must be taken to ensure that 1069 routing protocol packets can traverse intermediate routers 1070 that don't support the new format. 1072 C. In an environment where both secured and non-secured systems 1073 are interoperating, a mechanism MUST exist for secured 1074 systems to identify whether a peer intended the messages to 1075 be secured. 1077 D. In an environment where secured service is in the process of 1078 being deployed, a mechanism MUST exist to support a 1079 transition free of service interruption (caused by the 1080 deployment per se). 1082 20. The introduction of mechanisms to improve routing security may 1083 increase the processing performed by a router. Since most of 1084 the currently deployed routers do not have hardware to 1085 accelerate cryptographic operations, these operations could 1086 impose a significant processing burden under some circumstances. 1087 Thus proposed solutions should be evaluated carefully with 1088 regard to the processing burden they may impose, since 1089 deployment may be impeded if network operators perceive that a 1090 solution will impose a processing burden which either incurs 1091 substantial capital expense, or threatens to destabilize 1092 routers. 1094 21. Given the number of routers that would require the new 1095 authentication mechanisms in a typical ISP deployment, solutions 1096 can increase their appeal by minimizing the burden imposed on 1097 all routers in favor of confining significant work loads to a 1098 relatively small number of devices. Optional features or 1099 increased assurance that engenders more pervasive processing 1100 loads MAY be made available for deployments where the additional 1101 resources are economically justifiable. 1103 22. New authentication and security mechanisms should not rely on 1104 systems external to the routing system (the equipment that is 1105 performing forwarding) in order for the routing system to 1106 function. In order to ensure the rapid initialization and/or 1107 return to service of failed nodes it is important to reduce 1108 reliance on these external systems to the greatest extent 1109 possible. Proposed solutions SHOULD NOT require connections to 1110 external systems, beyond those directly involved in peering 1111 relationships, in order to return to full service. It is 1112 however acceptable for the proposed solutions to require post 1113 initialization synchronization with external systems in order to 1114 fully synchronize the security information. 1116 If authentication and security mechanisms rely on systems 1117 external to the routing system, then there MUST be one or more 1118 options available to avoid circular dependencies. It is not 1119 acceptable to have a routing protocol (e.g., unicast routing) 1120 depend upon correct operation of a security protocol that, in 1121 turn, depends upon correct operation of the same instance of 1122 that routing protocol (i.e., the unicast routing). However, it 1123 is okay to have operation of a routing protocol (e.g., multicast 1124 routing) depend upon operation of a security protocol, which 1125 depends upon an independent routing protocol (e.g., unicast 1126 routing). Similarly it would be okay to have the operation of a 1127 routing protocol depend upon a security protocol, which in turn 1128 uses an out of band network to exchange information with remote 1129 systems. 1131 5. Security Considerations 1133 This document is mostly about security considerations for the KARP 1134 efforts, both threats and requirements for addressing those threats. 1135 More detailed security considerations were placed in the Security 1136 Considerations section of the KARP Design Guide [RFC6518]document. 1138 Spoofing by a Legitimate Neighbor - In several routing protocols (e.g 1139 OSPF) all speakers share the same key, a group key, on a broadcast 1140 segment. Possession of the group key itself is used for identity 1141 validation, and no other identity check is used. Under these 1142 conditions an attack exists where one neighbor (E.g. Router 1, or 1143 R1) can masquerade as a different neighbor, R2, by sending spoofed 1144 packets using R2 as the source IP address. When other neighbors, R3 1145 and R4, receive these packets, they will calculate the MAC 1146 successfully, and process its contents as if it originated from R2. 1147 SPOOFING this way, the attacker can succeed in several different 1148 types of attacks, including FALSIFICATION and INTERFERENCE. The 1149 source of such an attack is a BYZANTINE actor, since the attack 1150 originates from a legitimate actor in the routing system, and such 1151 sources are out of scope for KARP. This type of attack has been well 1152 documented in the group keying problem space, and it's non-trivial to 1153 solve. The common method used to prevent this type of attack is to 1154 use a unique key for each sender rather than a group key. Other 1155 solutions exist within the group keying realm, but they come with 1156 significant increases in complexity and computational intensity. 1158 6. IANA Considerations 1160 This document has no actions for IANA. 1162 7. Acknowledgements 1164 The majority of the text for version -00 of this document was taken 1165 from "Roadmap for Cryptographic Authentication of Routing Protocol 1166 Packets on the Wire", draft-lebovitz-karp-roadmap, authored by 1167 Gregory M. Lebovitz. 1169 Brian Weis provided significant assistance in handling the many 1170 comments that came back during IESG review. 1172 We would like to thank the following people for their thorough 1173 reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent, 1174 Vishwas Manral. 1176 Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for 1177 the majority of the time he worked on this document, though not at 1178 the time of its publishing. Thus Juniper sponsored much of this 1179 effort. 1181 8. References 1183 8.1. Normative References 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, March 1997. 1188 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1189 Routing Protocols", RFC 4593, October 2006. 1191 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1192 IAB workshop on Unwanted Traffic March 9-10, 2006", 1193 RFC 4948, August 2007. 1195 8.2. Informative References 1197 [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure 1198 Security Report", October 2008, 1199 . 1201 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1202 dual environments", RFC 1195, December 1990. 1204 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1206 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1207 November 1998. 1209 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1210 Signature Option", RFC 3562, July 2003. 1212 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1213 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1215 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1216 Internet Protocol", RFC 4301, December 2005. 1218 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1219 RFC 4303, December 2005. 1221 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 1222 Authentication", RFC 4822, February 2007. 1224 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1225 RFC 4949, August 2007. 1227 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1228 Specification", RFC 5036, October 2007. 1230 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1231 and M. Fanto, "IS-IS Generic Cryptographic 1232 Authentication", RFC 5310, February 2009. 1234 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 1235 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 1236 Authentication", RFC 5709, October 2009. 1238 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1239 (BFD)", RFC 5880, June 2010. 1241 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1242 Authentication Option", RFC 5925, June 2010. 1244 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 1245 with Existing Cryptographic Protection Methods for Routing 1246 Protocols", RFC 6039, October 2010. 1248 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 1249 Routing Protocols (KARP) Design Guidelines", RFC 6518, 1250 February 2012. 1252 Authors' Addresses 1254 Gregory Lebovitz 1255 Aptos, California 95003 1256 USA 1258 Email: gregory.ietf@gmail.com 1260 Manav Bhatia 1261 Alcatel-Lucent 1262 Bangalore, 1263 India 1265 Phone: 1266 Email: manav.bhatia@alcatel-lucent.com