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

Re: paradox

Hi,

On Mon, Jul 10, 2006 at 06:56:37PM -0400, Barney Wolff wrote:

> On Mon, Jul 10, 2006 at 01:31:11PM -0700, Glen Zorn (gwz) wrote:
> > Barney Wolff <> supposedly scribbled:
> > 
> > > I find it mildly astonishing, listening to today's radext session,
> > > that the group seemed to feel that the only problem worth fixing is
> > > the 255 limit on AVP type, when just a few minutes before the debate
> > > was over what to do with filter/traffic rules that go over the
> > > 253-byte limit.    
> > > 
> > > Apperently people feel that it's preferable to debate this issue
> > > every time it comes up, rather than solve it once. 
> > 
> > If you alleviate the attribute namespace shortage, aren't there established ways of dealing w/overly long values (up to the message size limit anyway)?
> 
> I'm always willing to be educated - please point me to a document that
> solves the attribute length problem when there can be more than one
> of the attribute in the message.

Ok, ok, kids. It's not /that/ hard to come up with something proper, or
is it? Is bickering all we can do nowadays? 

The issues can really be fixed in a simple and elegant way. We don't
need to make it seem any harder than it is.

I'll do it powerpoint-style:

1. the only sensible way of overcoming the 253-byte limit is
   concatenating all instances into one string. Of course, that means only
   one instance. Let's call this basic facility CONCAT.

2. for some attributes (all the ones allowing just one instance anyway),
   the CONCAT layer above RADIUS is enough. Let's call that class of
   attributes SINGLE LONG.

3. in other cases though, you want multiple instances, because a list of
   values has a meaning different from one single value. So it's
   desireable for the long attribute to be split in parts. 
   
   How to split a string? You have a number of options, as we all know.
   You either need:

   - fixed length subparts, or
   - a delimiter that may not occur (unescaped) in the string, or
   - a length, value structure (see eg. DNS), using a sufficently wide
     length field.

   Depending on the case, any of these mechanisms may be used. They all
   work above CONCAT, which works above RADIUS. No layering violations,
   standard mechanisms, all proven in RADIUS. Let's call this DELIMITED
   LIST. There's the 'document'. That didn't hurt, did it? 

Let's go on a bit:

4. in yet other cases though, you may want to have multiple individually
   identifyable elements in that delimited string, so that you don't
   have to rely on a fixed order, and can leave elements out.

   And how to do that? Well, you simply add a type (AVP code) field to
   the length, value structure given under 3. above. If you make that
   field sufficiently wide, you also solve the attribute number space
   crunch, and can delegate parts of it using smart prefixing (we all
   know about IPv4 classes, don't we?).

   Of course, that the only thing the extended attribute header format
   is: a TLV structure for use inside the single long string attribute.
   There are two contenters for this header format: the DIAMETER format,
   and a RADIUS-like format suggested earlier by yours truly that is
   fully backwards compatible with existing RADIUS features, including
   tags, and allows parts of the space to be delegated, and which, just
   like Barney's proposal incidentally, hardly got any comment about its
   technical merit or substance, as opposed to the amount of abstract
   philosophy, politics and instinctive feelings voiced around IETF-65.

   Anyway, let's call this layer, whichever way it's done, EXTATTR.

5. depending on the type of EXTATTR TLV structure chosen, EXTATTR.
   supports nested trees of attributes using physical parser level
   nesting or an inode-like structure using tags, which also provides
   the functionality of the current DIRTYTAGS we have in RFC 2868 et al.
   (Dirty only because of the the way the first octet of these
   attributes is both a flag, tag and a value in RFC2868). So, above
   EXTRAD you either directly have TREE, or you have TAGSET in between.

It can be summarised in a simple picture:

                                   +-------+
                                   |  ...  |
+-------+                          +-------+----+
|  ...  |                          | TREE  | .. |
+-------+-------+------------------+-------+----+----+
|  EAP  |  ...  |       ... *)     |  [TAGSET]  | .. |
+-------+-------+------------------+------------+----+------+-----+
|  SINGLE LONG  |  DELIMITED LIST  |    EXTATTR      | 2868 | ... |
+---------------+------------------+-----------------+------+-----+-----+
|                      CONCAT                        | DIRTYTAGS  | ... |
+----------------------------------------------------+------------+-----+
|                   Standard RADIUS attribute encoding                  |
+-----------------------------------------------------------------------+

  *) Eg. NAS-Filter

There are no dirty layering violations, implementations can pick and
choose how far they want to go with the newfangled bits, and you don't
have to rewrite any of your lower layers if you later decide you want to
add some or more of the new stuff.

It took me 15 minutes to come up with the above, and another 45 to put
it down. It should not take any more time from any of you.

So, what about it. Can we still /solve/ anything technical here, or has
this just become another slashdot?

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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