idnits 2.17.1 draft-ietf-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 6, 2015) is 3391 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 418, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-gdoi-mac-tek' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 441, 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-03 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: July 10, 2015 Ericsson Inc. 6 N. Shen 7 Cisco Systems, Inc. 8 January 6, 2015 10 IS-IS Extended Sequence number TLV 11 draft-ietf-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 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 10. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . 8 73 10.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . 8 74 11. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Operational/Implementation consideration . . . . . . . . 9 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 12.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 With the rapid development of new data center infrastructures, due to 84 its flexibility and scalability attributes, IS-IS has been adopted 85 widely in various L2/L3 routing and switching deployment of the data 86 centers and for critical business operations. At the meantime the 87 SDN-enabled networks even though put more power to Internet 88 applications and also make network management easier, it does raise 89 the security requirement of network routing infrastructure to another 90 level. 92 A replayed IS-IS PDU can potentially cause many problems in the IS-IS 93 networks ranging from bouncing adjacencies to black hole or even some 94 form of Denial of Service (DoS) attacks as explained in Section 2. 95 This problem is also discussed in security consideration section, in 96 the context of cryptographic authentication work as described in 97 [RFC5304] and in [RFC5310]. 99 Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) 100 and Sequence number PDUs (SNPs) from the replay attacks. However, 101 Link State PDUs (LSPs) have sequence number in the LSP header as 102 defined in [ISO10589], with which it can effectively mitigate 103 the intra-session replay attacks. But, LSPs are still susceptible to 104 inter-session replay attacks. 106 This document defines Extended Sequence number (ESN) TLV to protect 107 Intermediate System to Intermediate System (IS-IS) PDUs from replay 108 attacks. 110 The new ESN TLV defined here thwart these threats and can be deployed 111 with authentication mechanism as specified in [RFC5304] and in 112 [RFC5310] for a more secure network. 114 Replay attacks can be effectively mitigated by deploying a group key 115 management protocol (being developed as defined in [I-D.yeung- 116 g-ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key change 117 policy. Currently, there is no such mechanism defined for IS-IS. 118 Even if such a mechanism is defined, usage of this TLV can be helpful 119 to avoid replays before the keys are changed. 121 Also, it is believed, even when such key management system is 122 deployed, there always will be some manual key based systems that co- 123 exist with KMP (Key Management Protocol) based systems. The ESN TLV 124 defined in this document is more helpful for such deployments. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 1.2. Acronyms 134 CSNP - Complete Sequence Number PDU 136 ESN - Extended Sequence Number 138 IIH - IS-IS Hello PDU 140 KMP - Key Management Protocol (auto key management) 142 LSP - IS-IS Link State PDU 143 MKM - Manual Key management Protocols 145 PDU - Protocol Data Unit 147 PSNP - Partial Sequence Number PDU 149 SNP - Sequence Number PDU 151 2. Replay attacks and Impact on IS-IS networks 153 Replaying a captured protocol packet to cause damage is a common 154 threat for any protocol. Securing the packet with cryptographic 155 authentication information alone cannot mitigate this threat 156 completely. This section explains the replay attacks and the 157 applicability of the same for each IS-IS PDU. 159 2.1. IIHs 161 At the time of adjacency bring up an IS sends IIH packet with empty 162 neighbor list (TLV 6) and with or without the authentication 163 information as per provisioned authentication mechanism. If this 164 packet is replayed later on the broadcast network all ISes in the 165 broadcast network can bounce the adjacency to create a huge churn in 166 the network. 168 2.2. LSPs 170 Normal operation of the IS-IS update Process as specified in 171 [ISO10589] provides timely recovery from all LSP replay 172 attacks. Therefore the use of the extensions defined in this 173 document are prohibited in LSPs. Further discussion of the 174 vulnerability of LSPs to replay attacks can be found in [I-D.ietf- 175 karp-isis-analysis]. 177 2.3. SNPs 179 A replayed CSNP can result in the sending of unnecessary PSNPs on a 180 given link. A replayed CSNP or PSNP can result in unnecessary LSP 181 flooding on the link. 183 3. Extended Sequence Number TLV 185 The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 186 Type, 1 octet that specifies the number of bytes in the Value field 187 and a 12 byte Value field. This TLV is defined only for IIH and SNP 188 PDUs. 190 x CODE - TBD. 192 x LENGTH - total length of the value field, which is 12 bytes. 194 x Value - 64-bit Extended Session Sequence Number (ESSN), which is 195 followed by a 32 bit monotonically increasing per Packet Sequence 196 Number (PSN). 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+ 201 | Type | 202 +-+-+-+-+-+-+-+-+ 203 | Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Extended Session Sequence Number (High Order 32 Bits) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Extended Session Sequence Number (Low Order 32 Bits) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Packet Sequence Number (32 Bits) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: Extended Sequence Number (ESN) TLV 214 The ESN TLV defined here is optional. Though this is an optional 215 TLV, this can be mandatory on a link when 'verify' mode is enabled as 216 specified in Section 5.1. The ESN TLV MAY be present only in any IIH 217 and SNP PDUs. A PDU with multiple ESN TLVs is invalid and MUST be 218 discarded on receipt. 220 The 64 bit ESSN MUST be non-zero and MUST contain ever increasing 221 number whenever it is changed due any situation as specified in 222 Section 3.1. For each PDU which contains the ESN TLV the 96 bit 223 unsigned integer value consisting of the 64 bit ESSN and 32 bit 224 Packet Sequence Number (PSN) - where ESSN is the higher order 64 bits 225 - MUST be greater than the most recently received value in a PDU of 226 the same type originated by the same IS. 228 3.1. Sequence Number Wrap 230 If the 32-bit Packet Sequence Number in ESN TLV wraps or for the cold 231 restart of the router, the 64-bit ESSN value MUST be set higher than 232 the previous value. IS-IS implementations MAY use guidelines 233 provided in Section 10 for accomplishing this. 235 4. Mechanism and Packet Encoding 237 The encoding of ESN TLV in each applicable IS-IS PDU is detailed 238 below. Please refer to Section 5 for appropriate operations on how 239 to inter-op with legacy node(s) that do not support the extensions 240 defined in this document. If the received PDU with ESN TLV is 241 accepted then the stored value for the corresponding originator and 242 PDU type MUST be updated with the latest value received. Please note 243 that level information is included in the PDU type. 245 4.1. IIHs 247 ESN TLV information is maintained for each type of IIH PDU being sent 248 on a given circuit. The procedures for encoding, verification and 249 sequence number wrap scenarios are explained in Section 3. 251 4.2. SNPs 253 A separate CSNP/PSNP ESN TLV information is maintained per PDU type, 254 per originator and per link. The procedures for encoding, 255 verification and sequence number wrap scenarios are explained in 256 Section 3. 258 5. Backward Compatibility and Deployment 260 The implementation and deployment of the ESN TLV can be done to 261 support backward compatibility and gradual deployment in the network 262 without requiring a flag day. This feature can also be deployed for 263 the links in a certain area of the network where the maximum security 264 mechanism is needed, or it can be deployed for the entire network. 266 The implementation SHOULD allow the configuration of ESN TLV feature 267 on each IS-IS link level. The implementation SHOULD also allow 268 operators to control the configuration of 'send' and/or 'verify' the 269 feature of IS-IS PDUs for the links and for the node. In this 270 document, the 'send' operation is to include the ESN TLV in its own 271 IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in 272 the receiving IS-IS PDUs from neighbors. 274 In the face of an adversary doing an active attack, it is possible to 275 have inconsistent data view in the network, if there is a 276 considerable delay in enabling ESN TLV 'verify' operation from first 277 node to the last node in the network. This can happen primarily 278 because, replay PDUs can potentially be accepted by the nodes where 279 'verify' operation is still not provisioned at the time of the 280 attack. To minimize such a window it is recommended that 281 provisioning of 'verify' SHOULD be done in a timely fashion by the 282 network operators. 284 5.1. IIH and SNPs 286 On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP 287 and PSNP). The "send" and "verify" modes described above can be set 288 independently on each link and in the case of a broadcast network 289 independently for each level. 291 To introduce ESN support without disrupting operations, ISs on a 292 given interface are first configured to operate in 'send' mode. Once 293 all routers operating on an interface are operating in 'send' mode 294 'verify' mode can be enabled on each IS. Once 'verify' mode is set 295 for an interface all the IIH and SNP PDUs being sent on that 296 interface MUST contain the ESN TLV. Any such PDU received without an 297 ESN TLV MUST be discarded when 'verify' mode is enabled 299 6. IANA Considerations 301 This document requests that IANA allocate from the IS-IS TLV 302 Codepoints Registry a new TLV, referred to as the "Extended Sequence 303 Number" TLV, with the following attributes: 305 Type Description IIH LSP SNP Purge 306 ---- --------------------- --- --- --- ----- 307 TBD ESN TLV Y N Y N 309 Figure 2: IS-IS Codepoints Registry Entry 311 7. Security Considerations 313 This document describes a mechanism to the replay attack threat as 314 discussed in the Security Considerations section of [RFC5304] and in 315 [RFC5310]. This document does not introduce any new security 316 concerns to IS-IS or any other specifications referenced in this 317 document. 319 8. Contributors 321 Authors would like to thank Les Ginsberg for his significant 322 contribution in detailed reviews and suggestions. 324 9. Acknowledgements 326 As some sort of sequence number mechanism to thwart protocol replays 327 is a old mechanism, authors of this document do not make any claims 328 on the originality of the overall protection idea described. Authors 329 are thankful for the review and the valuable feedback provided by 330 Acee Lindem and Joel Halpern. 332 10. Appendix A 334 IS-IS nodes implementing this specification SHOULD use available 335 mechanisms to preserve the 64-bit Extended Session Sequence Number's 336 strictly increasing property, whenever it is changed for the deployed 337 life of the IS-IS node (including cold restarts). 339 This Appendix provides only guidelines for achieving the same and 340 implementations can resort to any similar method as far as strictly 341 increasing property of the 64-bit ESSN in ESN TLV is maintained. 343 10.1. Appendix A.1 345 One mechanism for accomplishing this is by encoding 64-bit ESSN as 346 system time represented in 64-bit unsigned integer value. This MAY 347 be similar to the system timestamp encoding for NTP long format as 348 defined in Appendix A.4 of [RFC5905]. New current time MAY be used 349 when the IS-IS node loses its sequence number state including in 350 Packet Sequence Number wrap scenarios. 352 Implementations MUST make sure while encoding the 64-bit ESN value 353 with current system time, it should not default to any previous value 354 or some default node time of the system; especially after cold 355 restarts or any other similar events. In general system time must be 356 preserved across cold restarts in order for this mechanism to be 357 feasible. One example of such implementation is to use a battery 358 backed real-time clock (RTC). 360 10.2. Appendix A.2 362 One other mechanism for accomplishing this would be similar to the 363 one as specified in [I-D.ietf-ospf-security-extension-manual-keying], 364 to use the 64-bit ESSN as a wrap/boot count stored in non-volatile 365 storage. This value is incremented anytime the IS-IS node loses its 366 sequence number state including in Packet Sequence Number wrap 367 scenarios. 369 The drawback of this approach per Section 6 of [I-D.ietf-ospf- 370 security-extension-manual-keying], if used is applicable here. The 371 only drawback is, it requires the IS-IS implementation to be able to 372 save its boot count in non-volatile storage. If the non-volatile 373 storage is ever repaired or upgraded such that the contents are lost, 374 keys MUST be changed to prevent replay attacks. 376 11. Appendix B 378 11.1. Operational/Implementation consideration 380 Since the ESN is maintained per interface, per level and per PDU 381 type, this scheme can be useful for monitoring the health of the IS- 382 IS adjacency. A Packet Sequence Number skip on IIH can be recorded 383 by the neighbors which can be used later to correlate with adjacency 384 state changes over the interface. For instance in a multi-access 385 media, all the neighbors have the skips from the same IIH sender or 386 only one neighbor has the Packet Sequence Number skips can indicate 387 completely different issues on the network. Effective usage of the 388 TLV defined in this document for operational issues MAY also need 389 more system information before making concrete conclusions and 390 defining all that information is beyond the scope of this document. 392 12. References 394 12.1. Normative References 396 [ISO10589] 397 International Organization for Standardization, 398 "Intermediate system to intermediate system intra-domain- 399 routing routine information exchange protocol for use in 400 conjunction with the protocol for providing the 401 connectionless-mode Network Service (ISO 8473)", ISO/ 402 IEC 10589:2002, Second Edition, Nov. 2002. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 408 Time Protocol Version 4: Protocol and Algorithms 409 Specification", RFC 5905, June 2010. 411 12.2. Informative References 413 [I-D.hartman-karp-mrkmp] 414 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 415 Key Management Protocol (MaRK)", draft-hartman-karp- 416 mrkmp-05 (work in progress), September 2012. 418 [I-D.ietf-karp-isis-analysis] 419 Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security 420 analysis", draft-ietf-karp-isis-analysis-03 (work in 421 progress), September 2014. 423 [I-D.ietf-ospf-security-extension-manual-keying] 424 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 425 "Security Extension for OSPFv2 when using Manual Key 426 Management", draft-ietf-ospf-security-extension-manual- 427 keying-11 (work in progress), November 2014. 429 [I-D.weis-gdoi-mac-tek] 430 Weis, B. and S. Rowles, "GDOI Generic Message 431 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 432 (work in progress), September 2011. 434 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 435 Authentication", RFC 5304, October 2008. 437 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 438 and M. Fanto, "IS-IS Generic Cryptographic 439 Authentication", RFC 5310, February 2009. 441 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 442 Routing Protocols (KARP) Design Guidelines", RFC 6518, 443 February 2012. 445 Authors' Addresses 447 Uma Chunduri 448 Ericsson Inc. 449 300 Holger Way, 450 San Jose, California 95134 451 USA 453 Phone: 408 750-5678 454 Email: uma.chunduri@ericsson.com 456 Wenhu Lu 457 Ericsson Inc. 458 300 Holger Way, 459 San Jose, California 95134 460 USA 462 Email: wenhu.lu@ericsson.com 463 Albert Tian 464 Ericsson Inc. 465 300 Holger Way, 466 San Jose, California 95134 467 USA 469 Phone: 408 750-5210 470 Email: albert.tian@ericsson.com 472 Naiming Shen 473 Cisco Systems, Inc. 474 225 West Tasman Drive, 475 San Jose, California 95134 476 USA 478 Email: naiming@cisco.com