Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
draft-ietf-radext-coa-proxy-10

S 3.3.

>      The new Operator-NAS-Identifier attribute is defined as follows.

I suggest adding the depiction of the fields and their lengths in
bytes, as is done in RFC 5580. I was a little confused about whether
the fields in the attribute are just the TLV.

I'm clearing my DISCUSS based on discussion over email and in the telechat. I am happy to leave the outcome to Benjamin's discretion. I'm including the original text below for reference:

<old-discuss>
(This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do think it needs to be resolved prior to publication..)

This draft is standards track, yet it primarily serves to extend RFC 5176. That RFC is informational. The shepherd writeup argues that this is okay because it seems like 5176 should have been standards track. But the applicability statement RFC 5176 explains why it was informational, and the reasons seem convincing. Therefore I do not think it is appropriate to publish this draft as Standards Track. I think it would be fine to progress it as Informational (or even Experimental) if it included an applicability statement explaining why in order to avoid the appearance of a standard masquerading as an Informational RFC.
</old-discuss>


Thanks for a readable and understandable drafts. I have some additional comments that do not rise to the level of a DISCUSS

Substantive Comments:

- I support Adam's DISCUSS point concerning the security properties of Operator-NAS-Identifier. But I will let that play out in Adam's thread.

§3.1 and §3,3: Do the normative changes to Access-Request and Accounting-Request mean that this draft needs to update documents other than just RFC 5176?

Editorial Comments:

- The abstract and introduction explain how this draft updates 5176, which is good. However, they avoid using the explicit term-of-art "Updates RFC 5176". Doing so would help make things more explicit. (The RFC style guide recommends doing this at least in the abstract.)

- Please expand PPTP and L2TP on first mention.

§3.1: I suspect some of the normative keywords in this section refer to previously existing requirements rather than new requirements. If  so, they should not be capitalized except in literal quotes.

§6: I think it would be helpful to mention the discussion in §4.3 in the security considerations.

§7: It would be helpful for the IANA considerations to briefly summarize the new attributes, so that a reader that started out reading the IANA considerations doesn't have to flip back to §3.3 just to find out what they are.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5085


I concur with Adam's DISCUSS (but marking no-objection to let him
manage this). Specifically, you need to describe what the security
expectations are for the Operator-NAS-Identifier. Need it be
unguessable? Should separate identifiers that refer to the same NAS be
unlinkable? "Cryptographically strong" is not a sufficiently specific
term to determine what the requirements are here.

COMMENTS
S 6.
>      issues.
>   
>      The Operator-NAS-Identifier SHOULD be created by the Visited Network
>      such that its contents are opaque to all other parties.  This ensures
>      that anyone observing unencrypted RADIUS traffic gains no information
>      about the internals of the Visited Network.

See above about the requirements here. Does there need to be an
unlinkable identifier each time?

Just a minor comment, the intended status is STD Track but the footer says Informational. The disconnect will need to be resolved at some point.

-m

Thanks for this well-written doc.

One nit in sec 3.1: s/activee/active/

One quick question on sec 3.3:
"Operator-NAS-Identifier MUST NOT occur more than once in a packet."
What happens if it occurs more than once? Just ignore or send an error?