RE: Diameter Considerations Section

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled:

> Greg Weber said:
> "     In section 4.1 of RFC 3588, I see:
>       Unless otherwise noted, AVPs will have the following default AVP
>       Flags field settings:
>          The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.
> 
> Is the M-bit supposed to be set for these RADIUS attrs?"

I think so.

> 
> Jari Arkko said:
> 
> "Good question. Based on Section 1.3 of the vlan document, I believe
> the M bit may have to be set in AA-Answer message. 
> There may be other issues like that -- please review the text
> carefully." 
> 
> Given the security implications I think that the 'M' bit must be set
> for the Egress-VLANID, Ingress-Fitlers, and Egress-VLAN-Name
> attributes and may or may not be set for the User-Priority-Table
> attribute.  Here is the modified text:  
> 
>    When used in Diameter, the attributes defined in this specification
>    can be used as Diameter AVPs from the Code space 1-255 (RADIUS
>    attribute compatibility space). No additional Diameter Code values
>    are therefore allocated. The data types and flag rules for the
>    attributes are as follows:
> 
>                                   +---------------------+
>                                   |    AVP Flag rules   |
>                                   |----+-----+----+-----|----+
>                                   |    |     |SHLD| MUST|    |
>    Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
>    -------------------------------|----+-----+----+-----|----|
>    Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
>    Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
>    Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
>    User-Priority-Table OctetString|    | M,P |    |  V  | Y  |
>    -------------------------------|----+-----+----+-----|----|
> 
> This brings up another issue.  I believe that the addition of
> Mandatory attributes to RFC 4005 and 4072 requires assignment of new
> Application-Ids, correct?  

IIRC, the intent was that Diameter would (MUST) support all standard RADIUS attributes.  Of course, at the time it was (rather naively) supposed that no more standard RADIUS attributes would be defined.  Given this, I don't really think that new App-Ids need to be assigned; in fact, if such an assignment took place, I would argue that the attributes in question should be mapped to new Diameter AVPs, rather than handled in the same way as legacy standard RADIUS attributes.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
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/>