idnits 2.17.1 draft-ietf-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 date (January 26, 2016) is 3005 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-01 Summary: 1 error (**), 0 flaws (~~), 2 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: July 29, 2016 Cisco Systems 6 B. Decraene 7 Orange 8 T. Przygienda 9 Ericsson 10 H. Gredler 11 Private Contributer 12 January 26, 2016 14 IS-IS Minimum Remaining Lifetime 15 draft-ietf-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 July 29, 2016. 48 Copyright Notice 50 Copyright (c) 2016 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 Table of Contents 65 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 68 3.1. Inconsistent Values for MaxAge . . . . . . . . . . . . . 5 69 3.2. Reporting Corrupted Lifetime . . . . . . . . . . . . . . 5 70 3.3. Impact of Delayed LSP Purging . . . . . . . . . . . . . . 6 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 7.2. Informational References . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Problem Statement 81 Each Link State PDU (LSP) includes a Remaining Lifetime field. This 82 field is set by the originator based on local configuration and then 83 decremented by all systems once the entry is stored in their Link 84 State PDU Database (LSPDB) consistent with the passing of time. This 85 allows all Intermediate Systems (ISs) to age out the LSP at 86 approximately the same time. 88 Each LSP also has a checksum field to allow receiving systems to 89 detect errors which may have occurred during transmission. As the 90 Remaining Lifetime field changes as it is flooded and as the checksum 91 field MUST NOT be altered by receiving ISs the Remaining Lifetime is 92 deliberately excluded from the checksum calculation. In cases where 93 cryptographic authentication is included in an LSP ([RFC5304] or 94 [RFC5310]) the Remaining Lifetime field is also excluded from the 95 hash calculation. If the Remaining Lifetime field gets corrupted 96 during flooding this corruption is therefore undetectable. The 97 consequences of such corruption depend upon how the Remaining 98 Lifetime is altered. 100 In cases where the Remaining Lifetime becomes larger than the 101 originator intended the impact is benign. As the originator is 102 responsible for refreshing the LSP before it ages out a new version 103 of the LSP will be generated before the LSP ages out - so no harm is 104 done. 106 In cases where the Remaining Lifetime field becomes smaller than the 107 originator intended the LSP may age out prematurely (i.e. before the 108 originator refreshes the LSP). This has two negative consequences: 110 1. The LSP will be purged by an IS when the Remaining Lifetime 111 expires. This will cause a temporary loss of reachability to 112 destinations impacted by the content of that LSP. 114 2. Unnecessary LSP flooding will occur as a result of the premature 115 purge and subsequent regeneration/flooding of a new version of 116 the LSP by the originator 118 If the corrupted Remaining Lifetime is only modestly shorter than the 119 lifetime assigned by the originator the negative impacts are also 120 modest. If, however, the corrupted Remaining Lifetime becomes very 121 small, then the negative impacts can become significant - especially 122 in cases where the cause of the corruption is persistent so that the 123 cycle repeats itself frequently. 125 A backwards compatible solution to this problem is defined in the 126 following sections. 128 2. Solution 130 As discussed in the previous section, the problematic case is when 131 Remaining Lifetime is corrupted and becomes much smaller than it 132 should be. The goal of the solution is then to prevent premature 133 purging. 135 Under normal circumstances updates to an LSP - including purging if 136 appropriate - are the responsibility of the originator of the LSP. 137 There is a maximum time between generations of a given LSP. Once 138 this time has expired it is the responsibility of the originator to 139 refresh the LSP (i.e. issue a new version with higher sequence 140 number) even if the contents of the LSP have not changed. [ISO10589] 141 specifies that maximumLSPGenerationInterval MUST be sufficiently less 142 than the maximum lifetime of an LSP so that the new version can be 143 flooded network wide before the old version ages out on any IS. 145 There are two cases where a system other than the originator of an 146 LSP is allowed to purge an LSP: 148 1. The LSP ages out. This should only occur if the originating IS 149 is no longer reachable and therefore is unable to update the LSP 151 2. There is a Designated Intermediate System (DIS) change on a LAN. 152 The pseudo-node LSPs generated by the previous DIS are no longer 153 required and MAY be purged by the new DIS. 155 In both of these cases purging is not necessary for correct operation 156 of the protocol. It is provided as an optimization to remove stale 157 entries from the LSPDB. 159 In cases where the Remaining Lifetime in a received LSP has been 160 corrupted and is smaller than the remaining lifetime at the 161 originating node when the RemainingLifetime expires on the receiving 162 node it can appear as if the originating IS has failed to regenerate 163 the LSP (case #1 above) when in fact the LSP still has significant 164 lifetime remaining. To prevent this from having a negative impact a 165 modest change to the storage of "new" LSPs in the LSPDB is specified. 167 [ISO10589] Section 7.3.16 defines the rules to determine whether a 168 received LSP is older, the same, or newer than the copy of the same 169 LSP in the receiver's LSPDB. The key elements are: 171 o Higher sequence numbers are newer 173 o If sequence numbers are the same, an LSP with zero 174 RemainingLifetime (a purged LSP) is newer than the same LSP w non- 175 zero RemainingLifetime 177 o If both the received and local copy of the LSP have non-zero 178 RemainingLifetime they are considered the same even if the 179 RemainingLifetimes differ 181 [ISO10589] Section 7.3.15.1.e(1) defines the actions to take on 182 receipt of an LSP generated by another IS which is newer than the 183 local copy and has a non-zero RemainingLifetime. An additional 184 action is added: 186 vi. If the RemainingLifetime of the new LSP is less than MaxAge it 187 is set to MaxAge 189 This additional action insures that no matter what value of Remaining 190 Lifetime is received a system other than the originator of an LSP 191 will never purge the LSP until the LSP has existed in the database 192 for at least MaxAge. 194 It is important to note that no change is proposed for handling the 195 receipt of purged LSPs. The rules specified in [ISO10589] 196 Section 7.3.15.1b still apply i.e., an LSP received with zero 197 RemainingLifetime is still considered newer than a matching LSP with 198 non-zero RemainingLifetime. Therefore the changes proposed here will 199 not result in LSPDB inconsistency among routers in the newtork. 201 3. Deployment Considerations 203 This section discusses some possible deployment issues for this 204 protocol extension. 206 3.1. Inconsistent Values for MaxAge 208 [ISO10589] defines MaxAge (the maximum value for Remaining Lifetime 209 in an LSP) as an architectural constant of 20 minutes (1200 seconds). 210 However, in practice, implementations have supported allowing this 211 value to be configurable. The common intent of a configurable value 212 is to support longer lifetimes than the default - thus reducing the 213 periodic regeneration of LSPs in the absence of topology changes. 214 See a discussion of this point in [RFC3719]. It is therefore 215 possible for the value of MaxAge on the IS which originates an LSP to 216 be higher or lower than the value of MaxAge on the ISs which receive 217 the LSP. 219 If the value of MaxAge of the IS which originated the LSP is smaller 220 than the value of MaxAge of the receiver of an LSP, then setting the 221 RemainingLifetime of the received LSP to the local value of MaxAge 222 will insure that it is not purged prematurely. However, if the value 223 of MaxAge on the receiver is less than that of the originator then it 224 is still possible when using the extension defined in the previous 225 section to have an LSP purged prematurely. Implementors of this 226 extension MAY wish to protect against this case by making the value 227 to which RemainingLifetime is set under the conditions described in 228 the previous section configurable. If that is done the configured 229 value MUST be greater than or equal to the locally configured value 230 of MaxAge. 232 3.2. Reporting Corrupted Lifetime 234 Reporting reception of an LSP with a possible corrupt 235 RemainingLifetime field can be useful in identifying a problem in the 236 network. In order to minimize the reports of false positives the 237 following algorithm SHOULD be used in determining whether the 238 RemainingLifetime in the received LSP is possibly corrupt: 240 o The LSP has passed all acceptance tests as specified in [ISO10589] 241 Section 7.3.15.1 243 o The LSP is newer than the copy in the local LSPDB (including the 244 case of not being present in the LSPDB) 246 o RemainingLifetime in the received LSP is less than ZeroAgeLifetime 248 o The adjacency to the neighbor from which the LSP is received has 249 been up for a minimum of ZeroAgeLifetime 251 In such a case an IS SHOULD generate a CorruptRemainingLifetime 252 event. 254 Note that it is not possible to guarantee that all cases of corrupt 255 RemainingLifetime will be detected using the above algorithm. It is 256 also not possible to guarantee that all CorruptRemainingLifetime 257 events reported using the above algorithm are valid. As a diagnostic 258 aid an implementation MAY wish to retain the value of 259 RemainingLifetime received when the LSP was added to the LSPDB. 261 3.3. Impact of Delayed LSP Purging 263 The extensions defined in this document may result in retaining an 264 LSP longer than its original lifetime. In order for this to occur 265 the scheduled refresh of the LSP by the originator of the LSP must 266 fail to occur - which implies the originator is no longer reachable. 267 In such a case its neighbors will update their own LSPs reporting the 268 loss of connectivity to the originator. LSPs from a node which is 269 unreachable (failure of the two-way-connectivity check) MUST NOT be 270 used. Note this behavior applies to ALL information in the set of 271 LSPs from such a node. 273 Retention of stale LSPs therefore has no negative side effects other 274 than requiring additional memory for the LSPDB. In networks where a 275 combination of pathological behaviors (LSP corruption, frequent 276 resetting of nodes in the network) is seen this could lead to a large 277 number of stale LSPs being retained - but such networks are already 278 compromised. 280 4. IANA Considerations 282 None. 284 5. Security Considerations 286 The ability to introduce corrupt LSPs is not altered by the rules 287 defined in this document. Use of authentication as defined in 288 [RFC5304] and [RFC5310] prevents such LSPs from being intentionally 289 introduced. A "man-in-the-middle" attack which modifies an existing 290 LSP by changing the Remaining Lifetime to a small value can cause 291 premature purges even in the presence of cryptographic 292 authentication. The mechanisms defined in this document prevent such 293 an attack from being effective. 295 6. Acknowledgements 297 The problem statement in [LIFE-PROB] motivated this work. 299 7. References 301 7.1. Normative References 303 [ISO10589] 304 International Organization for Standardization, 305 "Intermediate system to Intermediate system intra-domain 306 routeing information exchange protocol for use in 307 conjunction with the protocol for providing the 308 connectionless-mode Network Service (ISO 8473)", ISO/ 309 IEC 10589:2002, Second Edition, Nov 2002. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 317 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 318 2008, . 320 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 321 and M. Fanto, "IS-IS Generic Cryptographic 322 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 323 2009, . 325 7.2. Informational References 327 [LIFE-PROB] 328 "IS-IS LSP lifetime corruption - Problem Statement, draft- 329 decraene-isis-lsp-lifetime-problem-statement-01(work in 330 progress)", January 2016. 332 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 333 Networks using Intermediate System to Intermediate System 334 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 335 . 337 Authors' Addresses 339 Les Ginsberg 340 Cisco Systems 341 510 McCarthy Blvd. 342 Milpitas, CA 95035 343 USA 345 Email: ginsberg@cisco.com 347 Paul Wells 348 Cisco Systems 349 170 W Tasman Dr 350 San Jose, Ca 95035 351 USA 353 Email: pauwells@cisco.com 355 Stefano Previdi 356 Cisco Systems 357 Via Del Serafico 200 358 Rome 0144 359 Italy 361 Email: sprevidi@cisco.com 363 Bruno Decraene 364 Orange 365 38 rue du General Leclerc 366 Issy Moulineaux cedex 9 92794 367 France 369 Email: bruno.decraene@orange.com 371 Tony Przygienda 372 Ericsson 373 300 Holger Way 374 San Jose, Ca 95134 375 USA 377 Email: antoni.przygienda@ericsson.com 378 Hannes Gredler 379 Private Contributer 381 Email: hannes@gredler.at