[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                        B. Decraene
Internet-Draft                                                C. Schmitz
Intended status: Informational                                    Orange
Expires: January 5, 2017                                    July 4, 2016


           IS-IS LSP lifetime corruption - Problem Statement
         draft-decraene-isis-lsp-lifetime-problem-statement-02

Abstract

   The IS-IS protocol exchanges Link State Packet (LSP) to exchange
   routing information.  The lifetime of this LSP is located in the LSP
   header and is neither protected from corruption by the Fletcher
   checksum nor by cryptographic authentication.  So the LSP lifetime
   may be altered, either accidentally or maliciously any time.

   The lifetime field of the LSP is an important field for the correct
   operation of IS-IS.  Corruption of this LSP lifetime may cause
   flooding storm with severe impact in the network.

   This draft documents the problem statement and calls for a solution.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Decraene & Schmitz       Expires January 5, 2017                [Page 1]


Internet-Draft   Lifetime corruption - Problem Statement       July 2016


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Lifetime is not protected from corruption . . . . . . . . . .   2
   3.  Consequences of a corrupted LSP Lifetime  . . . . . . . . . .   3
     3.1.  Lifetime corrupted to zero  . . . . . . . . . . . . . . .   3
     3.2.  Lifetime corrupted to a non zero value  . . . . . . . . .   3
     3.3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Protocol extension  . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   A LSP is a Link State PDU, originated by a router and then flooded in
   the routing domain.  A LSP may advertise topological, reachability or
   general routing information.  A LSP is valid for the duration of its
   lifetime which is set by the originator and decreased during flooding
   and as time passes.  Lifetime is encoded in the LSP header and is not
   protected by the LSP header Fletcher checksum nor by the
   cryptographic signature because both are computed by the originator
   while the lifetime is modified during flooding.

2.  Lifetime is not protected from corruption

   The IS-IS protocol is defined in [ISO10589-Second-Edition].  IS-IS
   exchanges Link State PDU (LSP) to advertise routing information.
   Each LSP its lifetime advertised in the PDU header.  This lifetime is
   neither protected by the Fletcher checksum in the LSP header nor by
   the cryptographic checksum (TLV 10) defined in [RFC5304].  Hence the
   LSP lifetime may be corrupted but still used.

   The lifetime field of the LSP header is an important field for the
   correct operation of IS-IS.  Corruption of the LSP lifetime may cause
   LSP churn with severe impact in the network.




Decraene & Schmitz       Expires January 5, 2017                [Page 2]


Internet-Draft   Lifetime corruption - Problem Statement       July 2016


3.  Consequences of a corrupted LSP Lifetime

   The lifetime field of the LSP is an important field for the correct
   operation of IS-IS.  This section evaluates the impact of LSP
   lifetime corruption on one LSP.

3.1.  Lifetime corrupted to zero

   In this case, a non-purge LSP gets its LSP lifetime corrupted to zero
   between its origination and a router "R" receiving the LSP.

   If cryptographic authentication, as defined in [RFC5304], is not
   enabled in the network, this corrupted LSP is processed as if its
   lifetime has expired.  This will replace any non-expired version of
   the same LSP in the LSPDB and will cause the purge to be flooded
   network-wide.  This creates a topological change in the network,
   requiring new routes computation and installation.  This purge LSP is
   then flooded in the whole network, including to routers having a non
   corrupted version of the LSP.  Finally, the originator of the LSP
   receive the purge LSP and advertise a new LSP with an increased
   sequence number.  If the corruption is systematic, the processes
   cycles forever.

   If cryptographic authentication is enabled in the network, [RFC5304]
   and [RFC6233] restrict the TLV code that are allowed in a purge.
   They specify that LSP with zero lifetime but having TLV not allowed
   in purge, must be ignored.  As only a few TLV are acceptable in
   purge, this provides an effective protection as the LSP with the
   corrupted LSP lifetime will be ignored.  Note that this additional
   check has been added because the lifetime, hence LSP purge, is not
   authenticated.

3.2.  Lifetime corrupted to a non zero value

   In this case, a non-purge LSP gets its LSP lifetime corrupted to
   value strictly greater than zero between its origination and a
   receiving IS-IS router.

   This corrupted LSP is accepted as a regular LSP.  The problem is that
   the originator is not aware of this change and if the lifetime has
   been reduced as a result of this corruption, the originator will
   likely not refresh the LSP before it expire.  When the LSP expire, a
   LSP purge will be originated and flooded in the network.  This
   creates a topological change in the network, requiring new routes
   computation and installation.  At some point, the originator of the
   LSP receive the purge LSP and advertise a new LSP with an increased
   sequence number.  If the corruption is systematic, the processes
   cycles forever.



Decraene & Schmitz       Expires January 5, 2017                [Page 3]


Internet-Draft   Lifetime corruption - Problem Statement       July 2016


   Cryptographic authentication does not provide any additional
   protection.

   If the lifetime is corrupted to a small to very small value, the
   effect is virtually equivalent to a purge.  Hence, the restriction,
   introduced by [RFC5304], to restrict the list of TLV allowed in a
   purge LSP is not really effective.  Hence, [RFC5304] does not succeed
   in "prevent[ing] a hostile system from receiving an LSP, setting the
   Remaining Lifetime field to [a small value], and flooding it, thereby
   initiating a purge without knowing the authentication password".

3.3.  Summary

   Cryptographic authentication addresses one case, where the LSP
   lifetime is corrupted to zero.  All others cases triggers a flooding
   storm.

   If the corruption is systematic on a given link, all LSPs flooded
   through that link are affected, creating flooding storm for multiple
   LSPs with severe impact in the network.

4.  Protocol extension

   Given the importance of the IGP for the network and the services
   carried in those IP/MPLS networks, and given the possibly large
   impact of LSP lifetime corruption, this documents calls for a
   protocol extension protecting or mitigating from the corruption of
   LSP lifetime.

   Preferably, the protocol extension could be deployed incrementally
   with incremental benefit.

5.  IANA Considerations

   This document has no IANA action.

6.  Security Considerations

   This document describes a lack of integrity protection of the LSP
   LifeTime field.  This LifeTime may be altered as a result of packet
   corruption (e.g. over transmission links, in routers' linecard or
   switch fabric) or may be voluntarily modified by an external party
   having access to one of theses resources used between IS-IS
   neighbours.  Such modification are not detected by IS-IS checksum
   defined in [ISO10589-Second-Edition] nor the cryptographic
   authentication defined in [RFC5304].  This field is important for the
   protocol as it contains the life time of the routing information.




Decraene & Schmitz       Expires January 5, 2017                [Page 4]


Internet-Draft   Lifetime corruption - Problem Statement       July 2016


   Modification of the lifetime of a single LSP transient impact the
   network by transiently removing a node from the routing topology and
   impacting the traffic crossing this node.  This may also impact
   traffic not crossing the link as micro-loops may happen which would
   saturate some links.

   Systematic modification of the lifetime of all LSPs crossing a single
   link would have a huge impact on the network.  One part of the
   network would likely become virtually inoperative as having no
   (stable) available routes across the network.  The whole flooding
   domain (L1 area or L2) would also be severely affected, especially
   since IGP instabilities creates instabilities to routing and
   signalling protocols relying on the IGP such as BGP, LDP, RSVP-TE,
   PCE...

   As such, this may be considered as a security vulnerability.

7.  Acknowledgement

   The authors wish to thank Hannes Gredler, Les Ginsberg, Paul Wells
   and Stefano Previdi for discussions related to this topic.

8.  References

8.1.  Normative References

   [ISO10589-Second-Edition]
              International Organization for Standardization,
              "Intermediate system to Intermediate system intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473)", ISO/
              IEC 10589:2002, Second Edition, Nov 2002.

8.2.  Informative References

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <http://www.rfc-editor.org/info/rfc5304>.

   [RFC6233]  Li, T. and L. Ginsberg, "IS-IS Registry Extension for
              Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,
              <http://www.rfc-editor.org/info/rfc6233>.








Decraene & Schmitz       Expires January 5, 2017                [Page 5]


Internet-Draft   Lifetime corruption - Problem Statement       July 2016


Authors' Addresses

   Bruno Decraene
   Orange

   Email: bruno.decraene@orange.com


   Christof Schmitz
   Orange

   Email: christof.schmitz@orange.com







































Decraene & Schmitz       Expires January 5, 2017                [Page 6]