idnits 2.17.1 draft-ietf-isis-extended-sequence-no-tlv-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 (January 25, 2014) is 3744 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) == Missing Reference: 'I-D.yeung-g-ikev2' is mentioned on line 116, but not defined == Unused Reference: 'I-D.ietf-karp-isis-analysis' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-gdoi-mac-tek' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 488, 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-00 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-05 Summary: 0 errors (**), 0 flaws (~~), 7 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 29, 2014 Ericsson Inc. 6 N. Shen 7 Cisco Systems, Inc. 8 January 25, 2014 10 IS-IS Extended Sequence number TLV 11 draft-ietf-isis-extended-sequence-no-tlv-01 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 29, 2014. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . 5 61 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 6 62 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 6 63 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2.1. CSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2.2. PSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Backward Compatibility and Deployment . . . . . . . . . . . . 7 68 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . 9 74 9.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . 9 75 10. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Operational/Implementation consideration . . . . . . . . 10 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 11.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 With the rapid development of new data center infrastructures, due to 85 its flexibility and scalability attributes, IS-IS has been adopted 86 widely in various L2 and L3 routing deployment of the data centers 87 for critical business operations. At the meantime the SDN-enabled 88 networks even though put more power to Internet applications and also 89 make network management easier, it does raise the security 90 requirement of network routing infrastructure to another 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 116 [I-D.yeung-g-ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key 117 change policy. Currently, there is no such mechanism defined for IS- 118 IS. Even if such a mechanism is defined, usage of this TLV can be 119 helpful 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 can not 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 Today Link State PDUs (LSPs) have intra-session replay protection as 171 LSP header contains 32-bit sequence number which is verified for 172 every received PDU against the local LSP database. But, if the key 173 is not changed, an adversary can cause an inter-session replay attack 174 by replaying a old LSP with higher sequence number and fewer prefixes 175 or fewer adjacencies. This forces the receiver to accept and remove 176 the routes from the routing table, which eventually causes traffic 177 disruption to those prefixes. The more common pre-conditions for 178 inter-session replay attacks with LSPs and the current in-built 179 recovery mechanism, have been discussed in details in "Replay 180 Attacks" Section of KARP IS-IS gap analysis document [I-D.ietf-karp- 181 isis-analysis]. 183 This document does not propose any solution to completely mitigate 184 the replay threat for LSPs as its perceived that network can still 185 recover from the short-lived disruption, reliably after processing a 186 reply. 188 2.3. SNPs 190 In broadcast networks a replayed Complete Sequence Number PDU (CSNP) 191 can force the receiver to request Partial Sequence Number PDU (PSNP) 192 on a given link and similarly, based on the link type a replayed CSNP 193 /PSNP can cause unnecessary LSP flood on the link. 195 3. Extended Sequence Number TLV 197 The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 198 Type, 1 octet that specifies the number of bytes in the Value field 199 and a 12 byte Value field. This TLV is defined only for IIH and SNP 200 PDUs. 202 x CODE - TBD. 204 x LENGTH - total length of the value field, which is 12 bytes and 205 applicable for IIH and SNP PDUs. 207 x Value - 64-bit Extended Session Sequence Number (ESSN), which is 208 followed by a 32 bit monotonically increasing per Packet Sequence 209 Number (PSN). 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+ 214 | Type | 215 +-+-+-+-+-+-+-+-+ 216 | Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Extended Session Sequence Number (High Order 32 Bits) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Extended Session Sequence Number (Low Order 32 Bits) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Packet Sequence Number (32 Bits) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Extended Sequence Number (ESN) TLV 227 The Extended Sequence Number (ESN) TLV Type is TBD. Please refer to 228 IANA Considerations, in Section 6 for more details. Length indicates 229 the length of the value field, which is 12 bytes. 231 The ESN TLV defined here is optional. Though this is an optional 232 TLV, this can be mandatory on a link when 'verify' mode is enabled as 233 specified in Section 5.1. The ESN TLV MAY present only in any IIH 234 and SNP PDUs. If present and authentication is in use this TLV MUST 235 be included as part of the authentication data to calculate the 236 digest. A sender MUST only transmit a single ESN TLV in a IS-IS PDU. 238 In order to provide protection against both inter-session and intra- 239 session replay attacks, the IS-IS Extended Session Sequence Number 240 (ESSN) is defined as a 64-bits value; the value MUST contain ever 241 increasing number whenever it is changed due any situation as 242 specified in Section 3.1. While transmitting, the 64-bit ESSN MUST 243 always be started with a non-zero number and MAY use the guidelines 244 as specified in Section 9 to encode this 64-bit value. While 245 receiving, the 64-bit ESSN MUST always be either same or higher than 246 the stored value corresponding to the PDU and the combined unsigned 247 96 bit value (where ESSN is the 64 MSBs) MUST be greater than the 248 previously received value. 250 The 32-bit Packet Sequence Number (PSN) MUST be set and increase 251 monotonically. Upon reception, if ESSN field is unchanged, the 252 Packet Sequence number MUST be greater than the last sequence number 253 in the corresponding IIH or SNP PDUs accepted from the sending IS-IS 254 node. Otherwise, the IIH or SNP PDU is considered as replayed PDU 255 and dropped. 257 3.1. Sequence Number Wrap 259 If the 32-bit Packet Sequence Number in ESN TLV wraps; or session is 260 refreshed; or even for the cold restarts the 64-bit ESSN value MUST 261 be set higher than the previous value. IS-IS implementations MAY use 262 guidelines provided in Section 9 for accomplishing this. 264 4. Mechanism and Packet Encoding 266 The encoding and decoding of ESN TLV in each IS-IS PDU as applicable 267 is detailed below. Also refer, when to ignore processing of the ESN 268 TLV as described in Section 5 for appropriate operation in the face 269 of legacy node(s) in the network without having this capability. 271 4.1. IIHs 273 The IIH ESN TLV information is maintained per IS-IS link and per 274 level. For a broadcast link, it can have two sets of ESN TLV 275 information, if the circuit belongs to both level-1 and level-2. For 276 a point-to-point (P2P) link, only one ESN TLV information is needed. 277 The procedure for encoding, verification and sequence number wrap 278 scenarios are explained in Section 3. If the received PDU is 279 accepted then the stored value should be updated with the last 280 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, CSNP ESN TLV information is maintained per 291 level and per link. The procedure for encoding, verification and 292 sequence number wrap scenarios are explained in Section 3 and a 293 separate CSNP ESN TLV information should be used per link. In case 294 of DIS change the new DIS is free to start using an ESN, totally 295 independent of what was used by its predecessor DIS. 297 In P2P networks, CSNP ESN TLV information is maintained per link 298 similar to IIH ESN TLV information. The procedure for encoding, 299 verification and sequence number wrap scenarios are similar as 300 explained in Section 3, and a separate CSNP ESN TLV information 301 should be used. 303 4.2.2. PSNPs 305 In both broadcast and P2P networks, PSNP ESN TLV information is 306 maintained per link similar to CSNP ESN TLV information. The 307 procedure for encoding, verification and sequence number wrap 308 scenarios are explained in Section 3 and a separate PSNP ESN TLV 309 information should be used. 311 5. Backward Compatibility and Deployment 313 The implementation and deployment of the ESN TLV can be done to 314 support backward compatibility and gradual deployment in the network 315 without requiring a flag day. This feature can also be deployed for 316 the links in a certain area of the network where the maximum security 317 mechanism is needed, or it can be deployed for the entire network. 319 The implementation SHOULD allow the configuration of ESN TLV feature 320 on each IS-IS link level. The implementation SHOULD also allow 321 operators to control the configuration of 'send' and/or 'verify' the 322 feature of IS-IS PDUs for the links and for the node. In this 323 document, the 'send' operation is to include the ESN TLV in its own 324 IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in 325 the receiving IS-IS PDUs from neighbors. 327 In the face of an adversary doing an active attack, it is possible to 328 have inconsistent data view in the network, if there is a 329 considerable delay in enabling ESN TLV 'verify' operation from first 330 node to the last node in the network. This can happen primarily 331 because, replay PDUs can potentially be accepted by the nodes where 332 'verify' operation is still not provisioned at the time of the 333 attack. To minimize such a window it is recommended that 334 provisioning of 'verify' SHOULD be done in a timely fashion by the 335 network operators. 337 5.1. IIH and SNPs 339 On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP 340 and PSNP). When the router software is upgraded to include this 341 feature, the network operators can configure the IS-IS to 'send' the 342 ESN TLV in its IIH PDUs and SNPs for those IS-IS interfaces on the 343 IS-IS area or level. When all the routers attached to the link or 344 links have been upgraded with this feature, network operators can 345 start to configure 'verify' on the IS-IS interfaces for all the 346 routers sharing the same link(s). Once 'verify' mode is set for an 347 interface all the IIH and SNP PDUs being sent and received MUST 348 contain the ESN TLV and any single PDU sent without the ESN TLV 349 becomes a potential replay candidate and MUST be dropped. This way 350 deployment can be done in per link basis in the network. The 351 operators may decide to only apply ESN TLV feature on some of the 352 links in the network, or only on their multi-access media links. 354 6. IANA Considerations 356 This document requests that IANA allocate from the IS-IS TLV 357 Codepoints Registry a new TLV, referred to as the "Extended Sequence 358 Number" TLV, with the following attributes: 360 Type Description IIH LSP SNP Purge 361 ---- --------------------- --- --- --- ----- 362 TBD ESN TLV Y N Y N 364 Figure 2: IS-IS Codepoints Registry Entry 366 7. Security Considerations 368 This document describes a mechanism to the replay attack threat as 369 discussed in the Security Considerations section of [RFC5304] and in 370 [RFC5310]. This document does not introduce any new security 371 concerns to IS-IS or any other specifications referenced in this 372 document. 374 8. Acknowledgements 376 As some sort of sequence number mechanism to thwart protocol replays 377 is a old mechanism, authors of this document do not make any claims 378 on the originality of the overall protection idea described. Authors 379 are thankful for the review and the valuable feedback provided by 380 Acee Lindem, Joel Halpern and Les Ginsberg. 382 9. Appendix A 384 IS-IS nodes implementing this specification SHOULD use available 385 mechanisms to preserve the 64-bit Extended Session Sequence Number's 386 strictly increasing property, whenever it is changed for the deployed 387 life of the IS-IS node (including cold restarts). 389 This Appendix provides only guidelines for achieving the same and 390 implementations can resort to any similar method as far as strictly 391 increasing property of the 64-bit ESSN in ESN TLV is maintained. 393 9.1. Appendix A.1 395 One mechanism for accomplishing this is by encoding 64-bit ESSN as 396 system time represented in 64-bit unsigned integer value. This MAY 397 be similar to the system timestamp encoding for NTP long format as 398 defined in Appendix A.4 of [RFC5905]. New current time MAY be used 399 when the IS-IS node loses its sequence number state including in 400 Packet Sequence Number wrap scenarios. 402 Implementations MUST make sure while encoding the 64-bit ESN value 403 with current system time, it should not default to any previous value 404 or some default node time of the system; especially after cold 405 restarts or any other similar events. In general system time must be 406 preserved across cold restarts in order for this mechanism to be 407 feasible. One example of such implementation is to use a battery 408 backed real-time clock (RTC). 410 9.2. Appendix A.2 412 One other mechanism for accomplishing this would be similar to the 413 one as specified in [I-D.ietf-ospf-security-extension-manual-keying], 414 to use the 64-bit ESSN as a wrap/boot count stored in non-volatile 415 storage. This value is incremented anytime the IS-IS node loses its 416 sequence number state including in Packet Sequence Number wrap 417 scenarios. 419 The drawback of this approach per Section 6 of [I-D.ietf-ospf- 420 security-extension-manual-keying], if used is applicable here. The 421 only drawback is, it requires the IS-IS implementation to be able to 422 save its boot count in non-volatile storage. If the non-volatile 423 storage is ever repaired or upgraded such that the contents are lost, 424 keys MUST be changed to prevent replay attacks. 426 10. Appendix B 428 10.1. Operational/Implementation consideration 430 Since the ESN is maintained per interface, per level and per PDU 431 type, this scheme can be useful for monitoring the health of the IS- 432 IS adjacency. A Packet Sequence Number skip on IIH can be recorded 433 by the neighbors which can be used later to correlate with adjacency 434 state changes over the interface. For instance in a multi-access 435 media, all the neighbors have the skips from the same IIH sender or 436 only one neighbor has the Packet Sequence Number skips can indicate 437 completely different issues on the network. 439 11. References 441 11.1. Normative References 443 [ISO10589] 444 International Organization for Standardization, 445 "Intermediate system to intermediate system intra-domain- 446 routing routine information exchange protocol for use in 447 conjunction with the protocol for providing the 448 connectionless-mode Network Service (ISO 8473)", ISO/ 449 IEC 10589:2002, Second Edition, Nov. 2002. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 455 Time Protocol Version 4: Protocol and Algorithms 456 Specification", RFC 5905, June 2010. 458 11.2. Informative References 460 [I-D.hartman-karp-mrkmp] 461 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 462 Key Management Protocol (MaRK)", draft-hartman-karp- 463 mrkmp-05 (work in progress), September 2012. 465 [I-D.ietf-karp-isis-analysis] 466 Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security 467 analysis", draft-ietf-karp-isis-analysis-00 (work in 468 progress), March 2013. 470 [I-D.ietf-ospf-security-extension-manual-keying] 471 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 472 "Security Extension for OSPFv2 when using Manual Key 473 Management", draft-ietf-ospf-security-extension-manual- 474 keying-05 (work in progress), May 2013. 476 [I-D.weis-gdoi-mac-tek] 477 Weis, B. and S. Rowles, "GDOI Generic Message 478 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 479 (work in progress), September 2011. 481 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 482 Authentication", RFC 5304, October 2008. 484 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 485 and M. Fanto, "IS-IS Generic Cryptographic 486 Authentication", RFC 5310, February 2009. 488 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 489 Routing Protocols (KARP) Design Guidelines", RFC 6518, 490 February 2012. 492 Authors' Addresses 494 Uma Chunduri 495 Ericsson Inc. 496 300 Holger Way, 497 San Jose, California 95134 498 USA 500 Phone: 408 750-5678 501 Email: uma.chunduri@ericsson.com 503 Wenhu Lu 504 Ericsson Inc. 505 300 Holger Way, 506 San Jose, California 95134 507 USA 509 Email: wenhu.lu@ericsson.com 510 Albert Tian 511 Ericsson Inc. 512 300 Holger Way, 513 San Jose, California 95134 514 USA 516 Phone: 408 750-5210 517 Email: albert.tian@ericsson.com 519 Naiming Shen 520 Cisco Systems, Inc. 521 225 West Tasman Drive, 522 San Jose, California 95134 523 USA 525 Email: naiming@cisco.com