[RTG-DIR]Re: draft-ietf-teas-rsvp-auth-v2-02 early Rtgdir review

[Tony Li <[e-mail]>]

Hi Carlos,

Please see inline.


> From: "Carlos Pignataro via Datatracker - noreply at ietf.org <http://ietf.org/>" <[e-mail] <mailto:[e-mail]>>
> Subject: draft-ietf-teas-rsvp-auth-v2-02 early Rtgdir review
> 
> 1. Section 7 (IANA) uses RFC 2747 as the reference for HMAC-MD5, with a SHOULD,
> but this RFC obsoletes RFC 2747. This looks self-contradicting, particularly
> without MTI algo.


I believe that Joel Halpern has already addressed this comment.


> 2. Also, the column "Implementation Status" seems to be a misnomer, or a
> conflict with RFC 7942. Is that Requirement Level?


No, that was intentional. It has no relationship to RFC 7942, which does not have a trademark on “Implementation Status”.  We infer that you’re unhappy with the terminology.  Would you be happier with “Implementation Recommendation”?


> 3. Section 2 says the HF flag is a SHOULD. Section 4.3 says MUST.


Thank you, we will amend section 2.


> 4. In S4.1.1, is "computed over the message" enough clarity?


Given that this is the high level overview, we believe so.


> 5. Security association selection is based on the egress interface -- are there
> issues with RSVP with unnumbered, or budnle links?


Not that we know of.  Bundled links (i.e., LAGs) are an abstraction of multiple links into a single link.  RSVP operates at the level of the abstraction.  Similarly, the security association for an unnumbered link is specific to the link that the message arrived on.  Thus, numbering is not relevant, and unnumbered links are not an issue.


> 6. What is the length of the Challenge Cookie?


The challenge is variable length.  Its length for a given object is easily derived from the RSVP Object Header [RFC 2205, section 3.1.1], which defines a 16 bit length field for the object.  There are two reserved octets and then key identifier, of 48 bits, so the object length minus 8 octets gives the challenge length in octets.

Cheers,
Ran & Tony