Re: RADIUS Design Guidelines

[Barney Wolff <barney@databus.com>]

On Mon, Aug 28, 2006 at 03:35:26PM -0400, Nelson, David wrote:
> Barney Wolff writes...
> 
> > Let me try it again:  What's wrong with using the special value of 0
> for
> > extended-type to indicate that this extended attribute is a
> continuation
> > of the previous one?  That way, extra logic is only exercised when
> needed.
> 
> OK. Let's be a little more specific here.  I think what we are
> discussing is the following format:
> 
>       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       |            Vendor-Id
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          Vendor-Id (cont)            | Extended type |    Length2    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Tag      |     Data (Value)...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> I think that we have proposed that the Extended Attribute VSA (EA-VSA),
> i.e. the VSA with a Vendor-Id = IETF, may contain multiple instances of
> an Extended Attribute -- maybe we should call this an Encapsulated
> Extended Attribute (EEA) to distinguish it from the EA-VSA wrapper.  For
> example:
> 
>       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       |            Vendor-Id
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          Vendor-Id (cont)            | Extended type |    Length2    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Tag      |     Data (Value)...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Extended type |    Length2    |      Tag      |  Data (Value)...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      Data  (cont) ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> In this example, if *second* instance of "Extended type" were zero,
> would the value (data) portion of the second EEA be a continuation of
> the first EEA in this EA, or would it possibly be a continuation of as
> EEA in some other EA?
> 
> I think that this can get very complicated if we allow (a) tagging for
> data structuring, and (b) multiple extended attributes in a single VSA,
> and (c) a continuation "marker" of whatever sort.
> 
> Could you please restate you proposal for a "zero" EEA-type as
> continuation flag, given this discussion?  I'm trying to be sure that
> I'm not confused.

In order to avoid pathological cases, I would restrict EEA-type=0 to
the first instance of EEA-type in an EA-VSA, and only when the previous
EA-VSA had Length=253.  The meaning would be that the value indicated
by Length2 is to be concatenated with the last EEA in the previous EA-VSA.
It would be an error to have a Tag mismatch, an EEA-type=0 not right after
the Vendor-Id, or when the previous EA-VSA was not of max length or there
was no previous EA-VSA.

btw, I thought the WG consensus was to solve only Type exhaustion, not
all these other problems.  Since I think we should solve them, I don't
object, but I wonder if this is what people thought they were voting for.

-- 
Barney Wolff         I never met a computer I didn't like.

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