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