idnits 2.17.1 draft-decraene-isis-lsp-lifetime-problem-statement-02.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 (July 4, 2016) is 2852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft C. Schmitz 4 Intended status: Informational Orange 5 Expires: January 5, 2017 July 4, 2016 7 IS-IS LSP lifetime corruption - Problem Statement 8 draft-decraene-isis-lsp-lifetime-problem-statement-02 10 Abstract 12 The IS-IS protocol exchanges Link State Packet (LSP) to exchange 13 routing information. The lifetime of this LSP is located in the LSP 14 header and is neither protected from corruption by the Fletcher 15 checksum nor by cryptographic authentication. So the LSP lifetime 16 may be altered, either accidentally or maliciously any time. 18 The lifetime field of the LSP is an important field for the correct 19 operation of IS-IS. Corruption of this LSP lifetime may cause 20 flooding storm with severe impact in the network. 22 This draft documents the problem statement and calls for a solution. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Lifetime is not protected from corruption . . . . . . . . . . 2 60 3. Consequences of a corrupted LSP Lifetime . . . . . . . . . . 3 61 3.1. Lifetime corrupted to zero . . . . . . . . . . . . . . . 3 62 3.2. Lifetime corrupted to a non zero value . . . . . . . . . 3 63 3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Protocol extension . . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 A LSP is a Link State PDU, originated by a router and then flooded in 76 the routing domain. A LSP may advertise topological, reachability or 77 general routing information. A LSP is valid for the duration of its 78 lifetime which is set by the originator and decreased during flooding 79 and as time passes. Lifetime is encoded in the LSP header and is not 80 protected by the LSP header Fletcher checksum nor by the 81 cryptographic signature because both are computed by the originator 82 while the lifetime is modified during flooding. 84 2. Lifetime is not protected from corruption 86 The IS-IS protocol is defined in [ISO10589-Second-Edition]. IS-IS 87 exchanges Link State PDU (LSP) to advertise routing information. 88 Each LSP its lifetime advertised in the PDU header. This lifetime is 89 neither protected by the Fletcher checksum in the LSP header nor by 90 the cryptographic checksum (TLV 10) defined in [RFC5304]. Hence the 91 LSP lifetime may be corrupted but still used. 93 The lifetime field of the LSP header is an important field for the 94 correct operation of IS-IS. Corruption of the LSP lifetime may cause 95 LSP churn with severe impact in the network. 97 3. Consequences of a corrupted LSP Lifetime 99 The lifetime field of the LSP is an important field for the correct 100 operation of IS-IS. This section evaluates the impact of LSP 101 lifetime corruption on one LSP. 103 3.1. Lifetime corrupted to zero 105 In this case, a non-purge LSP gets its LSP lifetime corrupted to zero 106 between its origination and a router "R" receiving the LSP. 108 If cryptographic authentication, as defined in [RFC5304], is not 109 enabled in the network, this corrupted LSP is processed as if its 110 lifetime has expired. This will replace any non-expired version of 111 the same LSP in the LSPDB and will cause the purge to be flooded 112 network-wide. This creates a topological change in the network, 113 requiring new routes computation and installation. This purge LSP is 114 then flooded in the whole network, including to routers having a non 115 corrupted version of the LSP. Finally, the originator of the LSP 116 receive the purge LSP and advertise a new LSP with an increased 117 sequence number. If the corruption is systematic, the processes 118 cycles forever. 120 If cryptographic authentication is enabled in the network, [RFC5304] 121 and [RFC6233] restrict the TLV code that are allowed in a purge. 122 They specify that LSP with zero lifetime but having TLV not allowed 123 in purge, must be ignored. As only a few TLV are acceptable in 124 purge, this provides an effective protection as the LSP with the 125 corrupted LSP lifetime will be ignored. Note that this additional 126 check has been added because the lifetime, hence LSP purge, is not 127 authenticated. 129 3.2. Lifetime corrupted to a non zero value 131 In this case, a non-purge LSP gets its LSP lifetime corrupted to 132 value strictly greater than zero between its origination and a 133 receiving IS-IS router. 135 This corrupted LSP is accepted as a regular LSP. The problem is that 136 the originator is not aware of this change and if the lifetime has 137 been reduced as a result of this corruption, the originator will 138 likely not refresh the LSP before it expire. When the LSP expire, a 139 LSP purge will be originated and flooded in the network. This 140 creates a topological change in the network, requiring new routes 141 computation and installation. At some point, the originator of the 142 LSP receive the purge LSP and advertise a new LSP with an increased 143 sequence number. If the corruption is systematic, the processes 144 cycles forever. 146 Cryptographic authentication does not provide any additional 147 protection. 149 If the lifetime is corrupted to a small to very small value, the 150 effect is virtually equivalent to a purge. Hence, the restriction, 151 introduced by [RFC5304], to restrict the list of TLV allowed in a 152 purge LSP is not really effective. Hence, [RFC5304] does not succeed 153 in "prevent[ing] a hostile system from receiving an LSP, setting the 154 Remaining Lifetime field to [a small value], and flooding it, thereby 155 initiating a purge without knowing the authentication password". 157 3.3. Summary 159 Cryptographic authentication addresses one case, where the LSP 160 lifetime is corrupted to zero. All others cases triggers a flooding 161 storm. 163 If the corruption is systematic on a given link, all LSPs flooded 164 through that link are affected, creating flooding storm for multiple 165 LSPs with severe impact in the network. 167 4. Protocol extension 169 Given the importance of the IGP for the network and the services 170 carried in those IP/MPLS networks, and given the possibly large 171 impact of LSP lifetime corruption, this documents calls for a 172 protocol extension protecting or mitigating from the corruption of 173 LSP lifetime. 175 Preferably, the protocol extension could be deployed incrementally 176 with incremental benefit. 178 5. IANA Considerations 180 This document has no IANA action. 182 6. Security Considerations 184 This document describes a lack of integrity protection of the LSP 185 LifeTime field. This LifeTime may be altered as a result of packet 186 corruption (e.g. over transmission links, in routers' linecard or 187 switch fabric) or may be voluntarily modified by an external party 188 having access to one of theses resources used between IS-IS 189 neighbours. Such modification are not detected by IS-IS checksum 190 defined in [ISO10589-Second-Edition] nor the cryptographic 191 authentication defined in [RFC5304]. This field is important for the 192 protocol as it contains the life time of the routing information. 194 Modification of the lifetime of a single LSP transient impact the 195 network by transiently removing a node from the routing topology and 196 impacting the traffic crossing this node. This may also impact 197 traffic not crossing the link as micro-loops may happen which would 198 saturate some links. 200 Systematic modification of the lifetime of all LSPs crossing a single 201 link would have a huge impact on the network. One part of the 202 network would likely become virtually inoperative as having no 203 (stable) available routes across the network. The whole flooding 204 domain (L1 area or L2) would also be severely affected, especially 205 since IGP instabilities creates instabilities to routing and 206 signalling protocols relying on the IGP such as BGP, LDP, RSVP-TE, 207 PCE... 209 As such, this may be considered as a security vulnerability. 211 7. Acknowledgement 213 The authors wish to thank Hannes Gredler, Les Ginsberg, Paul Wells 214 and Stefano Previdi for discussions related to this topic. 216 8. References 218 8.1. Normative References 220 [ISO10589-Second-Edition] 221 International Organization for Standardization, 222 "Intermediate system to Intermediate system intra-domain 223 routeing information exchange protocol for use in 224 conjunction with the protocol for providing the 225 connectionless-mode Network Service (ISO 8473)", ISO/ 226 IEC 10589:2002, Second Edition, Nov 2002. 228 8.2. Informative References 230 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 231 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 232 2008, . 234 [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for 235 Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, 236 . 238 Authors' Addresses 240 Bruno Decraene 241 Orange 243 Email: bruno.decraene@orange.com 245 Christof Schmitz 246 Orange 248 Email: christof.schmitz@orange.com