[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on RADIUS Extended attributes
- To: "Bernard Aboba" <firstname.lastname@example.org>
- Subject: RE: Questions on RADIUS Extended attributes
- From: "Glen Zorn \(gwz\)" <email@example.com>
- Date: Wed, 16 Aug 2006 09:21:17 -0700
- Authentication-results: sj-dkim-6.cisco.com; header.Fromfirstname.lastname@example.org; dkim=pass ( sig from cisco.com verified; );
- Cc: <email@example.com>
- Dkim-signature: a=rsa-sha1; q=dns; l=2538; t=1155745279; x=1156609279; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; firstname.lastname@example.org; z=From:=22Glen=20Zorn=20\(gwz\)=22=20<email@example.com> |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=WfMjJ59ZfdtQlM3pcGdIM1g1NisR+rHW6v4pCpe/TkZOtvrN0gIAESOnkuGxs5vwM4AL6zsX 0AIk64XgJpLiCBdHl2gGg9ZTDE5iwtRMrxxSCnEvYhygNMjW4obXV/CL;
Bernard Aboba <> supposedly scribbled:
> At IETF 66, we discussed how to extend the RADIUS attribute space.
> The consensus in the room as well as on the WG mailing list seems to
> be to focus on extending the space only, not adding functionality,
> along the lines that Avi had proposed:
> During IETF 66, there was some sentiment that the RADIUS Extended
> attribute should utilize a new RADIUS attribute value, rather than
> using a Vendor-Id value of zero (0) with the existing RADIUS VSA
> attribute (Type 26).
Hmm. I don't remember any discussion like that at during the meeting, and searched in vain for mention of it in the draft minutes; I know that a couple of people stated that preference on the list recently, but without any technical justification.
> Taking that into account, find below a strawman proposal for what the
> Extended-Type attribute would look like.
> Some questions:
> a. Do we want an Extended-Type field of two or four octets? If it is
> four octets, this would seem to imply that RADIUS attributes and
> Diameter AVPs share the same type space. Will this work? If it is
> two octets, we could reserve 65535 values within the existing
> Diameter attribute space for RADIUS Extended-Type attributes.
> Opinions solicited.
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...
> b. Should the second length field include the Extended-Type field or
> If it is included and Extended-Type is 4 octets, then this implies
> that the Value field could only be 251 octets. If the second length
> field doesn't include Extended-Type, it could be as long as 255
> octets, but then we'd need to allow Extended-Type attributes to be
> split among multiple RADIUS attributes.
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.
> c. Should we allow multiple Extended-Type attributes to be placed
> inside a single RADIUS attribute? This is OK for RADIUS VSAs, is
> there an issue here?
Hope this helps,
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.