idnits 2.17.1 draft-ietf-isis-extended-sequence-no-tlv-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (April 22, 2015) is 3292 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-isis-analysis' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-gdoi-mac-tek' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 393, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-07) exists of draft-ietf-karp-isis-analysis-04 Summary: 0 errors (**), 0 flaws (~~), 5 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 W. Lu 4 Intended status: Standards Track A. Tian 5 Expires: October 24, 2015 Ericsson Inc. 6 N. Shen 7 Cisco Systems, Inc. 8 April 22, 2015 10 IS-IS Extended Sequence number TLV 11 draft-ietf-isis-extended-sequence-no-tlv-06 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 October 24, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4 57 2.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . 4 61 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 5 62 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 6 63 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Backward Compatibility and Deployment . . . . . . . . . . . . 6 66 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 10.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. ESSN Encoding Mechanisms . . . . . . . . . . . . . . 9 75 A.1. Using Timestamp . . . . . . . . . . . . . . . . . . . . . 9 76 A.2. Using Non-Volatile Storage . . . . . . . . . . . . . . . 10 77 Appendix B. Operational/Implementation consideration . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 With the rapid development of new data center infrastructures, due to 83 its flexibility and scalability attributes, Intermediate System to 84 Intermediate System (IS-IS, [ISO10589]) has been adopted widely 85 in various L2/L3 routing and switching deployment of the data centers 86 and for critical business operations. Also, while technologies such 87 as Software Defined Networks (SDN) may improve network management and 88 enable new applications, their use also has an effect on the security 89 requirements of the routing infrastructure. 91 A replayed IS-IS PDU can potentially cause many problems in the IS-IS 92 networks ranging from bouncing adjacencies to black hole or even some 93 form of Denial of Service (DoS) attacks as explained in Section 2. 94 This problem is also discussed in security consideration section, in 95 the context of cryptographic authentication work as described in 96 [RFC5304] and in [RFC5310]. 98 Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) 99 and Sequence number PDUs (SNPs) from the replay attacks. However, 100 Link State PDUs (LSPs) have sequence number in the LSP header as 101 defined in [ISO10589], with which it can effectively mitigate 102 the intra-session replay attacks. But, LSPs are still susceptible to 103 inter-session replay attacks. 105 This document defines Extended Sequence number (ESN) TLV to protect 106 Intermediate System to Intermediate System (IS-IS) PDUs from replay 107 attacks. 109 The new ESN TLV defined here thwart these threats and can be deployed 110 with authentication mechanism as specified in [RFC5304] and in 111 [RFC5310] for a more secure network. 113 Replay attacks can be effectively mitigated by deploying a group key 114 management protocol (being developed as defined in [I-D.yeung- 115 g-ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key change 116 policy. Currently, there is no such mechanism defined for IS-IS. 117 Even if such a mechanism is defined, usage of this TLV can be helpful 118 to avoid replays before the keys are changed. 120 Also, it is believed, even when such a key management system is 121 deployed, there always will be some manual key based systems that co- 122 exist with KMP (Key Management Protocol) based systems. The ESN TLV 123 defined in this document is more helpful for such deployments. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 1.2. Acronyms 133 CSNP - Complete Sequence Number PDU 135 ESN - Extended Sequence Number 137 IIH - IS-IS Hello PDU 139 IS - Intermediate System 141 KMP - Key Management Protocol (auto key management) 142 LSP - IS-IS Link State PDU 144 MKM - Manual Key management Protocols 146 PDU - Protocol Data Unit 148 PSNP - Partial Sequence Number PDU 150 SNP - Sequence Number PDU 152 2. Replay attacks and Impact on IS-IS networks 154 Replaying a captured protocol packet to cause damage is a common 155 threat for any protocol. Securing the packet with cryptographic 156 authentication information alone cannot mitigate this threat 157 completely. This section explains the replay attacks and the 158 applicability of the same for each IS-IS PDU. 160 2.1. IIHs 162 When an adjacency is brought up an IS sends an IIH packet with an 163 empty neighbor list (TLV 6), which can be sent with or without 164 authentication information. Packets can be replayed later on the 165 broadcast network which may cause all ISes to bounce the adjacency, 166 thus churning the network. Note that mitigating replay is only 167 possible when authentication information is present. 169 2.2. LSPs 171 Normal operation of the IS-IS update Process as specified in 172 [ISO10589] provides timely recovery from all LSP replay 173 attacks. Therefore the use of the extensions defined in this 174 document are prohibited in LSPs. Further discussion of the 175 vulnerability of LSPs to replay attacks can be found in [I-D.ietf- 176 karp-isis-analysis]. 178 2.3. SNPs 180 A replayed CSNP can result in the sending of unnecessary PSNPs on a 181 given link. A replayed CSNP or PSNP can result in unnecessary LSP 182 flooding on the link. 184 3. Extended Sequence Number TLV 186 The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 187 Type, 1 octet that specifies the number of bytes in the Value field 188 and a 12 byte Value field. This TLV is defined only for IIH and SNP 189 PDUs. 191 x CODE - 11. 193 x LENGTH - total length of the value field, which is 12 bytes. 195 x Value - 64-bit Extended Session Sequence Number (ESSN), which is 196 followed by a 32 bit monotonically increasing per Packet Sequence 197 Number (PSN). 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+ 202 | Type | 203 +-+-+-+-+-+-+-+-+ 204 | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Extended Session Sequence Number (High Order 32 Bits) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Extended Session Sequence Number (Low Order 32 Bits) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Packet Sequence Number (32 Bits) | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 1: Extended Sequence Number (ESN) TLV 215 The ESN TLV defined here is optional. Though this is an optional 216 TLV, this can be mandatory on a link when 'verify' mode is enabled as 217 specified in Section 5.1. The ESN TLV MAY be present only in any IIH 218 and SNP PDUs. A PDU with multiple ESN TLVs is invalid and MUST be 219 discarded on receipt. 221 The 64 bit ESSN MUST be non-zero and MUST contain ever increasing 222 number whenever it is changed due any situation as specified in 223 Section 3.1. Encoding the 64-bit unsigned integer ESSN value is a 224 local matter and implementations MAY use one of the alternatives 225 provided in Appendix A. Effectively, for each PDU which contains the 226 ESN TLV the 96 bit unsigned integer value consisting of the 64 bit 227 ESSN and 32 bit Packet Sequence Number (PSN) - where ESSN is the 228 higher order 64 bits - MUST be greater than the most recently 229 received value in a PDU of the same type originated by the same IS. 231 3.1. Sequence Number Wrap 233 If the 32-bit Packet Sequence Number in ESN TLV wraps or for the cold 234 restart of the router, the 64-bit ESSN value MUST be set higher than 235 the previous value. IS-IS implementations MAY use guidelines 236 provided in Appendix A for accomplishing this. 238 4. Mechanism and Packet Encoding 240 The encoding of ESN TLV in each applicable IS-IS PDU is detailed 241 below. Please refer to Section 5 for appropriate operations on how 242 to inter-op with legacy node(s) that do not support the extensions 243 defined in this document. If the received PDU with ESN TLV is 244 accepted then the stored value for the corresponding originator and 245 PDU type MUST be updated with the latest value received. Please note 246 that level information is included in the PDU type. 248 4.1. IIHs 250 ESN TLV information is maintained for each type of IIH PDU being sent 251 on a given circuit. The procedures for encoding, verification and 252 sequence number wrap scenarios are explained in Section 3. 254 4.2. SNPs 256 A separate CSNP/PSNP ESN TLV information is maintained per PDU type, 257 per originator and per link. The procedures for encoding, 258 verification and sequence number wrap scenarios are explained in 259 Section 3. 261 5. Backward Compatibility and Deployment 263 The implementation and deployment of the ESN TLV can be done to 264 support backward compatibility and gradual deployment in the network 265 without requiring a flag day. This feature can also be deployed for 266 the links in a certain area of the network where the maximum security 267 mechanism is needed, or it can be deployed for the entire network. 269 The implementation SHOULD allow the configuration of ESN TLV feature 270 on each IS-IS link level. The implementation SHOULD also allow 271 operators to control the configuration of the 'send' and/or 'verify' 272 feature of IS-IS PDUs for the links and for the node. In this 273 document, the 'send' operation is to include the ESN TLV in its own 274 IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in 275 the receiving IS-IS PDUs from neighbors. 277 In the face of an adversary doing an active attack, it is possible to 278 have inconsistent data view in the network, if there is a 279 considerable delay in enabling ESN TLV 'verify' operation from first 280 node to the last node in the network or all nodes of a particular LAN 281 segment, where 'send' mode is configured. This can happen primarily 282 because, replay PDUs can potentially be accepted by the nodes where 283 'verify' operation is still not provisioned at the time of the 284 attack. To minimize such a window it is recommended that 285 provisioning of 'verify' SHOULD be done in a timely fashion by the 286 network operators. 288 5.1. IIH and SNPs 290 On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP 291 and PSNP). The "send" and "verify" modes described above can be set 292 independently on each link and in the case of a broadcast network 293 independently for each level. 295 To introduce ESN support without disrupting operations, ISs on a 296 given interface are first configured to operate in 'send' mode. Once 297 all routers operating on an interface are operating in 'send' mode 298 'verify' mode can be enabled on each IS. Once 'verify' mode is set 299 for an interface all the IIH and SNP PDUs being sent on that 300 interface MUST contain the ESN TLV. Any such PDU received without an 301 ESN TLV MUST be discarded when 'verify' mode is enabled. Similarly, 302 to safely disable ESN support on a link, 'verify' mode is disabled on 303 all ISs on the link. Once all routers operating on an interface are 304 disabled from 'verify' mode 'send' mode can be disabled on each IS. 305 Please refer Section 5 for considerations on enabling or disabling 306 'verify' mode on all ISs on a link. 308 6. IANA Considerations 310 A new TLV code point is assigned by IANA from the IS-IS TLV 311 Codepoints Registry as defined in this document, referred to as the 312 "Extended Sequence Number" TLV, with the following attributes: 314 Type Description IIH LSP SNP Purge 315 ---- --------------------- --- --- --- ----- 316 11 ESN TLV Y N Y N 318 Figure 2: IS-IS Codepoints Registry Entry 320 7. Security Considerations 322 This document describes a mechanism to the replay attack threat as 323 discussed in the Security Considerations section of [RFC5304] and in 324 [RFC5310]. If an adversary either does not forward the packets or 325 delay the same as specified in Section 3.3 of [RFC6862], the 326 mechanism specified in this document cannot mitigate those threats. 327 Also some of the threats as specified in Section 2.3 of [I-D.ietf- 328 karp-isis-analysis] are not addressable with ESN TLV as specified in 329 this document. This document does not introduce any new security 330 concerns to IS-IS or any other specifications referenced in this 331 document. 333 8. Contributors 335 Authors would like to thank Les Ginsberg for his significant 336 contribution in detailed reviews and suggestions. 338 9. Acknowledgements 340 As some sort of sequence number mechanism to thwart protocol replays 341 is a old mechanism, authors of this document do not make any claims 342 on the originality of the overall protection idea described. Authors 343 are thankful for the review and the valuable feedback provided by 344 Acee Lindem and Joel Halpern. Thanks to Alia Atlas, Chris Hopps, 345 Nevil Brownlee and Adam W. Montville for their reviews and 346 suggestions during IESG directorate review. Authors would also thank 347 Christer Holmberg, Ben Campbell, Barry Leiba, Stephen Farrell and 348 Alvaro Retana for their reviews on this document. 350 10. References 352 10.1. Normative References 354 [ISO10589] 355 International Organization for Standardization, 356 "Intermediate system to intermediate system intra-domain- 357 routing routine information exchange protocol for use in 358 conjunction with the protocol for providing the 359 connectionless-mode Network Service (ISO 8473)", ISO/ 360 IEC 10589:2002, Second Edition, Nov. 2002. 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 366 Time Protocol Version 4: Protocol and Algorithms 367 Specification", RFC 5905, June 2010. 369 10.2. Informative References 371 [I-D.hartman-karp-mrkmp] 372 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 373 Key Management Protocol (MaRK)", draft-hartman-karp- 374 mrkmp-05 (work in progress), September 2012. 376 [I-D.ietf-karp-isis-analysis] 377 Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security 378 analysis", draft-ietf-karp-isis-analysis-04 (work in 379 progress), March 2015. 381 [I-D.weis-gdoi-mac-tek] 382 Weis, B. and S. Rowles, "GDOI Generic Message 383 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 384 (work in progress), September 2011. 386 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 387 Authentication", RFC 5304, October 2008. 389 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 390 and M. Fanto, "IS-IS Generic Cryptographic 391 Authentication", RFC 5310, February 2009. 393 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 394 Routing Protocols (KARP) Design Guidelines", RFC 6518, 395 February 2012. 397 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 398 Authentication for Routing Protocols (KARP) Overview, 399 Threats, and Requirements", RFC 6862, March 2013. 401 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 402 "Security Extension for OSPFv2 When Using Manual Key 403 Management", RFC 7474, April 2015. 405 Appendix A. ESSN Encoding Mechanisms 407 IS-IS nodes implementing this specification SHOULD use available 408 mechanisms to preserve the 64-bit Extended Session Sequence Number's 409 strictly increasing property, whenever it is changed for the deployed 410 life of the IS-IS node (including cold restarts). 412 This Appendix provides only guidelines for achieving the same and 413 implementations can resort to any similar method as far as strictly 414 increasing property of the 64-bit ESSN in ESN TLV is maintained. 416 A.1. Using Timestamp 418 One mechanism for accomplishing this is by encoding 64-bit ESSN as 419 system time represented in 64-bit unsigned integer value. This MAY 420 be similar to the system timestamp encoding for NTP long format as 421 defined in Appendix A.4 of [RFC5905]. New current time MAY be used 422 when the IS-IS node loses its sequence number state including in 423 Packet Sequence Number wrap scenarios. 425 Implementations MUST make sure while encoding the 64-bit ESN value 426 with current system time, it should not default to any previous value 427 or some default node time of the system; especially after cold 428 restarts or any other similar events. In general system time must be 429 preserved across cold restarts in order for this mechanism to be 430 feasible. One example of such implementation is to use a battery 431 backed real-time clock (RTC). 433 A.2. Using Non-Volatile Storage 435 One other mechanism for accomplishing this would be similar to the 436 one as specified in [RFC7474], to use the 64-bit ESSN as a wrap/boot 437 count stored in non-volatile storage. This value is incremented 438 anytime the IS-IS node loses its sequence number state including in 439 Packet Sequence Number wrap scenarios. 441 The drawback of this approach per Section 8 of [RFC7474], if used is 442 applicable here. It requires the IS-IS implementation to be able to 443 save its boot count in non-volatile storage. If the non-volatile 444 storage is ever repaired or router hardware is upgraded such that the 445 contents are lost, keys MUST be changed to prevent replay attacks. 447 Appendix B. Operational/Implementation consideration 449 Since the ESN is maintained per interface, per level and per PDU 450 type, this scheme can be useful for monitoring the health of the IS- 451 IS adjacency. A Packet Sequence Number skip on IIH can be recorded 452 by the neighbors which can be used later to correlate with adjacency 453 state changes over the interface. For instance in a multi-access 454 media, all the neighbors have the skips from the same IIH sender or 455 only one neighbor has the Packet Sequence Number skips can indicate 456 completely different issues on the network. Effective usage of the 457 TLV defined in this document for operational issues MAY also need 458 more system information before making concrete conclusions and 459 defining all that information is beyond the scope of this document. 461 Authors' Addresses 463 Uma Chunduri 464 Ericsson Inc. 465 300 Holger Way, 466 San Jose, California 95134 467 USA 469 Phone: 408 750-5678 470 Email: uma.chunduri@ericsson.com 471 Wenhu Lu 472 Ericsson Inc. 473 300 Holger Way, 474 San Jose, California 95134 475 USA 477 Email: wenhu.lu@ericsson.com 479 Albert Tian 480 Ericsson Inc. 481 300 Holger Way, 482 San Jose, California 95134 483 USA 485 Phone: 408 750-5210 486 Email: albert.tian@ericsson.com 488 Naiming Shen 489 Cisco Systems, Inc. 490 225 West Tasman Drive, 491 San Jose, California 95134 492 USA 494 Email: naiming@cisco.com