draft-ietf-lsr-isis-invalid-tlv-02.txt   draft-ietf-lsr-isis-invalid-tlv-03.txt 
LSR Working Group L. Ginsberg LSR Working Group L. Ginsberg
Internet-Draft P. Wells Internet-Draft P. Wells
Updates: 5305 6232 (if approved) Cisco Systems Updates: 5305 6232 (if approved) Cisco Systems
Intended status: Standards Track T. Li Intended status: Standards Track T. Li
Expires: December 24, 2020 Arista Networks Expires: January 27, 2021 Arista Networks
T. Przygienda T. Przygienda
S. Hegde S. Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
June 22, 2020 July 26, 2020
Invalid TLV Handling in IS-IS Invalid TLV Handling in IS-IS
draft-ietf-lsr-isis-invalid-tlv-02 draft-ietf-lsr-isis-invalid-tlv-03
Abstract Abstract
Key to the extensibility of the Intermediate System to Intermediate Key to the extensibility of the Intermediate System to Intermediate
System (IS-IS) protocol has been the handling of unsupported and/or System (IS-IS) protocol has been the handling of unsupported and/or
invalid Type/Length/Value (TLV) tuples. Although there are explicit invalid Type/Length/Value (TLV) tuples. Although there are explicit
statements in existing specifications, deployment experience has statements in existing specifications, deployment experience has
shown that there are inconsistencies in the behavior when a TLV which shown that there are inconsistencies in the behavior when a TLV which
is disallowed in a particular Protocol Data Unit (PDU) is received. is disallowed in a particular Protocol Data Unit (PDU) is received.
This document discusses such cases and makes the correct behavior This document discusses such cases and makes the correct behavior
explicit in order to insure that interoperability is maximized. explicit in order to ensure that interoperability is maximized.
This document updates RFC5305 and RFC6232. This document updates RFC5305 and RFC6232.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 24, 2020. This Internet-Draft will expire on January 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3 2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3
3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4 3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4
3.1. Handling of Disallowed TLVs in Received PDUs other than 3.1. Handling of Disallowed TLVs in Received PDUs other than
LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4 LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Special Handling of Disallowed TLVs in Received LSP 3.2. Special Handling of Disallowed TLVs in Received LSP
Purges . . . . . . . . . . . . . . . . . . . . . . . . . 4 Purges . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5 3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5
3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5 3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5
4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 5 4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Intermediate System to Intermediate System (IS-IS) protocol The Intermediate System to Intermediate System (IS-IS) protocol
[ISO10589] utilizes Type/Length/Value (TLV) encoding for all content [ISO10589] utilizes Type/Length/Value (TLV) encoding for all content
in the body of Protocol Data Units (PDUs). New extensions to the in the body of Protocol Data Units (PDUs). New extensions to the
protocol are supported by defining new TLVs. In order to allow protocol are supported by defining new TLVs. In order to allow
protocol extensions to be deployed in a backwards compatible way an protocol extensions to be deployed in a backwards compatible way an
implementation is required to ignore TLVs that it does not implementation is required to ignore TLVs that it does not
understand. This behavior is also applied to sub-TLVs [RFC5305], understand. This behavior is also applied to sub-TLVs [RFC5305],
which are contained within TLVs. which are contained within TLVs.
A corollary to ignoring unknown TLVs is having the validation of PDUs Also essential to the correct operation of the protocol is having the
be independent from the validation of the TLVs contained in the PDU. validation of PDUs be independent from the validation of the TLVs
PDUs which are valid must be accepted [ISO10589] even if an contained in the PDU. PDUs which are valid must be accepted
individual TLV contained within that PDU is invalid in some way [ISO10589] even if an individual TLV contained within that PDU is not
(e.g., incorrect syntax, data value out of range, etc.). understood or is invalid in some way (e.g., incorrect syntax, data
value out of range, etc.).
The set of TLVs (and sub-TLVs) which are allowed in each PDU type is The set of TLVs (and sub-TLVs) which are allowed in each PDU type is
documented in the TLV Codepoints Registry established by [RFC3563] documented in the TLV Codepoints Registry established by [RFC3563]
and updated by [RFC6233] and [RFC7356]. and updated by [RFC6233] and [RFC7356].
This document is intended to clarify some aspects of existing This document is intended to clarify some aspects of existing
specifications and thereby reduce the occurrence of non-conformant specifications and thereby reduce the occurrence of non-conformant
behavior seen in real world deployments. Although behaviors behavior seen in real world deployments. Although behaviors
specified in existing protocol specifications are not changed, the specified in existing protocol specifications are not changed, the
clarifications contained in this document serve as updates to RFC clarifications contained in this document serve as updates to RFC
skipping to change at page 4, line 15 skipping to change at page 4, line 15
3. TLV Acceptance in PDUs 3. TLV Acceptance in PDUs
This section describes the correct behavior when a PDU is received This section describes the correct behavior when a PDU is received
which contains a TLV which is specified as disallowed in the TLV which contains a TLV which is specified as disallowed in the TLV
Codepoints Registry. Codepoints Registry.
3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges 3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges
[ISO10589] defines the behavior required when a PDU is received [ISO10589] defines the behavior required when a PDU is received
containing a TLV which is "not recognised". It states (see Sections containing a TLV which is "not recognised". It states (see Sections
9.3 - 9.13): 9.5 - 9.13):
"Any codes in a received PDU that are not "Any codes in a received PDU that are not
recognised shall be ignored." recognised shall be ignored."
This is the model to be followed when a TLV is received which is This is the model to be followed when a TLV is received which is
disallowed. Therefore TLVs in a PDU (other than LSP purges) which disallowed. Therefore TLVs in a PDU (other than LSP purges) which
are disallowed MUST be ignored and MUST NOT cause the PDU itself to are disallowed MUST be ignored and MUST NOT cause the PDU itself to
be rejected by the receiving IS. be rejected by the receiving IS.
3.2. Special Handling of Disallowed TLVs in Received LSP Purges 3.2. Special Handling of Disallowed TLVs in Received LSP Purges
skipping to change at page 4, line 50 skipping to change at page 4, line 50
other than the authentication TLV". other than the authentication TLV".
This behavior was extended by [RFC6232] which introduced the Purge This behavior was extended by [RFC6232] which introduced the Purge
Originator Identification (POI) TLV and [RFC6233] which added the Originator Identification (POI) TLV and [RFC6233] which added the
"Purge" column to the TLV Codepoints registry to identify all the "Purge" column to the TLV Codepoints registry to identify all the
TLVs which are allowed in purges. TLVs which are allowed in purges.
The behavior specified in [RFC5304] is not backwards compatible with The behavior specified in [RFC5304] is not backwards compatible with
the behavior defined by [ISO10589] and therefore can only be safely the behavior defined by [ISO10589] and therefore can only be safely
enabled when all nodes support cryptographic authentication. enabled when all nodes support cryptographic authentication.
Similarly, the extensions defined by [RFC6233] are not compatible Similarly, the extensions defined by [RFC6232] are not compatible
with the behavior defined in [RFC5304], therefore can only be safely with the behavior defined in [RFC5304], therefore can only be safely
enabled when all nodes support the extensions. enabled when all nodes support the extensions.
It is RECOMMENDED that implementations provide controls for the When new protocol behaviors are specified that are not backwards
enablement of behaviors that are not backward compatible. compatible, it is RECOMMENDED that implementations provide controls
for their enablement. This serves to prevent interoperability issues
and allow for non-disruptive introduction of the new functionality
into an existing network.
3.3. Applicability to sub-TLVs 3.3. Applicability to sub-TLVs
[RFC5305] introduced sub-TLVs, which are TLV tuples advertised within [RFC5305] introduced sub-TLVs, which are TLV tuples advertised within
the body of a parent TLV. Registries associated with sub-TLVs are the body of a parent TLV. Registries associated with sub-TLVs are
associated with the TLV Codepoints Registry and specify in which TLVs associated with the TLV Codepoints Registry and specify in which TLVs
a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the
following sentence: following sentence:
"As with TLVs, it is required that sub-TLVs which "As with TLVs, it is required that sub-TLVs which
skipping to change at page 5, line 46 skipping to change at page 5, line 49
Remaining Lifetime." Remaining Lifetime."
However, the IANA section of the same document stated: However, the IANA section of the same document stated:
"The additional values for this TLV should be "The additional values for this TLV should be
IIH:n, LSP:y, SNP:n, and Purge:y." IIH:n, LSP:y, SNP:n, and Purge:y."
The correct setting for "LSP" is "n". This document updates The correct setting for "LSP" is "n". This document updates
[RFC6232] by correcting that error. [RFC6232] by correcting that error.
This document also updates the previously quoted text from Section 3
of [RFC6232] to be:
"The POI TLV SHOULD be sent in all purges and
MUST NOT be sent in LSPs with a non-zero
Remaining Lifetime."
4. TLV Validation and LSP Acceptance 4. TLV Validation and LSP Acceptance
The correct format of a TLV and its associated sub-TLVs, if The correct format of a TLV and its associated sub-TLVs, if
applicable, are defined in the document(s) which introduce each applicable, are defined in the document(s) which introduce each
codepoint. The definition MUST include what action to take when the codepoint. The definition MUST include what action to take when the
format/content of the TLV does not conform to the specification format/content of the TLV does not conform to the specification
(e.g., "MUST be ignored on receipt"). When making use of the (e.g., "MUST be ignored on receipt"). When making use of the
information encoded in a given TLV (or sub-TLV) receiving nodes MUST information encoded in a given TLV (or sub-TLV) receiving nodes MUST
verify that the TLV conforms to the standard definition. This verify that the TLV conforms to the standard definition. This
includes cases where the length of a TLV/sub-TLV is incorrect and/or includes cases where the length of a TLV/sub-TLV is incorrect and/or
skipping to change at page 8, line 5 skipping to change at page 8, line 19
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232, Originator Identification TLV for IS-IS", RFC 6232,
DOI 10.17487/RFC6232, May 2011, DOI 10.17487/RFC6232, May 2011,
<https://www.rfc-editor.org/info/rfc6232>. <https://www.rfc-editor.org/info/rfc6232>.
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for
Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,
<https://www.rfc-editor.org/info/rfc6233>. <https://www.rfc-editor.org/info/rfc6233>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLV_CODEPOINTS] [TLV_CODEPOINTS]
IANA, "IS-IS TLV Codepoints web page IANA, "IS-IS TLV Codepoints web page
(https://www.iana.org/assignments/isis-tlv-codepoints/ (https://www.iana.org/assignments/isis-tlv-codepoints/
isis-tlv-codepoints.xhtml)". isis-tlv-codepoints.xhtml)".
8.2. Informative References 8.2. Informative References
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV)
Codepoints in Intermediate System to Intermediate System", Codepoints in Intermediate System to Intermediate System",
RFC 3359, DOI 10.17487/RFC3359, August 2002, RFC 3359, DOI 10.17487/RFC3359, August 2002,
<https://www.rfc-editor.org/info/rfc3359>. <https://www.rfc-editor.org/info/rfc3359>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>.
Authors' Addresses Authors' Addresses
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Paul Wells Paul Wells
Cisco Systems Cisco Systems
 End of changes. 14 change blocks. 
21 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/