I have reviewed this document as part of the early review process.  Document editors and WG chairs should treat these comments just like any other early review comments.

This standards track draft specifies a mechanism for authentication and integrity protection of messages of the Resource ReSerVation Protocol (RSVP), where routers and hosts share state information of the underlying network.

This security considerations section does exist and describes that this protocol is algorithm agnostic for the authentication of RSVP messages and therefore defers to the security properties to those of the utilized algorithm.  They disclose that the messages are not confidential and subject to traffic analysis as designed, but defer to protocols, such as IEEE 802.1 MAC Security, to provide confidentiality for hop-to-hop connectivity.  I agree with these assertions.  HMAC-MD5 is the only initial registry entry specified in this draft.  Fortunately, there is another draft, draft-ietf-teas-rsvp-hmac-sha2, that specifies HMAC-SHA2.

For the pathological event, why does the RSVP Security Association (SA) have an infinite lifetime in this scenario?  If it's to preserve backwards compatibility then why not provision an option where administrators can disable infinite lifetime SAs once the infrastructure deploys the new version of the protocol?  It seems, in its current state, that triggering a pathological event would be considered as a high value attack.

Why does a manually entered RSVP Security Association lifetime MAY be used forever?  Again, this seems like a high value attack, if manually RSVP SAs can be created, including the RSVP Cryptographic Transform, RSVP Authentication Key, etc., then an attacker would always manually create an SA.  If I'm misinterpreting the feasibility or scope of these elements of the specification then having text mitigating these concerns could be beneficial to the reader.

General Comments:

None.

Editorial Comment:

s/result are padding/result are padded/