[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Object identifier and type spaces in a rationalized RADIUS data model

Hi Bernard,

Your questions are valid. I'll try to answer, even if I'm
not sure I have all the answers. Some of these issues
are likely going to need more discussion.

a. Since the number spaces are unified, is the IANA allocation
process defined in RFC 3588 used?  Does this imply that *all* AVPs


I think having the same IANA rules makes sense. I can imagine
that there could be a discussion about what those rules are --
but if they need to be changed then I think the change should
apply to both.

defined in Diameter are automatically also defined in RADIUS? Some
of those attributes may rely on facilities that are not defined
in RADIUS.


I can imagine that there are a few such attributes, as there
are a few RADIUS attributes that don't get translated into
Diameter.

b. Since this format optionally supports a Vendor-Specific format, does
this mean that we now have *two* Vendor-Specific Attribute (VSA) spaces
going forward?  Or do we deprecate one of them (presumably the existing
RADIUS attribute 26 space) for some uses (say SDO-specific attributes)?

We could do this either way.

But my thinking was that we need a "fresh start" for both VSAs and
standard attributes. Defining a new, somewhat more powerful format
and deprecating the old space would achieve this pretty well. Of
course, old VSAs would not stop working so no one's products would
be in danger. But we would send a message to vendors and SDOs
and ourselves that we have a new format that should be used for
new work.

c. How do we deal with differences in attribute length between RADIUS and
Diameter?  My assumption is that we would concatenate attributes of the
same code and Vendor-ID.  But this might not work correctly for
all attributes - some can be present more than once.

That was one of my open issues. I think the alternatives are:

  1. Limit the attributes to 255 bytes in RADIUS. (Did the
     charter say something about this limitation?) This
     is the simplest approach and my current preference.

  2. Come up with a concatenation scheme that works.
     As you point out, the simple Code-VID concatenation
     rule does not work. However, it would be possible
     to have a "Full Length" or "Offset" field or a
     "More to Follow" flag in the header. I had a "Full
     Length" field in an early design before I sent the
     proposal. However, I decided that it was too
     complicated.

As we think about this issue, we should remember that
RADIUS runs over UDP, and to avoid too many problems
with fragmentation one shouldn't put too many >255
byte attributes to the messages in the first place --
so there are some underlying limitations and relaxing
the attribute length limit may not help that much.

--Jari

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