RFC 3097 (rfc3097) - Page 2 of 4

RSVP Cryptographic Authentication -- Updated Message Type Value

RFC 3097           RSVP Cryptographic Authentication          April 2001


2. Modification

   Message Types defined in the RSVP Integrity extension [RFC 2747]
   shall be changed as follows:

      o Challenge message has Message Type 25.
      o Integrity Response message has Message Type 25+1.

3. Compatibility

   Two communicating nodes whose Integrity implementations are
   conformant with this modification will interoperate, using Message
   Type 12 for Bundle messages and Message Types 25 and 26 for the
   Integrity handshake.  A non-conformant implementation of the
   Integrity extension will not interoperate with a conformant
   implementation (though two non-conformant implementations can
   interoperate as before).

   There is no possibility of an Integrity handshake succeeding
   accidentally due to this change, since both sides of the handshake
   use the new numbers or the old numbers.  Furthermore, the Integrity
   Response message includes a 32-bit cookie that must match a cookie in
   the Challenge message, else the challenge will fail.  Finally, a
   non-conformant implementation should never receive a Bundle message
   that it interprets as an Integrity Response message, since RFC 2961
   requires that Bundle messages be sent only to a Bundle-capable node.

4. References

   [RFC 2747]  Baker, F., Lindell, R. and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [RFC 2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, April 2001.

Security Considerations

   No new security considerations are introduced beyond RFC 2747 itself
   and the compatibility issues above.











Braden & Zhang              Standards Track