RFC 5495

Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures

📅 published March 2009, from ietf

RFC 5495: Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures 🎀

Okay so this one is from the Network Working Group, filed as Request for Comments 5495 in March 2009 ✨. It's an Informational doc, which means it's here to explain stuff, not to set a new standard. It was written by D. Li (Huawei), J. Gao (Huawei), A. Satyanarayana (Cisco), and S. Bardalai (Fujitsu) 👑. The title block doesn't list any obsoletes or updates, so it doesn't replace or change any other RFC.

Status of This Memo

Real talk: this memo is just providing info for the Internet community. It is NOT an Internet standard of any kind 🙈 Distribution of it is unlimited, so share away 💅

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

This document falls under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were in effect on the date of publication (http://trustee.ietf.org/license-info). Please read those carefully, because they spell out your rights and restrictions for this document 📜

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Abstract

Okay, the Hello message for the Resource Reservation Protocol (RSVP) was defined to set up and keep up basic signaling node adjacencies for Label Switching Routers (LSRs) in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network 🦋 The Hello message was then extended for Generalized MPLS (GMPLS) networks so it can recover state after a control channel or nodal fault 🔥

The GMPLS protocol definitions for RSVP also let a restarting node figure out which label it had previously allocated for use on a Label Switched Path (LSP) ✨

Further RSVP protocol extensions let a restarting node recover its full control plane state by swapping RSVP messages with its upstream and downstream neighbors 🫶

This document is an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures. It also describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different. Main character energy 👑

This document does not define any new processes or procedures. All of the protocol mechanisms are already defined in the referenced documents 💀

Table of Contents

   1. Introduction ....................................................3
   2. Existing Procedures for Single Node Restart .....................4
      2.1. Procedures Defined in RFC 3473 .............................4
      2.2. Procedures Defined in RFC 5063 .............................5
   3. Multiple Node Restart Scenarios .................................6
   4. RSVP State ......................................................7
   5. Procedures for Multiple Node Restart ............................7
      5.1. Procedures for the Normal Node .............................8
      5.2. Procedures for the Restarting Node .........................8
           5.2.1. Procedures for Scenario 1 ...........................8
           5.2.2. Procedures for Scenario 2 ...........................9
           5.2.3. Procedures for Scenario 3 ..........................11
           5.2.4. Procedures for Scenario 4 ..........................12
           5.2.5. Procedures for Scenario 5 ..........................12
      5.3. Consideration of the Reuse of Data Plane Resources ........12
      5.4. Consideration of Management Plane Intervention ............13
   6. Clarification of Restarting Node Procedure .....................13
   7. Security Considerations ........................................15
   8. Acknowledgments ................................................16
   9. References .....................................................17
      9.1. Normative References ......................................17
      9.2. Informative References ....................................17

1. Introduction ✨

The Hello message for the Resource Reservation Protocol (RSVP) was defined to set up and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) taking part in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network [RFC3209]. The Hello message was extended for Generalized MPLS (GMPLS) networks so it can recover state after a control channel or nodal fault, using the exchange of the Restart_Cap Object [RFC3473] 🎀

The GMPLS protocol definitions for RSVP [RFC3473] also let a restarting node learn which label it had previously allocated for use on a Label Switched Path (LSP). It finds this out through the Recovery_Label Object, which is carried on a Path message that the upstream neighbor sends to the restarting node 🦋

Further RSVP protocol extensions were defined [RFC5063] to perform graceful restart and to let a restarting node recover its full control plane state by swapping RSVP messages with its upstream and downstream neighbors. The state previously sent to the upstream neighbor (mainly the downstream label) gets recovered from that neighbor in a Path message, using the Recovery_Label Object as described in [RFC3473]. The state previously sent to the downstream neighbor (including the upstream label, interface identifiers, and the explicit route) gets recovered from that neighbor using a RecoveryPath message 🧚

[RFC5063] also extends the Hello message so nodes can exchange info about whether they can support the RecoveryPath message 🌈

The examples and procedures in [RFC3473] and [RFC5063] focus on describing a single node restart when the adjacent network nodes are operative. The procedures are equally applicable to multi-node restarts, but no detailed explanation is given for that case 🙈

This document is an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures. It also describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different 💜

This document does not define any new processes or procedures. Every protocol mechanism already defined in [RFC3473] and [RFC5063] is definitive 🫶

2. Existing Procedures for Single Node Restart 🌸

This section documents, for information only, the existing procedures defined in [RFC3473] and [RFC5063]. Those documents are the definitive ones, and the description here is non-normative. It's provided purely for informational clarification 🎀

2.1. Procedures Defined in RFC 3473

For nodal faults, the procedures for the restarting node and the procedures for the neighbor of a restarting node get applied to the matching nodes. These procedures, described in [RFC3473], go like this 💅

For the Restarting Node:

  1. Tells its neighbors that state recovery is supported, using the Hello message.
  2. Recovers its RSVP state with the help of a Path message, received from its upstream neighbor, that carries the Recovery_Label Object.
  3. For bidirectional LSPs, uses the Upstream_Label Object on the received Path message to recover the matching RSVP state.
  4. If the matching forwarding state in the data plane does not exist, the node treats this as a setup for a new LSP. If the forwarding state in the data plane does exist, that forwarding state is bound to the LSP associated with the message, and the related forwarding state should be considered valid and refreshed. Also, if the node is not the tail-end of the LSP, the incoming label on the downstream interface is retrieved from the forwarding state on the restarting node and set in the Upstream_Label Object in the Path message sent to the downstream neighbor 🔥

For the Neighbor of a Restarting Node:

  1. Sends a Path message with the Recovery_Label Object containing a label value that matches the label value received in the most recently received corresponding Resv message.
  2. Resumes refreshing Path state with the restarting node.
  3. Resumes refreshing Resv state with the restarting node.

2.2. Procedures Defined in RFC 5063

[RFC5063] introduces a new message called the RecoveryPath message. The downstream neighbor of a restarting node sends this message to convey the contents of the last received Path message back to the restarting node 🦋

The restarting node receives the Path message with the Recovery_Label Object from its upstream neighbor, and/or the RecoveryPath message from its downstream neighbor. The restarting node's full RSVP state can be recovered from these two messages 🌈

The following state can be recovered from the received Path message:

  • Upstream data interface (from RSVP_Hop Object)
  • Label on the upstream data interface (from Recovery_Label Object)
  • Upstream label for bidirectional LSP (from Upstream_Label Object)

The following state can be recovered from the received RecoveryPath message:

  • Downstream data interface (from RSVP_Hop Object)
  • Label on the downstream data interface (from Recovery_Label Object)
  • Upstream direction label for bidirectional LSP (from Upstream_Label Object)

The other objects that were originally exchanged on Path and Resv messages can be recovered from the regular Path and Resv refresh messages, or from the RecoveryPath 🧚

3. Multiple Node Restart Scenarios ✨

okay so first, the vocab 🫶 we need these terms for each node type:

  • Restarting - the node has restarted 🔄. Communication with its neighbor nodes is restored, and its RSVP state is under recovery.
  • Delayed Restarting - the node has restarted, but communication with a neighbor node is interrupted 😬 (for example, the neighbor node needs to restart).
  • Normal - the normal node is the fully operational neighbor of a restarting or delayed restarting node 💅.

there are five scenarios for multi-node restart 🦋. we're focusing on where the restarting node sits. in Figure 1, an LSP starts at Node A, goes through Nodes B and C, and ends at Node D 🛤️

      +-----+  Path  +-----+  Path  +-----+  Path  +-----+
      | PSB |------->| PSB |------->| PSB |------->| PSB |
      |     |        |     |        |     |        |     |
      | RSB |<-------| RSB |<-------| RSB |<-------| RSB |
      +-----+  Resv  +-----+  Resv  +-----+  Resv  +-----+
      Node A         Node B         Node C         Node D

               Figure 1: Two Neighbor Nodes Restart
  1. A restarting node with downstream delayed restarting node. For example, in Figure 1, Nodes A and D are normal nodes, Node B is a restarting node, and Node C is a delayed restarting node.
  2. A restarting node with upstream delayed restarting node. For example, in Figure 1, Nodes A and D are normal nodes, Node B is a delayed restarting node, and Node C is a restarting node.
  3. A restarting node with downstream and upstream delayed restarting nodes. For example, in Figure 1, Node A is a normal node, Nodes B and D are delayed restarting nodes, and Node C is a restarting node.
  4. A restarting ingress node with downstream delayed restarting node. For example, in Figure 1, Node A is a restarting node and Node B is a delayed restarting node. Nodes C and D are normal nodes.
  5. A restarting egress node with upstream delayed restarting node. For example, in Figure 1, Nodes A and B are normal nodes, Node C is a delayed restarting node, and Node D is a restarting node.

if the link between two nodes gets interrupted 📡, the upstream node may think the downstream node is a delayed restarting node, or vice versa. classic mix-up, iykyk 🙈

also, if multiple nodes that aren't neighbors restart, the restart procedures can be applied as multiple separate restart procedures that work exactly like the ones in [RFC3473] and [RFC5063]. so these scenarios aren't described in this document 🙌. for example, in Figure 1, Node A and Node C are normal nodes, and Node B and Node D are restarting nodes. so Node B could be restarted through Node A and Node C, while Node D could be restarted through Node C separately 🧚

4. RSVP State 🎀

for each scenario, the RSVP state that needs recovering at the restarting nodes is the Path State Block (PSB) and Resv State Block (RSB). they get created when the node receives the matching Path message and Resv message 💜

according to [RFC2209], how you build the PSB and RSB is really an implementation issue 🛠️. honestly there's no requirement to keep PSB and RSB as separate data structures. in GMPLS, Path and Resv state are way more tightly tied, so you can combine the info into one state block (the LSP state block) ✨. on the other hand, if point-to-multipoint is supported, it may be convenient to keep upstream and downstream state separate. and fyi, the PSB and RSB are not upstream and downstream state, because the PSB is the one receiving a Path from upstream and sending a Path downstream 🤓

no matter how you implement it, on recovery there are two logical pieces of state to recover, and they line up with the PSB and RSB 💖

5. Procedures for Multiple Node Restart 👑

in this document, all the nodes are assumed to have the graceful restart capabilities described in [RFC3473] and [RFC5063] 🫶

5.1. Procedures for the Normal Node

when the downstream normal node notices its neighbor restarting, it must send a RecoveryPath message for each LSP associated with the restarting node, as long as it previously sent a Resv message for that LSP and it hasn't been torn down 📨

when the upstream normal node notices its neighbor restarting, it must send a Path message carrying a Recovery_Label Object. the label value in that object matches the label value from the most recently received corresponding Resv message 🏷️

this document doesn't change the normal node procedures, which are described in [RFC3473] and [RFC5063] 💅

5.2. Procedures for the Restarting Node

this document doesn't change the restarting node procedures either. those are described in [RFC3473] and [RFC5063] 🙌

5.2.1. Procedures for Scenario 1

after the restarting node restarts, it starts a Recovery Timer ⏲️. any RSVP state that hasn't been resynchronized by the time the Recovery Timer expires should be cleared 🧹

at the restarting node (Node B in the example), full resynchronization with the upstream neighbor (Node A) is possible, because Node A is a normal node 🥰. the upstream Path info gets recovered from the Path message received from Node A. Node B also recovers the upstream Resv info (the stuff it previously sent to Node A) from the Recovery_Label Object carried in that Path message. but obviously, some info (like the Recorded_Route Object) will be missing from the new Resv message Node B generates, and it can't be supplied until the downstream delayed restarting node (Node C) restarts and sends a Resv 😭

after Node B has recovered the upstream Path and upstream Resv info, the normal refresh procedure with upstream Node A should be started 🔁

as per [RFC5063], the restarting node (Node B) would normally expect to receive a RecoveryPath message from its downstream neighbor (Node C). it would use that to recover the downstream Path info, then send a Path message to its downstream neighbor and receive a Resv message back. but in this scenario, the downstream neighbor hasn't restarted yet, so Node B detects that communication with Node C is interrupted and has to wait before resynchronizing with its downstream neighbor ⏳

in this case, the restarting node (Node B) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the downstream neighbor (Node C) to restart. if Node C hasn't restarted before that timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. one thing to note though 👀: the Restart Time value suggested in [RFC3473] is based on the previous Hello message exchanged with the node that hasn't restarted yet (Node C). since that time value is unlikely to be available to the restarting node (Node B), a configured time value must be used if the timer is operated ⚙️

the RSVP state must be reconciled with the retained data plane state if the cross-connect info can be retrieved from the data plane 🔍. if there are any mismatches, local policy decides what happens next, which could include:

  • reprogramming the data plane
  • sending an alert to the management plane
  • tearing down the control plane state for the LSP

if the delayed restarting node never comes back and no Restart Timer is used to automatically tear down LSPs, the LSPs can be tidied up through the control plane using a PathTear from the upstream node (Node A) 🧼. but note that if Node C restarts after this operation, the RecoveryPath message it sends to Node B won't match any state on Node B. it will get a PathTear as its response, which tears down the LSP at all downstream nodes 💀

5.2.2. Procedures for Scenario 2

in this case, the restarting node (Node C) can recover full downstream state from its downstream neighbor (Node D), which is a normal node 🙌. the downstream Path state can be recovered from the RecoveryPath message sent by Node D. that lets Node C send a Path refresh message to Node D, and Node D responds with a Resv message, so Node C can rebuild the downstream Resv state 🧩

after Node C has recovered the downstream Path and downstream Resv info, the normal refresh procedure with downstream Node D should be started 🔁

the restarting node would normally expect to resynchronize with its upstream neighbor to re-learn the upstream Path and Resv state. but here, the upstream neighbor (Node B) hasn't restarted yet, so the restarting node (Node C) detects that communication with Node B is interrupted 😬. Node C follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the upstream neighbor (Node B) to restart. if Node B hasn't restarted before the Restart Timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. again, the Restart Time value suggested in [RFC3473] is based on the previous Hello message exchanged with the node that hasn't restarted yet (Node B). since that time value is unlikely to be available to the restarting node (Node C), a configured time value must be used if the timer is operated ⏱️

note that no Resv message is sent to the upstream neighbor (Node B), because it hasn't restarted 🙅‍♀️

the RSVP state must be reconciled with the retained data plane state if the cross-connect info can be retrieved from the data plane 🔍

if there are any mismatches, local policy decides the action that must be taken, which could include:

  • reprogramming the data plane
  • sending an alert to the management plane
  • tearing down the control plane state for the LSP

if the delayed restarting node never comes back and no Restart Timer is used to automatically tear down LSPs, the LSPs can't be tidied up through the control plane using a PathTear from the upstream node (Node A), because there's no control plane connectivity to Node C from the upstream direction 🚫. there are two possibilities in [RFC3473]:

  • management action may be taken at the restarting node to tear the LSP. this removes the LSP from Node C and sends a PathTear downstream to Node D.
  • management action may be taken at any downstream node (for example, Node D). this results in a PathErr message with the Path_State_Removed flag set being sent to Node C to tear the LSP state 🧹

note that if Node B restarts after this operation, the Path message it sends to Node C won't match any state on Node C. it gets treated as a new Path message, which results in LSP setup 🌱. Node C should use the labels carried in that Path message (in the Upstream_Label Object and in the Recovery_Label Object) to drive its label allocation, but it may use other labels according to normal LSP setup rules 🏷️

5.2.3. Procedures for Scenario 3 🧩

Okay so in this one, the restarting node (Node C) is totally isolated 🥺. Its upstream and downstream neighbors have not restarted, so it's kinda on its own. 💔

The restarting node (Node C) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer for each of its neighbors (Nodes B and D). If a neighbor hasn't restarted before its Restart Timer expires, the matching LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time values suggested in [RFC3473] are based on the previous Hello message exchanged with the nodes that haven't restarted yet. Since those time values are unlikely to be available to the restarting node (Node C), a configured time value must be used if the timer is operated. ⏱️

During the Recovery Time, if the upstream delayed restarting node has restarted, the procedure for scenario 1 can be applied. 🦋

During the Recovery Time, if the downstream delayed restarting node has restarted, the procedure for scenario 2 can be applied. 🌸

Now for the worst case 😭. If neither delayed restarting node ever comes back, and a Restart Timer isn't used to automatically tear down LSPs, then management intervention is required to tidy up the control plane and the data plane on the node that's waiting for the failed device to restart. Someone has to go in and clean up by hand. 🧹

If the downstream delayed restarting node restarts after the cleanup of LSPs at Node C, the RecoveryPath message from Node D will be responded to with a PathTear message. 🙃

If the upstream delayed restarting node restarts after the cleanup of LSPs at Node C, the Path message from Node B will be treated as a new LSP setup request. But the setup will fail because Node D can't be reached, so Node C will respond with a PathErr message. 💀 Since this happens to Node B during its restart processing, it should follow the rules of [RFC5063] and tear down the LSP. 💅

5.2.4. Procedures for Scenario 4 🎀

When the ingress node (Node A) restarts, it doesn't know which LSPs it caused to be created. Usually though, this info gets pulled from the management plane, or from the configuration requests stored in non-volatile form in the node, so it can recover the LSP state. 🗂️

Also, if the downstream node (Node B) is a normal node, then according to the procedures in [RFC5063], the ingress will receive a RecoveryPath message and will understand that it was the ingress of the LSP. ✨

Here though, the downstream node is a delayed restarting node 😬. So Node A must either rely on the information from the management plane or stored configuration, or it must wait for Node B to restart. Waiting is a vibe, but it's not always an option. ⏳

In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP control plane state restored from the management plane or from local configuration, and to release any data plane resources. 🧽

5.2.5. Procedures for Scenario 5 🌈

In this scenario, the egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. 🥹 In this case, the egress node may have no control plane state relating to the LSPs. It has no downstream neighbor to help it, and no management plane or configuration information, even though there will be data plane state for the LSP. 🫠

So the egress node must simply wait until its upstream neighbor restarts and gives it the information in Path messages carrying Recovery_Label Objects. Patience, bestie 🧘‍♀️💜.

5.3. Consideration of the Reuse of Data Plane Resources 🔌

Here's the foundation of everything above 🏛️: data plane resources may remain in use (allocated and cross-connected) when control plane state hasn't been fully resynchronized, because some control plane nodes haven't restarted. It's giving "the hardware is still busy, don't touch it." 🙅‍♀️

It's assumed that these data plane resources might be carrying traffic, so they should not be reconfigured except through application of operator-configured policy, or as a direct result of operator action. 🚦

In particular, new LSP setup requests from the control plane or the management plane should not be allowed to use data plane resources that are still in use. Specific action must first be taken to release the resources. No sneaking in. 🥷

5.4. Consideration of Management Plane Intervention 🛠️

The management plane must always retain the ability to control data plane resources and to override the control plane. 👑 In this context, the management plane must always be able to release data plane resources that were previously in place for use by control-plane-established LSPs. Further, the management plane must always be able to instruct any control plane node to tear down any LSP. It's the boss energy 💅.

Operators should be aware of the risks of misconnection that could be caused by careless manipulation from the management plane of in-use data plane resources. ⚠️ Handle with care, bestie.

6. Clarification of Restarting Node Procedure 🔁

According to the current graceful restart procedure [RFC3473], after a node restarts its control plane, it needs its upstream node to send a PATH message with a recovery label in order to synchronize its RSVP state. 🔄 But if the restarted control plane becomes operational quickly, the upstream node may not detect that the downstream node restarted. So it may send a PATH message without a recovery label, and that causes errors and unwanted connection deletion. 😱

  N1               N2
  |                |
  |                X (Restart start)
  | HELLO          |
  |--------------->|
  |                |
  | SRefresh       |
  |--------------->|
  |                |
  | HELLO          |
  |--------------->|
  |                |
  |                X (Restart complete)
  | SRefresh       |
  |--------------->|
  | NACK           |
  |<---------------|
  | Path without   |
  | recovery label |
  |--------------->|
  |                X (resource allocation failed because the
  |                | resources are in use)
  |  PathErr       |
  |<---------------|
  |  PathTear      |
  |--------------->|
  X(LSP deletion)  X (LSP deletion)
  |                |

         Figure 2: Message Flow for Accidental LSP Deletion

The sequence diagram above shows one scenario where the LSP may get deleted. 🎬

Here's the tea ☕. N1 doesn't detect the Hello failure, so it keeps sending SRefreshes. Those may get NACK'ed by N2 once the restart completes, because there's no Path state corresponding to the SRefresh message. That NACK causes a Path refresh message to be generated. But there's no Recovery_Label, because N1 doesn't yet detect that N2 has restarted, since Hello exchanges haven't started yet. So the Path message is treated as "new" and fails to allocate the resources, because they're still in use. 😩 This causes a PathErr message to be generated, which may lead to the teardown of the LSP. 💔

To resolve this aforementioned problem, the following procedures should be followed. They're implicit in [RFC3473] and [RFC5063], so this is really just making them explicit 📝. These procedures work together with the recovery procedures documented in [RFC3473]. Here, it's assumed that the restarting node and the neighboring node(s) support the Hello extension as documented in [RFC3209], as well as the recovery procedures documented in [RFC3473]. 🤝

After a node restarts its control plane, it should ignore and silently drop all RSVP-TE messages (except Hello messages) it receives from any neighbor to which no HELLO session has been established. 🙈

The restarting node should follow [RFC3209] to establish Hello sessions with its neighbors, after its control plane becomes operational. 🫡

The restarting node resumes processing of RSVP-TE messages sent from each neighbor to which the Hello session has been established. ✅

7. Security Considerations 🔐

This document clarifies the procedures defined in [RFC3473] and [RFC5063] to be performed on RSVP agents that neighbor one or more restarting RSVP agents. It doesn't introduce any new procedures, so it doesn't introduce any new security risks or issues. 🧁

For the control plane in general, and the RSVP agent in particular, there's a bigger story. Where one or more nodes carrying one or more LSPs are restarted due to external attacks, the procedures defined in [RFC5063] and described in this document let the restarting RSVP agents recover the RSVP state in each restarting node corresponding to the LSPs, with the least possible perturbation to the rest of the network. 🛡️ These procedures can be considered to provide mechanisms by which the GMPLS network can recover from physical attacks or from attacks on remotely controlled power supplies. ⚡

The procedures described are such that only the neighboring RSVP agents should notice the restart of a node, and so only they need to perform additional processing. This lets a network with active LSPs recover LSP state gracefully from an external attack, without perturbing the data/forwarding plane state and without propagating the error condition in the control or data plane. 🌊 In other words, the effect of the restart (which might be the result of an attack) doesn't spread into the network. 🙌

Note that concern has been expressed about the vulnerability of a restarting node to false messages received from its neighbors. For example, a restarting node might receive a false Path message with a Recovery_Label Object from an upstream neighbor, or a false RecoveryPath message from its downstream neighbor. This situation might arise in one of four cases:

  • The message is spoofed and does not come from the neighbor at all.
  • The message has been modified as it was traveling from the neighbor.
  • The neighbor is defective and has generated a message in error.
  • The neighbor has been subverted and has a "rogue" RSVP agent. 😈

The first two cases may be handled using standard RSVP authentication and integrity procedures [RFC3209], [RFC3473]. If the operator is particularly worried, the control plane may be operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]. 🔒

Protection against defective or rogue RSVP implementations is generally hard-to-impossible. 😭 Neighbor-to-neighbor authentication and integrity validation is, by definition, ineffective in these situations.

For example, if a neighbor node sends a Resv during normal LSP setup, and if that message carries a Generalized_Label Object with an incorrect label value, then the receiving LSR will use the supplied value and the LSP will be set up incorrectly. 🫣 Alternatively, if a Path message is modified by an upstream LSR to change the destination and explicit route, there's no way for the downstream LSR to detect this, and the LSP may be set up to the wrong destination. Furthermore, the upstream LSR could disguise this fact by modifying the recorded route reported in the Resv message. 🕵️‍♀️ Thus, these issues are in no way specific to the restart case, don't cause any greater or different problems from the normal case, and don't warrant specific security measures applicable to restart scenarios. 🧠

Note that the RSVP Policy_Data Object [RFC2205] provides a scope by which secure end-to-end checks could be applied. However, very little definition of the use of this object has been made to date. 🫥

See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS networks. 📚

8. Acknowledgments 💌

We would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou Berger for their useful comments. 🫶🌟

9. References 📖

The reference list didn't come through in this chunk of the text, so it isn't rewritten here. 🙏

9.1. Normative References

okay so these are the must-read ones 📚 Without them the spec doesn't really make sense, so they're "normative" (aka required reading, bestie 💅)

   [RFC2209]  Braden, R. and L. Zhang, "Resource ReSerVation Protocol
              (RSVP) -- Version 1 Message Processing Rules", RFC 2209,
              September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation
              Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
              3473, January 2003.

   [RFC5063]  Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to
              GMPLS Resource Reservation Protocol (RSVP) Graceful
              Restart", RFC 5063, October 2007.

9.2. Informative References

these ones are the extra context list 🦋 helpful for the vibes and the backstory, but the spec doesn't need them to function. the security one is giving serious energy 🔥

   [MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS
              Networks", Work in Progress, November 2008.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2411]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
              Document Roadmap", RFC 2411, November 1998.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4306]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
              Protocol", RFC 4306, December 2005.

   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4835, April 2007.

Authors' Addresses ✨

and here are the brilliant minds who wrote this thing 🫶 Four people, two companies, one very good spec 🌸

   Dan Li
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base,
   Shenzhen 518129, China

   Phone: +86 755 28970230
   EMail: danli@huawei.com
   Jianhua Gao
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base,
   Shenzhen 518129, China

   Phone: +86 755 28972902
   EMail: gjhhit@huawei.com
   Arun Satyanarayana
   Cisco Systems
   170 West Tasman Dr
   San Jose, CA 95134, USA

   Phone: +1 408 853-3206
   EMail: asatyana@cisco.com
   Snigdho C. Bardalai
   Fujitsu Network Communications
   2801 Telecom Parkway
   Richardson, Texas 75082, USA

   Phone: +1 972 479 2951
   EMail: snigdho.bardalai@us.fujitsu.com

that's the whole thing, bestie! 🌈✨ you made it through the entire RFC 🎀 iconic behavior 👑

📦 where this page comes from