idnits 2.17.1 draft-chunduri-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 (March 12, 2012) is 4428 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 429, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-gdoi-mac-tek' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 460, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-03 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-00 == Outdated reference: A later version (-03) exists of draft-weis-gdoi-mac-tek-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: September 13, 2012 Ericsson Inc. 6 N. Shen 7 Cisco Systems, Inc. 8 March 12, 2012 10 IS-IS Extended Sequence number TLV 11 draft-chunduri-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 September 13, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4 57 2.1. Replay attacks . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Impact of Replays . . . . . . . . . . . . . . . . . . . . 5 59 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . . 5 60 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 7 61 4. Packet Encoding . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.3.1. CSNPs . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3.2. PSNPs . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Operational/Implementation consideration . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 With the rapid development of new data center infrastructures, due to 83 its flexibility and scalability attributes, ISIS 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 This document defines Extended Sequence number TLV to protect 91 Intermediate System to Intermediate System (IS-IS) PDUs from replay 92 attacks. 94 A replayed IS-IS PDU can potentially cause many problems in the IS-IS 95 networks ranging from bouncing adjacencies to black hole or even some 96 form of Denial of Service (DoS) attacks as explained in Section 2. 97 This problem is also discussed in security consideration section, in 98 the context of cryptographic authentication work as described in 99 [RFC5304] and in [RFC5310]. 101 Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) 102 and Sequence number PDUs (SNPs) from the replay attacks. However, 103 Link State PDUs (LSPs) have sequence number in the LSP header as 104 defined in [RFC1195], with which it can effectively mitigate the 105 intra-session replay attacks. But, LSPs are still susceptible to 106 inter-session replay attacks. 108 This document defines a new Extended Sequence Number (ESN) TLV to 109 thwart these threats and can be deployed with authentication 110 mechanism as specified in [RFC5304] and in [RFC5310] for a more 111 secure network. 113 Replay attacks can be effectively mitigated by deploying a group key 114 management protocol (similar to as defined in [I-D.weis-gdoi-mac- 115 tek], using GDOI [I-D.ietf-msec-gdoi-update]) with a frequent key 116 change policy. Currently, there is no such mechanism defined for 117 routing protocols and one of the KARP WG goals is to define such 118 mechanism eventually. Even if such a mechanism is in use, usage of 119 this TLV can be 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 144 MKM - Manual Key management Protocols 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. Though this has been described in detail in 154 KARP IS-IS gap analysis document, it is being restated below for 155 completeness. 157 2.1. Replay attacks 159 Replaying a captured protocol packet to cause damage is a common 160 threat for any protocol. Securing the packet with cryptographic 161 authentication information alone can not mitigate this threat 162 completely. 164 In intra-session replay attacks, a secured protocol packet of the 165 current session is replayed, can cause damage if there is no other 166 mechanism to confirm this is a replayed packet. 168 In inter-session replay attacks, captured packet from one of the 169 previous session can be replayed to cause the damage. IS-IS packets 170 are vulnerable to both these attacks as there is no sequence number 171 verification for IIH packets, SNP packets and limited protection for 172 LSPs. 174 2.2. Impact of Replays 176 At the time of adjacency bring up an IS sends IIH packet with empty 177 neighbor list (TLV 6) and with or with out the authentication 178 information as per provisioned authentication mechanism. If this 179 packet is replayed later on the broadcast network all ISes in the 180 broadcast network can bounce the adjacency to create a huge churn in 181 the network. 183 Today Link State PDUs (LSPs) have intra-session replay protection as 184 LSP header contains 32-bit sequence number which is verified for 185 every received packet against the local LSP database. But, if the 186 key is not changed, an adversary can cause an inter-session replay 187 attack by replaying a old LSP with higher sequence number and fewer 188 prefixes or fewer adjacencies. This forces the receiver to accept 189 and remove the routes from the routing table, which eventually causes 190 traffic disruption to those prefixes. 192 In broadcast networks a replayed Complete Sequence Number packet 193 (CSNP) can force the receiver to request Partial Sequence Number 194 packet (PSNP) in the network and similarly, a replayed PSNP can cause 195 unnecessary LSP flood in the network. 197 Please refer KARP IS-IS gap analysis document for further details. 199 3. Extended Sequence Number TLV 201 The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 202 Type, 1 octet that specifies the number of bytes in the Value field 203 and an 8 or 12 byte Value field. 205 x CODE - TBD. 207 x LENGTH - total length of the value field, which is 12 bytes for 208 IIH, SNP PDUs and 8 bytes for LSPs. 210 x Value - 64-bit Extended Session Sequence Number (ESSN), which is 211 present for all IS-IS PDUs followed 32 bit monotonically increasing 212 per Packet Sequence Number (PSN). PSN is not required for LSPs. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+ 217 | Type | 218 +-+-+-+-+-+-+-+-+ 219 | Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Extended Session Sequence Number (High Order 32 Bits) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Extended Session Sequence Number (Low Order 32 Bits) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | (optional) Packet Sequence Number (32 Bits) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 1: Extended Sequence Number (ESN) TLV 230 The Extended Sequence Number (ESN) TLV Type is TBD. Please refer to 231 IANA Considerations, in Section 5 for more details. Length indicates 232 the length of the value field; which is 12 bytes for IIH and SNP PDUs 233 and 8 bytes for LSPs. 235 In order to provide protection against both inter-session and intra- 236 session replay attacks, the IS-IS Extended Session Sequence Number 237 (ESSN) is defined a 64-bits value; the value MUST contain ever 238 increasing number in all IS-IS PDUs including LSPs whenever it is 239 changed due any situation as specified in Section 3.1. 241 The 32-bit Packet Sequence Number (PSN) MUST be set and increase 242 monotonically for IIH or SNP PDUs sent by IS-IS router. Upon 243 reception, the Packet Sequence number MUST be greater than the last 244 sequence number in the IIH or SNP PDUs accepted from the sending 245 IS-IS router. Otherwise, the IIH or SNP PDU is considered as 246 replayed PDU and dropped. 248 As LSPs contain 32-bit sequence number field already in the LSP 249 header, Packet Sequence Number in the ESN TLV MUST be omitted by 250 setting the length field to 8 bytes and implementations continue to 251 refer the header sequence number for all encoding and validation 252 purposes. 254 The ESN TLV defined here is optional. The ESN TLV MAY present in any 255 IS-IS PDU. If present and authentication is in use this TLV MUST be 256 included as part of the authentication data to calculate the digest. 257 A sender MUST only transmit a single ESN TLV in a IS-IS PDU. 259 3.1. Sequence Number Wrap 261 If the 32-bit Packet Sequence Number in ESN TLV and for LSPs the 32- 262 bit header sequence number wraps; or session is refreshed; or even 263 for the cold restarts the 64-bit ESSN value MUST be set higher than 264 the previous value. IS-IS implementations MAY use guidelines 265 provided in Section 8 for accomplishing this. 267 4. Packet Encoding 269 The ESN TLV defined in this document is optional and the encoding and 270 decoding of this TLV in each IS-IS PDU is as detailed below. 272 4.1. IIHs 274 The IIH ESN TLV information is maintained per IS-IS interface and per 275 level. For a broadcast interface, it can have two sets of ESN TLV 276 information, if the circuit belongs to both level-1 and level-2. For 277 point-to-point (P2P) interface, only one ESN TLV information is 278 needed. This TLV information can be maintained as part of the 279 adjacency state. 281 While transmitting, the 64-bit ESSN MUST always be started with a non 282 zero number and MAY use the guidelines as specified in Section 8 to 283 encode this 64-bit value. The 32-bit PSN starts from 1 and increases 284 monotonically for every subsequent packet. 286 While receiving, the 64-bit ESSN MUST always be either same or higher 287 than the stored value in the adjacency state. Similarly, the 32-bit 288 PSN MUST be higher than the stored value in the adjacency state. If 289 the PDU is accepted then the adjacency state should be updated with 290 the last received IIH PDU's ESN TLV information. 292 For an adjacency refresh or the 32-bit PSN wrap the associated higher 293 order 64-bit ESSN MUST always be higher than the previous value and 294 the lower order 32-bit packet sequence number starts all over again. 296 4.2. LSPs 298 For LSPs, while originating, the 64-bit ESSN MUST always be started 299 with a non zero number and MAY use the guidelines as specified in 300 Section 8 for encoding this value. 302 While receiving, the 64-bit Extended Sequence Number MUST always be 303 either same or higher than the stored value in the LSP database. 304 This document does not specify any changes for the existing LSP 305 header 32-bit sequence number validation mechanism. 307 4.3. SNPs 309 4.3.1. CSNPs 311 In broadcast networks, only Designated Intermediate System (DIS) CSNP 312 ESN TLV information is maintained per adjacency (per level) similar 313 to IIH ESN TLV information. The procedure for encoding, verification 314 and sequence number wrap scenarios are similar as explained in 315 Section 4.1, except separate DIS ESN TLV information should be used. 316 In case of DIS change all adjacencies in the broadcast network MUST 317 reflect new DIS's CSNP ESN TLV information in the adjacency and 318 should be used for encoding/verification. 320 In P2P networks, CSNP ESN TLV information is maintained per adjacency 321 similar to IIH ESN TLV information. The procedure for encoding, 322 verification and sequence number wrap scenarios are similar as 323 explained in Section 4.1, except separate CSNP ESN TLV information 324 should be used. 326 4.3.2. PSNPs 328 In both broadcast and P2P networks, PSNP ESN TLV information is 329 maintained per adjacency (per level) similar to IIH ESN TLV 330 information. The procedure for encoding, verification and sequence 331 number wrap scenarios are similar as explained in Section 4.1, except 332 separate PSNP ESN TLV information should be used. 334 5. IANA Considerations 336 This document requests that IANA allocate from the IS-IS TLV 337 Codepoints Registry a new TLV, referred to as the "Extended Sequence 338 Number" TLV, with the following attributes: IIH = y, LSP = y, SNP = 339 y, Purge = y. 341 6. Security Considerations 343 This document describes a mechanism to the replay attack threat as 344 discussed in the Security Considerations section of [RFC5304] and in 345 [RFC5310]. This document does not introduce any new security 346 concerns to IS-IS or any other specifications referenced in this 347 document. 349 7. Acknowledgements 351 The authors of this document do not make any claims on the 352 originality of the ideas described. Authors are thankful for the 353 review and the valuable feedback provided by Acee Lindem and Joel 354 Halpern. 356 8. Appendix A 358 IS-IS routers implementing this specification SHOULD use available 359 mechanisms to preserve the 64-bit Extended Session Sequence Number's 360 strictly increasing property, when ever it is changed for the 361 deployed life of the IS-IS router (including cold restarts). 363 This Appendix provides only guidelines for achieving the same and 364 implementations can resort to any similar method as far as strictly 365 increasing property of the 64-bit ESSN in ESN TLV is maintained. 367 8.1. Appendix A.1 369 One mechanism for accomplishing this is by encoding 64-bit ESSN as 370 system time represented in 64-bit unsigned integer value. This MAY 371 be similar to the system timestamp encoding for NTP long format as 372 defined in Appendix A.4 of [RFC5905]. New current time MAY be used 373 when the IS-IS router loses its sequence number state including in 374 Packet Sequence Number wrap scenarios. 376 Implementations MUST make sure while encoding the 64-bit ESN value 377 with current system time, it should not default to any previous value 378 or some default router time of the system; especially after cold 379 restarts or any other similar events. In general system time must be 380 preserved across cold restarts in order for this mechanism to be 381 feasible. One example of such implemetation is to use a battery 382 backed real-time clock (RTC). 384 8.2. Appendix A.2 386 One other mechanism for accomplishing this would be similar to the 387 one as specified in [I-D.ietf-ospf-security-extension-manual-keying], 388 to use the 64-bit ESSN as a wrap/boot count stored in non-volatile 389 storage. This value is incremented anytime the IS-IS router loses 390 its sequence number state including in Packet Sequence Number wrap 391 scenarios. 393 The drawback of this approach per Section 6 of [I-D.ietf-ospf- 394 security-extension-manual-keying], if used is applicable here. The 395 only drawback is, it requires the IS-IS implementation to be able to 396 save its boot count in non-volatile storage. If the non-volatile 397 storage is ever repaired or upgraded such that the contents are lost, 398 keys MUST be changed to prevent replay attacks. 400 9. Appendix B 402 9.1. Operational/Implementation consideration 404 Since the ESN is maintained per interface, per level and per packet 405 type, this scheme can be useful for monitoring the health of the ISIS 406 adjacency. A Packet Sequence Number skip on IIH can be recorded by 407 the neighbors which can be used later to correlate with adjacency 408 state changes over the interface. For instance in a multi-access 409 media, all the neighbors have the skips from the same IIH sender or 410 only one neighbor has the Packet Sequence Number skips can indicate 411 completely different issues on the network. 413 10. References 415 10.1. Normative References 417 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 418 dual environments", RFC 1195, December 1990. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 424 Time Protocol Version 4: Protocol and Algorithms 425 Specification", RFC 5905, June 2010. 427 10.2. Informative References 429 [I-D.ietf-karp-threats-reqs] 430 Lebovitz, G., Bhatia, M., and R. White, "The Threat 431 Analysis and Requirements for Cryptographic Authentication 432 of Routing Protocols' Transports", 433 draft-ietf-karp-threats-reqs-03 (work in progress), 434 June 2011. 436 [I-D.ietf-msec-gdoi-update] 437 Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 438 of Interpretation", draft-ietf-msec-gdoi-update-11 (work 439 in progress), August 2011. 441 [I-D.ietf-ospf-security-extension-manual-keying] 442 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 443 "Security Extension for OSPFv2 when using Manual Key 444 Management", 445 draft-ietf-ospf-security-extension-manual-keying-00 (work 446 in progress), May 2011. 448 [I-D.weis-gdoi-mac-tek] 449 Weis, B. and S. Rowles, "GDOI Generic Message 450 Authentication Code Policy", draft-weis-gdoi-mac-tek-02 451 (work in progress), March 2011. 453 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 454 Authentication", RFC 5304, October 2008. 456 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 457 and M. Fanto, "IS-IS Generic Cryptographic 458 Authentication", RFC 5310, February 2009. 460 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 461 Routing Protocols (KARP) Design Guidelines", RFC 6518, 462 February 2012. 464 Authors' Addresses 466 Uma Chunduri 467 Ericsson Inc. 468 300 Holger Way, 469 San Jose, California 95134 470 USA 472 Phone: 408 750-5678 473 Email: uma.chunduri@ericsson.com 475 Wenhu Lu 476 Ericsson Inc. 477 300 Holger Way, 478 San Jose, California 95134 479 USA 481 Email: wenhu.lu@ericsson.com 483 Albert Tian 484 Ericsson Inc. 485 300 Holger Way, 486 San Jose, California 95134 487 USA 489 Phone: 408 750-5210 490 Email: albert.tian@ericsson.com 491 Naiming Shen 492 Cisco Systems, Inc. 493 225 West Tasman Drive, 494 San Jose, California 95134 495 USA 497 Email: naiming@cisco.com