IS-IS Minimum Remaining
LifetimeCisco Systems510 McCarthy Blvd.Milpitas95035CAUSAginsberg@cisco.comCisco Systems170 W Tasman DrSan Jose95035CaUSApauwells@cisco.comOrange38 rue du General LeclercIssy Moulineaux cedex 992794Francebruno.decraene@orange.comJuniper1137 Innovation WaySunnyvale, Ca94089USAprz@juniper.netPrivate Contributerhannes@gredler.at
Routing Area
Networking Working GroupSampleCorruption of the Remainining Lifetime Field in a Link State PDU can
go undetected. In certain scenarios this may cause or exacerbate
flooding storms. It is also a possible denial of service attack vector.
This document defines a backwards compatible solution to this
problem.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].[ISO10589] defines the format of a Link State PDU (LSP) which
includes a Remaining Lifetime field. This field is set by the originator
based on local configuration and then decremented by all systems once
the entry is stored in their Link State PDU Database (LSPDB) consistent
with the passing of time. This allows all Intermediate Systems (ISs) to
age out the LSP at approximately the same time.Each LSP also has a checksum field to allow receiving systems to
detect errors which may have occurred during transmission. [ISO 10589]
mandates that the checksum is calculated by the originator of the LSP
and cannot be modified by other routers. Therefore the Remaining
Lifetime is deliberately excluded from the checksum calculation. In
cases where cryptographic authentication is included in an LSP
([RFC5304] or [RFC5310]) the Remaining Lifetime field is also excluded
from the hash calculation. If the Remaining Lifetime field gets
corrupted during flooding this corruption is therefore undetectable. The
consequences of such corruption depend upon how the Remaining Lifetime
is altered.In cases where the Remaining Lifetime becomes larger than the
originator intended the impact is benign. As the originator is
responsible for refreshing the LSP before it ages out a new version of
the LSP will be generated before the LSP ages out - so no harm is
done.In cases where the Remaining Lifetime field becomes smaller than the
originator intended the LSP may age out prematurely (i.e. before the
originator refreshes the LSP). This has two negative consequences:The LSP will be purged by an IS when the Remaining Lifetime
expires. This will cause a temporary loss of reachability to
destinations impacted by the content of that LSP.Unnecessary LSP flooding will occur as a result of the premature
purge and subsequent regeneration/flooding of a new version of the
LSP by the originatorIf the corrupted Remaining Lifetime is only modestly shorter than the
lifetime assigned by the originator the negative impacts are also
modest. If, however, the corrupted Remaining Lifetime becomes very
small, then the negative impacts can become significant - especially in
cases where the cause of the corruption is persistent so that the cycle
repeats itself frequently.A backwards compatible solution to this problem is defined in the
following sections.As discussed in the previous section, the problematic case is when
Remaining Lifetime is corrupted and becomes much smaller than it should
be. The goal of the solution is then to prevent premature purging.Under normal circumstances updates to an LSP - including purging if
appropriate - are the responsibility of the originator of the LSP. There
is a maximum time between generations of a given LSP. Once this time has
expired it is the responsibility of the originator to refresh the LSP
(i.e. issue a new version with higher sequence number) even if the
contents of the LSP have not changed. [ISO10589] defines
maximumLSPGenerationInterval to be sufficiently less than the maximum
lifetime of an LSP so that the new version can be flooded network wide
before the old version ages out on any IS.[ISO10589] defines two cases where a system other than the originator
of an LSP is allowed to purge an LSP:The LSP ages out. This should only occur if the originating IS is
no longer reachable and therefore is unable to update the LSPThere is a Designated Intermediate System (DIS) change on a LAN.
The pseudo-node LSPs generated by the previous DIS are no longer
required and may be purged by the new DIS.In both of these cases purging is not necessary for correct operation
of the protocol. It is provided as an optimization to remove stale
entries from the LSPDB.In cases where the Remaining Lifetime in a received LSP has been
corrupted and is smaller than the Remaining Lifetime at the originating
node when the Remaining Lifetime expires on the receiving node it can
appear as if the originating IS has failed to regenerate the LSP before
it ages out (case #1 above). To prevent this from having a negative
impact a modest change to the storage of "new" LSPs in the LSPDB is
specified.[ISO10589] Section 7.3.16 defines the rules to determine whether a
received LSP is older, the same, or newer than the copy of the same LSP
in the receiver's LSPDB. The key elements are:Higher sequence numbers are newerIf sequence numbers are the same, an LSP with zero Remaining
Lifetime (a purged LSP) is newer than the same LSP w non-zero
Remaining LifetimeIf both the received and local copy of the LSP have non-zero
Remaining Lifetime they are considered the same even if the
Remaining Lifetimes differ[ISO10589] Section 7.3.15.1.e(1) defines the actions to take on
receipt of an LSP generated by another IS which is newer than the local
copy and has a non-zero Remaining Lifetime. An additional action is
defined by this document:vi. If the Remaining Lifetime of the new LSP is less than MaxAge it
is set to MaxAgeThis additional action insures that no matter what value of Remaining
Lifetime is received a system other than the originator of an LSP will
never purge the LSP until the LSP has existed in the database for at
least MaxAge.It is important to note that no change is proposed for handling the
receipt of purged LSPs. The rules specified in [ISO10589] Section
7.3.15.1b still apply i.e., an LSP received with zero Remaining Lifetime
is still considered newer than a matching LSP with non-zero Remaining
Lifetime. Therefore the changes proposed here will not result in LSPDB
inconsistency among routers in the newtork.This section discusses some possible deployment issues for this
protocol extension.[ISO10589] defines MaxAge (the maximum value for Remaining Lifetime
in an LSP) as an architectural constant of 20 minutes (1200 seconds).
However, in practice, implementations have supported allowing this
value to be configurable. The common intent of a configurable value is
to support longer lifetimes than the default - thus reducing the
periodic regeneration of LSPs in the absence of topology changes. See
a discussion of this point in [RFC3719]. It is therefore possible for
the value of MaxAge on the IS which originates an LSP to be higher or
lower than the value of MaxAge on the ISs which receive the LSP.If the value of MaxAge of the IS which originated the LSP is
smaller than the value of MaxAge of the receiver of an LSP, then
setting the Remaining Lifetime of the received LSP to the local value
of MaxAge will insure that it is not purged prematurely. However, if
the value of MaxAge on the receiver is less than that of the
originator then it is still possible when using the extension defined
in the previous section to have an LSP purged prematurely.
Implementors of this extension may wish to protect against this case
by making the value to which Remaining Lifetime is set under the
conditions described in the previous section configurable. If that is
done the configured value MUST be greater than or equal to the locally
configured value of MaxAge.Reporting reception of an LSP with a possible corrupt Remaining
Lifetime field can be useful in identifying a problem in the network.
In order to minimize the reports of false positives the following
algorithm SHOULD be used in determining whether the Remaining Lifetime
in the received LSP is possibly corrupt:The LSP has passed all acceptance tests as specified in
[ISO10589] Section 7.3.15.1The LSP is newer than the copy in the local LSPDB (including
the case of not being present in the LSPDB)Remaining Lifetime in the received LSP is less than
ZeroAgeLifetimeThe adjacency to the neighbor from which the LSP is received
has been up for a minimum of ZeroAgeLifetimeIn such a case an IS SHOULD generate a CorruptRemainingLifetime
event.Note that it is not possible to guarantee that all cases of corrupt
Remaining Lifetime will be detected using the above algorithm. It is
also not possible to guarantee that all CorruptRemainingLifetime
events reported using the above algorithm are valid. As a diagnostic
aid an implementation MAY wish to retain the value of Remaining
Lifetime received when the LSP was added to the LSPDB.The extensions defined in this document may result in retaining an
LSP longer than its original lifetime. In order for this to occur the
scheduled refresh of the LSP by the originator of the LSP must fail to
occur - which implies the originator is no longer reachable. In such a
case its neighbors will update their own LSPs reporting the loss of
connectivity to the originator. [ISO10589] specifies that LSPs from a
node which is unreachable (failure of the two-way-connectivity check)
will not be used. Note this behavior applies to ALL information in the
set of LSPs from such a node.Retention of stale LSPs therefore has no negative side effects
other than requiring additional memory for the LSPDB. In networks
where a combination of pathological behaviors (LSP corruption,
frequent resetting of nodes in the network) is seen this could lead to
a large number of stale LSPs being retained - but such networks are
already compromised.None.The ability to introduce corrupt LSPs is not altered by the rules
defined in this document. Use of authentication as defined in [RFC5304]
and [RFC5310] prevents such LSPs from being intentionally introduced. A
"man-in-the-middle" attack which modifies an existing LSP by changing
the Remaining Lifetime to a small value can cause premature purges even
in the presence of cryptographic authentication. The mechanisms defined
in this document prevent such an attack from being effective.The problem statement in [LIFE-PROB] motivated this work.The following people gave a substantial conrtibution to the content
of this document and should be considered as co-authors: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)International Organization for
StandardizationIS-IS LSP lifetime corruption - Problem Statement,
draft-decraene-isis-lsp-lifetime-problem-statement-02(work in
progress)