[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question regarding draft-ietf-radext-design-05.txt
Hi Bernard,
Maybe I was misunderstood.
I am not asking for RADIUS to become Diameter (even though the group is
heading into that direction in a step-by-step fashion already).
Instead, I am asking for something different. I would like to have a bit
more reality touch regarding what can be done with the encoding in RADIUS
today and where custom encoding is necessary.
To give you an example: Some time back when RFC 4675 was written it was
state-of-the-art to define an attribute as:
User-Priority-Table
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where 'String' represented a customing encoding. Other attributes in the
same document followed the same format.
Given the available data types this was essentially the only choice to
comply with the idea of the data dictionary and the desire to have
everything be covered under the available data types.
The dictionary might look like:
ATTRIBUTE User-Priority-Table 59 String
Today, the encoding of RFC 4675 might quite likely be different and there is
still a lot of possibility to argue around why this is still a good
encoding.
Whether the AAA server had to be updated in order to provide additional
parsing capability depends a lot on the procedure how some of these
attributes (and the values in them) get introduced into the system in the
first place. In some systems they might be statically provisioned into a
database and just retrieved without any additional logic and in other
systems they would be dynamically generated and there might be some logic
behind all this stuff.
Now, the extended attributes draft extends the limits a bit.
Still, there is this tendency to label custom encoding (like the one from
above) as really bad (by calling it "interoperability and deployment issues"
or see the discussion in Section 2.1.4 of draft-ietf-radext-design-05.txt
regarding "Complex Attributes and Security").
I guess nobody would argue that attributes that can have a simple encoding
are supposed to get unnecessarily complex.
However, I would like to present the story in a way that custom encoding is
a side-effect of the design constraints that are introduced by the work the
group did. If you want something that does not fall into the "simple scheme"
(which btw happens quite often these days) then a custom encoding is more
difficult to avoid.
There is nothing bad about this. The reason for this is largely based on the
fact that implementers have seen custom encoding already for a while and
hence they have found ways to deal with it.
Maybe what I should be doing is to go through the RADIUS Design Guidelines
draft and to make detailed text proposals to make it clearer what I actually
mean.
Ciao
Hannes
>-----Original Message-----
>From: owner-radiusext@ops.ietf.org
>[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
>Sent: 27 December, 2008 00:18
>To: 'D. B. Nelson'; radiusext@ops.ietf.org
>Subject: RE: Question regarding draft-ietf-radext-design-05.txt
>
>"I think that the basic issues here is that there is a
>disconnect between the consensus position of the RADEXT WG (to
>keep things pretty simple) and need you are describing to
>provide [near] capability parity with Diameter."
>
>To quote the conclusions of the AAA protocol Evaluation team
>(RFC 3127) with
>
>respect to the prospects for enhancing RADIUS so as to meet the AAA
>requirements:
>
>" Radius++ is not considered acceptable as an AAA protocol.
>There is a
> fairly substantial amount of engineering required to make
>it meet all
> requirements, and that engineering would most likely result in
> something close to the functionality of Diameter."
>
>Indeed, at various points with the RADEXT WG, questions have
>come up relating to adoption of one or more features of
>Diameter, and WG consensus has lined up with the RFC 3127 assessment:
>
>1) during the discussion on Extended Attributes, the question
>arose as to whether RADIUS should adopt the Diameter AVP
>format. The WG consensus was against this, and as a result
>only modest extensions (for tagging and additional attribute
>space) were adopted.
>
>2) during the transport work, questions have arisen about the
>suitability of the RFC 3539 watchdog timer and failover logic.
> Again, WG sentiment does not appear to support a strict port
>of the Diameter functionality to RADIUS.
>
>So while it is possible (and potentially desirable) for RADEXT
>to develop enhancements (such as Extended Attributes and
>RADSEC), this falls considerably short of providing the full
>functionality of Diameter.
>
>
>
>
>
>
>--
>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/>
>
--
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/>