idnits 2.17.1 draft-ietf-isis-remaining-lifetime-04.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 (August 17, 2016) is 2802 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' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Cisco Systems 5 Expires: February 18, 2017 B. Decraene 6 Orange 7 T. Przygienda 8 Juniper 9 H. Gredler 10 Private Contributer 11 August 17, 2016 13 IS-IS Minimum Remaining Lifetime 14 draft-ietf-isis-remaining-lifetime-04.txt 16 Abstract 18 Corruption of the Remainining Lifetime Field in a Link State PDU can 19 go undetected. In certain scenarios this may cause or exacerbate 20 flooding storms. It is also a possible denial of service attack 21 vector. This document defines a backwards compatible solution to 22 this problem. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 18, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 67 3.1. Inconsistent Values for MaxAge . . . . . . . . . . . . . 5 68 3.2. Reporting Corrupted Lifetime . . . . . . . . . . . . . . 5 69 3.3. Impact of Delayed LSP Purging . . . . . . . . . . . . . . 6 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 8.2. Informational References . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Problem Statement 81 [ISO10589] defines the format of a Link State PDU (LSP) which 82 includes a Remaining Lifetime field. This field is set by the 83 originator based on local configuration and then decremented by all 84 systems once the entry is stored in their Link State PDU Database 85 (LSPDB) consistent with the passing of time. This allows all 86 Intermediate Systems (ISs) to age out the LSP at approximately the 87 same time. 89 Each LSP also has a checksum field to allow receiving systems to 90 detect errors which may have occurred during transmission. [ISO 91 10589] mandates that the checksum is calculated by the originator of 92 the LSP and cannot be modified by other routers. Therefore the 93 Remaining Lifetime is deliberately excluded from the checksum 94 calculation. In cases where cryptographic authentication is included 95 in an LSP ([RFC5304] or [RFC5310]) the Remaining Lifetime field is 96 also excluded from the hash calculation. If the Remaining Lifetime 97 field gets corrupted during flooding this corruption is therefore 98 undetectable. The consequences of such corruption depend upon how 99 the Remaining Lifetime is altered. 101 In cases where the Remaining Lifetime becomes larger than the 102 originator intended the impact is benign. As the originator is 103 responsible for refreshing the LSP before it ages out a new version 104 of the LSP will be generated before the LSP ages out - so no harm is 105 done. 107 In cases where the Remaining Lifetime field becomes smaller than the 108 originator intended the LSP may age out prematurely (i.e. before the 109 originator refreshes the LSP). This has two negative consequences: 111 1. The LSP will be purged by an IS when the Remaining Lifetime 112 expires. This will cause a temporary loss of reachability to 113 destinations impacted by the content of that LSP. 115 2. Unnecessary LSP flooding will occur as a result of the premature 116 purge and subsequent regeneration/flooding of a new version of 117 the LSP by the originator 119 If the corrupted Remaining Lifetime is only modestly shorter than the 120 lifetime assigned by the originator the negative impacts are also 121 modest. If, however, the corrupted Remaining Lifetime becomes very 122 small, then the negative impacts can become significant - especially 123 in cases where the cause of the corruption is persistent so that the 124 cycle repeats itself frequently. 126 A backwards compatible solution to this problem is defined in the 127 following sections. 129 2. Solution 131 As discussed in the previous section, the problematic case is when 132 Remaining Lifetime is corrupted and becomes much smaller than it 133 should be. The goal of the solution is then to prevent premature 134 purging. 136 Under normal circumstances updates to an LSP - including purging if 137 appropriate - are the responsibility of the originator of the LSP. 138 There is a maximum time between generations of a given LSP. Once 139 this time has expired it is the responsibility of the originator to 140 refresh the LSP (i.e. issue a new version with higher sequence 141 number) even if the contents of the LSP have not changed. [ISO10589] 142 defines maximumLSPGenerationInterval to be sufficiently less than the 143 maximum lifetime of an LSP so that the new version can be flooded 144 network wide before the old version ages out on any IS. 146 [ISO10589] defines two cases where a system other than the originator 147 of an LSP is allowed to purge an LSP: 149 1. The LSP ages out. This should only occur if the originating IS 150 is no longer reachable and therefore is unable to update the LSP 152 2. There is a Designated Intermediate System (DIS) change on a LAN. 153 The pseudo-node LSPs generated by the previous DIS are no longer 154 required and may be purged by the new DIS. 156 In both of these cases purging is not necessary for correct operation 157 of the protocol. It is provided as an optimization to remove stale 158 entries from the LSPDB. 160 In cases where the Remaining Lifetime in a received LSP has been 161 corrupted and is smaller than the Remaining Lifetime at the 162 originating node when the Remaining Lifetime expires on the receiving 163 node it can appear as if the originating IS has failed to regenerate 164 the LSP before it ages out (case #1 above). To prevent this from 165 having a negative impact a modest change to the storage of "new" LSPs 166 in the LSPDB is specified. 168 [ISO10589] Section 7.3.16 defines the rules to determine whether a 169 received LSP is older, the same, or newer than the copy of the same 170 LSP in the receiver's LSPDB. The key elements are: 172 o Higher sequence numbers are newer 174 o If sequence numbers are the same, an LSP with zero Remaining 175 Lifetime (a purged LSP) is newer than the same LSP w non-zero 176 Remaining Lifetime 178 o If both the received and local copy of the LSP have non-zero 179 Remaining Lifetime they are considered the same even if the 180 Remaining Lifetimes differ 182 [ISO10589] Section 7.3.15.1.e(1) defines the actions to take on 183 receipt of an LSP generated by another IS which is newer than the 184 local copy and has a non-zero Remaining Lifetime. An additional 185 action is defined by this document: 187 vi. If the Remaining Lifetime of the new LSP is less than MaxAge it 188 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 Remaining Lifetime is still considered newer than a matching LSP with 198 non-zero Remaining Lifetime. Therefore the changes proposed here 199 will 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 Remaining Lifetime 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 Remaining Lifetime 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 Remaining 235 Lifetime field can be useful in identifying a problem in the network. 236 In order to minimize the reports of false positives the following 237 algorithm SHOULD be used in determining whether the Remaining 238 Lifetime 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 Remaining Lifetime in the received LSP is less than 247 ZeroAgeLifetime 249 o The adjacency to the neighbor from which the LSP is received has 250 been up for a minimum of ZeroAgeLifetime 252 In such a case an IS SHOULD generate a CorruptRemainingLifetime 253 event. 255 Note that it is not possible to guarantee that all cases of corrupt 256 Remaining Lifetime will be detected using the above algorithm. It is 257 also not possible to guarantee that all CorruptRemainingLifetime 258 events reported using the above algorithm are valid. As a diagnostic 259 aid an implementation MAY wish to retain the value of Remaining 260 Lifetime received when the LSP was added to the LSPDB. 262 3.3. Impact of Delayed LSP Purging 264 The extensions defined in this document may result in retaining an 265 LSP longer than its original lifetime. In order for this to occur 266 the scheduled refresh of the LSP by the originator of the LSP must 267 fail to occur - which implies the originator is no longer reachable. 268 In such a case its neighbors will update their own LSPs reporting the 269 loss of connectivity to the originator. [ISO10589] specifies that 270 LSPs from a node which is unreachable (failure of the two-way- 271 connectivity check) will not be used. Note this behavior applies to 272 ALL information in the set of LSPs from such a node. 274 Retention of stale LSPs therefore has no negative side effects other 275 than requiring additional memory for the LSPDB. In networks where a 276 combination of pathological behaviors (LSP corruption, frequent 277 resetting of nodes in the network) is seen this could lead to a large 278 number of stale LSPs being retained - but such networks are already 279 compromised. 281 4. IANA Considerations 283 None. 285 5. Security Considerations 287 The ability to introduce corrupt LSPs is not altered by the rules 288 defined in this document. Use of authentication as defined in 289 [RFC5304] and [RFC5310] prevents such LSPs from being intentionally 290 introduced. A "man-in-the-middle" attack which modifies an existing 291 LSP by changing the Remaining Lifetime to a small value can cause 292 premature purges even in the presence of cryptographic 293 authentication. The mechanisms defined in this document prevent such 294 an attack from being effective. 296 6. Acknowledgements 298 The problem statement in [LIFE-PROB] motivated this work. 300 7. Contributors 302 The following people gave a substantial conrtibution to the content 303 of this document and should be considered as co-authors: 305 Stefano Previdi 306 Cisco Systems 308 Email: sprevidi@cisco.com 310 8. References 312 8.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 8.2. Informational References 338 [LIFE-PROB] 339 "IS-IS LSP lifetime corruption - Problem Statement, draft- 340 decraene-isis-lsp-lifetime-problem-statement-02(work in 341 progress)", July 2016. 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 Bruno Decraene 367 Orange 368 38 rue du General Leclerc 369 Issy Moulineaux cedex 9 92794 370 France 372 Email: bruno.decraene@orange.com 373 Tony Przygienda 374 Juniper 375 1137 Innovation Way 376 Sunnyvale, Ca 94089 377 USA 379 Email: prz@juniper.net 381 Hannes Gredler 382 Private Contributer 384 Email: hannes@gredler.at