idnits 2.17.1 draft-chunduri-isis-extended-sequence-no-tlv-04.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 (January 18, 2013) is 4114 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-karp-threats-reqs' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-gdoi-mac-tek' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 490, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-chunduri-karp-is-is-gap-analysis-03 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group U. Chunduri 3 Internet-Draft W. Lu 4 Intended status: Standards Track A. Tian 5 Expires: July 22, 2013 Ericsson Inc. 6 N. Shen 7 Cisco Systems, Inc. 8 January 18, 2013 10 IS-IS Extended Sequence number TLV 11 draft-chunduri-isis-extended-sequence-no-tlv-04 13 Abstract 15 This document defines Extended Sequence number TLV to protect 16 Intermediate System to Intermediate System (IS-IS) PDUs from replay 17 attacks. 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 July 22, 2013. 36 Copyright Notice 38 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4 57 2.1. Impact of Replays . . . . . . . . . . . . . . . . . . . . 4 58 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . . 5 59 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 6 60 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 7 61 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2.1. CSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2.2. PSNPs . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Backward Compatibility and Deployment . . . . . . . . . . . . 8 66 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . . 10 73 10. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 10.1. Operational/Implementation consideration . . . . . . . . . 10 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 With the rapid development of new data center infrastructures, due to 83 its flexibility and scalability attributes, IS-IS has been adopted 84 widely in various L2 and L3 routing deployment of the data centers 85 for critical business operations. At the meantime the SDN-enabled 86 networks even though put more power to Internet applications and also 87 make network management easier, it does raise the security 88 requirement of network routing infrastructure to another level. 90 A replayed IS-IS PDU can potentially cause many problems in the IS-IS 91 networks ranging from bouncing adjacencies to black hole or even some 92 form of Denial of Service (DoS) attacks as explained in Section 2. 93 This problem is also discussed in security consideration section, in 94 the context of cryptographic authentication work as described in 95 [RFC5304] and in [RFC5310]. 97 Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) 98 and Sequence number PDUs (SNPs) from the replay attacks. However, 99 Link State PDUs (LSPs) have sequence number in the LSP header as 100 defined in [RFC1195], with which it can effectively mitigate the 101 intra-session replay attacks. But, LSPs are still susceptible to 102 inter-session replay attacks. 104 This document defines Extended Sequence number (ESN) TLV to protect 105 Intermediate System to Intermediate System (IS-IS) PDUs from replay 106 attacks. 108 The new ESN TLV defined here thwart these threats and can be deployed 109 with authentication mechanism as specified in [RFC5304] and in 110 [RFC5310] for a more secure network. 112 Replay attacks can be effectively mitigated by deploying a group key 113 management protocol (being developed as defined in [I-D.yeung-g- 114 ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key change 115 policy. Currently, there is no such mechanism defined for IS-IS. 116 Even if such a mechanism is defined, usage of this TLV can be helpful 117 to avoid replays before the keys are changed. 119 Also, it is believed, even when such key management system is 120 deployed, there always will be some manual key based systems that co- 121 exist with KMP (Key Management Protocol) based systems. The ESN TLV 122 defined in this document is more helpful for such deployments. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 1.2. Acronyms 132 CSNP - Complete Sequence Number PDU 134 ESN - Extended Sequence Number 136 IIH - IS-IS Hello PDU 138 KMP - Key Management Protocol (auto key management) 140 LSP - IS-IS Link State PDU 142 MKM - Manual Key management Protocols 144 PDU - Protocol Data Unit 146 PSNP - Partial Sequence Number PDU 148 SNP - Sequence Number PDU 150 2. Replay attacks and Impact on IS-IS networks 152 This section explains the replay attacks and the applicability of the 153 same for IS-IS networks. Replaying a captured protocol packet to 154 cause damage is a common threat for any protocol. Securing the 155 packet with cryptographic authentication information alone can not 156 mitigate this threat completely. This has been described in detail 157 in "Replay Attacks" section of KARP IS-IS gap analysis document 158 [I-D.chunduri-karp-is-is-gap-analysis]. 160 2.1. Impact of Replays 162 At the time of adjacency bring up an IS sends IIH packet with empty 163 neighbor list (TLV 6) and with or with out the authentication 164 information as per provisioned authentication mechanism. If this 165 packet is replayed later on the broadcast network all ISes in the 166 broadcast network can bounce the adjacency to create a huge churn in 167 the network. 169 Today Link State PDUs (LSPs) have intra-session replay protection as 170 LSP header contains 32-bit sequence number which is verified for 171 every received PDU against the local LSP database. But, if the key 172 is not changed, an adversary can cause an inter-session replay attack 173 by replaying a old LSP with higher sequence number and fewer prefixes 174 or fewer adjacencies. This forces the receiver to accept and remove 175 the routes from the routing table, which eventually causes traffic 176 disruption to those prefixes. The more common pre-conditions for 177 inter-session replay attacks with LSPs and the current in-built 178 recovery mechanism, have been discussed in details in Section 2.3.1.1 179 of KARP IS-IS gap analysis document [I-D.chunduri-karp-is-is-gap- 180 analysis]. This document does not propose any solution to completely 181 mitigate the replay threat for LSPs as network can still recover 182 reliably after processing a disruptive reply. 184 In broadcast networks a replayed Complete Sequence Number PDU (CSNP) 185 can force the receiver to request Partial Sequence Number PDU (PSNP) 186 in the network and similarly, a replayed PSNP can cause unnecessary 187 LSP flood in the network. 189 Please refer KARP IS-IS gap analysis document for further details. 191 3. Extended Sequence Number TLV 193 The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 194 Type, 1 octet that specifies the number of bytes in the Value field 195 and a 12 byte Value field. This TLV is defined only for IIH and SNP 196 PDUs. 198 x CODE - TBD. 200 x LENGTH - total length of the value field, which is 12 bytes and 201 applicable for IIH and SNP PDUs. 203 x Value - 64-bit Extended Session Sequence Number (ESSN), which is 204 present for all IS-IS PDUs followed 32 bit monotonically increasing 205 per Packet Sequence Number (PSN). 207 0 1 2 3 208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 209 +-+-+-+-+-+-+-+-+ 210 | Type | 211 +-+-+-+-+-+-+-+-+ 212 | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Extended Session Sequence Number (High Order 32 Bits) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Extended Session Sequence Number (Low Order 32 Bits) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Packet Sequence Number (32 Bits) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 1: Extended Sequence Number (ESN) TLV 223 The Extended Sequence Number (ESN) TLV Type is TBD. Please refer to 224 IANA Considerations, in Section 6 for more details. Length indicates 225 the length of the value field; which is 12 bytes for IIH and SNP 226 PDUs. 228 In order to provide protection against both inter-session and intra- 229 session replay attacks, the IS-IS Extended Session Sequence Number 230 (ESSN) is defined a 64-bits value; the value MUST contain ever 231 increasing number in IIH and SNP PDUs whenever it is changed due any 232 situation as specified in Section 3.1. 234 The 32-bit Packet Sequence Number (PSN) MUST be set and increase 235 monotonically for IIH or SNP PDUs sent by IS-IS node. Upon 236 reception, the Packet Sequence number MUST be greater than the last 237 sequence number in the IIH or SNP PDUs accepted from the sending 238 IS-IS node. Otherwise, the IIH or SNP PDU is considered as replayed 239 PDU and dropped. 241 The ESN TLV defined here is optional. The ESN TLV MAY present only 242 in any IIH and SNP PDUs. If present and authentication is in use 243 this TLV MUST be included as part of the authentication data to 244 calculate the digest. A sender MUST only transmit a single ESN TLV 245 in a IS-IS PDU. 247 3.1. Sequence Number Wrap 249 If the 32-bit Packet Sequence Number in ESN TLV wraps; or session is 250 refreshed; or even for the cold restarts the 64-bit ESSN value MUST 251 be set higher than the previous value. IS-IS implementations MAY use 252 guidelines provided in Section 9 for accomplishing this. 254 4. Mechanism and Packet Encoding 256 The ESN TLV defined in this document is optional and the encoding and 257 decoding of this TLV in each IS-IS PDU is as detailed below. Also 258 refer, when to ignore processing of the ESN TLV as described in 259 Section 5 for appropriate operation in the face of legacy node(s) in 260 the network with out having this capability. 262 4.1. IIHs 264 The IIH ESN TLV information is maintained per IS-IS interface and per 265 level. For a broadcast interface, it can have two sets of ESN TLV 266 information, if the circuit belongs to both level-1 and level-2. For 267 point-to-point (P2P) interface, only one ESN TLV information is 268 needed. This TLV information can be maintained as part of the 269 adjacency state. 271 While transmitting, the 64-bit ESSN MUST always be started with a non 272 zero number and MAY use the guidelines as specified in Section 9 to 273 encode this 64-bit value. The 32-bit PSN starts from 1 and increases 274 monotonically for every subsequent PDU. 276 While receiving, the 64-bit ESSN MUST always be either same or higher 277 than the stored value in the adjacency state. Similarly, the 32-bit 278 PSN MUST be higher than the stored value in the adjacency state. If 279 the PDU is accepted then the adjacency state should be updated with 280 the last received IIH PDU's ESN TLV information. 282 For an adjacency refresh or the 32-bit PSN wrap the associated higher 283 order 64-bit ESSN MUST always be higher than the previous value and 284 the lower order 32-bit packet sequence number starts all over again. 286 4.2. SNPs 288 4.2.1. CSNPs 290 In broadcast networks, only Designated Intermediate System (DIS) CSNP 291 ESN TLV information is maintained per adjacency (per level) similar 292 to IIH ESN TLV information. The procedure for encoding, verification 293 and sequence number wrap scenarios are similar as explained in 294 Section 4.1, except separate DIS ESN TLV information should be used. 295 In case of DIS change all adjacencies in the broadcast network MUST 296 reflect new DIS's CSNP ESN TLV information in the adjacency and 297 should be used for encoding/verification. 299 In P2P networks, CSNP ESN TLV information is maintained per adjacency 300 similar to IIH ESN TLV information. The procedure for encoding, 301 verification and sequence number wrap scenarios are similar as 302 explained in Section 4.1, except separate CSNP ESN TLV information 303 should be used. 305 4.2.2. PSNPs 307 In both broadcast and P2P networks, PSNP ESN TLV information is 308 maintained per adjacency (per level) similar to IIH ESN TLV 309 information. The procedure for encoding, verification and sequence 310 number wrap scenarios are similar as explained in Section 4.1, except 311 separate PSNP ESN TLV information should be used. 313 5. Backward Compatibility and Deployment 315 The implementation and deployment of the ESN TLV can be done to 316 support backward compatibility and gradual deployment in the network 317 without requiring a flag day. This feature can also be deployed for 318 the links in a certain area of the network where the maximum security 319 mechanism is needed, or it can be deployed for the entire network. 321 The implementation SHOULD allow the configuration of ESN TLV feature 322 on each IS-IS link level. The implementation SHOULD also allow 323 operators to control the configuration of 'send' and/or 'verify' the 324 feature of IS-IS PDUs for the links and for the node. In this 325 document, the 'send' operation is to include the ESN TLV in it's own 326 IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in 327 the receiving IS-IS PDUs from neighbors. 329 In the face of an adversary doing an active attack, it is possible to 330 have inconsistent data view in the network, if there is a 331 considerable delay in enabling ESN TLV 'verify' operation from first 332 node to the last node in the network. This can happen primarily 333 because, replay PDUs can potentially be accepted by the nodes where 334 'verify' operation is still not provisioned at the time of the 335 attack. To minimize such a window it is recommended that 336 provisioning of 'verify' SHOULD be done in a timely fashion by the 337 network operators. 339 5.1. IIH and SNPs 341 On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP 342 and PSNP). When the router software is upgraded to include this 343 feature, the network operators can configure the IS-IS to 'send' the 344 ESN TLV in it's IIH PDUs and SNPs for those IS-IS interfaces on the 345 IS-IS area or level. When all the routers attached to the link or 346 links have been upgraded with this feature, network operators can 347 start to configure 'verify' on the IS-IS interfaces for all the 348 routers sharing the same link(s). This way deployment can be done in 349 per link basis in the network. The operators may decide to only 350 apply ESN TLV feature on some of the links in the network, or only on 351 their multi-access media links. 353 6. IANA Considerations 355 This document requests that IANA allocate from the IS-IS TLV 356 Codepoints Registry a new TLV, referred to as the "Extended Sequence 357 Number" TLV, with the following attributes: 359 Type Description IIH LSP SNP Purge 360 ---- --------------------- --- --- --- ----- 361 TBD ESN TLV Y N Y N 363 Figure 2: IS-IS Codepoints Registry Entry 365 7. Security Considerations 367 This document describes a mechanism to the replay attack threat as 368 discussed in the Security Considerations section of [RFC5304] and in 369 [RFC5310]. This document does not introduce any new security 370 concerns to IS-IS or any other specifications referenced in this 371 document. 373 8. Acknowledgements 375 The authors of this document do not make any claims on the 376 originality of the ideas described. Authors are thankful for the 377 review and the valuable feedback provided by Acee Lindem, Joel 378 Halpern and Les Ginsberg. 380 9. Appendix A 382 IS-IS nodes implementing this specification SHOULD use available 383 mechanisms to preserve the 64-bit Extended Session Sequence Number's 384 strictly increasing property, when ever it is changed for the 385 deployed life of the IS-IS node (including cold restarts). 387 This Appendix provides only guidelines for achieving the same and 388 implementations can resort to any similar method as far as strictly 389 increasing property of the 64-bit ESSN in ESN TLV is maintained. 391 9.1. Appendix A.1 393 One mechanism for accomplishing this is by encoding 64-bit ESSN as 394 system time represented in 64-bit unsigned integer value. This MAY 395 be similar to the system timestamp encoding for NTP long format as 396 defined in Appendix A.4 of [RFC5905]. New current time MAY be used 397 when the IS-IS node loses its sequence number state including in 398 Packet Sequence Number wrap scenarios. 400 Implementations MUST make sure while encoding the 64-bit ESN value 401 with current system time, it should not default to any previous value 402 or some default node time of the system; especially after cold 403 restarts or any other similar events. In general system time must be 404 preserved across cold restarts in order for this mechanism to be 405 feasible. One example of such implementation is to use a battery 406 backed real-time clock (RTC). 408 9.2. Appendix A.2 410 One other mechanism for accomplishing this would be similar to the 411 one as specified in [I-D.ietf-ospf-security-extension-manual-keying], 412 to use the 64-bit ESSN as a wrap/boot count stored in non-volatile 413 storage. This value is incremented anytime the IS-IS node loses its 414 sequence number state including in Packet Sequence Number wrap 415 scenarios. 417 The drawback of this approach per Section 6 of [I-D.ietf-ospf- 418 security-extension-manual-keying], if used is applicable here. The 419 only drawback is, it requires the IS-IS implementation to be able to 420 save its boot count in non-volatile storage. If the non-volatile 421 storage is ever repaired or upgraded such that the contents are lost, 422 keys MUST be changed to prevent replay attacks. 424 10. Appendix B 426 10.1. Operational/Implementation consideration 428 Since the ESN is maintained per interface, per level and per PDU 429 type, this scheme can be useful for monitoring the health of the 430 IS-IS adjacency. A Packet Sequence Number skip on IIH can be 431 recorded by the neighbors which can be used later to correlate with 432 adjacency state changes over the interface. For instance in a multi- 433 access media, all the neighbors have the skips from the same IIH 434 sender or only one neighbor has the Packet Sequence Number skips can 435 indicate completely different issues on the network. 437 11. References 439 11.1. Normative References 441 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 442 dual environments", RFC 1195, December 1990. 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 448 Time Protocol Version 4: Protocol and Algorithms 449 Specification", RFC 5905, June 2010. 451 11.2. Informative References 453 [I-D.chunduri-karp-is-is-gap-analysis] 454 Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security 455 gap analysis", draft-chunduri-karp-is-is-gap-analysis-03 456 (work in progress), October 2012. 458 [I-D.hartman-karp-mrkmp] 459 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 460 Key Management Protocol (MaRK)", 461 draft-hartman-karp-mrkmp-05 (work in progress), 462 September 2012. 464 [I-D.ietf-karp-threats-reqs] 465 Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 466 Authentication for Routing Protocols (KARP) Overview, 467 Threats, and Requirements", 468 draft-ietf-karp-threats-reqs-07 (work in progress), 469 December 2012. 471 [I-D.ietf-ospf-security-extension-manual-keying] 472 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 473 "Security Extension for OSPFv2 when using Manual Key 474 Management", 475 draft-ietf-ospf-security-extension-manual-keying-02 (work 476 in progress), April 2012. 478 [I-D.weis-gdoi-mac-tek] 479 Weis, B. and S. Rowles, "GDOI Generic Message 480 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 481 (work in progress), September 2011. 483 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 484 Authentication", RFC 5304, October 2008. 486 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 487 and M. Fanto, "IS-IS Generic Cryptographic 488 Authentication", RFC 5310, February 2009. 490 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 491 Routing Protocols (KARP) Design Guidelines", RFC 6518, 492 February 2012. 494 Authors' Addresses 496 Uma Chunduri 497 Ericsson Inc. 498 300 Holger Way, 499 San Jose, California 95134 500 USA 502 Phone: 408 750-5678 503 Email: uma.chunduri@ericsson.com 505 Wenhu Lu 506 Ericsson Inc. 507 300 Holger Way, 508 San Jose, California 95134 509 USA 511 Email: wenhu.lu@ericsson.com 513 Albert Tian 514 Ericsson Inc. 515 300 Holger Way, 516 San Jose, California 95134 517 USA 519 Phone: 408 750-5210 520 Email: albert.tian@ericsson.com 522 Naiming Shen 523 Cisco Systems, Inc. 524 225 West Tasman Drive, 525 San Jose, California 95134 526 USA 528 Email: naiming@cisco.com