Subject: [Gen-art] Gen-ART review of draft-ietf-radext-rfc3576bis-09.txt

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Sep 2007 17:04:49 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-radext-rfc3576bis-09.txt
Reviewer: Ben Campbell
Review Date: 9/20/07
IETF LC End Date: 9/24/07

Summary:

This draft is basically ready for publication as an informational  
RFC, but has nits that should be fixed before publication.

Comments:

idnits reports two relevant issues:

>   -- The exact meaning of the all-uppercase expression 'MAY NOT' is  
> not
>      defined in RFC 2119.  If it is intended as a requirements  
> expression, it
>      should be rewritten using one of the combinations defined in  
> RFC 2119;
>      otherwise it should not be all-uppercase.
>
>   ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306)

Section 2.2, diagram:

I'm not sure that the term "authz" is well known enough to use  
without definition. Consider spelling out "authorization" or adding  
"authz" to the terminology list.

Section 2.3: Definition of RADIUS code values

This section references RFC3575 for the IANA registrations. RFC3575  
references RFC3576, which is being obsoleted by _this_ spec, for the  
value definitions.  Is that the intent?

Section 3, first paragraph:

"All NAS and session identification attributes included in a
    CoA-Request or Disconnect-Request packet MUST match at least one
    session in order for a Request to be successful; otherwise a
    Disconnect-NAK or CoA-NAK MUST be sent."

Is the above text correct? If so, what does it mean for a NAS  
identification attribute to match a _session_? I assume we are using  
the NAS identifiers as a scope in which the session identifiers have  
meaning, so that all sessions could be considered of having an  
implied NAS property? A little more explanation might be helpful.

Section 3, 5th paragraph from end:

"Where a Diameter client utilizes the same Session-Id for both
    authorization and accounting, inclusion of an Acct-Session-Id
    Attribute in a Disconnect-Request or CoA-Request can assist with
    Diameter/RADIUS translation, since Diameter RAR and ASR commands
    include a Session-Id AVP.  An Acct-Session-Id Attribute SHOULD be
    included in Disconnect-Request and CoA-Request packets."

I find the above text to be confusing. I _think_ you intend to  
compare the difference between an NAC behavior and a Diameter client  
behavior, but on the first read I it seemed like you were proposing  
suggested RADIUS behavior as conditional based on what a particular  
Diameter client does. I propose changing the first few words to  
"While Diameter clients... "

Section 3.1, last paragraph:

Should the following sentence us normative language?

"Since
    Disconnect and CoA responses are authenticated on the entire packet
    contents, the stripping of the Proxy-State Attribute invalidates the
    integrity check - so the proxy needs to recompute it."

Section 3.2, entire section:

It would be helpful to mention in this section how Authorize Only is  
used to ease mapping to Diameter, and reference the Diameter  
Considerations section. As it is, I spent some time wondering what  
the semantic effect of the resulting Access-Request message was  
supposed to be.

Section 3.5 Paragraph 5:

"When the HMAC-MD5 message integrity check is calculated the
       Request Authenticator field and Message-Authenticator Attribute
       should be considered to be sixteen octets of zero."

Is that 16 octets _combined_ or _each_? I originally assumed  
combined, but the calculation for use in an ACK/NAK the Message- 
Authenticator is treated as 16 octets of zero all by itself.

Section 6.2 paragraph 4:

Can a proxy be expected to easily know if it is one-hop away from the  
NAS? Is the mechanism for determining this well-known or documented  
somewhere that could be referenced here? (Sorry if I am showing my  
RADIUS ignorance here.)

Thanks!

Ben Campbell.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art