idnits 2.17.1 draft-ginsberg-isis-remaining-lifetime-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 31, 2015) is 3185 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-02) exists of draft-decraene-isis-lsp-lifetime-problem-statement-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft P. Wells 4 Intended status: Standards Track S. Previdi 5 Expires: February 1, 2016 Cisco Systems 6 B. Decraene 7 Orange 8 T. Przygienda 9 Ericsson 10 H. Gredler 11 Juniper Networks, Inc 12 July 31, 2015 14 IS-IS Minimum Remaining Lifetime 15 draft-ginsberg-isis-remaining-lifetime-00.txt 17 Abstract 19 Corruption of the Remainining Lifetime Field in a Link State PDU can 20 go undetected. In certain scenarios this may cause or exacerbate 21 flooding storms. It is also a possible denial of service attack 22 vector. This document defines a backwards compatible solution to 23 this problem. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 1, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 78 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 80 3.1. Inconsistent Values for MaxAge . . . . . . . . . . . . . 5 81 3.2. Reporting Corrupted Lifetime . . . . . . . . . . . . . . 6 82 3.3. Impact of Delayed LSP Purging . . . . . . . . . . . . . . 6 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 88 7.2. Informational References . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 91 1. Problem Statement 93 Each Link State PDU (LSP) includes a Remaining Lifetime field. This 94 field is set by the originator based on local configuration and then 95 decremented by all systems once the entry is stored in their Link 96 State PDU Database (LSPDB) consistent with the passing of time. This 97 allows all Intermediate Systems (ISs) to age out the LSP at 98 approximately the same time. 100 Each LSP also has a checksum field to allow receiving systems to 101 detect errors which may have occurred during transmission. As the 102 Remaining Lifetime field changes as it is flooded and as the checksum 103 field MUST NOT be altered by receiving ISs the Remaining Lifetime is 104 deliberately excluded from the checksum calculation. In cases where 105 cryptographic authentication is included in an LSP ([RFC5304] or 106 [RFC5310]) the Remaining Lifetime field is also excluded from the 107 hash calculation. If the Remaining Lifetime field gets corrupted 108 during flooding this corruption is therefore undetectable. The 109 consequences of such corruption depend upon how the Remaining 110 Lifetime is altered. 112 In cases where the Remaining Lifetime becomes larger than the 113 originator intended the impact is benign. As the originator is 114 responsible for refreshing the LSP before it ages out a new version 115 of the LSP will be generated before the LSP ages out - so no harm is 116 done. 118 In cases where the Remaining Lifetime field becomes smaller than the 119 originator intended the LSP may age out prematurely (i.e. before the 120 originator refreshes the LSP). This has two negative consequences: 122 1. The LSP will be purged by an IS when the Remaining Lifetime 123 expires. This will cause a temporary loss of reachability to 124 destinations impacted by the content of that LSP. 126 2. Unnecessary LSP flooding will occur as a result of the premature 127 purge and subsequent regeneration/flooding of a new version of 128 the LSP by the originator 130 If the corrupted Remaining Lifetime is only modestly shorter than the 131 lifetime assigned by the originator the negative impacts are also 132 modest. If, however, the corrupted Remaining Lifetime becomes very 133 small, then the negative impacts can become significant - especially 134 in cases where the cause of the corruption is persistent so that the 135 cycle repeats itself frequently. 137 A backwards compatible solution to this problem is defined in the 138 following sections. 140 2. Solution 142 As discussed in the previous section, the problematic case is when 143 Remaining Lifetime is corrupted and becomes much smaller than it 144 should be. The goal of the solution is then to prevent premature 145 purging. 147 Under normal circumstances updates to an LSP - including purging if 148 appropriate - are the responsibility of the originator of the LSP. 149 There is a maximum time between generations of a given LSP. Once 150 this time has expired it is the responsibility of the originator to 151 refresh the LSP (i.e. issue a new version with higher sequence 152 number) even if the contents of the LSP have not changed. [ISO10589] 153 specifies that maximumLSPGenerationInterval MUST be sufficiently less 154 than the maximum lifetime of an LSP so that the new version can be 155 flooded network wide before the old version ages out on any IS. 157 There are two cases where a system other than the originator of an 158 LSP is allowed to purge an LSP: 160 1. The LSP ages out. This should only occur if the originating IS 161 is no longer reachable and therefore is unable to update the LSP 163 2. There is a Designated Intermediate System (DIS) change on a LAN. 164 The pseudo-node LSPs generated by the previous DIS are no longer 165 required and MAY be purged by the new DIS. 167 In both of these cases purging is not necessary for correct operation 168 of the protocol. It is provided as an optimization to remove stale 169 entries from the LSPDB. 171 In cases where the Remaining Lifetime in a received LSP has been 172 corrupted and is smaller than the remaining lifetime at the 173 originating node when the RemainingLifetime expires on the receiving 174 node it can appear as if the originating IS has failed to regenerate 175 the LSP (case #1 above) when in fact the LSP still has significant 176 lifetime remaining. To prevent this from having a negative impact a 177 modest change to the storage of "new" LSPs in the LSPDB is specified. 179 [ISO10589] Section 7.3.16 defines the rules to determine whether a 180 received LSP is older, the same, or newer than the copy of the same 181 LSP in the receiver's LSPDB. The key elements are: 183 o Higher sequence numbers are newer 185 o If sequence numbers are the same, an LSP with zero 186 RemainingLifetime (a purged LSP) is newer than the same LSP w non- 187 zero RemainingLifetime 189 o If both the received and local copy of the LSP have non-zero 190 RemainingLifetime they are considered the same even if the 191 RemainingLifetimes differ 193 [ISO10589] Section 7.3.15.1.e(1) defines the actions to take on 194 receipt of an LSP generated by another IS which is newer than the 195 local copy and has a non-zero RemainingLifetime. An additional 196 action is added: 198 vi. If the RemainingLifetime of the new LSP is less than MaxAge it 199 is set to MaxAge 201 This additional action insures that no matter what value of Remaining 202 Lifetime is received a system other than the originator of an LSP 203 will never purge the LSP until the LSP has existed in the database 204 for at least MaxAge. 206 It is important to note that no change is proposed for handling the 207 receipt of purged LSPs. The rules specified in [ISO10589] 208 Section 7.3.15.1b still apply i.e., an LSP received with zero 209 RemainingLifetime is still considered newer than a matching LSP with 210 non-zero RemainingLifetime. Therefore the changes proposed here will 211 not result in LSPDB inconsistency among routers in the newtork. 213 3. Deployment Considerations 215 This section discusses some possible deployment issues for this 216 protocol extension. 218 3.1. Inconsistent Values for MaxAge 220 [ISO10589] defines MaxAge (the maximum value for Remaining Lifetime 221 in an LSP) as an architectural constant of 20 minutes (1200 seconds). 222 However, in practice, implementations have supported allowing this 223 value to be configurable. The common intent of a configurable value 224 is to support longer lifetimes than the default - thus reducing the 225 periodic regeneration of LSPs in the absence of topology changes. 226 See a discussion of this point in [RFC3719]. It is therefore 227 possible for the value of MaxAge on the IS which originates an LSP to 228 be higher or lower than the value of MaxAge on the ISs which receive 229 the LSP. 231 If the value of MaxAge of the IS which originated the LSP is smaller 232 than the value of MaxAge of the receiver of an LSP, then setting the 233 RemainingLifetime of the received LSP to the local value of MaxAge 234 will insure that it is not purged prematurely. However, if the value 235 of MaxAge on the receiver is less than that of the originator then it 236 is still possible when using the extension defined in the previous 237 section to have an LSP purged prematurely. Implementors of this 238 extension MAY wish to protect against this case by making the value 239 to which RemainingLifetime is set under the conditions described in 240 the previous section configurable. If that is done the configured 241 value MUST be greater than or equal to the locally configured value 242 of MaxAge. 244 3.2. Reporting Corrupted Lifetime 246 It may be useful for an IS to report reception of an LSP with a 247 possible corrupt RemainingLifetime field. In order to minimize the 248 reports of false positives the following algorithm SHOULD be used in 249 determining whether the RemainingLifetime in the received LSP is 250 possibly corrupt: 252 o The LSP has passed all acceptance tests as specified in [ISO10589] 253 Section 7.3.15.1 255 o The LSP is newer than the copy in the local LSPDB (including the 256 case of not being present in the LSPDB) 258 o RemainingLifetime in the received LSP is less than ZeroAgeLifetime 260 o The adjacency to the neighbor from which the LSP is received has 261 been up for a minimum of ZeroAgeLifetime 263 In such a case an IS MAY generate a CorruptRemainingLifetime event. 265 Note that it is not possible to guarantee that all cases of corrupt 266 RemainingLifetime will be detected using the above algorithm. It is 267 also not possible to guarantee that all CorruptRemainingLifetime 268 events reported using the above algorithm are valid. As a diagnostic 269 aid an implementation MAY wish to retain the value of 270 RemainingLifetime received when the LSP was added to the LSPDB. 272 3.3. Impact of Delayed LSP Purging 274 The extensions defined in this document may result in retaining an 275 LSP longer than its original lifetime. In order for this to occur 276 the scheduled refresh of the LSP by the originator of the LSP must 277 fail to occur - which implies the originator is no longer reachable. 278 In such a case its neighbors will update their own LSPs reporting the 279 loss of connectivity to the originator. LSPs from a node which is 280 unreachable (failure of the two-way-connectivity check) MUST NOT be 281 used. Note this behavior applies to ALL information in the set of 282 LSPs from such a node. 284 Retention of stale LSPs therefore has no negative side effects other 285 than requiring additional memory for the LSPDB. In networks where a 286 combination of pathological behaviors (LSP corruption, frequent 287 resetting of nodes in the network) is seen this could lead to a large 288 number of stale LSPs being retained - but such networks are already 289 compromised. 291 4. IANA Considerations 293 None. 295 5. Security Considerations 297 The ability to introduce corrupt LSPs is not altered by the rules 298 defined in this document. Use of authentication as defined in 299 [RFC5304] and [RFC5310] prevents such LSPs from being intentionally 300 introduced. A "man-in-the-middle" attack which modifies an existing 301 LSP by changing the Remaining Lifetime to a small value can cause 302 premature purges even in the presence of cryptographic 303 authentication. The mechanisms defined in this document prevent such 304 an attack from being effective. 306 6. Acknowledgements 308 The problem statement in [LIFE-PROB] motivated this work. 310 7. References 312 7.1. Normative References 314 [ISO10589] 315 International Organization for Standardization, 316 "Intermediate system to Intermediate system intra-domain 317 routeing information exchange protocol for use in 318 conjunction with the protocol for providing the 319 connectionless-mode Network Service (ISO 8473)", ISO/ 320 IEC 10589:2002, Second Edition, Nov 2002. 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 328 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 329 2008, . 331 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 332 and M. Fanto, "IS-IS Generic Cryptographic 333 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 334 2009, . 336 7.2. Informational References 338 [LIFE-PROB] 339 "IS-IS LSP lifetime corruption - Problem Statement, draft- 340 decraene-isis-lsp-lifetime-problem-statement-00(work in 341 progress)", July 2015. 343 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 344 Networks using Intermediate System to Intermediate System 345 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 346 . 348 Authors' Addresses 350 Les Ginsberg 351 Cisco Systems 352 510 McCarthy Blvd. 353 Milpitas, CA 95035 354 USA 356 Email: ginsberg@cisco.com 358 Paul Wells 359 Cisco Systems 360 170 W Tasman Dr 361 San Jose, Ca 95035 362 USA 364 Email: pauwells@cisco.com 366 Stefano Previdi 367 Cisco Systems 368 Via Del Serafico 200 369 Rome 0144 370 Italy 372 Email: sprevidi@cisco.com 373 Bruno Decraene 374 Orange 375 38 rue du General Leclerc 376 Issy Moulineaux cedex 9 92794 377 France 379 Email: bruno.decraene@orange.com 381 Tony Przygienda 382 Ericsson 383 300 Holger Way 384 San Jose, Ca 95134 385 USA 387 Email: antoni.przygienda@ericsson.com 389 Hannes Gredler 390 Juniper Networks, Inc 391 1194 N. Matilda Ave 392 Sunnyvale, Ca 94089 393 USA 395 Email: hannes@juniper.net