Invalid TLV Handling in IS-IS
updates
Extracted elements (20)
PDU validation must be independent from TLV validation because the unit of flooding for the IS-IS Update process is the entire LSP. Rejecting an LSP due to an invalid TLV would cause inconsistent LSP Databases across nodes, compromising correct protocol operation.
RFC 5304 introduced strict purge TLV restrictions (authentication TLV only) to prevent attackers from initiating purges without the authentication key, addressing a security hole created by the original loose ISO 10589 purge handling.
The ISO 10589 model of ignoring unrecognized codes is deliberately applied to disallowed TLVs as well, not just unknown ones, because extensibility requires that new TLVs added to PDU types do not break older implementations that have not yet been updated.
RFC 6232 erroneously set the LSP column to 'y' for the Purge Originator Identification (POI) TLV in the IANA section, contradicting the normative text which states the POI TLV MUST NOT be found in LSPs with a non-zero Remaining Lifetime. The correct value is 'n'.
RFC 6232 Section 3 used the phrase 'found in' for the POI TLV requirement; this document corrects it to 'sent in' to better reflect the intent: 'The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non-zero Remaining Lifetime.'
LSP purge handling has evolved through multiple incompatible specifications: ISO 10589 allows TLVs in purges (just ignores them), RFC 5304 restricted purges to authentication TLV only, and RFC 6233/6232 further extended allowed purge TLVs. Each change is not backwards compatible with the prior behavior.
PDU validation and TLV validation must be independent: PDUs that are valid must be accepted even if an individual contained TLV is not understood or is invalid in some way (incorrect syntax, data value out of range, etc.).
The strict purge TLV restriction from RFC 5304 (authentication TLV only) can only be safely enabled when all nodes support cryptographic authentication; similarly RFC 6232 extensions require all nodes to support those extensions.
Receiving nodes MUST verify that a TLV conforms to the standard definition when making use of its encoded information, including cases where the length is incorrect or the value field does not conform to defined restrictions.
Sub-TLVs that are disallowed MUST be ignored on receipt. This updates RFC 5305 Section 2 to strengthen 'are to be ignored' to MUST.
The definition of a TLV's correct format MUST include what action to take when the format/content does not conform to the specification (e.g., 'MUST be ignored on receipt').
The presence of a TLV (or sub-TLV) with content that does not conform to the relevant specification MUST NOT cause the LSP itself to be rejected. Failure to follow this will result in inconsistent LSP Databases across the network.
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.
Unknown sub-TLVs MUST be ignored and skipped upon receipt. This replaces the previous weaker 'are to be ignored and skipped' language in RFC 5305 Section 2.
When new protocol behaviors are specified that are not backwards compatible, it is RECOMMENDED that implementations provide controls for their enablement to prevent interoperability issues.
IS-IS uses TLV encoding for all content in PDU bodies, and new extensions are supported by defining new TLVs. Implementations must ignore TLVs they do not understand, and this applies equally to sub-TLVs contained within TLVs.
Sub-TLVs, introduced by RFC 5305, are TLV tuples advertised within the body of a parent TLV. Registries associated with sub-TLVs specify in which parent TLVs a given sub-TLV is allowed.
The IS-IS TLV Codepoints Registry tracks which TLV types are allowed in each PDU type (IIH, LSP, SNP, Purge), with 'Y' meaning allowed and 'N' meaning disallowed. Established by RFC 3563, updated by RFC 6233 and RFC 7356.
The IS-IS TLV Codepoints Registry (established by RFC 3563) is updated by this document: the POI TLV entry is corrected to IIH:n, LSP:n, SNP:n, Purge:y, and this document is added as a reference for the registry.
The clarifications in this document are intended to make it less likely that implementations will incorrectly process received LSPs, thereby making it less likely that a bad actor could exploit a faulty implementation. No new security issues are introduced.