RFC 8918

Invalid TLV Handling in IS-IS

📅 published September 2020, from ietf

RFC 8918: Invalid TLV Handling in IS-IS 💖

okay bestie, let's get into it 🫶

  • RFC number: 8918
  • Title: Invalid TLV Handling in IS-IS
  • Authors: L. Ginsberg, P. Wells (Cisco Systems), T. Li (Arista Networks), T. Przygienda, S. Hegde (Juniper Networks, Inc.)
  • Stream: Internet Engineering Task Force (IETF)
  • Category: Standards Track
  • Date: September 2020
  • ISSN: 2070-1721
  • Updates: 5305, 6232

Abstract ✨

so IS-IS has always been SO extensible, and the secret sauce is how it handles TLVs (Type-Length-Value tuples) it doesn't support or that are just... wrong 💅 the existing specs do say stuff about this, but real deployments have shown that routers don't always act the same when a TLV that isn't allowed in a particular PDU (Protocol Data Unit) shows up 😭

this doc talks through those cases and spells out the correct behavior so that everyone can actually talk to each other, which is the whole point 🦋

this document updates RFCs 5305 and 6232.

Status of This Memo 📋

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841.

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8918

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) as in effect on the date of publication. please read these carefully, bestie, because they spell out your rights and restrictions for this doc. code components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

1.  Introduction
  1.1.  Requirements Language
2.  TLV Codepoints Registry
3.  TLV Acceptance in PDUs
  3.1.  Handling of Disallowed TLVs in Received PDUs Other Than LSP
        Purges
  3.2.  Special Handling of Disallowed TLVs in Received LSP Purges
  3.3.  Applicability to Sub-TLVs
  3.4.  Correction to POI "TLV Codepoints Registry" Entry
4.  TLV Validation and LSP Acceptance
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🧚

so IS-IS uses TLV encoding for ALL the content in the body of a PDU ✨ new features get added by defining new TLVs. to keep things backwards compatible, an implementation is required to ignore any TLVs it doesn't understand. this same rule applies to sub-TLVs [RFC5305], which live inside TLVs 🍓

also super important: whether a PDU is valid has to be decided separately from whether the TLVs inside it are valid. a valid PDU must be accepted [ISO10589] even if one of its TLVs isn't understood or is invalid somehow (wrong syntax, a data value out of range, that kind of thing) 💅

the set of TLVs (and sub-TLVs) that are allowed in each PDU type is written down in the "TLV Codepoints Registry" set up by [RFC3563] and updated by [RFC6233] and [RFC7356] 📚

this document is here to clarify some of the existing specs and cut down on the non-conformant behavior people see in the real world 🦋 it doesn't change what the existing protocol specs say, but the clarifications do work as updates to [RFC5305] (see Section 3.3) and [RFC6232] (see Section 3.4) 🫶

1.1. 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. 💜

2. TLV Codepoints Registry 📖

[RFC3563] set up the IANA-managed "IS-IS TLV Codepoints Registry" for recording assigned TLV codepoints [TLV_CODEPOINTS]. the first entries in this registry were based on [RFC3359] 🌈

the registry has a set of columns that show which PDU types a given TLV is allowed in:

  • IIH: the TLV is allowed in Intermediate System to Intermediate System Hello (IIH) PDUs (Point-to-point and LAN) 🌸
  • LSP: the TLV is allowed in Link State PDUs (LSPs) 🌸
  • SNP: the TLV is allowed in Sequence Number PDUs (SNPs), which covers Partial Sequence Number PDUs (PSNPs) and Complete Sequence Number PDUs (CSNPs) 🌸
  • Purge: the TLV is allowed in LSP Purges [RFC6233] 🌸

if "Y" is in a column, the TLV is allowed in that PDU type ✅

if "N" is in a column, the TLV is NOT allowed in that PDU type ❌

3. TLV Acceptance in PDUs 🎀

this section is all about the correct behavior when a PDU shows up with a TLV that the "TLV Codepoints Registry" marks as disallowed 👑

3.1. Handling of Disallowed TLVs in Received PDUs Other Than LSP Purges 💅

[ISO10589] spells out what happens when a PDU has a TLV that is "not recognised". it says (see Sections 9.5 - 9.13):

Any codes in a received PDU that are not recognised shall be ignored.

this is the model to follow when a disallowed TLV is received 🧚 so TLVs in a PDU (other than LSP purges) that are disallowed MUST be ignored and MUST NOT cause the PDU itself to be rejected by the receiving IS. no drama, just ignore it and keep going ✨

3.2. Special Handling of Disallowed TLVs in Received LSP Purges 🗑️

when purging LSPs, [ISO10589] recommends (but doesn't require) that the body of the LSP (aka all the TLVs) get removed before the purge is generated. LSP purges that have TLVs in the body still get accepted, though any TLVs that are there get ignored 🙈

when cryptographic authentication [RFC5304] came along, this looseness in how received purges were processed had to be tightened up. otherwise attackers could start a purge without having the authentication key, which is a huge security no-no 💀 so [RFC5304] put strict requirements on what TLVs are allowed in a purge (authentication only), and it specified that:

ISes MUST NOT accept purges that contain TLVs other than the authentication TLV.

[RFC6232] extended this behavior, introducing the Purge Originator Identification (POI) TLV. then [RFC6233] added the "Purge" column to the "TLV Codepoints Registry" so you can see every TLV that's allowed in purges 📋

the behavior in [RFC5304] isn't backwards compatible with the behavior defined in [ISO10589]. so it can only be safely turned on when all nodes support cryptographic authentication 🔐 same deal for [RFC6232]: its extensions aren't compatible with [RFC5304], so they can only be safely enabled when all nodes support those extensions 🫶

when new protocol behaviors that aren't backwards compatible get specified, it is RECOMMENDED that implementations provide controls for turning them on. this helps prevent interoperability issues and lets the new functionality roll out into an existing network without causing disruption.

3.3. Applicability to Sub-TLVs 🌷

[RFC5305] introduced sub-TLVs, which are TLV tuples advertised inside the body of a parent TLV. the registries for sub-TLVs are tied to the "TLV Codepoints Registry" and say which TLVs a given sub-TLV is allowed in 📚 Section 2 of [RFC5305] gets updated by this sentence:

As with TLVs, it is required that sub-TLVs that 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 Codepoints Registry" Entry 🛠️

there was an error introduced by [RFC6232] about which PDUs the POI TLV is allowed in 😬 Section 3 of [RFC6232] says:

The POI TLV SHOULD be found in all purges and MUST NOT be found in LSPs with a non-zero Remaining Lifetime.

but the IANA section of that same document says:

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 fixing that error 🩹

this document also updates the quoted text from Section 3 of [RFC6232] to say:

The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non-zero Remaining Lifetime.

to be continued... 🧚✨

6. Security Considerations 🔐

okay so bestie, this one is short and sweet 🍓 This document makes no changes to the protocol, so there are no new security issues introduced ✨ no cap, that's it.

The clarifications in here are meant to make it less likely that implementations will process received LSPs incorrectly 🧚 and that also makes it less likely that a bad actor could take advantage of a buggy implementation. Lowkey iconic, a fix that makes the whole network harder to exploit 💅

Security concerns for IS-IS are covered in [ISO10589], [RFC5304], and [RFC5310]. Go read those if you want the full security tea ☕💜

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

The authors would like to thank Alvaro Retana. Iconic behavior, honestly 👑

Authors' Addresses 🎀

Les Ginsberg (Cisco Systems)

Les Ginsberg
Cisco Systems

Email: ginsberg@cisco.com

Paul Wells (Cisco Systems)

Paul Wells
Cisco Systems

Email: pauwells@cisco.com

Tony Li (Arista Networks)

Tony Li
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
United States of America

Email: tony.li@tony.li

Tony Przygienda (Juniper Networks, Inc.)

Tony Przygienda
Juniper Networks, Inc.
1194 N. Matilda Ave
Sunnyvale, CA 94089
United States of America

Email: prz@juniper.net

Shraddha Hegde (Juniper Networks, Inc.)

Shraddha Hegde
Juniper Networks, Inc.
Embassy Business Park
Bangalore 560093
KA
India

Email: shraddha@juniper.net

That's the whole RFC, bestie! 🌈💖 Protocol girlies unite 🦋

📦 where this page comes from