RFC 3373

Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies

📅 published September 2002, from ietf

RFC 3373 💖 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies

Network Working Group 🎀

Request for Comments: 3373 🦋

Authors: D. Katz (Juniper Networks, Inc.) and R. Saluja (Tenet Technologies) 👑

Category: Informational 📚

Date: September 2002 📅

The title block doesn't list anything this RFC obsoletes or updates. 🙈

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🔥

okay so the IS-IS routing protocol (ISO 10589) needs reliable protocols at the link layer for point-to-point links. because of that, it doesn't do a three-way handshake when it sets up adjacencies on point-to-point media. this paper adds a backward-compatible extension to the protocol that does give you a three-way handshake. it's fully interoperable with systems that don't support the extension, so nobody gets left out 🫶

the extension also lets a single router run more than 256 point-to-point links, and it works robustly. iconic 👑

multiple router vendors have already implemented this extension. this paper is shared as information for the Internet community so other vendors can build interoperable implementations too 💅

1. Terms ✨

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14, RFC 2119. 📖

2. Introduction 🧚

okay bestie, so the IS-IS protocol [1] depends on some requirements from ISO 10589 (section 6.7.2) for running over point-to-point links. because of that, it only has a two-way handshake when it sets up adjacencies on point-to-point links. 😭 if those subnetwork requirements for point-to-point links aren't met, the protocol doesn't work correctly.

the basic mechanism in the standard is that each side declares the other side reachable once it hears a Hello packet from it. after that happens, each side sends a Complete Sequence Number PDU (CSNP) to kick off database synchronization. 🔄

three failure modes are known. 💀

First, the link goes down and comes back up, or one of the systems restarts. if the CSNP packet gets lost, and the network has a cut set of one through the link, the link state databases on either side won't synchronize for a full LSP refresh period (up to eighteen hours). not it 😩

A second, more serious failure happens when the link fails in only one direction. then only one of the two systems detects the failure. normally only one system announces the adjacency in its link state packets, so the SPF algorithm ignores the link. but if there are two parallel links between systems and one of them fails in one direction, SPF will still calculate paths between the two systems. the system that didn't notice the failure will try to send traffic down the failed link (in the direction that doesn't work). ngl this is so messy 🙈

The third issue is that on some physical layers, the interconnectivity between endpoints can change without causing a link-layer-down condition. when that happens, a system may receive packets that are actually meant for a different system (or a different link on the same system). the receiving system may end up thinking it has an adjacency with the remote system, when really the remote system is adjacent with a third system. 🌈

The solution in this paper keeps the protocol running correctly over unreliable point-to-point links. ✨ As part of solving the three-way handshaking issue, the paper also defines a method that removes the limit of 255 point-to-point interfaces that IS-IS [1] imposes. this method is more robust than the ad hoc methods people use right now. 👑

3. Overview of Extensions 🦋

3.1. Handshaking 🎀

the goal is to give point-to-point adjacency setup a three-way handshake, in a backward-compatible way. this is done with an optional mechanism that lets each system report its adjacency three-way state. this way, a system only declares an adjacency up when it knows the other system is receiving its IS-IS Hello (IIH) packets. it's giving careful 🫶

the adjacency three-way state can be one of the following:

  • Down: This is the initial point-to-point adjacency three-way state. The system hasn't received any IIH packet containing the three-way handshake option on this point-to-point circuit. 🍓
  • Initializing: The system has received an IIH packet containing the three-way handshake option from a neighbor, but it doesn't know whether the neighbor is receiving its IIH packet. 🌸
  • Up: The system knows that the neighbor is receiving its IIH packets. ✨

the three-way state this mechanism reports is not equal or equivalent to the adjacency state described in ISO 10589 [1]. if this mechanism is supported, an adjacency can have two states: its state as defined in ISO 10589 [1], and its three-way state. for example, under ISO 10589 [1], receiving an ISH moves an adjacency to Initializing state. but receiving an ISH has no effect on the three-way state of an adjacency. that one stays firmly Down until it receives an IIH from a neighbor that contains the three-way handshaking option. 💅

on top of that, the neighbor's system ID and the (newly-defined) extended circuit ID are reported. this detects the case where the same stream is being received by multiple systems, where only one of them can talk back. 🕵️‍♀️

this mechanism is pretty similar to the one in the Netware Link Services Protocol (NLSP) [2], which is a variant of IS-IS used for routing IPX traffic. the differences are where the information is carried (NLSP uses two of the reserved bits in the IIH header, while this solution adds a separate option to the IIH), and the presence of the neighbor's system ID and circuit ID. 🧠

in theory, using the reserved header bits should be backward compatible, since systems are supposed to ignore them. still, it was felt that this was risky, because untested mechanisms like that have caused problems in other protocols before. new option codes, on the other hand, have been shown to work properly, since the deployment of Integrated IS-IS for IP [3] did exactly that. 🌈

the new mechanism only kicks in when the remote system includes the new option in its IIH packet. if the option isn't there, the system is assumed not to support the new mechanism, so the old procedures are used. 🦋

3.2. More Than 256 Interfaces 👑

the IS-IS spec has an implicit limit of 256 interfaces, because of the eight bit Circuit ID field carried in various packets. 🔢 Clever implementors realized that the only true constraint is 256 LAN interfaces. and really, it's only 256 LAN interfaces for which a system is the Designated IS. that's because the circuit ID only gets advertised in LSPs in the pseudonode LSP ID. 🧚

implementors have treated the point-to-point Circuit ID number space as independent from the LAN interfaces. these Circuit IDs only show up in IIH PDUs and are only used to detect a change in identity at the other end of a link. so more than 256 point-to-point interfaces have been supported by sending the same circuit ID on multiple interfaces. but that makes the ID change detection algorithm less robust, since links could then be switched between interfaces on a system without the change being detected. 😬

since the Circuit ID is a core part of the new handshaking mechanism, this specification includes a backward-compatible way to expand the circuit ID number space. ✨

4. Details 🌸

4.1. Syntax 🎀

a new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is defined. 💖

x Type - 0xF0 (decimal 240)
x Length - total length of the value field (1 to 17 octets)
x Value -
                                                    No. of Octets
              +-----------------------------------+
              | Adjacency Three-Way State         |      1
              +-----------------------------------+
              | Extended Local Circuit ID         |      4
              +-----------------------------------+
              | Neighbor System ID                |      ID Length
              +-----------------------------------+
              | Neighbor Extended Local Circuit ID|      4
              +-----------------------------------+

Adjacency Three-Way State: the adjacency three-way state of the point-to-point adjacency. these values are defined:

0  - Up
1 -  Initializing
2 -  Down

Extended Local Circuit ID: a unique ID assigned to this circuit when it's created by this Intermediate system. 🧚

Neighbor System ID: the System ID of the neighbor Intermediate system, if known. the length of this field equals the "ID Length" of the IIH PDU described in the section "Point-to-point IS to IS hello PDU" (section 9.7 of [1]). 🔍

Neighbor Extended Local Circuit ID: the Extended Local Circuit ID of the other end of the point-to-point adjacency, if known. 🌈

any system that supports this mechanism SHALL include this option in its Point-to-Point IIH packets. 👑

any system that doesn't understand this option SHALL ignore it, and (of course) SHALL NOT include it in its own IIH packets. 💅

any system that supports this mechanism MUST include the Adjacency Three-Way State field in this option. the other fields in this option SHOULD be included, as explained below in section 3.2. 🫶

any system that is able to process this option SHALL follow the procedures below. ✨

4.2. Elements of Procedure ✨

Okay bestie, so the new handshake gets tucked into the IS-IS point-to-point IIH state machine, and it only kicks in after the PDU acceptance tests have run 🦋

Now, the extended circuit ID is only used in the three-way handshake, but it's lowkey a whole safety net 🧚 It guards against the unlikely (but very real 💀) situation where a link gets moved to another interface on a system that has the same local circuit ID. The received PDUs get ignored by the checks defined below, and the existing adjacency fails. Iconic defense, no notes 💅

Add a clause e) to the end of section "Receiving ISH PDUs by an intermediate system" (section 8.2.2 of [1]):

Set the state to be reported in the Adjacency Three-Way State field of the Point-to-Point Three-Way Adjacency option to Down.

Add a clause e) to the end of section "Sending point-to-point IIH PDUs" (section 8.2.3 of [1]):

The IS SHALL include the Point-to-Point Three-Way Adjacency option in the transmitted Point-to-Point IIH PDU. The current three-way state of the adjacency with its neighbor on the link (as defined in new section 8.2.4.1.1 introduced later in the document) SHALL be reported in the Adjacency Three-Way State field. If no adjacency exists, the state SHALL be reported as Down. The Extended Local Circuit ID field SHALL contain a value assigned by this IS when the circuit is created. This value SHALL be unique among all the circuits of this Intermediate System. The value is not necessarily related to that carried in the Local Circuit ID field of the IIH PDU. If the system ID and Extended Local Circuit ID of the neighboring system are known (in adjacency three-way state Initializing or Up), the neighbor's system ID SHALL be reported in the Neighbor System ID field, and the neighbor's Extended Local Circuit ID SHALL be reported in the Neighbor Extended Local Circuit ID field.

Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to section "IIH PDU Processing" (section 8.2.4.2 of [1]):

A received Point-to-Point IIH PDU may or may not contain the Point-to-Point Three-Way Adjacency option. If it does not, the link is assumed to be functional in both directions, and the procedures described in section 8.2.4.2 are followed. If the option is present and contains invalid Adjacency Three-Way State, the PDU SHALL be discarded and no further action is taken. If the option with a valid Adjacency Three-Way State is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, SHALL be examined. If they are present, and the Neighbor System ID contained therein does not match the local system's ID, or the Neighbor Extended Local Circuit ID does not match the local system's extended circuit ID, the PDU SHALL be discarded and no further action is taken. If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present, the procedures described in section 8.2.4.2 are followed with following changes: - a) In section 8.2.4.2 a and b, the action "Up" from state tables 5, 6, 7 and 8 may create a new adjacency but the three-way state of the adjacency SHALL be Down. - b) If the action taken from section 8.2.4.2 a or b is "Up" or "Accept", the IS SHALL perform the action indicated by the new adjacency three-way state table below, based on the current adjacency three-way state and the received Adjacency Three-Way State value from the option. (Note that the procedure works properly if neither field is ever included. This provides backward compatibility to an earlier version of this option.)
                          Received Adjacency Three-Way State
                            Down           Initializing          Up
                       -------------------------------------------------
         Down          |  Initialize            Up                Down
                       |
   adj   Initializing  |  Initialize            Up                Up
   three               |
   -way  Up            |  Initialize            Accept            Accept
   state               |
                       |

                     Adjacency Three-Way State Table
If the new action is "Down", an adjacencyStateChange(Down) event is generated with the reason "Neighbor restarted" and the adjacency SHALL be deleted. If the new action is "Initialize", no event is generated and the adjacency three-way state SHALL be set to "Initializing". If the new action is "Up", an adjacencyStateChange(Up) event is generated. - c) Skip section 8.2.4.2 c and d. - d) If the new action is "Initialize", "Up" or "Accept", follow section 8.2.4.2 e.

5. Security Considerations 🔒

This document raises no new security issues for IS-IS. Clean bill of health, bestie 🫶

6. References

  • [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992.
  • [2] "Netware Link Services Protocol Specification, Version 1.0", Novell, Inc., February 1994.
  • [3] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.

7. Acknowledgements 🌸

The authors would like to thank Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their contributions to this document. The whole squad, honestly 👑

8. Authors' Addresses 💌

Dave Katz
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089

Phone: (408) 745-2073
EMail:  dkatz@juniper.net


Rajesh Saluja
Tenet Technologies
30/31, 100 Feet Road, Madiwala
Bangalore - 560 068  INDIA

Phone: +91 80 552 2215
EMail: rajesh.saluja@tenetindia.com

Since this part is legal stuff, I'm keeping the wording exactly as written so nothing gets lost in translation 🙈

Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🌈

📦 where this page comes from