Internet DRAFT - draft-ietf-lsr-isis-invalid-tlv
draft-ietf-lsr-isis-invalid-tlv
LSR Working Group L. Ginsberg
Internet-Draft P. Wells
Updates: 5305 6232 (if approved) Cisco Systems
Intended status: Standards Track T. Li
Expires: January 27, 2021 Arista Networks
T. Przygienda
S. Hegde
Juniper Networks, Inc.
July 26, 2020
Invalid TLV Handling in IS-IS
draft-ietf-lsr-isis-invalid-tlv-03
Abstract
Key to the extensibility of the Intermediate System to Intermediate
System (IS-IS) protocol has been the handling of unsupported and/or
invalid Type/Length/Value (TLV) tuples. Although there are explicit
statements in existing specifications, deployment experience has
shown that there are inconsistencies in the behavior when a TLV which
is disallowed in a particular Protocol Data Unit (PDU) is received.
This document discusses such cases and makes the correct behavior
explicit in order to ensure that interoperability is maximized.
This document updates RFC5305 and RFC6232.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 https://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
Ginsberg, et al. Expires January 27, 2021 [Page 1]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
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 27, 2021.
Copyright Notice
Copyright (c) 2020 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
(https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3
3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4
3.1. Handling of Disallowed TLVs in Received PDUs other than
LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Special Handling of Disallowed TLVs in Received LSP
Purges . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5
3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5
4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Intermediate System to Intermediate System (IS-IS) protocol
[ISO10589] utilizes Type/Length/Value (TLV) encoding for all content
in the body of Protocol Data Units (PDUs). New extensions to the
protocol are supported by defining new TLVs. In order to allow
protocol extensions to be deployed in a backwards compatible way an
implementation is required to ignore TLVs that it does not
Ginsberg, et al. Expires January 27, 2021 [Page 2]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
understand. This behavior is also applied to sub-TLVs [RFC5305],
which are contained within TLVs.
Also essential to the correct operation of the protocol is having the
validation of PDUs be independent from the validation of the TLVs
contained in the PDU. PDUs which are valid must be accepted
[ISO10589] even if an individual TLV contained within that PDU is not
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
documented in the TLV Codepoints Registry established by [RFC3563]
and updated by [RFC6233] and [RFC7356].
This document is intended to clarify some aspects of existing
specifications and thereby reduce the occurrence of non-conformant
behavior seen in real world deployments. Although behaviors
specified in existing protocol specifications are not changed, the
clarifications contained in this document serve as updates to RFC
5305 (see Section 3.3) and RFC 6232 (see Section 3.4).
2. TLV Codepoints Registry
[RFC3563] established the IANA-managed IS-IS TLV Codepoints Registry
for recording assigned TLV code points [TLV_CODEPOINTS]. The initial
contents of this registry were based on [RFC3359].
The registry includes a set of columns indicating in which PDU types
a given TLV is allowed:
IIH - TLV is allowed in Intermediate System to Intermediate System
Hello (IIH) PDUs (Point-to-point and LAN)
LSP - TLV is allowed in Link State PDUs (LSP)
SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence
Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP))
Purge - TLV is allowed in LSP Purges [RFC6233]
If "Y" is entered in a column it means the TLV is allowed in the
corresponding PDU type.
If "N" is entered in a column it means the TLV is not allowed in the
corresponding PDU type.
Ginsberg, et al. Expires January 27, 2021 [Page 3]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
3. TLV Acceptance in PDUs
This section describes the correct behavior when a PDU is received
which contains a TLV which is specified as disallowed in the TLV
Codepoints Registry.
3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges
[ISO10589] defines the behavior required when a PDU is received
containing a TLV which is "not recognised". It states (see Sections
9.5 - 9.13):
"Any codes in a received PDU that are not
recognised shall be ignored."
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
are disallowed MUST be ignored and MUST NOT cause the PDU itself to
be rejected by the receiving IS.
3.2. Special Handling of Disallowed TLVs in Received LSP Purges
When purging LSPs, [ISO10589] recommends (but does not require) 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
any TLVs which are present are ignored.
When cryptographic authentication [RFC5304] was introduced, this
looseness when processing received purges had to be addressed in
order to prevent attackers from being able to initiate a purge
without having access to the authentication key. [RFC5304] therefore
imposed strict requirements on what TLVs were allowed in a purge
(authentication only) and specified that:
"ISes MUST NOT accept purges that contain TLVs
other than the authentication TLV".
This behavior was extended by [RFC6232] which introduced the Purge
Originator Identification (POI) TLV and [RFC6233] which added the
"Purge" column to the TLV Codepoints registry to identify all the
TLVs which are allowed in purges.
The behavior specified in [RFC5304] is not backwards compatible with
the behavior defined by [ISO10589] and therefore can only be safely
enabled when all nodes support cryptographic authentication.
Similarly, the extensions defined by [RFC6232] are not compatible
with the behavior defined in [RFC5304], therefore can only be safely
enabled when all nodes support the extensions.
Ginsberg, et al. Expires January 27, 2021 [Page 4]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
When new protocol behaviors are specified that are not backwards
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
[RFC5305] introduced sub-TLVs, which are TLV tuples advertised within
the body of a parent TLV. Registries associated with sub-TLVs are
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
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
An error was introduced by [RFC6232] when specifying in which PDUs
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 LSPs with a non-zero
Remaining Lifetime."
However, the IANA section of the same document stated:
"The additional values for this TLV should be
IIH:n, LSP:y, SNP:n, and Purge:y."
The correct setting for "LSP" is "n". This document updates
[RFC6232] by correcting that error.
This document also updates the previously quoted text from Section 3
of [RFC6232] to be:
Ginsberg, et al. Expires January 27, 2021 [Page 5]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
"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
The correct format of a TLV and its associated sub-TLVs, if
applicable, are defined in the document(s) which introduce each
codepoint. The definition MUST include what action to take when the
format/content of the TLV does not conform to the specification
(e.g., "MUST be ignored on receipt"). When making use of the
information encoded in a given TLV (or sub-TLV) receiving nodes MUST
verify that the TLV conforms to the standard definition. This
includes cases where the length of a TLV/sub-TLV is incorrect and/or
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.
The presence of a TLV (or sub-TLV) with content which does not
conform to the relevant specification MUST NOT cause the LSP itself
to be rejected. Failure to follow this requirement will result in
inconsistent LSP Databases on different nodes in the network which
will compromise the correct operation of the protocol.
LSP Acceptance rules are specified in [ISO10589] . Acceptance rules
for LSP purges are extended by [RFC5304] and [RFC5310] and are
further extended by [RFC6233].
[ISO10589] also specifies the behavior when an LSP is not accepted.
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
Update process on the receiving router takes the same action.
5. IANA Considerations
IANA is requested to add this document as a reference for the TLV
Codepoints Registry.
IANA is also requested to modify the entry for the Purge Originator
Identification TLV in the TLV Codepoints Registry to be:
IIH:n, LSP:n, SNP:n, and Purge:y.
The reference field should be updated to point to this document.
Ginsberg, et al. Expires January 27, 2021 [Page 6]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
6. Security Considerations
As this document makes no changes to the protocol there are no new
security issues introduced.
The clarifications discussed in this document are intended to make it
less likely that implementations will incorrectly process received
LSPs, thereby also making it less likely that a bad actor could
exploit a faulty implementation.
Security concerns for IS-IS are discussed in [ISO10589], [RFC5304],
and [RFC5310].
7. Acknowledgements
The authors would like to thank Alvaro Retana.
8. References
8.1. Normative References
[ISO10589]
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF
and ISO/IEC Joint Technical Committee 1/Sub Committee 6
(JTC1/SC6) on IS-IS Routing Protocol Development",
RFC 3563, DOI 10.17487/RFC3563, July 2003,
<https://www.rfc-editor.org/info/rfc3563>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
Ginsberg, et al. Expires January 27, 2021 [Page 7]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
[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, <https://www.rfc-editor.org/info/rfc5310>.
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232,
DOI 10.17487/RFC6232, May 2011,
<https://www.rfc-editor.org/info/rfc6232>.
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for
Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,
<https://www.rfc-editor.org/info/rfc6233>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLV_CODEPOINTS]
IANA, "IS-IS TLV Codepoints web page
(https://www.iana.org/assignments/isis-tlv-codepoints/
isis-tlv-codepoints.xhtml)".
8.2. Informative References
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV)
Codepoints in Intermediate System to Intermediate System",
RFC 3359, DOI 10.17487/RFC3359, August 2002,
<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
Les Ginsberg
Cisco Systems
Email: ginsberg@cisco.com
Paul Wells
Cisco Systems
Email: pauwells@cisco.com
Ginsberg, et al. Expires January 27, 2021 [Page 8]
Internet-Draft draft-ietf-lsr-isis-invalid-tlv July 2020
Tony Li
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
USA
Email: tony.li@tony.li
Tony Przygienda
Juniper Networks, Inc.
1194 N. Matilda Ave
Sunnyvale, California 94089
USA
Email: prz@juniper.net
Shraddha Hegde
Juniper Networks, Inc.
Embassy Business Park
Bangalore, KA 560093
India
Email: shraddha@juniper.net
Ginsberg, et al. Expires January 27, 2021 [Page 9]
