Re: Subtypes

["Alan DeKok" <aland@ox.org>]

Avi Lior <avi@bridgewatersystems.com> wrote:
> I doubt that the SIP folks would support not using what they have in the
> draft already.  But I will let them voice their objections (or not).

  The Sterman draft is outdated, and subject to MITM attacks.  I doubt
that it will be accepted as-is, as an IETF draft.  It will need to be
updated, and implementations will follow suit.

> >   The same argument can be applied to any unknown attribute, 
> > tagged, sub-typed, or other.
> 
> Exactly. So what is the problem?

  My opposition is based solely on implementation difficulties in
adding new code to handle subtypes, for more than Vendor-Specific.

> >   With new attributes having sub-types, it's often impossible 
> > for any intermediate server to do *anything* with the 
> > attribute, other than blindly forward it.  This can 
> > significantly increase the cost of adoption.
> 
> But if those subtypes were not to be interpreted by intermediaries?

  I doubt that intermediaries would be happy being told that they
can't look at authentication packets which they forward.  Laziness
dictates that new attributes may be proxied without change by old
code, which leads to proxies not being updated.  However, for business
reasons, the proxy MAY choose to permit different service levels.  It
therefore needs to be able to examine the contents of new attributes,
even if it doesn't know what to do with them.

  It's a nit-pick, but a useful one.

> The guideline would be that subtypes would only be used if they were
> intended for a particular application.  Prepaid is a perfect example so is
> the Location Attribute and Digest attribute.

  Exactly.  Maybe your proxy refuses to permit SIP calls to the "555"
prefix.  With the current "grouped" attribute space, it's nearly
impossible for a proxy to implement that restriction without code
changes.  With a flat attribute space, it's substantially easier.

  All of this would be moot if subtypes were supported from the start,
but hind-sight is 20-20.

  Alan DeKok.

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