Early Review of draft-ietf-teas-rsvp-auth-v2-00
review-ietf-teas-rsvp-auth-v2-00-secdir-early-emery-2025-11-11-00

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/