idnits 2.17.1 draft-ietf-karp-threats-reqs-07.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 (December 19, 2012) is 4117 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4303' is defined on line 1188, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: June 22, 2013 Alcatel-Lucent 6 B. Weis 7 Cisco Systems 8 December 19, 2012 10 Keying and Authentication for Routing Protocols (KARP) Overview, 11 Threats, and Requirements 12 draft-ietf-karp-threats-reqs-07 14 Abstract 16 Different routing protocols employ different mechanisms for securing 17 protocol packets on the wire. While most already have some method 18 for accomplishing cryptographic message authentication, in many cases 19 the existing methods are dated, vulnerable to attack, and employ 20 cryptographic algorithms that have been deprecated. The "Keying and 21 Authentication for Routing Protocols" (KARP) effort aims to overhaul 22 and improve these mechanisms. 24 This document does not contain protocol specifications. Instead, it 25 defines the areas where protocol specification work is needed and a 26 set of requirements for KARP design teams to follow. RFC 6518, 27 "Keying and Authentication for Routing Protocols (KARP) Design 28 Guidelines" is a companion to this document; KARP design teams will 29 use them together to review and overhaul routing protocols. These 30 two documents reflect the input of both the IETF Security Area and 31 IETF Routing Area in order to form a mutually agreeable work plan. 33 This document has three main parts. The first part provides an 34 overview of the KARP effort. The second part lists the threats from 35 RFC 4593 (Generic Threats To Routing Protocols) that are in scope for 36 attacks against routing protocol transport systems. This includes 37 any mechanisms built into the routing protocols themselves, to 38 authenticate packets. The third part enumerates the requirements 39 that routing protocol specifications must meet when addressing those 40 threats for RFC 6518's "Work Phase 1", the update to a routing 41 protocol's existing transport security. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on June 22, 2013. 60 Copyright Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 79 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 8 81 2. KARP Effort Overview . . . . . . . . . . . . . . . . . . . . . 9 82 2.1. KARP Scope . . . . . . . . . . . . . . . . . . . . . . . . 9 83 2.2. Incremental Approach . . . . . . . . . . . . . . . . . . . 10 84 2.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 2.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 86 2.5. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 3.1. Threat Sources . . . . . . . . . . . . . . . . . . . . . . 15 90 3.1.1. OUTSIDERS . . . . . . . . . . . . . . . . . . . . . . 15 91 3.1.2. Unauthorized Key Holder . . . . . . . . . . . . . . . 16 92 3.1.2.1. Terminated Employee . . . . . . . . . . . . . . . 17 93 3.1.3. BYZANTINE . . . . . . . . . . . . . . . . . . . . . . 17 94 3.2. Threat Actions In Scope . . . . . . . . . . . . . . . . . 18 95 3.3. Threat Actions Out of Scope . . . . . . . . . . . . . . . 19 97 4. Requirements for KARP Work Phase 1, the Update to a 98 Routing Protocol's Existing Transport Security . . . . . 21 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 112 1. Introduction 114 In March 2006 the Internet Architecture Board (IAB) held a workshop 115 on the topic of "Unwanted Internet Traffic". The report from that 116 workshop is documented in [RFC4948]. Section 8.1 of that document 117 states "A simple risk analysis would suggest that an ideal attack 118 target of minimal cost but maximal disruption is the core routing 119 infrastructure." Section 8.2 calls for "[t]ightening the security of 120 the core routing infrastructure." Four main steps were identified 121 for that tightening: 123 o Create secure mechanisms and practices for operating routers. 125 o Clean up the Internet Routing Registry repository (IRR), and 126 securing both the database and the access, so that it can be used 127 for routing verification. 129 o Create specifications for cryptographic validation of routing 130 message content. 132 o Secure the routing protocols' packets on the wire 134 The first bullet is being addressed in the OPSEC working group. The 135 second bullet should be addressed through liaisons with those running 136 the IRR's globally. The third bullet is being addressed in other 137 efforts within the IETF. For example, BGP message content validity 138 is being addressed in the SIDR working group. 140 This document addresses the last item in the list above, securing the 141 transmission of routing protocol packets on the wire. More 142 precisely, it focuses on securing the transport systems employed by 143 routing protocols, including any mechanisms built into the protocols 144 themselves to authenticate packets. This effort is referred to as 145 Keying and Authentication for Routing Protocols, or "KARP". KARP is 146 concerned with issues and techniques for protecting the messages 147 between directly communicating peers. This may overlap with, but is 148 strongly distinct from, protection designed to ensure that routing 149 information is properly authorized relative to the source of the 150 information. Such assurances are provided by other mechanisms and 151 are outside the scope of this document. 153 This document is one of two that together form the guidance and 154 instructions for KARP design teams working to overhaul routing 155 protocol transport security. The other document is the KARP Design 156 Guide [RFC6518]. 158 This document does not contain protocol specifications. Instead, its 159 goal is to define the areas where protocol specification work is 160 needed and to provide a set of requirements for KARP design teams to 161 follow as they update a routing protocol's existing transport 162 security (see[RFC6518], Section 4.1's "Work Phase 1"). 164 This document has three main parts. The first part, found in Section 165 2, provides an overview of the KARP effort. Section 3 lists the 166 threats from [RFC4593], (Generic Threats To Routing Protocols), that 167 are in scope for per-packet authentication for routing protocol 168 transport systems. Therefore, this document does not contain a 169 complete threat model; it simply points to the parts of the governing 170 threat model that KARP design teams must address, and explicitly 171 states which parts are out of scope for KARP design teams. Section 4 172 enumerates the requirements that routing protocol specifications must 173 meet when addressing those threats related to KARP's "Work Phase 1", 174 the update to a routing protocol's existing transport security. 175 ("Work Phase 2", a framework and usage of a KMP, will be addressed in 176 a future document[s]). 178 This document uses the terminology "on the wire" to refer to the 179 information used by routing protocols' transport systems. This term 180 is widely used in IETF RFCs, but is used in several different ways. 181 In this document, it is used to refer both to information exchanged 182 between routing protocol instances, and to underlying protocols that 183 may also need to be protected in specific circumstances. Individual 184 protocol analysis documents will need to be more specific in their 185 use of this phrase. 187 1.1. Terminology 189 Within the scope of this document, the following words, when 190 beginning with a capital letter, or spelled in all capitals, hold the 191 meanings described immediately following each term. If the same word 192 is used uncapitalized, then it is intended to have its common English 193 definition. 195 Identifier 197 The type and value used by a peer of an authenticated message 198 exchange to signify who it is to another peer. The Identifier is 199 used by the receiver as an index into a table containing further 200 information about the peer that is required to continue processing 201 the message, for example a Security Association (SA) or keys. 203 Identity Authentication 204 Once the identity is verified, then there must be a cryptographic 205 proof of that identity, that the peer really is who it asserts to 206 be. Proof of identity can be arranged among peers in a few ways, 207 for example symmetric and asymmetric pre-shared keys, or an 208 asymmetric key contained in a certificate. Certificates can be 209 used in ways that requires no additional supporting systems 210 external to the routers themselves. An example of this would be 211 using self signed certificates and a flat file list of "approved 212 thumbprints". The use of these different identity verification 213 mechanisms vary in ease of deployment, ease of ongoing management, 214 startup effort, security strength, and consequences from loss of 215 secrets from one part of the system to the rest of the system. 216 For example, they differ in resistance to a security breach, and 217 the effort required to recover in the event of such a breach. The 218 point here is that there are options, many of which are quite 219 simple to employ and deploy. 221 KDF (Key derivation function) 223 A KDF is a function in which an input key and other input data is 224 used to generate keying material that can be employed by 225 cryptographic algorithms. The key that is input to a KDF is 226 called a key derivation key. KDFs can be used to generate one or 227 more keys from either (i) a random or pseudorandom seed value or 228 (ii) result of the Diffie-Hellman exchange or (iii) a non-uniform 229 random source (e.g., from a non-deterministic random bit 230 generator) or (iv) a pre-shared key which may or may not be 231 memorable by a human. 233 KMP (Key Management Protocol) 235 A protocol to establish a shared symmetric key between a pair (or 236 among a group) of users. It determines how secret keys are made 237 available to the users and in some cases also determines how the 238 secret keys are generated. In some routing protocols traffic keys 239 are derived by the routing protocol from a master key. In this 240 case, KMP is responsible for the master key generation and for 241 determining when it should be renewed. In other cases, there are 242 only traffic keys (and no master key), and in such a case KMP is 243 responsible for the traffic key generation and renewal mechanism. 245 KMP Function 247 Any KMP used in the general KARP solution framework 248 Peer Key 250 Keys that are used among peers as a basis for identifying one 251 another. These keys may or may not be connection-specific, 252 depending on how they were established, and what forms of identity 253 and identity authentication mechanism are used in the system. A 254 peer key generally would be provided by a KMP and would later be 255 used to derive fresh traffic keys. 257 PSK (Pre-Shared Key) 259 A key used to communicate with one or more peers in a secure 260 configuration. Always distributed out-of-band prior to a first 261 connection. 263 Replayed Messages 265 Replayed messages are genuine messages that have been re-sent by 266 an attacker. Messages may be replayed within a session (i.e., 267 intra-session) or replayed from a different session (i.e., inter- 268 session). For non-TCP based protocols like OSPF [RFC2328], IS-IS 269 [RFC1195], etc., two routers are said to have a session up if they 270 are able to exchange protocol packets (i.e., the peers have an 271 adjacency). Messages replayed during an adjacency are intra- 272 session replays while message replayed between two peers who re- 273 establish an adjacency after a reboot or loss of connectivity are 274 inter-session replays. 276 Routing Protocol 278 When used with capital "R" and "P" in this document the term 279 refers the Routing Protocol for which work is being done to its 280 packets on the wire. 282 SA (Security Association) 284 A relationship established between two or more entities to enable 285 them to protect data they exchange. Examples of attributes that 286 may be associated with an SA include: Identifier, PSK, Traffic 287 Key, cryptographic algorithms, key lifetimes. 289 Threat Source 291 A threat source is a motivated, capable adversary. 293 Traffic Key 295 The key (or one of a set of keys) used for protecting the routing 296 protocol traffic. A traffic key should not be a fixed value in a 297 device configuration. A traffic key should be known only to the 298 participants in a connection, so that a compromise of a stored key 299 (possibly available to a terminated or turned employee) does not 300 result in disclosure of traffic keys. If a server or other data 301 store is stolen or compromised, the attackers gain no access to 302 current traffic keys. They may gain access to key derivation 303 material, like a PSK, but not current traffic keys in use. 305 Additional terminology specific to threats are listed and defined 306 below in the Threats Section 3 section. 308 1.2. Requirements Language 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in RFC2119 [RFC2119]. 314 When used in lower case, these words convey their typical use in 315 common language, and are not to be interpreted as described in 316 RFC2119 [RFC2119]. 318 2. KARP Effort Overview 320 2.1. KARP Scope 322 Three basic principles are possible to secure any piece of data as it 323 is transmitted over the wire: confidentiality, authenticity, and 324 integrity. The focus for the KARP working group will be message 325 authentication and message integrity only. This work explicitly 326 excludes, at this point in time, confidentiality. Non-repudiation is 327 also excluded as a goal at this time. Since the objective of most 328 routing protocols is to broadly advertise the routing topology, 329 routing protocol packets are commonly sent in the clear; 330 confidentiality is not normally required for routing protocols. 331 However, ensuring that routing peers are authentically identified, 332 and that no rogue peers or unauthenticated packets can compromise the 333 stability of the routing environment is critical, and thus in scope. 334 Confidentiality and non-repudiation may be addressed in future work. 336 OSPF [RFC5709], IS-IS [RFC5310], LDP [RFC5036], and RIP [RFC2453] 337 [RFC4822] already incorporate mechanisms for cryptographically 338 authenticating and integrity checking the messages on the wire. 339 Products with these mechanisms have been produced, code has been 340 written, and have been optimized for these existing security 341 mechanisms. Rather than turn away from these mechanisms, this 342 document aims to enhance them, updating them to modern and secure 343 levels. 345 Therefore, the scope of KARP's roadmap of work includes: 347 o Making use of existing routing protocol transport security 348 mechanisms, where they have been specified, and enhancing or 349 updating them as necessary for modern cryptographic best 350 practices. [RFC6518], Section 4.1 labels this KARP's "Work Phase 351 1." 353 o Developing a framework for using automatic key management in order 354 to ease deployment, lower cost of operation, and allow for rapid 355 responses to security breaches. [RFC6518], Section 4.1 labels 356 this KARP's "Work Phase 2." 358 o Specifying an automated key management protocol that may be 359 combined with Routing Protocol mechanisms. [RFC6518], Section 4.1 360 labels this KARP's "Work Phase 2." 362 Neither this document nor [RFC6518] contain protocol specifications. 363 Instead, they define the areas where protocol specification work is 364 needed and set a direction, a set of requirements, and priorities for 365 addressing that specification work. 367 There are a set of threats to routing protocols that are considered 368 in-scope for KARP, and a set considered out-of- scope. These are 369 described in detail in the Threats (Section 3) section below. 371 2.2. Incremental Approach 373 This document also serves as an agreement between the Routing Area 374 and the Security Area about the priorities and work plan for 375 incrementally delivering the above work. The principle of "crawl, 376 walk, run" will be employed. Thus routing protocol authentication 377 mechanisms may not go immediately from their current state to a state 378 reflecting the best possible, most modern security practices. This 379 point is important as there will be times when the best-security- 380 possible will give way to vastly-improved-over-current-security-but- 381 admittedly-not-yet-best-security-possible, in order that incremental 382 progress toward a more secure Internet may be achieved. As such, 383 this document will call out places where agreement has been reached 384 on such trade offs. 386 Incremental steps will need to be taken for a few very practical 387 reasons. First, there are a considerable number of deployed routing 388 devices in operating networks that will not be able to run the most 389 modern cryptographic mechanisms without significant and unacceptable 390 performance penalties. The roadmap for any routing protocol MUST 391 allow for incremental improvements on existing operational devices. 392 Second, current routing protocol performance on deployed devices has 393 been achieved over the last 20 years through extensive tuning of 394 software and hardware elements, and is a constant focus for 395 improvement by vendors and operators alike. The introduction of new 396 security mechanisms affects this performance balance. The 397 performance impact of any incremental security improvement will need 398 to be weighed by the community, and introduced in such a way that 399 allows the vendor and operator community a path to adoption that 400 upholds reasonable performance metrics. Therefore, certain 401 specification elements may be introduced carrying the "SHOULD" 402 guidance, with the intention that the same mechanism will carry a 403 "MUST" in a future release of the specification. This approach gives 404 the vendors and implementors the guidance they need to tune their 405 software and hardware appropriately over time. Last, some security 406 mechanisms require the build out of other operational support 407 systems, and this will take time. 409 An example where these three reasons were at play in an incremental 410 improvement roadmap was seen in the improvement of BGP's [RFC4271] 411 security via the TCP Authentication Option (TCP-AO) [RFC5925] effort. 412 It would have been ideal, and reflected best common security 413 practice, to have a fully specified key management protocol for 414 negotiating TCP-AO's keying material, e.g., using certificates for 415 peer authentication. However, in the spirit of incremental 416 deployment, the IETF first addressed issues like cryptographic 417 algorithm agility, replay attacks, and TCP session resetting in the 418 base TCP-AO protocol, and then later began work to layer key 419 management on top of it. 421 2.3. Goals 423 The goals and general guidance for the KARP work follow. 425 1. Provide authentication and integrity protection for messages on 426 the wire for existing routing protocols. 428 2. Define a path to incrementally improve security of the routing 429 infrastructure as explained in Section 2.2. 431 3. Ensure that the improved security solutions are deployable on 432 current routing infrastructure. This requires consideration of 433 the current state of processing power available on routers in the 434 network today. 436 4. Operational deployability - A solution's acceptability also will 437 be measured by how deployable the solution is by operator teams, 438 with consideration for their deployment processes and 439 infrastructures. Specifically, KARP design teams will try to 440 make these solutions fit as well as possible into current 441 operational practices and router deployment methodologies. Doing 442 so will depend heavily on operator input during KARP design 443 efforts. Hopefully, operator input will lead to a more 444 deployable solution, which will, in turn, lead to more production 445 deployments. Deployment of incrementally more secure routing 446 infrastructure in the Internet is the final measure of success. 447 We would like to see an increase in the number of respondents to 448 surveys such as [ISR2008] to report deploying the updated 449 authentication and integrity mechanisms in their networks, as 450 well as see a sharp rise in usage for the total percentage of 451 their network's routers. 453 Interviews with operators show several points about routing 454 security. First, according to [ISR2008], over 70% of operators 455 have deployed transport connection protection via TCP-MD5 456 [RFC3562] on their exterior Border Gateway Protocol (eBGP) 457 sessions. Over 55% also deploy TCP-MD5 on their interior Border 458 Gateway Protocol (iBGP) connections, and 50% make use of TCP-MD5 459 offered on some other internal gateway protocol (IGP). The same 460 survey states that "a considerable increase was observed over 461 previous editions of the survey for use of TCP MD5 with external 462 peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs." 463 Though the data is not captured in the report, the authors 464 believe anecdotally that of those who have deployed TCP-MD5 465 somewhere in their network, only about 25-30% of the routers in 466 their network are deployed with the authentication enabled. None 467 report using IPsec [RFC4301] to protect the routing protocol, and 468 this was a decline from the few that reported doing so in the 469 previous year's report. Anecdotal evidence from operators using 470 MD5 shows that almost all report using one, manually-distributed 471 key throughout the entire network. These same operators report 472 that the single key has not been changed since it was originally 473 installed, sometimes five or more years ago. When asked why, 474 particularly for the case of protecting BGP sessions using TCP 475 MD5, the following reasons are often given: 477 A. Changing the keys triggers a TCP reset, and thus bounces the 478 links/adjacencies, undermining Service Level Agreements 479 (SLAs). 481 B. For external peers, the difficulty of coordination with the 482 other organization is an issue. Once they find the correct 483 contact at the other organization (not always so easy), the 484 coordination function is serialized and on a per peer/AS 485 basis. The coordination is very cumbersome and tedious to 486 execute in practice. 488 C. Keys must be changed at precisely the same time, or at least 489 within 60 seconds (as supported by two major vendors) in order 490 to limit connectivity outage duration. This is incredibly 491 difficult to do, operationally, especially between different 492 organizations. 494 D. Key change is perceived as a relatively low priority compared 495 to other operational issues. 497 E. Lack of staff to implement the changes on a device-by-device 498 basis. 500 F. There are three use cases for operational peering at play 501 here: peers and interconnection with other operators, iBGP and 502 other routing sessions within a single operator, and operator- 503 to-customer devices. All three have very different 504 properties, and all are reported as cumbersome to manage 505 securely. One operator reported that the same key is used for 506 all customer premise equipment (CPE). The same operator 507 reported that if the customer mandated it, a unique key could 508 be created, although the last time this occurred it created 509 such an operational headache that the administrators now 510 usually tell customers that the option doesn't even exist, to 511 avoid the difficulties. These customer-unique keys are never 512 changed, unless the customer demands so. The main threat here 513 is that a terminated employee from such an operator who had 514 access to the one (or several) keys used for authentication in 515 these environments could wage an attack. Alternatively, the 516 operator could offer the keys to others who would wage the 517 attack. In either case, the attacker could then bring down 518 many of the adjacencies, causing destabilization to the 519 routing system. 521 5. Whatever mechanisms KARP specifies need to be easier to deploy 522 than the current methods, and should provide obvious operational 523 efficiency gains along with significantly better security. This 524 combination of value may be enough to drive much broader 525 adoption. 527 6. Address the threats enumerated below in the "Threats" section 528 (Section 3) for each routing protocol. Not all threats may be 529 able to be addressed in the first specification update for any 530 one protocol. Roadmaps will be defined so that both the security 531 area and the routing area agree on how the threats will be 532 addressed completely over time. 534 7. Create a re-usable architecture, framework, and guidelines for 535 various IETF working groups who will address these security 536 improvements for various Routing Protocols. The crux of the KARP 537 work is to re-use the architecture, guidelines and the framework 538 as much as possible across relevant Routing Protocols. For 539 example, designers should aim to re-use the key management 540 protocol that will be defined for BGP, which will establish keys 541 for TCP-AO, for as many other routing protocols with similar 542 characteristics and properties as possible. 544 8. Bridge any gaps between IETF Routing and IETF Security Areas by 545 recording agreements on work items, roadmaps, and guidance from 546 the cognizant Area Directors and the Internet Architecture Board 547 (IAB). 549 2.4. Non-Goals 551 The following goals are considered out-of-scope for this effort: 553 o Confidentiality and non-repudiation of the packets on the wire. 554 Once this roadmap is realized, work on confidentiality may be 555 considered. 557 o Non-repudiation of the packets on the wire. 559 o Message content validity (routing database validity). This work 560 is being addressed in other IETF efforts. For example, BGP 561 message content validity is being addressed in the SIDR working 562 group. 564 2.5. Audience 566 The audience for this document includes: 568 o Routing Area working group chairs and participants - These people 569 are charged with updated Routing Protocol specifications. Any and 570 all cryptographic authentication work on these specifications will 571 occur in Routing Area working groups, in close partnership with 572 the Security Area. Co-advisors from the Security Area may often 573 be named for these partnership efforts. 575 o Security Area reviewers of routing area documents - These people 576 are tasked by the Security Area Directors to perform reviews on 577 routing protocol specifications as they pass through working group 578 last call or IESG review. Their particular attention to the use 579 of cryptographic authentication and newly specified security 580 mechanisms for the routing protocols is appreciated. They also 581 help to ensure that incremental security improvements are being 582 made, in line with this roadmap. 584 o Security Area engineers - These people partner with routing area 585 authors/designers on the security mechanisms in routing protocol 586 specifications. Some of these security area engineers will be 587 assigned by the Security Area Directors, while others will be 588 interested parties in the relevant working groups. 590 o Operators - The operators are a key audience for this work, as the 591 work is considered to have succeeded only if operators deploy the 592 technology. It is anticipated that deployment will take place 593 only if operators perceive that the improved security offered by 594 the Routing Protocol updates warrant the complexity and cost of 595 deployment and operation. Conversely, the work will be considered 596 a failure if operators do not deploy it, either due to lack of 597 perceived value or due to perceived operational complexity. As a 598 result, the GROW and OPSEC WGs should be kept squarely in the loop 599 as well. 601 3. Threats 603 This document uses the definition of "threat" from RFC4949 [RFC4949]: 604 "a potential for violation of security, which exists when there is a 605 circumstance, capability, action, or event that could breach security 606 and cause harm." 608 This section defines the threats that are in scope for the KARP 609 effort. It also lists those threats that are explicitly out of scope 610 for the KARP effort. Threats are discussed assuming that no 611 protection (i.e., message authentication and message integrity) has 612 been applied to routing protocol messages. 614 This document leverages the "Generic Threats to Routing Protocols" 615 model, [RFC4593]. Specifically, the threats below were derived by 616 reviewing [RFC4593], analyzing the KARP problem space relative to it, 617 and listing the threats that are applicable to the KARP design teams' 618 work. This document categorizes [RFC4593] threats into those in 619 scope and those out of scope for KARP. Each in-scope threat is 620 discussed below, and its applicability to the KARP problem space is 621 described. As such, the following text intentionally is not a 622 comprehensive threat analysis. Rather it describes the applicability 623 of the existing threat analysis [RFC4593] to KARP. 625 Note: terms from [RFC4593] appear capitalized below -- e.g. 626 OUTSIDERS -- so as to make explicit the term's origin, and to enable 627 rapid cross referencing to the source RFC. 629 For convenience, a terse definition of most [RFC4593] terms is 630 offered here. Those interested in a more thorough description of 631 routing protocol threat sources, motivations, consequences and 632 actions will want to read [RFC4593] before continuing here. 634 3.1. Threat Sources 636 3.1.1. OUTSIDERS 638 One of the threats that will be addressed in this roadmap are those 639 where the source is an OUTSIDER. An OUTSIDER attacker may reside 640 anywhere in the Internet, have the ability to send IP traffic to the 641 router, may be able to observe the router's replies, and may even 642 control the path for a legitimate peer's traffic. OUTSIDERS are not 643 legitimate participants in the routing protocol. The use of message 644 authentication and integrity protection specifically aims to identify 645 packets originating from OUTSIDERS. 647 KARP design teams will consider two specific use cases of OUTSIDERS: 648 those on-path, and those off-path. 650 o On-Path - These attackers have control of a network resource or a 651 tap that sits along the path between two routing peers. A "Man- 652 in-the-Middle" (MitM) is an on-path attacker. From this vantage 653 point, the attacker can conduct either active or passive attacks. 654 An active attack occurs when the attacker places packets on the 655 network as part of the attack. One active MitM attack relevant to 656 KARP, an active wiretapping attack, occurs when the attacker 657 tampers with packets moving between two legitimate router peers in 658 such a way that both peers think they are talking to each other 659 directly, when in fact they are actually talking to the attacker. 660 Protocols conforming to this roadmap will use cryptographic 661 mechanisms to detect MitM attacks and reject packets from such 662 attacks (i.e. discard them as being not authentic). Passive on- 663 path attacks occur when the attacker silently gathers data and 664 analyses it to gain advantage. Passive activity by an on-path 665 attacker may lead to an active attack. 667 o Off-Path - These attackers sit on some network outside of that 668 over which runs the packets between two routing peers. The source 669 may be one or several hops away. Off-path attackers can launch 670 active attacks, such as SPOOFING or denial-of-service (DoS) 671 attacks, to name a few. 673 3.1.2. Unauthorized Key Holder 675 This threat source exists when an unauthorized entity somehow manages 676 to gain access to keying material. Using this material, the attacker 677 could send packets that pass the authenticity checks based on message 678 authentication codes (MACs). The resulting traffic might appear to 679 come from router A, destined to router B, and thus the attacker could 680 impersonate an authorized peer. The attacker could then adversely 681 affect network behavior by sending bogus messages that appear to be 682 authentic. The attack source possessing the unauthorized keys could 683 be on-path, off-path, or both. 685 The obvious mitigation for an unauthorized key holder is to change 686 the keys currently in use by the legitimate routing peers. This 687 mitigation can be either reactive or pro-active. Reactive mitigation 688 occurs when keys are changed only after one has discovered that the 689 previous keys fell into the possession of unauthorized users. The 690 reactive mitigation case is highlighted here in order to explain a 691 common operational situation where new keying material will need to 692 be put in place with little or no advanced warning. In such a case 693 new keys must be able to be installed and put into use very quickly, 694 and with little operational expense. Pro-active mitigation occurs 695 when an operator assumes that unauthorized possession will occur from 696 time to time without being discovered, and the operator moves to new 697 keying material in order to cut short an attacker's window of 698 opportunity to use the stolen keys effectively. 700 KARP design teams can address this type of attack by creating 701 specifications that make it practical for the operator to quickly 702 change keys without disruption to the routing system, and with 703 minimal operational overhead. Operators can further mitigate threats 704 from unauthorized key holders by regularly changing keys. 706 3.1.2.1. Terminated Employee 708 A terminated employee is an important example of an "unauthorized key 709 holder". Staff attrition is a reality in routing operations, and so 710 regularly causes the potential for a threat source. The threat 711 source risk arises when a network operator who had been granted 712 access to keys ceases to be an employee. If new keys are deployed 713 immediately, the situation of a terminated employee can become an 714 "unauthorized key holder, pro-active" case, as described above, 715 rather than an "unauthorized key holder, reactive mitigation" case. 716 It behooves the operator to change the keys, to enforce the 717 revocation of authorization of the old keys, in order to minimize the 718 threat source's window of opportunity. 720 A terminated employee is a valid unauthorized key holder threat 721 source for KARP, and designs should address the associated threats. 722 For example,new keys must be able to be installed and made 723 operational in the routing protocols very quickly, with zero impact 724 to the routing system, and with little operational expense. The 725 threat actions associated with a terminated employee also motivate 726 the need to roll the keys quickly, also with little operational 727 expense. 729 3.1.3. BYZANTINE 731 According to [RFC4593] , Section 3.1.1.2, BYZANTINE "attackers are 732 faulty, misconfigured, or subverted routers, i.e., legitimate 733 participants in the routing protocol" whose messages cause routing to 734 malfunction. 736 [RFC4593] goes on to say that "[s]ome adversaries can subvert 737 routers, or the management workstations used to control these 738 routers. These Byzantine failures represent the most serious form of 739 attack capability in that they result in emission of bogus traffic by 740 legitimate routers." 742 [RFC4593] explains that "[d]eliberate attacks are mimicked by 743 failures that are random and unintentional. In particular, a 744 Byzantine failure in a router may occur because the router is faulty 745 in hardware or software or is misconfigured," and thus routing 746 malfunctions unintentionally. Though not malicious, such occurrences 747 still disrupt network operation. 749 Whether faulty, misconfigured, or subverted, Byzantine routers have 750 an empowered position from which to provide believable yet bogus 751 routing messages that are damaging to the network. 753 3.2. Threat Actions In Scope 755 These THREAT ACTIONS are in scope for KARP: 757 o SPOOFING - when an unauthorized device assumes the identity of an 758 authorized one. Spoofing is special in that it can be used to 759 carry out other threat actions causing other threat consequences. 760 SPOOFING can be used, for example, to inject malicious routing 761 information that causes the disruption of network services. 762 SPOOFING can also be used to cause a neighbor relationship to form 763 that subsequently denies the formation of the relationship with 764 the legitimate router. 766 o DoS attacks 768 1. At the transport layer - This occurs when an attacker sends 769 packets aimed at halting or preventing the underlying protocol 770 over which the routing protocol runs. The attacker could use 771 SPOOFING, FALSIFICATION and INTERFERENCE (see below) to 772 produce the DoS attack. For example, BGP running over TLS 773 will still not solve the problem of being able to send a 774 spoofed TCP FIN or TCP RST and causing the BGP session to go 775 down. Since this attack depends on spoofing, operators are 776 encouraged to deploy proper authentication mechanisms to 777 prevent such attacks. Specification work should ensure that 778 Routing Protocols can operate over transport sub-systems in a 779 fashion that is resilient to such DoS attacks. 781 2. Using the authentication mechanism - This includes an attacker 782 causing INTERFERENCE, which is inhibiting the exchanges of 783 legitimate routers. The attack is often perpetrated by 784 sending packets that confuse or overwhelm a security mechanism 785 itself. An example is initiating an overwhelming load of 786 spoofed routing protocol packets that contain a MAC (i.e, 787 INSERTING MESSAGES), so that the receiver needs to spend the 788 processing cycles to check the MAC, only to discard the 789 spoofed packet, consuming substantial CPU resources. Other 790 types of INTERFERENCE include: REPLAYING OUT-DATED PACKETS, 791 CORRUPTING MESSAGES, and BREAKING SYNCHRONIZATION. 793 o FALSIFICATION - an action whereby an attacker sends false routing 794 information. This document is only targeting FALSIFICATION from 795 OUTSIDERS as may occur from tampering with packets in flight, or 796 sending entirely false messages. FALSIFICATION from BYZANTINES 797 (see the Threats Out of Scope section below) are not addressed by 798 the KARP effort. 800 o Brute Force Attacks Against Password/Keys - This includes either 801 online or offline attacks where attempts are made repeatedly using 802 different keys/passwords until a match is found. While it is 803 impossible to make brute force attacks on keys completely 804 unsuccessful, proper design can make such attacks much harder to 805 succeed. For example, current guidance for the security strength 806 of an algorithm with a particular key length should be deemed 807 acceptable for a period of 10 years. (Section 10 of [SP.800-131A] 808 is one source for guidance). Using per session keys is another 809 widely used method for reducing the number of brute force attacks 810 as this would make it difficult to guess the keys. 812 3.3. Threat Actions Out of Scope 814 BYZANTINE sources -- be they faulty, misconfigured, or subverted -- 815 are out of scope for this roadmap. KARP works to cryptographically 816 ensure that received routing messages originated from authorized 817 peers, and that the message was not altered in transit. Formation of 818 a bogus message by a valid and authorized peer falls outside the KARP 819 scope. Any of the attacks described in the above section 820 (Section 3.2) that may be levied by a BYZANTINE source are therefore 821 also out of scope, e.g. FALSIFICATION from BYZANTINE sources, or 822 unauthorized message content by a legitimate authorized peer. 824 In addition, these other attack actions are out of scope for this 825 work: 827 o SNIFFING (passive wiretapping) - passive observation of route 828 message contents in flight. Data confidentiality, as achieved by 829 data encryption, is the common mechanism for preventing SNIFFING. 830 While useful, especially to prevent the gathering of data needed 831 to perform an off-path packet injection attack, data encryption is 832 out-of-scope for KARP. 834 o INTERFERENCE due to: 836 A. NOT FORWARDING PACKETS - cannot be prevented with 837 cryptographic authentication. Note: If sequence numbers with 838 sliding windows are used in the solution (as is done, for 839 example, in BFD [RFC5880]), a receiver can at least detect the 840 occurrence of this attack. 842 B. DELAYING MESSAGES - cannot be prevented with cryptographic 843 authentication. Note: Timestamps can be used to detect 844 delays. 846 C. DENIAL OF RECEIPT (non-repudiation) - cannot be prevented with 847 cryptographic authentication 849 D. UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR 850 working group 851 (http://www.ietf.org/html.charters/sidr-charter.html). 853 E. DoS attacks not involving the routing protocol. For example, 854 a flood of traffic that fills the link ahead of the router, so 855 that the router is rendered unusable and unreachable by valid 856 packets is NOT an attack that KARP will address. Many such 857 examples could be contrived. 859 4. Requirements for KARP Work Phase 1, the Update to a Routing 860 Protocol's Existing Transport Security 862 The KARP Design Guide [RFC6518], Section 4.1 describes two distinct 863 work phases for the KARP effort. This section addresses requirements 864 for the first work phase only, "Work Phase 1", the update to a 865 routing protocol's existing transport security. "Work Phase 2", a 866 framework and usage of a KMP, will be addressed in a future 867 document(s). 869 The following list of requirements SHOULD be addressed by a KARP Work 870 Phase 1 security update to any Routing Protocol (according to section 871 4.1 of the KARP Design Guide [RFC6518]document). IT IS RECOMMENDED 872 that any Work Phase 1 security update to a Routing Protocol contain a 873 section of the specification document that describes how each of the 874 following requirements are met. It is further RECOMMENDED that 875 justification be presented for any requirements that are NOT 876 addressed. 878 1. Clear definitions of which elements of the transmitted data 879 (frame, packet, segment, etc.) are protected by an 880 authentication/integrity mechanism 882 2. Strong cryptographic algorithms, as defined and accepted by the 883 IETF security community, MUST be specified. The use of non- 884 standard or unpublished algorithms MUST be avoided. 886 3. Algorithm agility for the cryptographic algorithms used in the 887 authentication MUST be specified, and protocol specifications 888 MUST be clear how new algorithms are specified and used within 889 the protocol. This requirement exists because research 890 identifying weaknesses in cryptographic algorithms can cause the 891 security community to reduce confidence in some algorithms. 892 Breaking a cipher isn't a matter of if, but when it will occur. 893 Having the ability to specify alternate algorithms (algorithm 894 agility) within the protocol specification to support such an 895 event is essential. Additionally, more than one algorithm MUST 896 be specified. Mandating support for two algorithms (i.e., one 897 mandatory to implement algorithm and one or more backup 898 algorithms to guide transition) provides both redundancy, and a 899 mechanism for enacting that redundancy. 901 4. Secure use of PSKs, offering both operational convenience and a 902 baseline level of security, MUST be specified. 904 5. Routing Protocols (or the transport or network mechanism 905 protecting routing protocols) SHOULD be able to detect and 906 reject replayed intra-session and inter-session messages. 908 Packets captured from one session MUST NOT be able to be re-sent 909 and accepted during a later session (i.e., inter-session 910 replay). Additionally, replay mechanisms MUST work correctly 911 even in the presence of routing protocol packet prioritization 912 by the router. 914 There is a specific case of replay attack combined with spoofing 915 that must be addressed. Several routing protocols (e.g., OSPF 916 [RFC2328], IS-IS [RFC1195], BFD [RFC5880], RIP [RFC2453], etc.), 917 require all speakers to share the same authentication and 918 message association key on a broadcast segment. It is important 919 that an integrity check associated with a message fail if an 920 attacker has replayed the message with a different origin. 922 6. A change of security parameters MUST force a change of session 923 traffic keys. The specific security parameters for the various 924 routing protocols will differ, and will be defined by each 925 protocols design team. Some examples may include: master key, 926 key lifetime, cryptographic algorithm, etc. If one of these 927 configured parameters changes, then a new session traffic key 928 MUST immediately be established using the updated parameters. 929 The routing protocol security mechanisms MUST support this 930 behavior. 932 7. Security mechanisms MUST specify a means to affect intra-session 933 re-keying without disrupting a routing session. This should be 934 accomplished without data loss, if possible. Keys may need to 935 be changed periodically based on policy, or when an 936 administrator who had access to the keys leaves an organization. 937 A re-keying mechanism enables the operators to execute the 938 change without productivity loss. 940 8. Re-keying SHOULD be supported in such a way that it can occur 941 during a session without the peer needing to use multiple keys 942 to validate a given packet. The rare exception will occur if a 943 routing protocol's design team can find no other way to re-key 944 and still adhere to the other requirements in this section. The 945 specification SHOULD include a key identifier, which allows 946 receivers to choose the correct key (or determine that they are 947 not in possession of the correct key). 949 9. New mechanisms MUST resist DoS attacks described as in-scope in 950 Section 3.2. Routers protect the control plane by implementing 951 mechanisms to reject completely or rate limit traffic not 952 required at the control plane level (i.e., unwanted traffic). 953 Typically line rate packet filtering capabilities look at 954 information at the IP and transport (TCP or UDP) headers, but do 955 not include higher layer information. Therefore the new 956 mechanisms shouldn't hide nor encrypt the information carried in 957 the IP and transport layers in control plane packets. 959 10. Mandatory cryptographic algorithms and mechanisms MUST be 960 specified for each routing protocol security mechanism. 961 Further, the protocol specification MUST define default security 962 mechanism settings for all implementations to use when no 963 explicit configuration is provided. To understand the need for 964 this requirement, consider the case where a routing protocol 965 mandates 3 different cryptographic algorithms for a MAC 966 operation. If company A implements algorithm 1 as the default 967 for this protocol, while company B implements algorithm 2 as the 968 default, then two operators who enable the security mechanism 969 with no explicit configuration other than a PSK will experience 970 a connection failure. It is not enough that each implementation 971 implement the 3 mandatory algorithms; one default must further 972 be specified in order to gain maximum out-of-the-box 973 interoperability. 975 11. For backward compatibility reasons, manual keying MUST be 976 supported. 978 12. The specification MUST consider and allow for future use of a 979 KMP. 981 13. The authentication mechanism in a Routing Protocol MUST be 982 decoupled from the key management system used. The 983 authentication protocol MUST include a specification for 984 agreeing on keying material. This will accommodate both manual 985 keying and the use of KMPs. 987 14. Convergence times of the Routing Protocols SHOULD NOT be 988 materially affected. Changes in the convergence time will be 989 immediately and independently verifiable by convergence 990 performance test beds already in use (e.g. those maintained by 991 router vendors, service providers, and researchers). An 992 increase in convergence time in excess of 5% is likely to be 993 considered to have materially affected convergence by network 994 operators. A number of other facts can also change convergence 995 over time (e.g., speed of processors used on individual routing 996 peers, processing power increases due to Moore's law, 997 implementation specifics), and the effect of an authentication 998 mechanism on Routing Protocols will need to take these into 999 account by implementors. Protocol designers should consider the 1000 impact on convergence times as a function of both the total 1001 number of protocol packets that must be exchanged and the 1002 required computational processing of individual messages in the 1003 specification, understanding that the operator community's 1004 threshold for increase of convergence times is very low, as 1005 stated above. 1007 15. The changes to or addition of security mechanisms SHOULD NOT 1008 cause a refresh of route advertisements or cause additional 1009 route advertisements to be generated. 1011 16. Router implementations provide prioritized treatment for certain 1012 protocol packets. For example, OSPF HELLO packets and ACKs are 1013 prioritized for processing above other OSPF packets. The 1014 security mechanism SHOULD NOT interfere with the ability to 1015 observe and enforce such prioritization. Any effect on such 1016 priority mechanisms MUST be explicitly documented and justified. 1017 Replay protection mechanisms provided by the routing protocols 1018 MUST work even if certain protocol packets are offered 1019 prioritized treatment. 1021 17. The Routing Protocol MUST send minimal information regarding the 1022 authentication mechanisms and associated parameters in its 1023 protocol packets. This keeps the Routing Protocols as clean and 1024 focused as possible, and loads security negotiations into the 1025 KMP as much as possible. Another reason is to avoid exposing 1026 any security negotiation information unnecessarily to possible 1027 attackers on the path. 1029 18. Routing Protocols that rely on the IP header (or information 1030 separate from routing protocol payload) to identify the neighbor 1031 that originated the packet, MUST either protect the IP header or 1032 provide some other means to authenticate the neighbor. 1033 [RFC6039] describes some attacks that motivate this requirement. 1035 19. Every new KARP-developed security mechanisms MUST support 1036 incremental deployment. It will not be feasible to deploy a new 1037 Routing Protocol authentication mechanism throughout a network 1038 instantaneously. Indeed, it may not actually be feasible to 1039 deploy such a mechanism to all routers in a large autonomous 1040 system (AS) in a bounded timeframe. Proposed solutions MUST 1041 support an incremental deployment method that benefits those who 1042 participate. Because of this, there are several requirements 1043 that any proposed KARP mechanism should consider. 1045 A. The Routing Protocol security mechanism MUST enable each 1046 router to configure use of the security mechanism on a per- 1047 peer basis where the communication is peer-to-peer 1048 (unicast). 1050 B. Every new KARP-developed security mechanism MUST provide 1051 backward compatibility with respect to message formatting, 1052 transmission, and processing of routing information carried 1053 through a secure and non-secure security environment. 1054 Message formatting in a fully secured environment MAY be 1055 handled in a non-backward compatible fashion though care 1056 must be taken to ensure that routing protocol packets can 1057 traverse intermediate routers that don't support the new 1058 format. 1060 C. In an environment where both secured and non-secured routers 1061 are interoperating, a mechanism MUST exist for secured 1062 systems to identify whether a peer intended the messages to 1063 be secured. 1065 D. In an environment where secured service is in the process of 1066 being deployed, a mechanism MUST exist to support a 1067 transition free of service interruption (caused by the 1068 deployment per se). 1070 20. The introduction of mechanisms to improve routing security may 1071 increase the processing performed by a router. Since most of 1072 the currently deployed routers do not have hardware to 1073 accelerate cryptographic operations, these operations could 1074 impose a significant processing burden under some circumstances. 1075 Thus proposed solutions SHOULD be evaluated carefully with 1076 regard to the processing burden they may impose, since 1077 deployment may be impeded if network operators perceive that a 1078 solution will impose a processing burden which either incurs 1079 substantial capital expense, or threatens to degrade router 1080 performance. 1082 21. New authentication and security mechanisms should not rely on 1083 systems external to the routing system (the equipment that is 1084 performing forwarding) in order for the routing system to be 1085 secure. In order to ensure the rapid initialization and/or 1086 return to service of failed nodes it is important to reduce 1087 reliance on these external systems to the greatest extent 1088 possible. Proposed solutions SHOULD NOT require connections to 1089 external systems, beyond those directly involved in peering 1090 relationships, in order to return to full service. It is 1091 however acceptable for the proposed solutions to require post 1092 initialization synchronization with external systems in order to 1093 fully synchronize security associations. 1095 If authentication and security mechanisms rely on systems 1096 external to the routing system, then there MUST be one or more 1097 options available to avoid circular dependencies. It is not 1098 acceptable to have a routing protocol (e.g., unicast routing) 1099 depend upon correct operation of a security protocol that, in 1100 turn, depends upon correct operation of the same instance of 1101 that routing protocol (i.e., the unicast routing). However, it 1102 is acceptable to have operation of a routing protocol (e.g., 1103 multicast routing) depend upon operation of a security protocol, 1104 which depends upon an independent routing protocol (e.g., 1105 unicast routing). Similarly it would be okay to have the 1106 operation of a routing protocol depend upon a security protocol, 1107 which in turn uses an out of band network to exchange 1108 information with remote systems. 1110 5. Security Considerations 1112 This document is mostly about security considerations for the KARP 1113 efforts, both threats and requirements for addressing those threats. 1114 More detailed security considerations were placed in the Security 1115 Considerations section of the KARP Design Guide [RFC6518]document. 1117 The use of a group key between a set of Routing Protocol peers has 1118 special security considerations. Possession of the group key itself 1119 is used for identity validation, and no other identity check is used. 1120 Under these conditions an attack exists where one peer masquerades as 1121 a neighbor by using the neighbor's source IP address. This type of 1122 attack has been well documented in the group keying problem space, 1123 and it's non-trivial to solve. Solutions exist within the group 1124 keying realm, but they come with significant increases in complexity 1125 and computational intensity. 1127 6. IANA Considerations 1129 This document has no actions for IANA. 1131 7. Acknowledgements 1133 The majority of the text for version -00 of this document was taken 1134 from "Roadmap for Cryptographic Authentication of Routing Protocol 1135 Packets on the Wire", draft-lebovitz-karp-roadmap, authored by 1136 Gregory M. Lebovitz. 1138 Brian Weis provided significant assistance in handling the many 1139 comments that came back during IESG review, including making textual 1140 edits directly to the XML. For his extensive efforts he was added as 1141 an author on -07. 1143 We would like to thank the following people for their thorough 1144 reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent, 1145 Vishwas Manral, Barry Leiba, Sean Turner, Uma Chunduri. 1147 Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for 1148 much of the time he worked on this document, though not at the time 1149 of its publishing. Thus Juniper sponsored much of this effort. 1151 8. References 1153 8.1. Normative References 1155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1156 Requirement Levels", BCP 14, RFC 2119, March 1997. 1158 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1159 Routing Protocols", RFC 4593, October 2006. 1161 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1162 IAB workshop on Unwanted Traffic March 9-10, 2006", 1163 RFC 4948, August 2007. 1165 8.2. Informative References 1167 [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure 1168 Security Report", October 2008, 1169 . 1171 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1172 dual environments", RFC 1195, December 1990. 1174 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1176 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1177 November 1998. 1179 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1180 Signature Option", RFC 3562, July 2003. 1182 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1183 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1185 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1186 Internet Protocol", RFC 4301, December 2005. 1188 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1189 RFC 4303, December 2005. 1191 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 1192 Authentication", RFC 4822, February 2007. 1194 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1195 RFC 4949, August 2007. 1197 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1198 Specification", RFC 5036, October 2007. 1200 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1201 and M. Fanto, "IS-IS Generic Cryptographic 1202 Authentication", RFC 5310, February 2009. 1204 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 1205 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 1206 Authentication", RFC 5709, October 2009. 1208 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1209 (BFD)", RFC 5880, June 2010. 1211 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1212 Authentication Option", RFC 5925, June 2010. 1214 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 1215 with Existing Cryptographic Protection Methods for Routing 1216 Protocols", RFC 6039, October 2010. 1218 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 1219 Routing Protocols (KARP) Design Guidelines", RFC 6518, 1220 February 2012. 1222 [SP.800-131A] 1223 Barker, E. and A. Roginsky, "Transitions: Recommendation 1224 for Transitioning the Use of Cryptographic Algorithms and 1225 Key Lengths", United States of America, National Institute 1226 of Science and Technology, NIST Special Publication 1227 800-131A, January 2011. 1229 Authors' Addresses 1231 Gregory Lebovitz 1232 Aptos, California 95003 1233 USA 1235 Email: gregory.ietf@gmail.com 1237 Manav Bhatia 1238 Alcatel-Lucent 1239 Bangalore, 1240 India 1242 Phone: 1243 Email: manav.bhatia@alcatel-lucent.com 1245 Brian Weis 1246 Cisco Systems 1247 170 W. Tasman Drive 1248 San Jose, California 95134-1706 1249 USA 1251 Phone: 1252 Email: bew@cisco.com 1253 URI: http://www.cisco.com