RE: AD review of draft-ietf-radext-management-authorization-05.txt

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Dan Romascanu writes...

> 1. section 2, page 4: replace 'NETCONF(XML over/SSH/BEEP/SOAP)' by
> 'NETCONF(XML over SSH or BEEP or SOAP)'

Sure.  Purely editorial.

> 2. section 5.2 and the following refer to 'a transport with equal or
> better protection'. I am wondering whether such a hierarchy of the
> Management-Transport-Protection is or will be always possible. Actually
> we may have a problem already, as SNMP allows any combination of
> authentication and privacy modes, and it is not clear which is the
> 'better' between (auth, noPriv) and (noAuth, priv).

OK, since the options are limited, maybe an enumeration of what's allowed
and what's not wouldn't be intractable.   For example:

   When a NAS receives a Management-Transport-Protection (TBA-3)
   Attribute in an Access-Accept packet, it MUST deliver the management
   access over a transport with at least the specified protection
   properties.  Additional protection MAY optionally be provided.
   For example, if No-Protection is specified then either Integrity-
   Protection or Integrity-Confidentiality-Protection MAY be provided.
   If Integrity-Protection is specified then Integrity-Confidentiality-
   Protection MAY be provided.  If the minimum protection cannot be
   provided the NAS MUST disconnect the session.
 
> 3. Related to the previous comment and in the same section - the
> Confidentiality-Protection value is missing from the enumeration of
> Value in the definition of the Management-Transport-Protection attribute

Based on WG review comments from the IETF-71 meeting and the WGLC, this was
removed.  It was thought that providing confidentiality without integrity
would pose potential security risks.

We would need to see if there is WG consensus to add this back in.

> 4. Section 5.3
> 
>    No precedence relationship is defined for multiple occurrences of the
>    Management-Policy-Id (TBA-4) Attribute.  NAS behavior in such cases
>    is undefined.  Therefore, two or more occurrences of this attribute
>    SHOULD NOT be included in an Access-Accept or CoA-Request.
> 
> I am wondering if a MUST NOT would not be in place here. How can
> interoperability of different vendors solutions be ensured if two or
> more occurrences of the attribute are included in an Access-Accept or
> CoA-Request and no standard precedence algorithm is in place? Any reason
> to allow this at all ever?

It would be good to discuss this.  In the presence of additional
documentation, this practice might be acceptable.  If the only form of
documentation for such procedures that we anticipate having would be another
Standards Track RFC that Updates this one, then MUST NOT would seem
appropriate.  OTOH, if we think there might be an Informational RFC that
suggests a way to handle the precedence, for certain areas of applicability,
then perhaps SHOULD NOT is better.

> 5. Last paragraph in Section 5.3, page 11
> 
> .  It is recommended that
>    the message contain UTF-8 encoded 10646 [RFC3629] characters.
> 
> It looks to me that RECOMMENDED needs to be capitalized here.

Sure.
 
> 6. Section 9 - page 17 - I do not see 0+ being used in Table 9, so it
> can be dropped by now from the table clarification list

It *could* be dropped, but this text had become standard RADIUS
"boilerplate", and my personal preference would be to leave it for
consistency with other RFCs.  I'm open to either approach.

> 7. Section 10 - I suspect the first Note ends after '... As an RFC'.

Yes.  Is there a better way to phrase this?

> 8. Section 10, same comment as in Section 3 related to the values of the
> Management-Transport-Protection attribute

See above.

> 9. I am wondering if Section 11 should not say something about the
> option No-Protection of the Management-Transport-Protection attribute
> being NOT RECOMMEDED in any critical configuration, or secure sensible
> environment

Sure.  I see no objection, unless anyone else sees a problem with that text.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>