Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7987 P. Wells
Category: Standards Track Cisco Systems
ISSN: 2070-1721 B. Decraene
Orange
T. Przygienda
Juniper
H. Gredler
RtBrick Inc.
October 2016
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7987 P. Wells
Category: Standards Track Cisco Systems
ISSN: 2070-1721 B. Decraene
Orange
T. Przygienda
Juniper
H. Gredler
RtBrick Inc.
October 2016
IS-IS Minimum Remaining Lifetime
IS-IS最小剩余寿命
Abstract
摘要
Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) 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.
链路状态协议数据单元（LSP）中剩余生存期字段的损坏可能无法检测到。在某些情况下，这可能导致或加剧洪水风暴。它也是一种可能的拒绝服务攻击向量。本文档定义了此问题的向后兼容解决方案。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7987.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7987.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Problem Statement ...............................................3
1.1. Requirements Language ......................................4
2. Solution ........................................................4
3. Deployment Considerations .......................................5
3.1. Inconsistent Values for MaxAge .............................5
3.2. Reporting Corrupted Lifetime ...............................6
3.3. Impact of Delayed LSP Purging ..............................7
4. Security Considerations .........................................7
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................8
Acknowledgements ...................................................8
Contributors .......................................................8
Authors' Addresses .................................................9
1. Problem Statement ...............................................3
1.1. Requirements Language ......................................4
2. Solution ........................................................4
3. Deployment Considerations .......................................5
3.1. Inconsistent Values for MaxAge .............................5
3.2. Reporting Corrupted Lifetime ...............................6
3.3. Impact of Delayed LSP Purging ..............................7
4. Security Considerations .........................................7
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................8
Acknowledgements ...................................................8
Contributors .......................................................8
Authors' Addresses .................................................9
[ISO10589] defines the format of a Link State PDU (LSP) that 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 LSP Database (LSPDB) consistent with the passing of time. This allows all Intermediate Systems (ISs) to age out the LSP at approximately the same time.
[ISO10589]定义了包含剩余生存期字段的链路状态PDU（LSP）的格式。该字段由发起者根据本地配置设置，然后在条目存储在其LSP数据库（LSPDB）中后，所有系统根据时间的推移递减。这允许所有中间系统（ISs）几乎同时老化LSP。
Each LSP also has a checksum field to allow receiving systems to detect errors that may have occurred during transmission. [ISO10589] 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.
每个LSP还具有校验和字段，以允许接收系统检测传输期间可能发生的错误。[ISO10589]规定校验和由LSP的发起人计算，不能由其他路由器修改。因此，剩余寿命故意从校验和计算中排除。在LSP（[RFC5304]或[RFC5310]）中包括加密认证的情况下，剩余生存期字段也被排除在散列计算之外。如果剩余寿命字段在泛洪期间损坏，则无法检测到此损坏。这种腐败的后果取决于剩余寿命如何改变。
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.
如果剩余寿命超过发起人的预期寿命，则影响是良性的。由于发起人负责在LSP过期之前刷新LSP，因此将在LSP过期之前生成新版本的LSP，因此不会造成任何损害。
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:
在剩余生存期字段小于发端人预期的情况下，LSP可能会过早老化（即，在发端人刷新LSP之前）。这有两个负面后果：
1. 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.
1. 当剩余生存期到期时，LSP将由IS清除。这将导致受该LSP内容影响的目的地暂时无法访问。
2. 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 originator.
2. 由于发起人对新版LSP进行过早吹扫和随后的再生/溢流，将发生不必要的LSP溢流。
If 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.
此问题的向后兼容解决方案将在以下部分中定义。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
As discussed in the previous section, the problematic case is when the 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 a 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.
在正常情况下，LSP的发起人负责对LSP进行更新（包括清除，如果适用）。给定LSP的两代之间存在最长时间。一旦该时间到期，即使LSP的内容没有更改，发起人也有责任刷新LSP（即发布具有更高序列号的新版本）。[ISO10589]将MaximumLSPGGenerationInterval定义为充分小于LSP的最大生存期，以便在旧版本在任何IS上老化之前，新版本可以在网络范围内被淹没。
[ISO10589] defines two cases where a system other than the originator of an LSP is allowed to purge an LSP:
[ISO10589]定义了允许LSP发起人以外的系统清除LSP的两种情况：
1. The LSP ages out. This should only occur if the originating IS is no longer reachable and therefore is unable to update the LSP.
1. LSP过期了。只有当无法再访问发起服务器，因此无法更新LSP时，才会发生这种情况。
2. There is a Designated Intermediate System (DIS) change on a LAN. The pseudonode LSPs generated by the previous DIS are no longer required and may be purged by the new DIS.
2. 局域网上有一个指定的中间系统（DIS）变更。由以前的DIS生成的伪节点LSP不再需要，并且可以由新的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.
在这两种情况下，协议的正确运行不需要吹扫。它是作为从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.
在接收到的LSP中的剩余生存期已损坏且小于发起节点上的剩余生存期的情况下，当剩余生存期在接收节点上到期时，可能会出现发起is未能在LSP过期之前重新生成LSP的情况（上述情况#1）。为防止产生负面影响，对LSPDB中“新”LSP的存储进行适度更改。
Section 7.3.16 of [ISO10589] 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:
[ISO10589]第7.3.16节定义了确定接收的LSP是否比接收方LSPDB中相同LSP的副本旧、相同或更新的规则。关键要素包括：
o Higher sequence numbers are newer.
o 序列号越高越新。
o If sequence numbers are the same, an LSP with a zero Remaining Lifetime (a purged LSP) is newer than the same LSP with a non-zero Remaining Lifetime.
o 如果序列号相同，则剩余寿命为零的LSP（清除的LSP）比剩余寿命非零的LSP新。
o If both the received and local copy of the LSP have a non-zero Remaining Lifetime, they are considered the same even if the Remaining Lifetimes differ.
o 如果LSP的接收副本和本地副本都具有非零剩余寿命，则认为它们是相同的，即使剩余寿命不同。
Section 7.3.15.1.e(1) of [ISO10589] defines the actions to take on receipt of an LSP generated by another IS that is newer than the local copy and has a non-zero Remaining Lifetime. An additional action is defined by this document:
[ISO10589]第7.3.15.1.e（1）节定义了接收到另一个IS生成的LSP时要采取的措施，该LSP比本地副本更新，并且剩余寿命不为零。本文件规定了一项附加措施：
vi. If the Remaining Lifetime of the new LSP is less than MaxAge, it is set to MaxAge.
vi.如果新LSP的剩余寿命小于MaxAge，则设置为MaxAge。
This additional action ensures 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.
此附加操作确保无论接收到剩余生存期的值是多少，LSP的发起人以外的系统将永远不会清除LSP，直到LSP在数据库中至少存在MaxAge。
It is important to note that no change is proposed for handling the receipt of purged LSPs. The rules specified in Section 7.3.15.1.b of [ISO10589] still apply, i.e., an LSP received with a zero Remaining Lifetime is still considered newer than a matching LSP with a non-zero Remaining Lifetime. Therefore, the changes proposed here will not result in LSPDB inconsistency among routers in the network.
需要注意的是，不建议对接收清除的LSP进行更改。[ISO10589]第7.3.15.1.b节中规定的规则仍然适用，即，剩余寿命为零的LSP仍然被认为比剩余寿命为非零的匹配LSP更新。因此，此处提出的更改不会导致网络中路由器之间的LSPDB不一致。
This section discusses some possible deployment issues for this protocol extension.
本节讨论此协议扩展的一些可能的部署问题。
[ISO10589] defines MaxAge (the maximum value for the 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
[ISO10589]将MaxAge（LSP剩余寿命的最大值）定义为20分钟（1200秒）的体系结构常数。然而，在实践中，实现支持允许配置此值。可配置值的共同目的是支持比默认值更长的生命周期，从而在没有拓扑更改的情况下减少LSP的周期性再生。参见[RFC3719]中对这一点的讨论。信息技术
is therefore possible for the value of MaxAge on the IS that originates an LSP to be higher or lower than the value of MaxAge on the ISs that receive the LSP.
因此，发起LSP的is上的MaxAge值可能高于或低于接收LSP的ISs上的MaxAge值。
If the value of MaxAge of the IS that 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 ensure 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 to have an LSP purged prematurely when using the extension defined in the previous section. Implementors of this extension may wish to protect against this case by making the value to which the 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.
如果发起LSP的IS的MaxAge值小于LSP接收器的MaxAge值，则将接收到的LSP的剩余生存期设置为MaxAge的本地值将确保不会过早清除它。但是，如果接收方的MaxAge值小于发起方的MaxAge值，则在使用上一节中定义的扩展时，仍然可能过早清除LSP。此扩展的实现者可能希望通过在上一节中描述的条件下设置剩余生存期的值来防止这种情况。如果这样做，则配置的值必须大于或等于本地配置的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:
报告接收到具有可能损坏的剩余寿命字段的LSP有助于识别网络中的问题。为了尽量减少误报报告，应使用以下算法确定接收到的LSP中的剩余生存期是否可能损坏：
o The LSP has passed all acceptance tests as specified in Section 7.3.15.1 of [ISO10589].
o LSP已通过[ISO10589]第7.3.15.1节规定的所有验收测试。
o The LSP is newer than the copy in the local LSPDB (including the case of not being present in the LSPDB).
o LSP比本地LSPDB中的副本更新（包括LSPDB中不存在的情况）。
o The Remaining Lifetime in the received LSP is less than ZeroAgeLifetime.
o 接收到的LSP中的剩余生存期小于ZeroAgeLifetime。
o The adjacency to the neighbor from which the LSP is received has been up for a minimum of ZeroAgeLifetime.
o 与接收到LSP的邻居的邻接已被设置为最短的零寿命。
In such a case, an IS SHOULD generate a CorruptRemainingLifetime event.
在这种情况下，IS应生成CorruptRemainingLifetime事件。
Note that it is not possible to guarantee that all cases of a 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 the Remaining Lifetime received when the LSP was added to the LSPDB.
请注意，无法保证使用上述算法检测所有剩余寿命损坏的情况。也无法保证使用上述算法报告的所有CorruptRemainingLifetime事件都有效。作为诊断帮助，实现可能希望保留将LSP添加到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 -- this implies that the originator is no longer reachable. In such a case, its neighbors will update their own LSPs to report the loss of connectivity to the originator. [ISO10589] specifies that LSPs from a node that is unreachable (failure of the two-way connectivity check) will not be used. Note that this behavior applies to ALL information in the set of LSPs from such a node.
本文档中定义的扩展可能导致LSP的保留时间超过其原始使用寿命。为了实现这一点，LSP的发起者对LSP的预定刷新必须失败——这意味着发起者不再是可访问的。在这种情况下，其邻居将更新其自己的LSP，以向发起人报告连接丢失。[ISO10589]指定不会使用来自无法访问的节点（双向连接检查失败）的LSP。请注意，此行为适用于来自此类节点的LSP集中的所有信息。
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 (e.g., LSP corruption and 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.
因此，保留陈旧的LSP除了需要LSPDB额外的内存外，没有其他负面影响。在同时存在病理行为（例如，LSP损坏和网络中节点频繁重置）的网络中，这可能会导致大量过时的LSP被保留，但此类网络已经受损。
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 that 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.
引入损坏LSP的能力不受本文档中定义的规则的影响。使用[RFC5304]和[RFC5310]中定义的身份验证可防止故意引入此类LSP。中间人攻击通过将剩余生存期更改为较小值来修改现有LSP，即使在存在加密身份验证的情况下，也可能导致过早清除。本文件中定义的机制可防止此类攻击生效。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- 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, November 2002.
[ISO10589]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，DOI 10.17487/RFC5304，2008年10月<http://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，DOI 10.17487/RFC5310，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
[PROB-STATEMENT] Decraene, B. and C. Schmitz, "IS-IS LSP lifetime corruption - Problem Statement", Work in Progress, draft-decraene-isis-lsp-lifetime-problem-statement-02, July 2016.
[PROB-STATEMENT]Decraene，B.和C.Schmitz，“IS-IS LSP终身腐败-问题陈述”，正在进行的工作，草稿-Decraene-isis-LSP-lifetime-Problem-STATEMENT-022016年7月。
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, <http://www.rfc-editor.org/info/rfc3719>.
[RFC3719]Parker，J.，Ed.“使用中间系统到中间系统（IS-IS）的互操作网络的建议”，RFC 3719，DOI 10.17487/RFC3719，2004年2月<http://www.rfc-editor.org/info/rfc3719>.
Acknowledgements
致谢
The problem statement in [PROB-STATEMENT] motivated this work.
[PROB-statement]中的问题陈述推动了这项工作。
Contributors
贡献者
The following individual contributed substantially to the content of this document and should be considered a co-author:
以下个人对本文件的内容做出了重大贡献，应被视为共同作者：
Stefano Previdi Cisco Systems Email: sprevidi@cisco.com
Stefano Previdi Cisco Systems电子邮件：sprevidi@cisco.com
Authors' Addresses
作者地址
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States of America
莱斯金斯伯格思科系统公司，麦卡锡大道510号。美国加利福尼亚州米尔皮塔斯95035
Email: ginsberg@cisco.com
Email: ginsberg@cisco.com
Paul Wells Cisco Systems 170 W. Tasman Dr. San Jose, CA 95035 United States of America
Paul Wells Cisco Systems 170 W.Tasman博士，加利福尼亚州圣何塞，美利坚合众国95035
Email: pauwells@cisco.com
Email: pauwells@cisco.com
Bruno Decraene Orange 44 avenue de la Republique, CS 50010 92326 Chatillon Cedex 92794 France
布鲁诺·德雷恩·奥兰治共和国大道44号，CS 50010 92326法国西德克斯查蒂隆92794
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com
Tony Przygienda Juniper 1137 Innovation Way Sunnyvale, CA 94089 United States of America
Tony Przygienda Juniper 1137创新之路美国加利福尼亚州桑尼维尔94089
Email: prz@juniper.net
Email: prz@juniper.net
Hannes Gredler RtBrick Inc.
汉内斯·格雷德勒RtBrick公司。
Email: hannes@rtbrick.com
Email: hannes@rtbrick.com