idnits 2.17.1 draft-chunduri-karp-is-is-gap-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4107' is defined on line 452, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-hartman-karp-mrkmp-02 == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-01 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-03 == Outdated reference: A later version (-03) exists of draft-weis-gdoi-mac-tek-02 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group U. Chunduri 3 Internet-Draft A. Tian 4 Intended status: Informational W. Lu 5 Expires: September 13, 2012 Ericsson Inc., 6 March 12, 2012 8 KARP IS-IS security gap analysis 9 draft-chunduri-karp-is-is-gap-analysis-01 11 Abstract 13 This document analyzes the threats applicable for Intermediate system 14 to Intermediate system (IS-IS) routing protocol and security gaps 15 according to the KARP Design Guide. This document also provides 16 specific requirements to address the gaps with both manual and auto 17 key management protocols. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. Sub network Independent . . . . . . . . . . . . . . . 4 59 2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 4 60 2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5 62 2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . 5 63 2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . . 6 64 2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 7 65 3. Gap Analysis and Security Requirements . . . . . . . . . . . . 7 66 3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 7 67 3.2. Key Management Protocols . . . . . . . . . . . . . . . . . 8 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 This document analyzes the current state of Intermediate system to 79 Intermediate system (IS-IS) protocol according to the requirements 80 set forth in [RFC6518] for both manual and key management protocols. 82 With currently published work, IS-IS meets some of the requirements 83 expected from a manually keyed routing protocol. Integrity 84 protection is expanded with more cryptographic algorithms and also 85 limited algorithm agility (HMAC-SHA family) is provided with 86 [RFC5310]. Basic form of Intra-connection re-keying capability is 87 provided by the specification [RFC5310] with some gaps as explained 88 in Section 3. 90 This draft summarizes the current state of cryptographic key usage in 91 IS-IS protocol and several previous efforts to analyze IS-IS 92 security. This includes base IS-IS specification [RFC1195], 93 [RFC5304], [RFC5310] and the OPSEC working group document [RFC6039]. 94 Authors would like to acknowledge all the previous work done in the 95 above documents. 97 This document also analyzes applicability of various threats as 98 described in [ietf-karp-threats-reqs] to IS-IS, lists gaps and 99 provides specific recommendations to thwart the applicable threats 100 for both manual keying and for auto key management mechanisms. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 1.2. Acronyms 110 KMP - Key Management Protocol (auto key management) 112 MKM - Manual Key management Protocols 114 NONCE - Number Once 116 SA - Security Association 118 2. Current State 120 IS-IS is specified in International Standards Organization (ISO) 121 10589, with extensions to support Internet Protocol version 4 (IPv4) 122 described in [RFC1195]. The specification includes an authentication 123 mechanism that allows for any authentication algorithm and also 124 specifies the algorithm for clear text passwords. Further [RFC5304] 125 extends the authentication mechanism to work with HMAC-MD5 and also 126 modifies the base protocol for more effectiveness. [RFC5310] 127 provides algorithm agility, with new generic crypto authentication 128 mechanism (CRYPTO_AUTH) for IS-IS. The CRYPTO_AUTH also introduces 129 Key ID mechanism that map to unique IS-IS Security Associations 130 (SAs). 132 The following sections describe the current authentication key usage 133 for various IS-IS messages, current key change methodologies and the 134 various potential security threats. 136 2.1. Key Usage 138 IS-IS can be provisioned with a per interface, peer-to-peer key for 139 IS-IS HELLO PDUs (IIH) and a group key for Link State PDUs (LSPs) and 140 Sequence number PDUs (SNPs). IIH packets also can use the group key 141 used for LSPs and SNPs. 143 2.1.1. Sub network Independent 145 Link State PDUs, Complete and partial Sequence Number PDUs come under 146 Sub network Independent messages. For protecting Level-1 SNPs and 147 Level-1 LSPs, provisioned Area Authentication key is used. Level-2 148 SNPs as well as Level-2 LSPs use the provisioned domain 149 authentication key. 151 Since authentication is performed on the LSPs transmitted by an IS, 152 rather than on the LSP packets transmitted to a specific neighbor, it 153 is implied that all the ISes within a single flooding domain must be 154 configured with the same key in order for authentication to work 155 correctly. This is also true for SNP packets, though they are 156 limited to link local scope in broadcast networks. 158 2.1.2. Sub network dependent 160 IS-IS HELLO PDUs use the Link Level Authentication key, which may be 161 different from that of Link State PDUs (LSPs) and Sequence number 162 PDUs (SNPs). This could be particularly true for point-to-point 163 links. In broadcast networks it is possible to provision the same 164 common key used for LSPs and SNPs, to protect IIH messages. This 165 allows neighbor discovery and adjacency formation with more than one 166 neighbor on the same physical interface. 168 2.2. Key Agility 170 Key roll over without effecting the routing protocols operation is 171 critical for effective key management protocol integration. 173 Current HMAC-MD5 crypto authentication as defined in [RFC5304], 174 suggests a transition mode, so that ISes use a set of keys when 175 verifying the authentication value, to allow key changes. This 176 approach will allow changing the authentication key manually without 177 bringing down the adjacency and without dropping any control packet. 178 But, this can increase the load on control plane for the key 179 transition duration as each control packet may have to be verified by 180 more than one key and also allows to mount a potential Denial of 181 Service (DoS) attack in the transition duration. 183 The above situation is improved with the introduction of Key ID 184 mechanism as defined in [RFC5310]. With this, the receiver 185 determines the active security association (SA) by looking at the Key 186 ID field in the incoming PDU and need not try with other keys, when 187 the integrity check or digest verification fails. But, neither Key 188 co-ordination across the group nor exact key change mechanism is 189 clearly defined. [RFC5310] says: " Normally, an implementation would 190 allow the network operator to configure a set of keys in a key chain, 191 with each key in the chain having a fixed lifetime. The actual 192 operation of these mechanisms is outside the scope of this document." 194 2.3. Security Issues 196 The following section analyzes various security threats possible, in 197 the current state for IS-IS protocol. 199 2.3.1. Replay Attacks 201 Replaying a captured protocol packet to cause damage is a common 202 threat for any protocol. Securing the packet with cryptographic 203 authentication information alone can not mitigate this threat 204 completely. 206 In intra-session replay attacks a secured protocol packet of the 207 current session is replayed, can cause damage, if there is no other 208 mechanism to confirm this is a replay packet. In inter-session 209 replay attacks, captured packet from one of the previous session can 210 be replayed to cause the damage. IS-IS packets are vulnerable to 211 both these attacks, as there is no sequence number verification for 212 IIH packets and SNP packets. Also with current manual key management 213 periodic key changes across the group are done rarely. Thus the 214 intra-connection and inter-connection replay requirements are not 215 met. 217 IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 218 family in [RFC5310], to protect IS-IS packets. An adversary could 219 replay old IIHs or replay old SNPs that would cause churn in the 220 network or bring down the adjacencies. 222 1. At the time of adjacency bring up an IS sends IIH packet with 223 empty neighbor list (TLV 6) and with the authentication 224 information as per provisioned authentication mechanism. If this 225 packet is replayed later on the broadcast network, all ISes in 226 the broadcast network can bounce the adjacency to create a huge 227 churn in the network. 229 2. Today Link State PDUs (LSPs) have intra-session replay protection 230 as LSP header contains 32-bit sequence number which is verified 231 for every received packet against the local LSP database. But, 232 if the key is not changed, an adversary can cause an inter- 233 session replay attack by replaying a old LSP with higher sequence 234 number and fewer prefixes or fewer adjacencies. This forces the 235 receiver to accept and remove the routes from the routing table, 236 which eventually causes traffic disruption to those prefixes. 238 3. In point-to-point (P2P) networks, if a old Complete Sequence 239 Number packet (CSNP) is replayed this can cause LSP flood in the 240 network. Similarly a replayed Partial Sequence Number packet 241 (PSNP) can cause LSP flood in the broadcast network. 243 2.3.2. Spoofing Attacks 245 IS-IS shares the same key between all neighbors in an area or in a 246 domain to protect the LSP, SNP packets and in broadcast networks even 247 IIH packets. False advertisement by a router is not within scope of 248 the KARP work. However, given the wide sharing of keys as described 249 above, there is a significant risk that an attacker can compromise a 250 key from one device, and use it to falsely participate in the 251 routing, possibly even in a very separate part of the network. 252 Possession of the key it self is used as authentication check and 253 there is no identity check separately. Spoofing occurs when an 254 illegitimate device assumes the identity of a legitimate one. An 255 attacker can use spoofing as a means for launching various types of 256 attacks. For example: 258 1. The attacker can send out unrealistic routing information that 259 might cause the disruption of network services such as block 260 holes. 262 2. A rogue system having access to the common key used to protect 263 the LSP, can send an LSP, setting the Remaining Lifetime field to 264 zero, and flooding it thereby initiating a purge. Subsequently, 265 this also can cause the sequence number of all the LSPs to 266 increase quickly to max out the sequence number space, which can 267 cause an IS to shut down for MaxAge + ZeroAgeLifetime period to 268 allow the old LSPs to age out in other ISes of the same flooding 269 domain. 271 2.3.3. DoS Attacks 273 Denial-of-service (DoS) attacks using the authentication mechanism is 274 possible and an attacker can send packets which can overwhelm the 275 security mechanism itself. An example is initiating an overwhelming 276 load of spoofed but integrity protected protocol packets, so that the 277 receiver needs to process the integrity check, only to discard the 278 packet. This can cause significant CPU usage. DoS attacks are not 279 generally preventable with in the routing protocol. As the attackers 280 are often remote, the DoS attacks are more damaging to area-scoped or 281 domain-scoped packet receivers than link-local scoped packet 282 receivers. 284 3. Gap Analysis and Security Requirements 286 This section outlines the differences between the current state of 287 the IS-IS routing protocol and the desired state as specified in KARP 288 Design Guidelines [RFC6518]. The section focuses on where IS-IS 289 protocol fails to meet general requirements as specified in the 290 threats and requirements document. 292 This section also describes security requirements that should be met 293 by IS-IS implementations that are secured by manual as well as auto 294 key management protocols. 296 3.1. Manual Key Management 298 1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be 299 protected with HMAC-SHA family of cryptographic algorithms. The 300 specification provides the limited algorithm agility (SHA 301 family). By using Key IDs, it also conceals the algorithm 302 information from the protected control messages. 304 2. Even though both intra and inter session replay attacks are best 305 prevented by deploying key management protocols with frequent key 306 change capability, basic constructs for sequence number should be 307 there in the protocol messages. So, some basic or extended 308 sequence number mechanism should be in place to protect IIH 309 packets and SNP packets. The sequence number should be increased 310 for each protocol packet. This allows mitigation of some of the 311 replay threats as mentioned in Section 2.3.1. 313 3. Any common key mechanism with keys shared across a group of 314 routers is susceptible to spoofing attacks caused by a malicious 315 router. Separate authentication check (apart from the integrity 316 check to verify the digest) with digital signatures as described 317 in [RFC2154], can effectively nullify this attack. But this 318 approach was never deployed and one can only assume due to 319 operational considerations at that time. The alternative 320 approach to thwart this threat would be by using the keys from 321 the group key management protocol. As the group key(s) are 322 generated by authenticating the member ISes in the group first, 323 and then periodically rekeyed, per packet identity or 324 authentication check may not be needed. 326 4. In general DoS attacks may not be preventable with mechanism from 327 routing protocols itself. But some form of Admin controlled 328 lists (ACLs) at the forwarding plane can reduce the damage. 329 There are some other forms the DoS attacks common to any protocol 330 are not in scope as per the section 2.2 in [I-D.ietf-karp- 331 threats-reqs]. 333 As discussed in Section 2.2, though Key ID mechanism in [RFC5310] 334 helps, better key co-ordination mechanism for key roll over is 335 desirable even with manual key management. But, it fell short of 336 specifying exact mechanism other than using key chains. The specific 337 requirements: 339 a. Keys SHOULD be able to change without affecting the established 340 adjacency and even better without any control packet loss. 342 b. Keys SHOULD be able to change without effecting the protocol 343 operations, for example, LSP flooding should not be help for a 344 specific Key ID availability. 346 c. Any proposed mechanism SHOULD also be further incrementally 347 deployable with key management protocols. 349 3.2. Key Management Protocols 351 In broadcast deployments, the keys used for protecting IS-IS 352 protocols messages can, in particular, be group keys. A mechanism, 353 similar to as described in [I-D.weis-gdoi-mac-tek] can be used to 354 distribute group keys to a group of ISes in Level-1 area or Level-2 355 domain, using GDOI [I-D.ietf-msec-gdoi-update]. There are also 356 similar approaches with IKEv2 ([RFC5996]) based GDOI, to routing 357 protocols as described in [I-D.hartman-karp-mrkmp]. 359 If a group key is used, the authentication granularity becomes group 360 membership of devices, not peer authentication between devices. 362 Group key management protocol deployed SHOULD be capable of 363 supporting rekeying support. 365 In some deployments, where IS-IS point-to-point (P2P) mode is used 366 for adjacency bring-up, sub network dependent messages (IIHs) can use 367 a different key shared between the two point-to-point peers, while 368 all other messages use a group key. When group keying mechanism is 369 deployed, even the P2P IIHs can be protected with the common group 370 keys. This approach facilitates one key management mechanism instead 371 of both pair-wise keying and group keying protocols to be deployed 372 together. 374 As mentioned earlier, effective key change capability with in the 375 routing protocol which allows key roll over without impacting the 376 routing protocol operation, is one of the requirements for deploying 377 any group key mechanism. Once such mechanism is in place with 378 deployment of group key management protocol, IS-IS can be protected 379 from various threats not limited to intra and inter session replay 380 attacks and spoofing attacks. 382 Specific use of crypto tables [I-D.ietf-karp-crypto-key-table] should 383 be defined for IS-IS protocol. 385 4. IANA Considerations 387 This document defines no new namespaces. 389 5. Security Considerations 391 This document is mostly about security considerations of IS-IS 392 protocol, lists potential threats and security requirements for 393 solving those threats. This document does not introduce any new 394 security threats for IS-IS protocol. For more detailed security 395 considerations please refer the Security Considerations section of 396 the KARP Design Guide [RFC6518] document as well as KARP threat 397 document [I-D.ietf-karp-threats-reqs] 399 6. Acknowledgements 401 Authors would like to thank Joel Halpern for encouraging us to come 402 up with this document and giving valuable review comments. 404 7. References 405 7.1. Normative References 407 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 408 dual environments", RFC 1195, December 1990. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 414 Authentication", RFC 5304, October 2008. 416 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 417 and M. Fanto, "IS-IS Generic Cryptographic 418 Authentication", RFC 5310, February 2009. 420 7.2. Informative References 422 [I-D.hartman-karp-mrkmp] 423 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 424 Key Management Protocol (MaRK)", 425 draft-hartman-karp-mrkmp-02 (work in progress), July 2011. 427 [I-D.ietf-karp-crypto-key-table] 428 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 429 Cryptographic Keys", draft-ietf-karp-crypto-key-table-01 430 (work in progress), May 2011. 432 [I-D.ietf-karp-threats-reqs] 433 Lebovitz, G., Bhatia, M., and R. White, "The Threat 434 Analysis and Requirements for Cryptographic Authentication 435 of Routing Protocols' Transports", 436 draft-ietf-karp-threats-reqs-03 (work in progress), 437 June 2011. 439 [I-D.ietf-msec-gdoi-update] 440 Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 441 of Interpretation", draft-ietf-msec-gdoi-update-11 (work 442 in progress), August 2011. 444 [I-D.weis-gdoi-mac-tek] 445 Weis, B. and S. Rowles, "GDOI Generic Message 446 Authentication Code Policy", draft-weis-gdoi-mac-tek-02 447 (work in progress), March 2011. 449 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 450 Digital Signatures", RFC 2154, June 1997. 452 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 453 Key Management", BCP 107, RFC 4107, June 2005. 455 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 456 "Internet Key Exchange Protocol Version 2 (IKEv2)", 457 RFC 5996, September 2010. 459 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 460 with Existing Cryptographic Protection Methods for Routing 461 Protocols", RFC 6039, October 2010. 463 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 464 Routing Protocols (KARP) Design Guidelines", RFC 6518, 465 February 2012. 467 Authors' Addresses 469 Uma Chunduri 470 Ericsson Inc., 471 300 Holger Way, 472 San Jose, California 95134 473 USA 475 Phone: 408 750-5678 476 Email: uma.chunduri@ericsson.com 478 Albert Tian 479 Ericsson Inc., 480 300 Holger Way, 481 San Jose, California 95134 482 USA 484 Phone: 408 750-5210 485 Email: albert.tian@ericsson.com 487 Wenhu Lu 488 Ericsson Inc., 489 300 Holger Way, 490 San Jose, California 95134 491 USA 493 Email: wenhu.lu@ericsson.com