[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on RADIUS Extended attributes
- To: "Bernard Aboba" <bernard_aboba@hotmail.com>
- Subject: RE: Questions on RADIUS Extended attributes
- From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
- Date: Wed, 16 Aug 2006 15:10:44 -0700
- Authentication-results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; );
- Cc: <radiusext@ops.ietf.org>
- Dkim-signature: a=rsa-sha1; q=dns; l=2073; t=1155766246; x=1156630246; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=pdiN0Y0jMMqNa5bnAjbG+Wd+aZHIYCaQk8jEr03aQxfvGalaM35agkjDi/VUy5wYlTkHFICb WZJfbZMI5Dt0sUliH/D4vgUyfMHx8nrTRZwKQi3fwme0SP711yZ4sPxi;
Bernard Aboba <mailto:bernard_aboba@hotmail.com> supposedly scribbled:
>> I know that a couple of people stated that preference on the list
>> recently, but without any technical justification.
>
> I think there may have been some concern about compatibility with
> existing RADIUS servers, since the format proposed in the Lior & Li
> draft utilized a larger Extended-Type field (32 bits) than was
> suggested for the VSA format in RFC 2865.
Yes, that's actually what I'm questioning the need for...
>
>> Is it really necessary to do more than double the number of standard
>> attributes? That is what the >VSA approach would do, without
>> requiring code changes...
>
> I think the implicit assumption here is that the VSA approach
> (Vendor-Id of 0) would utilize the VSA format described in RFC 2865
> (single octet Type
> field).
Yes, sorry, I should have been more explicit.
> However, the Lior & Li proposal was for a larger
> Extended-Type
> space, and I presume that this would require code changes.
>
>> In combination with the tagging scheme (or something very similar)
>> you mentioned in a recent >message, the "VSA Zero" approach solves
>> this problem, as well.
>
> RFC 2865 states that more than one vendor-specific attribute can be
> included within a RADIUS attribute of Type 26. However, I don't
> think it describes how vendor-specific attributes can be split across
> RADIUS attributes of Type 26. One way to address this is via a
> tagging scheme. I think the question is whether we'd want to
> *require* tags in each Extended attribute, or not.
I'd say yes -- the semantic difficulties w/the tagging scheme in RFC 2868 are I think in some part due to the false economy of trying to make the Tag field "disappear" if unused. Things would have been much had the Tag field been a real field in the attributes.
Hope this helps,
~gwz
Why is it that most of the world's problems can't be solved by simply
listening to John Coltrane? -- Henry Gabriel
--
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/>