Browse Prior Art Database

RSVP Cryptographic Authentication -- Updated Message Type Value (RFC3097)

IP.com Disclosure Number: IPCOM000005292D
Original Publication Date: 2001-Apr-01
Included in the Prior Art Database: 2001-Aug-21
Document File: 5 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Braden: AUTHOR [+2]

Abstract

This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 55% of the total text.

Network Working Group R. Braden Request for Comments: 3097 ISI Updates: 2747 L. Zhang Category: Standards Track UCLA

April 2001

RSVP Cryptographic Authentication

Updated Message Type Value

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages.

1. Introduction

RFC 2747 ("RSVP Cryptographic Authentication") [RFC2747] assigns RSVP Message Type 12 to an Integrity Response message, while RFC 2961 ("RSVP Refresh Overhead Reduction Extensions") [RFC2961] assigns the same value to a Bundle message. This memo resolves the conflict over RSVP Message Type 12 by assigning a different value to the Message Type of the Integrity Response Message in RFC 2747. It is believed that the protocol defined by RFC 2961 entered use in the field before the RFC's publication and before the conflicting Message Type was noticed, and that it may be easier to install new software in environments that have deployed the Integrity object than in those that have deployed the refresh reduction extension.

To simplify possible interoperability problems caused by this change, we also assign a new value to the Message Type of RFC 2747's Challenge message, to which the Integrity Response message is a reply.

Braden Zhang Standards Track [Page 1]

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

[RFC2747] Baker,...