RSVP | Support Protocols

RSVP, short for the Resource ReSerVation Protocol, is a protocol designed to allow clients on networks to negotiate bandwidth to provide and maintain a high Quality of Service (QoS) for a specific connection. Normally, TCP/IP will make a best effort to route packets from one machine to another as quickly as possible. However, due to the dynamic routing of internetworking, where packets take completely different routes each time they are transmitted, this cannot be guaranteed. This creates a special issue for VoIP communication, which requires a high QoS to maintain seamless and non-interruptive communication between two people. VoIP can be an especially demanding protocol that requires long periods of high bandwidth and low latency, and without RSVP, these conditions may fall below acceptable levels which could result in a loss of quality or disconnections. RSVP allows a dedicated path across a network between each client so that packets are routed randomly around, which retains a high level of bandwidth, and less latency RSVP is especially useful for WAN connections within a global organization to maintain these set paths inside a network, as many Internet routers do not support the protocol.

The RSVP protocol was first described in RFC 2205 in late 1997. Further modifications were made to this RFC, and the best current practices for the RSVP protocol are now discussed in RFC 3936, created in late 2004. There are also other RFCs that describe additional extensions and uses for the RSVP protocol. These include RSVP for LSP Tunnels (RFC 3209) and RSVP security properties (RFC 4230).

RSVP Protocol

The RSVP protocol works by transferring UDP packets from the recipient of the data transfer to its sender. This allows the data recipient to control whether to use regular TCP/IP or to use a dedicated path of travel between the two clients. The connection recipient initiates this path by sending a constructed RSVP packet to the connection initiator. This packet will contain a specific Message Type that indicates the action that should be acted upon. The common Message Types for an RSVP protocol are

• Path
• Resv (Reservation Request)
• PathErr (Path Error)
• ResvErr (Reservation Error)
• PathTear (Path Teardown)
• ResvTear (Reservation Teardown)
• ResvConf (Reservation Confirmation)

The RSVP packet also carries a data payload containing specific information on how the path should be constructed. The payload contains information such as:

• Session (Destination IP, Tunnel ID, Extended Tunnel ID)
• Hop (the neighboring router’s IP)
• Time Values (the refresh interval)
• Explicit Route (a list of routers between the two devices that creates the data path)
• Adspec (specifies the minimum path latency, MTU, and bandwidth requirements)

RSVP Operation

To create a dedicated path of travel, the RSVP protocol relies heavily on its Path and Resv messages. The Path message packet is used to define the path of routers to be used for communication between the two clients. This packet is sent from the receiving end of the communication towards the sender. As it passes through each individual router, the router examines the packet to determine its neighboring IP addresses, to which it must route packets to. The Resv message, or Reservation request, is equally important. The Resv message is sent from each router to its neighboring router, one hop at a time. The Resv packet helps create the reservation on each router involved in the path. The transfer of Path and Resv packets is detailed in Figure 1.

 
Figure 1: Creating an RSVP Path

Once a path has been created, with each router maintaining a reservation for the data, it must be updated routinely to remain open. If a router has not received a Resv and Path packet before the refresh interval on the path has been exhausted, then the router will remove the reservation from itself. As Resv and Path packets arrive to maintain the reservation, they may also make changes to it. If the path between the clients is to change to substitute routers, the recipient just sends a new Path message with the updated path and it will become effective. Each router will continually update its stored information based on the packets it continually receives during the transmission.

Once the communication between the two devices has ended, they initiate a teardown of the path. Although, realistically they could just stop transmitting RSVP packets and eventually the reservations on the routers would expire, it is recommended that they formally tear down the path immediately after finishing the connection. The teardown may be initiated by either side of the communication, or from any of the routers within the communication. A PathTear packet may be sent downstream from the sender, or a ResvTear may be sent upstream from the receiver. As each router in the path receives a teardown packet, they will immediately remove the path reservation and forward the packet onto the next hop in the path.

Security Implications for RSVP

Many of the security issues with the RSVP protocol involve actions that a person with malicious intentions could take to either disrupt traffic or capture it. For one, as the Path and Resc packets are transmitted across the network, they each include a session ID that can be used to uniquely identify a particular RSVP session. This data is also sent as clear text, where anyone who is armed with a network sniffer can capture the data. Knowing the session ID, a person could then use the same session ID and send a Path message to one of the routers in the path. This new Path could alter the path of the network, leading the network transmission to a completely different client than intended. Or, it could be used to disrupt the communication completely, preventing an RSVP connection to take place between the two devices.

There are various solutions that have come about to resolve issues like this. For one, the Session ID could be encoded into a public key that will be included in each packet, as well as a timestamp that acts as a digital signature. If the two devices are within the same localized network, a third-party server could be used to establish the identities of each device. Many such security implications and solutions were drafted by various authors, including Hannes Tschofenig, in an Internet Draft located atwww.tschofenig.com/drafts/draft-ietf-nsis-rsvpsec-properties-06.txt.