RFC 2747 (rfc2747) - Page 3 of 21
RSVP Cryptographic Authentication
Alternative Format: Original Text Document
RFC 2747 RSVP Cryptographic Authentication January 2000
The security associations in IPSEC are based on destination address.
It is not clear that RSVP messages are well defined for either source
or destination based security associations, as a router must forward
PATH and PATH TEAR messages using the same source address as the
sender listed in the SENDER TEMPLATE. RSVP traffic may otherwise not
follow exactly the same path as data traffic. Using either source or
destination based associations would require opening a new security
association among the routers for which a reservation traverses.
In addition, it was noted that neighbor relationships between RSVP
systems are not limited to those that face one another across a
communication channel. RSVP relationships across non-RSVP clouds,
such as those described in Section 2.9 of [1], are not necessarily
visible to the sending system. These arguments suggest the use of a
key management strategy based on RSVP router to RSVP router
associations instead of IPSEC.
2. Data Structures
2.1. INTEGRITY Object Format
An RSVP message consists of a sequence of "objects," which are type-
length-value encoded fields having specific purposes. The
information required for hop-by-hop integrity checking is carried in
an INTEGRITY object. The same INTEGRITY object type is used for both
IPv4 and IPv6.
The INTEGRITY object has the following format:
Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1
+-------------+-------------+-------------+-------------+
| Flags | 0 (Reserved)| |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
Baker, et al. Standards Track