idnits 2.17.1 draft-ietf-karp-threats-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4948]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2010) is 5168 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRR' is mentioned on line 129, but not defined == Unused Reference: 'I-D.ao-crypto' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pim-sm-linklocal' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC2453' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC3562' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC4615' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 966, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-00 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-10 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 23 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP G. Lebovitz 3 Internet-Draft Juniper 4 Intended status: Informational February 28, 2010 5 Expires: September 1, 2010 7 The Threat Analysis and Requirements for Cryptographic Authentication of 8 Routing Protocols' Transports 9 draft-ietf-karp-threats-reqs-00 11 Abstract 13 In the March of 2006 the IAB held a workshop on the topic of 14 "Unwanted Internet Traffic". The report from that workshop is 15 documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for 16 "[t]ightening the security of the core routing infrastructure." Four 17 main steps were identified for improving the security of the routing 18 infrastructure. One of those steps was "securing the routing 19 protocols' packets on the wire," also called the routing protocol 20 transport. One mechanism for securing routing protocol transports is 21 the use of per-packet cryptographic message authentication, providing 22 both peer authentication and message integrity. Many different 23 routing protocols exist and they employ a range of different 24 transport subsystems. Therefore there must necessarily be various 25 methods defined for applying cryptographic authentication to these 26 varying protocols. Many routing protocols already have some method 27 for accomplishing cryptographic message authentication. However, in 28 many cases the existing methods are dated, vulnerable to attack, 29 and/or employ cryptographic algorithms that have been deprecated. 30 The "Keying and Authentication for Routing Protocols" (KARP) effort 31 aims to overhaul and improve these mechanisms. This document has two 32 main parts. The first describes the threat analysis for attacks 33 against routing protocols' transports. The second enumerates the 34 requirements for addressing the described threats. This document, 35 along with the KARP Design Guide and KARP Framework documents, will 36 be used by KARP design teams for specific protocol review and 37 overhaul. This document reflects the input of both the IETF's 38 Security Area and Routing Area in order to form a jointly agreed upon 39 guidance. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt. 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 This Internet-Draft will expire on September 1, 2010. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 94 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 95 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 96 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 97 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 98 1.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 99 1.6. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 2.1. Threats In Scope . . . . . . . . . . . . . . . . . . . . . 12 102 2.2. Threats Out of Scope . . . . . . . . . . . . . . . . . . . 14 103 3. Requirements for Phase 1 of a Routing Protocol Transport's 104 Security Update . . . . . . . . . . . . . . . . . . . . . . . 15 105 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 106 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 107 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 108 7. Change History (RFC Editor: Delete Before Publishing) . . . . 19 109 8. Needs Work in Next Draft (RFC Editor: Delete Before 110 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 112 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 113 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 116 1. Introduction 118 In March 2006 the Internet Architecture Board (IAB) held a workshop 119 on the topic of "Unwanted Internet Traffic". The report from that 120 workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that 121 document states that "A simple risk analysis would suggest that an 122 ideal attack target of minimal cost but maximal disruption is the 123 core routing infrastructure." Section 8.2 calls for "[t]ightening 124 the security of the core routing infrastructure." Four main steps 125 were identified for that tightening: 127 o More secure mechanisms and practices for operating routers. This 128 work is being addressed in the OPSEC Working Group. 129 o Cleaning up the Internet Routing Registry repository [IRR], and 130 securing both the database and the access, so that it can be used 131 for routing verifications. This work should be addressed through 132 liaisons with those running the IRR's globally. 133 o Specifications for cryptographic validation of routing message 134 content. This work will likely be addressed in the SIDR Working 135 Group. 136 o Securing the routing protocols' packets on the wire 138 This document addresses the last bullet, securing the packets on the 139 wire of the routing protocol exchanges, i.e. the routing protocols' 140 transports. This effort is referred to as Keying and Authentication 141 for Routing Protocols, or "KARP". This document specifically 142 addresses the threat analysis for per packet routing protocol 143 transport authentication, and the requirements for protocols to 144 mitigate those threats. 146 This document is one of three that together form the guidance and 147 instructions for KARP design teams working to overhaul routing 148 protocol transport security. The other two are the KARP Design Guide 149 [I-D.ietf-karp-design-guide] and the KARP Framework 150 [I-D.ietf-karp-framework]. 152 1.1. Terminology 154 Within the scope of this document, the following words, when 155 beginning with a capital letter, or spelled in all capitals, hold the 156 meanings described to the right of each term. If the same word is 157 used uncapitalized, then it is intended to have its common english 158 definition. 160 [Editor's note: At this point, I'm not sure exactly which of these 161 will end up being included in this document. They came for the 162 original "roadmap document". We can clean out any unused terms a few 163 revisions from now.] 164 PSK Pre-Shared Key. A key used by both peers in a secure 165 configuration. Usually exchanged out-of-band prior to 166 a first connection. 168 Routing Protocol When used with capital "R" and "P" in this document 169 the term refers the Routing Protocol for which work is 170 being done to provide or enhance its peer 171 authentication mechanisms. 173 PRF Pseudorandom number function, or sometimes called 174 pseudorandom number generator (PRNG). An algorithm 175 for generating a sequence of numbers that approximates 176 the properties of random numbers. The sequence is not 177 truly random, in that it is completely determined by a 178 relatively small set of initial values that are passed 179 into the function. An exmaple is SHA-256. 181 KDF Key derivation function. A particular specified use 182 of a PRF that takes a PSK, combines it with other 183 inputs to the PRF, and produces a result that is 184 suitable for use as a Traffic Key. 186 Identifier The type and value used by one peer of an 187 authenticated message exchange to signify to the other 188 peer who they are. The Identifier is used by the 189 receiver as a lookup index into a table containing 190 further information about the peer that is required to 191 continue processing the message, for example a 192 Security Association (SA) or keys. 194 Identity Proof A cryptographic proof for an asserted identity, that 195 the peer really is who they assert themselves to be. 196 Proof of identity can be arranged between the peers in 197 a few ways, for example PSK, raw assymetric keys, or a 198 more user-friendly representation of assymetric keys, 199 like a certificate. 201 Security Association or SA The parameters and keys that together 202 form the required information for processing secure 203 sessions between peers. Examples of items that may 204 exist in an SA include: Identifier, PSK, Traffic Key, 205 cryptographic algorithms, key lifetimes. 207 KMP Key Management Protocol. A protocol used between 208 peers to exchange SA parameters and Traffic Keys. 209 Examples of KMPs include IKE, TLS, and SSH. 211 KMP Function Any actual KMP used in the general KARP solution 212 framework 214 Peer Key Keys that are used between peers as the identity 215 proof. These keys may or may not be connection 216 specific, depending on who they were established, and 217 what form of identity and identity proof is being used 218 in the system. 220 Traffic Key The actual key used on each packet of a message. 222 Definitions of items specific to the general KARP framework are 223 described in more detail in the KARP Framework 224 [I-D.ietf-karp-framework] document. 226 1.2. Requirements Language 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC2119 [RFC2119]. 232 When used in lower case, these words convey their typical use in 233 common language, and are not to be interpreted as described in 234 RFC2119 [RFC2119]. 236 1.3. Scope 238 Four basic tactics may be employed in order to secure any piece of 239 data as it is transmitted over the wire: privacy (or encryption), 240 authentication, message integrity, and non-repudiation. The focus 241 for this effort, and the scope for this roadmap document, will be 242 message authentication and packet integrity only. This work 243 explicitly excludes, at this point in time, the other two tactics: 244 privacy and non-repudiation. Since the objective of most routing 245 protocols is to broadly advertise the routing topology, routing 246 messages are commonly sent in the clear; confidentiality is not 247 normally required for routing protocols. However, ensuring that 248 routing peers truly are the trusted peers expected, and that no roque 249 peers or messages can compromise the stability of the routing 250 environment is critical, and thus our focus. The other two 251 explicitly excluded tactics, privacy and non-repudiation, may be 252 addressed in future work. 254 It is possible for routing protocol packets to be transmitted 255 employing all four security tactics mentioned above using existing 256 standards. For example, one could run unicast, layer 3 or above 257 routing protocol packets through IPsec ESP [RFC4303]. This would 258 provide the added benefit of privacy, and non-repudiation. However, 259 router platforms and systems have been fine tuned over the years for 260 the specific processing necessary for routing protocols' non- 261 encapsulated formats. Operators are, therefore, quite reluctant to 262 explore new packet encapsulations for these tried and true protocols. 264 In addition, at least in the case of OSPF, LDP, and RIP, these 265 protocols already have existing mechanisms for cryptographically 266 authenticating and integrity checking the packets on the wire. 267 Products with these mechanisms have already been produced, code has 268 already been written and both have been optimized for the existing 269 mechanisms. Rather than turn away from these mechanisms, we want to 270 enhance them, updating them to modern and secure levels. 272 Therefore, the scope of this roadmap of work includes: 274 o Making use of existing routing protocol security protocols, where 275 they exist, and enhancing or updating them as necessary for modern 276 cryptographic best practices, 278 o Developing a framework for using automatic key management in order 279 to ease deployment, lower cost of operation, and allow for rapid 280 responses to security breaches, and 282 o Specifying the automated key management protocol that may be 283 combined with the bits-on-the-wire mechanisms. 285 The work also serves as an agreement between the Routing Area and the 286 Security Area about the priorities and work plan for incrementally 287 delivering the above work. This point is important. There will be 288 times when the best-security-possible will give way to vastly- 289 improved-over-current-security-but-admittedly-not-yet-best-security- 290 possible, in order that incremental progress toward a more secure 291 Internet may be achieved. As such, this document will call out 292 places where agreement has been reached on such trade offs. 294 This document does not contain protocol specifications. Instead, it 295 defines the areas where protocol specification work is needed and 296 sets a direction, a set of requirements, and a relative priority for 297 addressing that specification work. 299 There are a set of threats to routing protocols that are considered 300 in-scope for this document/roadmap, and a set considered out-of- 301 scope. These are described in detail in the Threats (Section 2) 302 section below. 304 1.4. Goals 306 The goals and general guidance for the KARP work follow: 308 1. Provide authentication and integrity protection for packets on the 309 wire of existing routing protocols 311 2. Deliver a path to incrementally improve security of the routing 312 infrastructure. The principle of crawl, walk, run will be in 313 place. Routing protocol authentication mechanisms may not go 314 immediately from their current state to a state containing the 315 best possible, most modern security practices. Incremental steps 316 will need to be taken for a few very practical reasons. First, 317 there are a considerable number of deployed routing devices in 318 operating networks that will not be able to run the most modern 319 cryptographic mechanisms without significant and unacceptable 320 performance penalties. The roadmap for any one routing protocol 321 MUST allow for incremental improvements on existing operational 322 devices. Second, current routing protocol performance on deployed 323 devices has been achieved over the last 20 years through extensive 324 tuning of software and hardware elements, and is a constant focus 325 for improvement by vendors and operators alike. The introduction 326 of new security mechanisms affects this performance balance. The 327 performance impact of any incremental step of security improvement 328 will need to be weighed by the community, and introduced in such a 329 way that allows the vendor and operator community a path to 330 adoption that upholds reasonable performance metrics. Therefore, 331 certain specification elements may be introduced carrying the 332 "SHOULD" guidance, with the intention that the same mechanism will 333 carry a "MUST" in the next release of the specification. This 334 gives the vendors and implementors the guidance they need to tune 335 their software and hardware appropriately over time. Last, some 336 security mechanisms require the build out of other operational 337 support systems, and this will take time. An example where these 338 three reasons are at play in an incremental improvement roadmap is 339 seen in the improvement of BGP's [RFC4271] security via the update 340 of the TCP Authentication Option (TCP-AO) 341 [I-D.ietf-tcpm-tcp-auth-opt] effort. It would be ideal, and 342 reflect best common security practice, to have a fully specified 343 key management protocol for negotiating TCP-AO's authentication 344 material, using certificates for peer authentication in the 345 keying. However, in the spirit of incremental deployment, we will 346 first address issues like cryptographic algorithm agility, replay 347 attacks, TCP session resetting in the base TCP-AO protocol before 348 we layer key management on top of it. 350 3. The deploy-ability of the improved security solutions on currently 351 running routing infrastructure equipment. This begs the 352 consideration of the current state of processing power available 353 on routers in the network today. 355 4. Operational deploy-ability - A solutions acceptability will also 356 be measured by how deployable the solution is by common operator 357 teams using common deployment processes and infrastructures. I.e. 358 We will try to make these solutions fit as well as possible into 359 current operational practices or router deployment. This will be 360 heavily influenced by operator input, to ensure that what we 361 specify can -- and, more importantly, will -- be deployed once 362 specified and implemented by vendors. Deployment of incrementally 363 more secure routing infrastructure in the Internet is the final 364 measure of success. Measurably, we would like to see an increase 365 in the number of surveyed respondents who report deploying the 366 updated authentication mechanisms anywhere across their network, 367 as well as a sharp rise in usage for the total percentage of their 368 network's routers. 370 Interviews with operators show several points about routing 371 security. First, over 70% of operators have deployed transport 372 connection protection via TCP-MD5 on their EBGP [ISR2008] . Over 373 55% also deploy MD5 on their IBGP connections, and 50% deploy MD5 374 on some other IGP. The survey states that "a considerable 375 increase was observed over previous editions of the survey for use 376 of TCP MD5 with external peers (eBGP), internal peers (iBGP) and 377 MD5 extensions for IGPs." Though the data is not captured in the 378 report, the authors believe anecdotally that of those who have 379 deployed MD5 somewhere in their network, only about 25-30% of the 380 routers in their network are deployed with the authentication 381 enabled. None report using IPsec to protect the routing protocol, 382 and this was a decline from the few that reported doing so in the 383 previous year's report. 384 From my personal conversations with operators, of those using MD5, 385 almost all report deploying with one single manual key throughout 386 the entire network. These same operators report that the one 387 single key has not been changed since it was originally installed, 388 sometimes five or more years ago. When asked why, particularly 389 for the case of BGP using TCP MD5, the following reasons are often 390 given: 392 A. Changing the keys triggers a TCP reset, and thus bounces the 393 links/adjacencies, undermining Service Level Agreements 394 (SLAs). 396 B. For external peers, difficulty of coordination with the other 397 organization is an issue. Once they find the correct contact 398 at the other organization (not always so easy), the 399 coordination function is serialized and on a per peer/AS 400 basis. The coordination is very cumbersome and tedious to 401 execute in practice. 402 C. Keys must be changed at precisely the same time, or at least 403 within 60 seconds (as supported by two major vendors) in order 404 to limit connectivity outage duration. This is incredibly 405 difficult to do, operationally, especially between different 406 organizations. 407 D. Relatively low priority compared to other operatoinal issues. 408 E. Lack of staff to implement the changes device by device. 409 F. There are three use cases for operational peering at play 410 here: peers and interconnection with other operators, Internal 411 BGP and other routing sessions within a single operator, and 412 operator-to-customer-CPE devices. All three have very 413 different properties, and all are reported as cumbersome. One 414 operator reported that the same key is used for all customer 415 premise equipment. The same operator reported that if the 416 customer mandated, a unique key could be created, although the 417 last time this occurred it created such an operational 418 headache that the administrators now usually tell customers 419 that the option doesn't even exist, to avoid the difficulties. 420 These customer-uniqe keys are never changed, unless the 421 customer demands so. 422 The main threat at play here is that a terminated employee from 423 such an operator who had access to the one (or few) keys used for 424 authentication in these environments could easily wage an attack 425 -- or offer the keys to others who would wage the attack -- and 426 bring down many of the adjacencies, causing destabilization to the 427 routing system. 429 Whatever mechanisms we specify need to be easier than the current 430 methods to deploy, and should provide obvious operational 431 efficiency gains along with significantly better security and 432 threat protection. This combination of value may be enough to 433 drive much broader adoption. 435 5. Address the threats enumerated above in the "Threats" section 436 (Section 2) for each routing protocol, along a roadmap. Not all 437 threats may be able to be addressed in the first specification 438 update for any one protocol. Roadmaps will be defined so that 439 both the security area and the routing area agree on how the 440 threats will be addressed completely over time. 442 6. Create a re-usable architecture, framework, and guidelines for 443 various IETF working teams who will address these security 444 improvements for various Routing Protocols. The crux of the KARP 445 work is to re-use that framework as much as possible across 446 relevant Routing Protocols. For example, designers should aim to 447 re-use the key management protocol that will be defined for BGP's 448 TCP-AO key establishment for as many other routing protocols as 449 possible. This is but one example. 451 7. Bridge any gaps between IETF's Routing and Security Areas by 452 recording agreements on work items, roadmaps, and guidance from 453 the Area leads and Internet Architecture Board (IAB, www.iab.org). 455 1.5. Non-Goals 457 The following two goals are considered out-of-scope for this effort: 459 o Privacy of the packets on the wire, at this point in time. Once 460 this roadmap is realized, we may revisit work on privacy. 462 o Message content security. This work is being addressed in other 463 IETF efforts, like SIDR. 465 1.6. Audience 467 The audience for this roadmap includes: 469 o Routing Area working group chairs and participants - These 470 people are charged with updates to the Routing Protocol 471 specifications. Any and all cryptographic authentication work 472 on these specifications will occur in Routing Area working 473 groups, with close partnership with the Security Area. Co- 474 advisors from Security Area may often be named for these 475 partnership efforts. 477 o Security Area reviewers of routing area documents - These people 478 are delegated by the Security Area Directors to perform reviews 479 on routing protocol specifications as they pass through working 480 group last call or IESG review. They will pay particular 481 attention to the use of cryptographic authentication and 482 corresponding security mechanisms for the routing protocols. 483 They will ensure that incremental security improvements are 484 being made, in line with this roadmap. 486 o Security Area engineers - These people partner with routing area 487 authors/designers on the security mechanisms in routing protocol 488 specifications. Some of these security area engineers will be 489 assigned by the Security Area Directors, while others will be 490 interested parties in the relevant working groups. 492 o Operators - The operators are a key audience for this work, as 493 the work is considered to have succeeded if the operators deploy 494 the technology, presumably due to a perception of significantly 495 improved security value coupled with relative similarity to 496 deployment complexity and cost. Conversely, the work will be 497 considered a failure if the operators do not care to deploy it, 498 either due to lack of value or perceived (or real) over- 499 complexity of operations. And as such, the GROW and OPSEC WGs 500 should be kept squarely in the loop as well. 502 2. Threats 504 In RFC4949[RFC4949], a threat is defined as a potential for violation 505 of security, which exists when there is a circumstance, capability, 506 action, or event that could breach security and cause harm. This 507 section defines the threats that are in scope for this roadmap, and 508 those that are explicitly out of scope. This document leverages the 509 "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] , 510 capitalizes terms from that document, and offers a terse definition 511 of those terms. (More thorough description of routing protocol 512 threats sources, motivations, consequences and actions can be found 513 in RFC 4593 [RFC4593] itself). The threat listings below expand upon 514 these threat definitions. 516 2.1. Threats In Scope 518 The threats that will be addressed in this roadmap are those from 519 OUTSIDERS, attackers that may reside anywhere in the Internet, have 520 the ability to send IP traffic to the router, may be able to observe 521 the router's replies, and may even control the path for a legitimate 522 peer's traffic. These are not legitimate participants in the routing 523 protocol. Message authentication and integrity protection 524 specifically aims to identify messages originating from OUTSIDERS. 526 The concept of OUTSIDERS can be further refined to include attackers 527 who are terminated employees, and those sitting on-path. 529 o On-Path - attackers with control of a network resource or a tap 530 along the path of packets between two routers. An on-path 531 outsider can attempt a man-in-the-middle attack, in addition to 532 several other attack classes. A man-in-the-middle (MitM) attack 533 occurs when an attacker who has access to packets flowing between 534 two peers tampers with those packets in such a way that both peers 535 think they are talking to each other directly, when in fact they 536 are actually talking to the attacker only. Protocols conforming 537 to this roadmap will use cryptographic mechanisms to prevent a 538 man-in-the-middle attacker from situating himself undetected. 540 o Terminated Employees - in this context, those who had access 541 router configuration that included keys or keying material like 542 pre-shared keys used in securing the routing protocol. Using this 543 material, the attacker could send properly MAC'd spoofed packets 544 appearing to come from router A to router B, and thus impersonate 545 an authorized peer. The attacker could then send false traffic 546 that changes the network behavior from its operator's design. The 547 goal of addressing this source specifically is to call out the 548 case where new keys or keying material becomes necessary very 549 quickly, with little operational expense, upon the termination of 550 such an employee. This grouping could also refer to any attacker 551 who somehow managed to gain access to keying material, and said 552 access had been detected by the operators such that the operators 553 have an opportunity to move to new keys in order to prevent an 554 attack. 556 These ATTACK ACTIONS are in scope for this roadmap: 558 o SPOOFING - when an unauthorized device assumes the identity of an 559 authorized one. Spoofing can be used, for example, to inject 560 malicious routing information that causes the disruption of 561 network services. Spoofing can also be used to cause a neighbor 562 relationship to form that subsequently denies the formation of the 563 relationship with the legitimate router. 565 o FALSIFICATION - an action whereby an attacker sends false routing 566 information. To falsify the routing information, an attacker has 567 to be either the originator or a forwarder of the routing 568 information. Falsification may occur by an ORIGINATOR, or a 569 FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or 570 MISTATEMENT of network resource reachability. We must be careful 571 to remember that in this work we are only targeting falsification 572 from outsiders as may occur from tampering with packets in flight. 573 Falsification from BYZANTINES (see the Threats Out of Scope 574 section (Section 2.2) below) are not addressed by the KARP effort. 576 o INTERFERENCE - when an attacker inhibits the exchanges by 577 legitimate routers. The types of interference addressed by this 578 work include: 579 * ADDING NOISE 580 * REPLAYING OUT-DATED PACKETS 581 * INSERTING MESSAGES 582 * CORRUPTING MESSAGES 583 * BREAKING SYNCHRONIZATION 584 * Changing message content 586 o DoS attacks on transport sub-systems - This includes any other DoS 587 attacks specifically based on the above attack types. This is 588 when an attacker sends spoofed packets aimed at halting or 589 preventing the underlying protocol over which the routing protocol 590 runs, for example halting a BGP session by sending a TCP FIN or 591 RST packet. Since this attack depends on spoofing, operators are 592 encouraged to deploy 594 o DoS attacks using the authentication mechanism - This includes an 595 attacker sending packets which confuse or overwhelm a security 596 mechanism itself. An example is initiating an overwhelming load 597 of spoofed authenticated route messages so that the receiver needs 598 to process the MAC check, only to discard the packet, sending CPU 599 levels rising. Another example is when an attacker sends an 600 overwhelming load of keying protocol initiations from bogus 601 sources. All other possible DoS attacks are out of scope (see 602 next section). 604 o Brute Foce Attacks Against Password/Keys - This includes either 605 online or offline attacks where attempts are made repeatedly using 606 different keys/passwords until a match is found. While it is 607 impossible to make brute force attacks on keys completely 608 unsuccessful, proper design can make such attacks much harder to 609 succeed. For exmaple, the key length should be sufficiently long 610 so that covering the entire space of possible keys is improbable 611 using computational power expected to be available 10 years out or 612 more. Also, frequently changing the keys may render useless a 613 successful guess some time in the future, as those keys may no 614 longer be in use. 616 2.2. Threats Out of Scope 618 Threats from BYZANTINE sources -- faulty, misconfigured, or subverted 619 routers, i.e., legitimate participants in the routing protocol -- are 620 out of scope for this roadmap. Any of the attacks described in the 621 above section (Section 2.1) that may be levied by a BYZANTINE source 622 are therefore also out of scope. 624 In addition, these other attack actions are out of scope for this 625 work: 627 o SNIFFING - passive observation of route message contents in flight 628 o FALSIFICATION by BYZANTINE sources - unauthorized message content 629 by a legitimate authorized source. 630 o INTERFERENCE due to: 631 * NOT FORWARDING PACKETS - cannot be prevented with cryptographic 632 authentication 633 * DELAYING MESSAGES - cannot be prevented with cryptographic 634 authentication 635 * DENIAL OF RECEIPT - cannot be prevented with cryptographic 636 authentication 637 * UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR 638 working group 639 (http://www.ietf.org/html.charters/sidr-charter.html). 640 * Any other type of DoS attack. For example, a flood of traffic 641 that fills the link ahead of the router, so that the router is 642 rendered unusable and unreachable by valid packets is NOT an 643 attack that this work will address. Many other such examples 644 could be contrived. 646 3. Requirements for Phase 1 of a Routing Protocol Transport's Security 647 Update 649 The following list of requirements SHOULD be addressed by a KARP Work 650 Phase 1 security update to any Routing Protocol (according to section 651 4.1 of the KARP Design Guide [I-D.ietf-karp-design-guide] document). 652 IT IS RECOMMENDED that any Phase 1 security update to a Rouing 653 Protocol contain a section of the specification document that 654 describes how each of these requirements are met. It is further 655 RECOMMENDED that textual justification be presented for any 656 requirements that are NOT addressed. 658 1. Clear definitions of which elements of the transmission (frame, 659 packet, segment, etc.) are protected by the authentication 660 mechanism 661 2. Strong algorithms, and defined and accepted by the security 662 community, MUST be specified. The option should use algorithms 663 considered accepted by the IETF's Security community, which are 664 considered appropriately safe. The use of non-standard or 665 unpublished algorithms SHOULD BE avoided. 666 3. Algorithm agility for the cryptograhpic algorithms used in the 667 authentication MUST be specified, i.e. more than one algorithm 668 MUST be specified and it MUST be clear how new algorithms MAY be 669 specified and used within the protocol. This requirement exists 670 in case one algorithm gets broken suddenly. Research to 671 identify weakness in algorithms is constant. Breaking a cipher 672 isn't a matter of if, but when it will occur. It's highly 673 unlikely that two different algorithms will be broken 674 simultaneously. So, if two are supported, and one gets broken, 675 we can use the other until we get a new one in place. Having 676 the ability within the protocol specification to support such an 677 event, having algorithm agility, is essential. Mandating two 678 algorithms provides both a redundancy, and a mechanism for 679 enacting that redundancy when needed. Further, the mechanism 680 MUST describe the generic interface for new cryptographic 681 algorithms to be used, so that implementers can use algorithms 682 other than those specified, and so that new algorithms may be 683 specifed and supported in the future. 684 4. Secure use of simple PSKs, offering both operational convenience 685 as well as building something of a fence around stupidity, MUST 686 be specified. 687 5. Inter-connection replay protection. Packets captured from one 688 connection MUST NOT be able to be re-sent and accepted during a 689 later connection. 690 6. Intra-connection replay protection. Packets captured during a 691 connection MUST NOT be able to be re-sent and accepted during 692 that same connection, to deal with long-lived connections. 693 Additionally, replay mechanisms MUST work correctly even in the 694 presence of Routing Protocol packet prioritization by the router 695 (see requirement 17 below). 696 7. A change of security parameters REQUIRES, and even forces, a 697 change of session traffic keys 698 8. Intra-connection re-keying which occurs without a break or 699 interruption to the current peering session, and, if possible, 700 without data loss, MUST be specified. Keys need to be changed 701 periodically, for operational privacey (e.g. when an 702 administrator who had access to the keys leaves an organization) 703 and for entropy purposes, and a re-keying mechanism enables the 704 deployers to execute the change without productivity loss. 705 9. Efficient re-keying SHOULD be provided. The specificaion SHOULD 706 support rekeying during a connection without the need to expend 707 undue computational resources. In particular, the specification 708 SHOULD avoid the need to try/compute multiple keys on a given 709 packet. 710 10. Prevent DoS attacks as those described as in-scope in the 711 threats section Section 2.1 above. 712 11. Default mechanisms and algorithms specified and defined are 713 REQUIRED for all implementations. 714 12. Manual keying MUST be supported. 715 13. Architecture of the specification MUST consider and allow for 716 future use of a KMP. 718 14. The authentication mechanism in the Routing Protocol MUST be 719 decoupled from the key management system used. It MUST be 720 obvious how the keying material was obtained, and the process 721 for obtaining the keying material MUST exist outside of the 722 Routing Protocol. This will allow for the various key 723 generation methods, like manual keys and KMPs, to be used with 724 the same Routing Protocol mechanism. 725 15. Convergence times of the Routing Protocols SHOULD NOT be 726 materially affected. Materially here is defined as anything 727 greater than a 5% convergence time increase. Note that 728 convergence is different than boot time. Also note that 729 convergence time has a lot to do with the speed of processors 730 used on individual routing peers, and this processing power 731 increases by Moore's law over time, meaning that the same route 732 calculations and table population routines will decrease in 733 duration over time. Therefore, this requirement should be 734 considered only in terms of total number of messages that must 735 be exchanged, and less for the computational intensity of 736 processing any one message. 737 16. The changes or addition of security mechanisms SHOULD NOT cause 738 a refresh of route updates or cause additional route updates to 739 be generated. 740 17. Router implementations provide prioritized treament to certain 741 protocol packets. For example, OSPF HELLO messages and ACKs are 742 prioritized for processing above other OSPF packets. The 743 authentication mechanism SHOULD NOT interfere with the ability 744 to observe and enforce such prioritizations. Any effect on such 745 priority mechanisms MUST be explicitly documented and justified. 746 18. The authentication mechanism does not provide message 747 confidentiality, but SHOULD NOT preclude the possibility of 748 confidentiality support being added in the future. 749 19. The KARP mechanism MUST provide a sufficiently large sequence 750 number space so that intra-connection replay protection will 751 succeed. [Editor note: This may be more of a design guide item 752 than a requirement? Also, it may be best to include it with 753 3.6?] 754 20. The new security and authentication mechanisms MUST support 755 incremental deployment. It will not be feasible to deploy a new 756 Routing Protocol authentication mechanism throughout the network 757 instantaneously. It also may not be possible to deploy such a 758 mechanism to all routers in a large autonomous system (AS) at 759 one time. Proposed solutions SHOULD support an incremental 760 deployment method that provides some benefit for those who 761 participate. Because of this, there are several requirements 762 that any proposed KARP mechanism should consider. 763 21. 765 1. The Routing Protocol security mechanism MUST enable each 766 router to configure use of the security mechanism on a per- 767 peer basis where the communication is one-on-one. 768 2. The new KARP mechanism MUST provide backward compatibility 769 in the message formatting, transmission, and processing of 770 routing information carried through a mixed security 771 environment. Message formatting in a fully secured 772 environment MAY be handled in a non-backward compatible 773 fashion though care must be taken to ensure that routing 774 protocol packets can traverse intermediate routers which 775 don't support the new format. 776 3. In an environment where both secured and non-secured 777 systems are interoperating a mechanism MUST exist for 778 secured systems to identify whether an originator intended 779 the information to be secured. 780 4. In an environment where secured service is in the process 781 of being deployed a mechanism MUST exist to support a 782 transition free of service interruption (caused by the 783 deployment per se). 784 22. The introduction of mechanisms to improve routing authentication 785 and security may increase the processing performed by a router. 786 Since most of the currently deployed routers do not have 787 hardware to accelerate cryptographic operations, these 788 operations could impose a significant processing burden under 789 some circumstances. Thus proposed solutions should be evaluated 790 carefully with regard to the processing burden they may impose, 791 since deployment may be impeded if network operators perceive 792 that a solution will impose a processing burden which either: 793 23. 794 * provokes substantial capital expense, or 795 * threatens to destabilize routers. 796 24. Given the high number of routers that would require the new 797 authentication mechanisms in a typical ISP deployment, solutions 798 can increase their appeal by minimizing the burden imposed on 799 all routers in favor of confining significant work loads to a 800 relatively small number of devices. Optional features or 801 increased assurance that provokes more pervasive processing load 802 MAY be made available for deployments where the additional 803 resources are economically justifiable. 804 25. The new authentication and security mechanisms should not rely 805 on systems external to the routing system (the equipment that is 806 performing forwarding). In order to ensure the rapid 807 initialization and/or return to service of failed nodes it is 808 important to reduce reliance on these external systems to the 809 greatest extent possible. Therefore, proposed solutions SHOULD 810 NOT require connections to external systems, beyond those 811 directly involved in peering relationships, in order to return 812 to full service. It is however acceptable for the proposed 813 solutions to require post initialization synchronization with 814 external systems in order to fully synchronize the security 815 information. 816 26. 818 4. Security Considerations 820 This document is mostly about security considerations for the KARP 821 efforts, both threats and requirements for solving those threats. 822 More detailed security considerations were placed in the Security 823 Considerations section of the KARP Design Guide 824 [I-D.ietf-karp-design-guide] document. 826 5. IANA Considerations 828 This document has no actions for IANA. 830 6. Acknowledgements 832 The majority of the text for version -00 of this document was taken 833 from draft-lebovitz-karp-roadmap, authored by Gregory Lebovitz. 835 Manav Bhatia provided a detailed review of the existing requirements, 836 and provided text for a few more. 838 7. Change History (RFC Editor: Delete Before Publishing) 840 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 841 Please remove before publishing as RFC.] 843 kmart-00-00 original rough rough rough draft for review by routing 844 and security AD's 846 karp-threats-reqs-00- 848 o removed all the portions that will be covered in either 849 draft-ietf-karp-design-guide or draft-ietf-karp-framework 851 8. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 853 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 854 Please remove before publishing as RFC.] 855 List of stuff that still needs work 856 o Clean up section 3 requirements, parsing for overlaps, and 857 ensuring that each are written in such a way as to be objectively 858 either filled or not filled by a KARP spec. 859 o Manav check sect 3 for inclusion of the various requirements you 860 sent to Gregory. Provide clear text for any omissions. 861 o check Brian Weis text on threats against what is in sect 2 already 862 to ensure it's covered. 863 o Review by a few other security area folks. 865 9. References 867 9.1. Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 873 Routing Protocols", RFC 4593, October 2006. 875 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 876 IAB workshop on Unwanted Traffic March 9-10, 2006", 877 RFC 4948, August 2007. 879 9.2. Informative References 881 [I-D.ao-crypto] 882 Lebovitz, G., "Cryptographic Algorithms, Use and 883 Implementation Requirements for TCP Authentication 884 Option", March 2009, . 887 [I-D.ietf-karp-design-guide] 888 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 889 Routing Protocols (KARP) Design Guidelines", 890 draft-ietf-karp-design-guide-00 (work in progress), 891 February 2010. 893 [I-D.ietf-karp-framework] 894 Atwood, W. and G. Lebovitz, "Framework for Cryptographic 895 Authentication of Routing Protocol Packets on the Wire", 896 draft-ietf-karp-framework-00 (work in progress), 897 February 2010. 899 [I-D.ietf-pim-sm-linklocal] 900 Atwood, W., Islam, S., and M. Siami, "Authentication and 901 Confidentiality in PIM-SM Link-local Messages", 902 draft-ietf-pim-sm-linklocal-10 (work in progress), 903 December 2009. 905 [I-D.ietf-tcpm-tcp-auth-opt] 906 Touch, J., Mankin, A., and R. Bonica, "The TCP 907 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10 908 (work in progress), January 2010. 910 [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure 911 Security Report", October 2008, 912 . 914 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 915 dual environments", RFC 1195, December 1990. 917 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 919 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 920 November 1998. 922 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 923 Signature Option", RFC 3562, July 2003. 925 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 926 Protocol (MSDP)", RFC 3618, October 2003. 928 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 929 Independent Multicast - Dense Mode (PIM-DM): Protocol 930 Specification (Revised)", RFC 3973, January 2005. 932 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 933 Requirements for Security", BCP 106, RFC 4086, June 2005. 935 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 936 Key Management", BCP 107, RFC 4107, June 2005. 938 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 939 Protocol 4 (BGP-4)", RFC 4271, January 2006. 941 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 942 Internet Protocol", RFC 4301, December 2005. 944 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 945 RFC 4303, December 2005. 947 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 948 RFC 4306, December 2005. 950 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 951 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 952 Protocol Specification (Revised)", RFC 4601, August 2006. 954 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 955 Advanced Encryption Standard-Cipher-based Message 956 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 957 PRF-128) Algorithm for the Internet Key Exchange Protocol 958 (IKE)", RFC 4615, August 2006. 960 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 961 RFC 4949, August 2007. 963 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 964 Specification", RFC 5036, October 2007. 966 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 967 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 968 May 2008. 970 Authors' Addresses 972 Gregory Lebovitz 973 Juniper Networks, Inc. 974 1194 North Mathilda Ave. 975 Sunnyvale, CA 94089-1206 976 US 978 Phone: 979 Email: gregory.ietf@gmail.com 981 Phone: 982 Email: