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