draft-ietf-lsr-isis-invalid-tlv-01.txt   draft-ietf-lsr-isis-invalid-tlv-02.txt 
LSR Working Group L. Ginsberg LSR Working Group L. Ginsberg
Internet-Draft P. Wells Internet-Draft P. Wells
Updates: 3563 5305 6232 6233 (if Cisco Systems Updates: 5305 6232 (if approved) Cisco Systems
approved) T. Li Intended status: Standards Track T. Li
Intended status: Standards Track Arista Networks Expires: December 24, 2020 Arista Networks
Expires: July 18, 2020 T. Przygienda T. Przygienda
S. Hegde S. Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
January 15, 2020 June 22, 2020
Invalid TLV Handling in IS-IS Invalid TLV Handling in IS-IS
draft-ietf-lsr-isis-invalid-tlv-01 draft-ietf-lsr-isis-invalid-tlv-02
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 insure that interoperability is maximized.
This document when approved updates RFC3563, RFC5305, RFC6232, and This document updates RFC5305 and RFC6232.
RFC6233.
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.
Status of This Memo Status of This Memo
skipping to change at page 2, line 10 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 July 18, 2020. This Internet-Draft will expire on December 24, 2020.
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 41 skipping to change at page 2, line 38
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 . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 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
utilizes Type/Length/Value (TLV) encoding for all content in the body [ISO10589] utilizes Type/Length/Value (TLV) encoding for all content
of Protocol Data Units (PDUs). New extensions to the protocol are in the body of Protocol Data Units (PDUs). New extensions to the
supported by defining new TLVs. In order to allow protocol protocol are supported by defining new TLVs. In order to allow
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, which are understand. This behavior is also applied to sub-TLVs [RFC5305],
contained within TLVs. which are contained within TLVs.
A corollary to ignoring unknown TLVs is having the validation of PDUs A corollary to ignoring unknown TLVs is having the validation of PDUs
be independent from the validation of the TLVs contained in the PDU. be independent from the validation of the TLVs contained in the PDU.
PDUs which are valid MUST be accepted even if an individual TLV PDUs which are valid must be accepted [ISO10589] even if an
contained within that PDU is invalid in some way. individual TLV contained within that PDU is invalid in some way
(e.g., incorrect syntax, data value out of range, etc.).
These behaviors are specified in existing protocol documents - The set of TLVs (and sub-TLVs) which are allowed in each PDU type is
principally [ISO10589] and [RFC5305]. In addition, the set of TLVs documented in the TLV Codepoints Registry established by [RFC3563]
(and sub-TLVs) which are allowed in each PDU type is documented in
the TLV Codepoints Registry ( https://www.iana.org/assignments/isis-
tlv-codepoints/isis-tlv-codepoints.xhtml ) 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
3563 (see Section 2), RFC 5304, and RFC 6233 (see Section 3). 5305 (see Section 3.3) and RFC 6232 (see Section 3.4).
2. TLV Codepoints Registry 2. TLV Codepoints Registry
[RFC3563] established the IANA managed IS-IS TLV Codepoints Registry [RFC3563] established the IANA-managed IS-IS TLV Codepoints Registry
for recording assigned TLV code points [TLV_CODEPOINTS]. The initial for recording assigned TLV code points [TLV_CODEPOINTS]. The initial
contents of this registry were based on [RFC3359]. contents of this registry were based on [RFC3359].
The registry includes a set of columns indicating in which PDU types The registry includes a set of columns indicating in which PDU types
a given TLV is allowed: a given TLV is allowed:
IIH - TLV is allowed in Intermediate System to Intermediate System IIH - TLV is allowed in Intermediate System to Intermediate System
Hello (IIH) PDUs (Point-to-point and LAN) Hello (IIH) PDUs (Point-to-point and LAN)
LSP - TLV is allowed in Link State PDUs (LSP) LSP - TLV is allowed in Link State PDUs (LSP)
SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence
Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP)) Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP))
Purge - TLV is allowed in LSP Purges [RFC6233] Purge - TLV is allowed in LSP Purges [RFC6233]
If "Y" is entered in a column it means the TLV is allowed in the If "Y" is entered in a column it means the TLV is allowed in the
corresponding PDU type. corresponding PDU type.
If "N" is entered in a column it means the TLV is NOT allowed in the If "N" is entered in a column it means the TLV is not allowed in the
corresponding PDU type. corresponding PDU type.
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.3 - 9.13):
"Any codes in a received PDU that are not recognised shall be "Any codes in a received PDU that are not
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
When purging LSPs [ISO10589] recommends (but does not require) the When purging LSPs, [ISO10589] recommends (but does not require) the
body of the LSP (i.e., all TLVs) be removed before generating the body of the LSP (i.e., all TLVs) be removed before generating the
purge. LSP purges which have TLVs in the body are accepted though purge. LSP purges which have TLVs in the body are accepted though
any TLVs which are present "MUST" be ignored. any TLVs which are present are ignored.
When cryptographic authentication [RFC5304] was introduced, this When cryptographic authentication [RFC5304] was introduced, this
looseness when processing received purges had to be addressed in looseness when processing received purges had to be addressed in
order to prevent attackers from being able to initiate a purge order to prevent attackers from being able to initiate a purge
without having access to the authentication key. [RFC5304] therefore without having access to the authentication key. [RFC5304] therefore
imposed strict requirements on what TLVs were allowed in a purge imposed strict requirements on what TLVs were allowed in a purge
(authentication only) and specified that: (authentication only) and specified that:
"ISes MUST NOT accept purges that contain TLVs other than the "ISes MUST NOT accept purges that contain TLVs
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 [RFC6233] 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 It is RECOMMENDED that implementations provide controls for the
enablement of behaviors that are not backward compatible. enablement of behaviors that are not backward compatible.
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. As with TLVs, it is required that sub- a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the
TLVs which are disallowed MUST be ignored on receipt. following sentence:
"As with TLVs, it is required that sub-TLVs which
are disallowed MUST be ignored on receipt.".
The existing sentence in Section 2 of [RFC5305] :
"Unknown sub-TLVs are to be ignored and skipped upon
receipt."
is replaced by:
"Unknown sub-TLVs MUST be ignored and skipped upon
receipt."
3.4. Correction to POI TLV Registry Entry 3.4. Correction to POI TLV Registry Entry
An error was introduced by [RFC6232] when specifying in which PDUs An error was introduced by [RFC6232] when specifying in which PDUs
the POI TLV is allowed. Section 3 of [RFC6232] stated: the POI TLV is allowed. Section 3 of [RFC6232] stated:
"The POI TLV SHOULD be found in all purges and MUST NOT be found in "The POI TLV SHOULD be found in all purges and
LSPs with a non-zero Remaining Lifetime." MUST NOT be found in LSPs with a non-zero
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 IIH:n, LSP:y, SNP:n, "The additional values for this TLV should be
and Purge:y. " IIH:n, LSP:y, SNP:n, and Purge:y."
The correct setting for "LSP" is "n". This document corrects that The correct setting for "LSP" is "n". This document updates
error. [RFC6232] by correcting that error.
4. TLV Validation and LSP Acceptance 4. TLV Validation and LSP Acceptance
The correct format of a TLV and its associated sub-TLVs if applicable The correct format of a TLV and its associated sub-TLVs, if
are defined in the document(s) which introduce each codepoint. The applicable, are defined in the document(s) which introduce each
definition SHOULD include what action to take when the format/content codepoint. The definition MUST include what action to take when the
of the TLV does not conform to the specification (e.g., "MUST be format/content of the TLV does not conform to the specification
ignored on receipt"). When making use of the information encoded in (e.g., "MUST be ignored on receipt"). When making use of the
a given TLV (or sub-TLV) receiving nodes MUST verify that the TLV information encoded in a given TLV (or sub-TLV) receiving nodes MUST
conforms to the standard definition. This includes cases where the verify that the TLV conforms to the standard definition. This
length of a TLV/sub-TLV is incorrect and/or cases where the value includes cases where the length of a TLV/sub-TLV is incorrect and/or
field does not conform to the defined restrictions. cases where the value field does not conform to the defined
restrictions.
However, the unit of flooding for the IS-IS Update process is an LSP. However, the unit of flooding for the IS-IS Update process is an LSP.
The presence of a TLV (or sub-TLV) with content which does not The presence of a TLV (or sub-TLV) with content which does not
conform to the relevant specification MUST NOT cause the LSP itself conform to the relevant specification MUST NOT cause the LSP itself
to be rejected. Failure to follow this requirement will result in to be rejected. Failure to follow this requirement will result in
inconsistent LSP Databases on different nodes in the network which inconsistent LSP Databases on different nodes in the network which
will compromise the correct operation of the protocol. will compromise the correct operation of the protocol.
LSP Acceptance rules are specified in [ISO10589] . Acceptance rules LSP Acceptance rules are specified in [ISO10589] . Acceptance rules
for LSP purges are extended by [RFC5304] [RFC5310] and further for LSP purges are extended by [RFC5304] and [RFC5310] and are
extended by [RFC6233]. further extended by [RFC6233].
[ISO10589] also specifies the behavior when an LSP is not accepted. [ISO10589] also specifies the behavior when an LSP is not accepted.
This behavior is NOT altered by extensions to the LSP Acceptance This behavior is NOT altered by extensions to the LSP Acceptance
rules i.e., regardless of the reason for the rejection of an LSP the rules i.e., regardless of the reason for the rejection of an LSP the
Update process on the receiving router takes the same action. Update process on the receiving router takes the same action.
5. IANA Considerations 5. IANA Considerations
IANA is requested to update the TLV Codepoints Registry to reference IANA is requested to add this document as a reference for the TLV
this document. Codepoints Registry.
IANA is also requested to modify the entry for the POI TLV in the TLV IANA is also requested to modify the entry for the Purge Originator
Codepoints Registry to be: Identification TLV in the TLV Codepoints Registry to be:
IIH:n, LSP:n, SNP:n, and Purge:y. IIH:n, LSP:n, SNP:n, and Purge:y.
The reference field should be updated to point to this document.
6. Security Considerations 6. Security Considerations
As this document makes no changes to the protocol there are no new As this document makes no changes to the protocol there are no new
security issues introduced. security issues introduced.
The clarifications discussed in this document are intended to make it The clarifications discussed in this document are intended to make it
less likely that implementations will incorrectly process received less likely that implementations will incorrectly process received
LSPs, thereby also making it less likely that a bad actor could LSPs, thereby also making it less likely that a bad actor could
exploit a faulty implementaion. exploit a faulty implementation.
Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], Security concerns for IS-IS are discussed in [ISO10589], [RFC5304],
and [RFC5310]. and [RFC5310].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Alvaro Retana. The authors would like to thank Alvaro Retana.
8. References 8. References
 End of changes. 28 change blocks. 
59 lines changed or deleted 73 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/