Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 31 Aug 2006 14:49:19 +0000 Subject: RE: RADIUS Design Guidelines [SEQUENCE] From: "Murtaza S. Chiba" To: Avi Lior Cc: "Nelson, David" , radiusext@ops.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 31 Aug 2006 07:48:48 -0700 Message-Id: <1157035729.2804.2.camel@localhost.localdomain> Mime-Version: 1.0 DKIM-Signature: a=rsa-sha1; q=dns; l=4953; t=1157035728; x=1157899728; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=22Murtaza=20S.=20Chiba=22=20 |Subject:RE=3A=20RADIUS=20Design=20Guidelines=20[SEQUENCE]; X=v=3Dcisco.com=3B=20h=3DChtAiBsT0gpZXXTe65web9wA5QA=3D; b=XUTEdXV1HY8HJZXphsgTNh3J6MjJn9UxwAY5556KM4BzwVOXYxcN22fEEi1ZuYyhmRVJT4eJ Bt1fPRpnc/CgbjbHKEIOXYr7rIoM7AFidePqdO6QE60EIRnSNu4jL+p3; Authentication-Results: sj-dkim-2.cisco.com; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com verified; ); One way to group attributes, instead of embedding them, is to use explicit attributes that mark the beginning and end of the group. Ofcourse, it requires that the intermediate servers dont modify the sequence of attributes, but I have yet to come across a server that actually does that apart from removing attributes. On Tue, 2006-08-29 at 12:28 -0400, Avi Lior wrote: > One more requirement: > > SEQUENCE or (fixed encoding as I call it) does not support the notion > where an element may repeat. > > > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > > Sent: Tuesday, August 29, 2006 11:51 AM > > To: radiusext@ops.ietf.org > > Subject: RE: RADIUS Design Guidelines [SEQUENCE] > > > > Avi Lior writes... > > > > >Had to start a new thread. > > > > Thanks for getting back to the subject that I'd originally > > wanted to discuss. > > > > > Sequence as you propose does not work. > > > > > > It only works when all members of a sequence are required > > except the > > > last one which can be optional -- > > > > Well, I think that packet formats that have [dynamically] > > optional data parts are more complicated, and definitely > > outside the RADIUS design paradigm of the TLV. One type, one > > length, one value. > > > > > .. or that if an element in the sequence is not required > > its value is > > > still sent (as a zero) > > > > Assuming we were to accept that certain fields in a complex > > data type are optional, that would probably be the way to go. > > > > > As well the sequence does not work for variable length fields. > > > > I'd indicated the caveats around that in my initial post. > > > > > A sequence of TLVs will work. Since the Type field allows us to > > > identify the attribute resolving the first problem. > > > > What comes around, goes around. Three years later, it looks > > as if you are one again suggesting "sub-types", i.e. > > sequences of TLVs, potentially nested in other TLVs. > > > > > If we are going to do this lets do it right! > > > > Well, I'm sure that there are multiple definitions of "right". > > > > The WG consensus on this issue, to date, is that we do not > > want to redefine the RADIUS data model, even though we > > acknowledge that it is very informal and rather limited. > > Rather than change the current practices in on-the-wire > > encodings in any substantial way, I was looking for a method > > of designing attributes and documenting current practices in > > a way that leads itself to a more formal and regular (read > > modular) construction. I believe this will enhance the > > ability for data dictionary driven implementations to embrace > > the extended attributes. > > > > The current RADIUS data model is TLV, for single-valued, > > atomic data elements. We are currently discussing how to > > embrace structured forms of data elements (V). Over the > > years, the practice has developed of declaring the V as a > > String type (or worse yet, failing to declare its type at > > all), and defining the sub-elements of the string as "packed > > fields" using the textual descriptions. > > > > This makes it hard(er) to implement using a data dictionary. > > I say this because there is no standard set of data types > > that can be referenced. > > If the String data type is seen to be composed of a SEQUENCE OF other > > (base) data types, it is much easier. > > > > You make the point that string fields need a length. > > Absolutely. I think it is not an unreasonable assumption to > > make that the RADIUS String and Text data types *do* include > > a length, the L in the TLV. > > Sicne RADIUS only describes single-valued TLVs, there was no > > reason to associate the L with the string V. One L was > > always sufficient. It is logical, I think, to assume that if > > a TLV contains a SEQUENCE of string Vs, that the string Vs > > will each have associated Ls. > > > > OTOH, as you suggest, it is not a large step to further > > extend this to allowing nested TLVs. I don't think that > > nested TLVs are needed simply to express multi-part data > > values. That would only be necessary for variable-content > > structures. I think that it is only necessary for us to be > > able to work with fixed-content structures. That will > > certainly solve the 85% problem. > > > > > > -- > > 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: > > > > -- > 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 Aug 2006 16:28:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines [SEQUENCE] Date: Tue, 29 Aug 2006 12:28:15 -0400 Message-ID: Thread-Topic: RADIUS Design Guidelines [SEQUENCE] Thread-Index: AcbKujnta/J5jAUoSJCIkDjMrvbekAAwiiHgAACxjQAAAjHzwA== From: "Avi Lior" To: "Nelson, David" , One more requirement: SEQUENCE or (fixed encoding as I call it) does not support the notion where an element may repeat. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, August 29, 2006 11:51 AM > To: radiusext@ops.ietf.org > Subject: RE: RADIUS Design Guidelines [SEQUENCE] >=20 > Avi Lior writes... >=20 > >Had to start a new thread. >=20 > Thanks for getting back to the subject that I'd originally=20 > wanted to discuss. >=20 > > Sequence as you propose does not work. > >=20 > > It only works when all members of a sequence are required=20 > except the=20 > > last one which can be optional -- >=20 > Well, I think that packet formats that have [dynamically]=20 > optional data parts are more complicated, and definitely=20 > outside the RADIUS design paradigm of the TLV. One type, one=20 > length, one value. >=20 > > .. or that if an element in the sequence is not required=20 > its value is=20 > > still sent (as a zero) >=20 > Assuming we were to accept that certain fields in a complex=20 > data type are optional, that would probably be the way to go. > =20 > > As well the sequence does not work for variable length fields. >=20 > I'd indicated the caveats around that in my initial post. >=20 > > A sequence of TLVs will work. Since the Type field allows us to=20 > > identify the attribute resolving the first problem. >=20 > What comes around, goes around. Three years later, it looks=20 > as if you are one again suggesting "sub-types", i.e.=20 > sequences of TLVs, potentially nested in other TLVs. >=20 > > If we are going to do this lets do it right! >=20 > Well, I'm sure that there are multiple definitions of "right". >=20 > The WG consensus on this issue, to date, is that we do not=20 > want to redefine the RADIUS data model, even though we=20 > acknowledge that it is very informal and rather limited. =20 > Rather than change the current practices in on-the-wire=20 > encodings in any substantial way, I was looking for a method=20 > of designing attributes and documenting current practices in=20 > a way that leads itself to a more formal and regular (read=20 > modular) construction. I believe this will enhance the=20 > ability for data dictionary driven implementations to embrace=20 > the extended attributes. >=20 > The current RADIUS data model is TLV, for single-valued,=20 > atomic data elements. We are currently discussing how to=20 > embrace structured forms of data elements (V). Over the=20 > years, the practice has developed of declaring the V as a=20 > String type (or worse yet, failing to declare its type at=20 > all), and defining the sub-elements of the string as "packed=20 > fields" using the textual descriptions. >=20 > This makes it hard(er) to implement using a data dictionary. =20 > I say this because there is no standard set of data types=20 > that can be referenced. > If the String data type is seen to be composed of a SEQUENCE OF other > (base) data types, it is much easier. >=20 > You make the point that string fields need a length. =20 > Absolutely. I think it is not an unreasonable assumption to=20 > make that the RADIUS String and Text data types *do* include=20 > a length, the L in the TLV. > Sicne RADIUS only describes single-valued TLVs, there was no=20 > reason to associate the L with the string V. One L was=20 > always sufficient. It is logical, I think, to assume that if=20 > a TLV contains a SEQUENCE of string Vs, that the string Vs=20 > will each have associated Ls. >=20 > OTOH, as you suggest, it is not a large step to further=20 > extend this to allowing nested TLVs. I don't think that=20 > nested TLVs are needed simply to express multi-part data=20 > values. That would only be necessary for variable-content=20 > structures. I think that it is only necessary for us to be=20 > able to work with fixed-content structures. That will=20 > certainly solve the 85% problem. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 Aug 2006 16:17:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines [SEQUENCE] Date: Tue, 29 Aug 2006 12:16:37 -0400 Message-ID: Thread-Topic: RADIUS Design Guidelines [SEQUENCE] Thread-Index: AcbKujnta/J5jAUoSJCIkDjMrvbekAAwiiHgAACxjQAAAWuOoA== From: "Avi Lior" To: "Nelson, David" , Dave, See inline....=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, August 29, 2006 11:51 AM > To: radiusext@ops.ietf.org > Subject: RE: RADIUS Design Guidelines [SEQUENCE] >=20 > Avi Lior writes... >=20 > >Had to start a new thread. >=20 > Thanks for getting back to the subject that I'd originally=20 > wanted to discuss. >=20 > > Sequence as you propose does not work. > >=20 > > It only works when all members of a sequence are required=20 > except the=20 > > last one which can be optional -- >=20 > Well, I think that packet formats that have [dynamically]=20 > optional data parts are more complicated, and definitely=20 > outside the RADIUS design paradigm of the TLV. One type, one=20 > length, one value. >=20 > > .. or that if an element in the sequence is not required=20 > its value is=20 > > still sent (as a zero) >=20 > Assuming we were to accept that certain fields in a complex=20 > data type are optional, that would probably be the way to go. > =20 > > As well the sequence does not work for variable length fields. >=20 > I'd indicated the caveats around that in my initial post. >=20 > > A sequence of TLVs will work. Since the Type field allows us to=20 > > identify the attribute resolving the first problem. >=20 > What comes around, goes around. Three years later, it looks=20 > as if you are one again suggesting "sub-types", i.e.=20 > sequences of TLVs, potentially nested in other TLVs. At least I am consistant. But I am not consitant for the sake of being consistant. As well I am not saying this because I am being argumentative or rigid etc... I keep asserting the same requirements because that is what is needed. > > If we are going to do this lets do it right! >=20 > Well, I'm sure that there are multiple definitions of "right". >=20 > The WG consensus on this issue, to date, is that we do not=20 > want to redefine the RADIUS data model, even though we=20 > acknowledge that it is very informal and rather limited. =20 > Rather than change the current practices in on-the-wire=20 > encodings in any substantial way, I was looking for a method=20 > of designing attributes and documenting current practices in=20 > a way that leads itself to a more formal and regular (read=20 > modular) construction. I believe this will enhance the=20 > ability for data dictionary driven implementations to embrace=20 > the extended attributes. >=20 > The current RADIUS data model is TLV, for single-valued,=20 > atomic data elements. We are currently discussing how to=20 > embrace structured forms of data elements (V). Over the=20 > years, the practice has developed of declaring the V as a=20 > String type (or worse yet, failing to declare its type at=20 > all), and defining the sub-elements of the string as "packed=20 > fields" using the textual descriptions. >=20 > This makes it hard(er) to implement using a data dictionary. =20 > I say this because there is no standard set of data types=20 > that can be referenced. > If the String data type is seen to be composed of a SEQUENCE OF other > (base) data types, it is much easier. >=20 > You make the point that string fields need a length. =20 > Absolutely. I think it is not an unreasonable assumption to=20 > make that the RADIUS String and Text data types *do* include=20 > a length, the L in the TLV. > Sicne RADIUS only describes single-valued TLVs, there was no=20 > reason to associate the L with the string V. One L was=20 > always sufficient. It is logical, I think, to assume that if=20 > a TLV contains a SEQUENCE of string Vs, that the string Vs=20 > will each have associated Ls. >=20 > OTOH, as you suggest, it is not a large step to further=20 > extend this to allowing nested TLVs. I don't think that=20 > nested TLVs are needed simply to express multi-part data=20 > values. That would only be necessary for variable-content=20 > structures. I think that it is only necessary for us to be=20 > able to work with fixed-content structures. That will=20 > certainly solve the 85% problem. So you are going to augment the parsing rules for dictionaries and you don't want to solve the problem completely? Anyway what you are promposed is what I called fixed field encoding in the past. It has its merits but that still does not solve my issues -- which are real issues. I need the 'L' and I need the 'T' or something equivalent to that. =20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 Aug 2006 15:51:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines [SEQUENCE] Date: Tue, 29 Aug 2006 11:50:52 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021941E@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADIUS Design Guidelines [SEQUENCE] Thread-Index: AcbKujnta/J5jAUoSJCIkDjMrvbekAAwiiHgAACxjQA= From: "Nelson, David" To: Avi Lior writes... >Had to start a new thread. Thanks for getting back to the subject that I'd originally wanted to discuss. > Sequence as you propose does not work. >=20 > It only works when all members of a sequence are required=20 > except the last one which can be optional --=20 Well, I think that packet formats that have [dynamically] optional data parts are more complicated, and definitely outside the RADIUS design paradigm of the TLV. One type, one length, one value. > .. or that if an element in the sequence is not required > its value is still sent (as a zero) Assuming we were to accept that certain fields in a complex data type are optional, that would probably be the way to go. =20 > As well the sequence does not work for variable length fields. I'd indicated the caveats around that in my initial post. > A sequence of TLVs will work. Since the Type field allows us to > identify the attribute resolving the first problem. What comes around, goes around. Three years later, it looks as if you are one again suggesting "sub-types", i.e. sequences of TLVs, potentially nested in other TLVs. > If we are going to do this lets do it right! Well, I'm sure that there are multiple definitions of "right". The WG consensus on this issue, to date, is that we do not want to redefine the RADIUS data model, even though we acknowledge that it is very informal and rather limited. Rather than change the current practices in on-the-wire encodings in any substantial way, I was looking for a method of designing attributes and documenting current practices in a way that leads itself to a more formal and regular (read modular) construction. I believe this will enhance the ability for data dictionary driven implementations to embrace the extended attributes. The current RADIUS data model is TLV, for single-valued, atomic data elements. We are currently discussing how to embrace structured forms of data elements (V). Over the years, the practice has developed of declaring the V as a String type (or worse yet, failing to declare its type at all), and defining the sub-elements of the string as "packed fields" using the textual descriptions. This makes it hard(er) to implement using a data dictionary. I say this because there is no standard set of data types that can be referenced. If the String data type is seen to be composed of a SEQUENCE OF other (base) data types, it is much easier. You make the point that string fields need a length. Absolutely. I think it is not an unreasonable assumption to make that the RADIUS String and Text data types *do* include a length, the L in the TLV. Sicne RADIUS only describes single-valued TLVs, there was no reason to associate the L with the string V. One L was always sufficient. It is logical, I think, to assume that if a TLV contains a SEQUENCE of string Vs, that the string Vs will each have associated Ls. OTOH, as you suggest, it is not a large step to further extend this to allowing nested TLVs. I don't think that nested TLVs are needed simply to express multi-part data values. That would only be necessary for variable-content structures. I think that it is only necessary for us to be able to work with fixed-content structures. That will certainly solve the 85% problem. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 Aug 2006 15:09:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines [SEQUENCE] Date: Tue, 29 Aug 2006 11:09:02 -0400 Message-ID: Thread-Topic: RADIUS Design Guidelines [SEQUENCE] Thread-Index: AcbKujnta/J5jAUoSJCIkDjMrvbekAAwiiHg From: "Avi Lior" To: "Nelson, David" , Had to start a new thread. Sequence as you propose does not work. It only works when all members of a sequence are required expcept the last one which can be optional -- or That if an element in the sequence is not required its value is still sent (as a zero) As well the sequence does not work for variable length fields. A sequence of TLVs will work. Since the Type field allows us to identify the attribute resolving the first problem. And Length allows us to handle variable length attributes. If we are going to do this lets do it right! > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, August 28, 2006 11:54 AM > To: radiusext@ops.ietf.org > Subject: RADIUS Design Guidelines >=20 > I've been giving some thought to the current RADIUS Design=20 > Guidelines draft, and the group consensus regarding that=20 > document and the Extended Attribute, coming out of IETF-66. >=20 > The currently evolving proposals for Extended Attributes,=20 > solve some of the issues that have been identified in the=20 > Design Guidelines draft: > shortage of attribute IDs, grouping of attributes, and an=20 > explicit method of fragmentation and reassembly. >=20 > The one remaining issue raised in the RADIUS Design=20 > Guidelines draft not addressed is the issue of multi-part=20 > data values. Most of the RADIUS work to date has simply=20 > addressed this by defining an attribute, of base-type String,=20 > and then defining sub-fields within the string. >=20 > There is nothing inherently wrong with this approach, except=20 > perhaps that it makes it more difficult to maintain data=20 > dictionary driven implementations. >=20 > I have a suggestion to float, in term of the BCP for attribute design. > I'd like to suggest that any value portion of a RADIUS TLV=20 > that has multiple parts be formally defined in the document=20 > as a SEQUENCE of pre-defined RADIUS base-types. I'm stealing=20 > the SMI syntax for SEQUENCE, as used in creating conceptual=20 > tables for MIB modules. It would be relatively easy for data=20 > dictionary driven implementations to automatically understand=20 > a sequence of pre-defined base types. >=20 > Let me provide a contrived example. Suppose we want to=20 > define a new attribute whose value is a complex number. For=20 > those who may have forgotten, a complex number consists of a=20 > real part and an imaginary part. This is most often=20 > represented as: n + m*i, where n and m are real numbers and i=20 > is the square root of -1. Such a hypothetical attribute=20 > light look like: >=20 > >=20 > Complex-Number >=20 > Description >=20 > A complex number, consisting to two parts, a real part N and an=20 > imaginary part M, such that the value is N + M*i, where i is the > square root of -1. >=20 > A summary of the Complex Number Attribute format is shown below. > The fields are transmitted from left to right. > 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 | Real-Part (N) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Real-Part (cont) | Imaginary-Part (M) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Imaginary-Part (cont) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Type >=20 > TBA for Complex-Number. >=20 > Length >=20 > 10 >=20 > Value >=20 > SEQUENCE OF Real-Part, Imaginary-Part >=20 > Real-Part >=20 > RADIUS base-type of Integer. The real part of the=20 > complex number. >=20 > Imaginary-Part >=20 > RADIUS base-type of Integer. The imaginary part of the complex > number. >=20 > >=20 > I think there is some value here in the ability for data=20 > dictionary driven implementations to easily accommodate=20 > multi-part value fields that are simple concatenations, or=20 > sequences, of pre-defined base data types. >=20 > A counter example would be an attribute with varying length=20 > fields, some maybe only one or two octets in length. These=20 > types of constructs require custom parsing code. >=20 > The one additional caveat, that comes to mind, is that=20 > variable length fields would need to (a) only occur at the=20 > end of all fixed length fields, (b) have an explicit length=20 > field, or (c) have an explicit delimiter field. >=20 > Comments on this line of thought? >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 Aug 2006 01:29:46 +0000 Date: Mon, 28 Aug 2006 21:29:19 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Design Guidelines Message-ID: <20060829012919.GA54327@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Mon, Aug 28, 2006 at 02:07:59PM -0700, Glen Zorn (gwz) wrote: > Barney Wolff <> scribbled on Monday, August 28, 2006 1:17 PM: > > ... > > > 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. > > All a sudden, stealing a bit from the Tag sounds very simple ;-) Well, no. Every condition I listed would apply, just the same, however one does fragmentation and concatenation. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 21:08:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 14:07:59 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502882FE5@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbK3wxchWBd14ilSzCX76V51wW/gAABsLcg From: "Glen Zorn \(gwz\)" To: "Barney Wolff" , "Nelson, David" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=667; t=1156799281; x=1157663281; c=relaxed/simple; s=sjdkim5002; 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 |Subject:RE=3A=20RADIUS=20Design=20Guidelines; X=v=3Dcisco.com=3B=20h=3DMXEWZLDCF4l0YWO4jpSwk9BcfVY=3D; b=RBhpBnYnqK2tav8BD3l2/Cg2jpIWxPBvacumjDvTlRufBOUB8bMiAzwE6u0Q13E+nHUkz8PF KKZPTU3E9JvYUefVfv3tpXBfQCemJ6ch+L+Ky4e9oEC0+TXf1AAAvypq; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff <> scribbled on Monday, August 28, 2006 1:17 PM: ... > In order to avoid pathological cases, I would restrict EEA-type=3D0 to > the first instance of EEA-type in an EA-VSA, and only when the > previous EA-VSA had Length=3D253. 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=3D0 not right after the Vendor-Id, or when the previous = EA-VSA > was not of max length or there was no previous EA-VSA. =20 All a sudden, stealing a bit from the Tag sounds very simple ;-) =20 Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 20:28:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 16:28:21 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021941B@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbK3vkl41VMRYdFSD2DHhTpkN6pFgAALHww From: "Nelson, David" To: Barney Wolff writes... > > I think that we have proposed that the Extended Attribute VSA (EA-VSA), > > i.e. the VSA with a Vendor-Id =3D IETF, may contain multiple = instances of > > an Extended Attribute ... This has been proposed on the list, but not accepted as consensus. > btw, I thought the WG consensus was to solve only Type exhaustion, not > all these other problems. The consensus was to solve the attribute ID exhaustion, and not to solve all the issues addressed by the "Diameter-flavor" extended attribute proposal. Adding tags has also been proposed on the list, and at IETF-66, but not accepted as consensus. I am operating under the assumption that this series of list discussions will spawn a new Extended Attributes draft, and the WG will be asked, after suitable review, whether it has consensus to accept that document. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 20:17:38 +0000 Date: Mon, 28 Aug 2006 16:17:16 -0400 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Design Guidelines Message-ID: <20060828201716.GA85089@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 19:35:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 15:35:26 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021941A@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbK1i4XorcEhLx0QlOPyNbwwwiMbgAAC2mQ From: "Nelson, David" To: 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 =3D 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. =20 > Pardon me for grumbling, but it was specifically to avoid this sort of > debate that some of us suggested we adopt the Diameter attribute header. Well, yeah, but that's not where the WG consensus came down. Folks in the WG wanted something much simpler. We're just trying to nail down all the corner conditions and figure out which ones we need to address, and which we can simply declare off limits. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 19:14:49 +0000 Date: Mon, 28 Aug 2006 15:14:22 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: RADIUS Design Guidelines Message-ID: <20060828191422.GA21726@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Mon, Aug 28, 2006 at 10:50:02AM -0700, Glen Zorn (gwz) wrote: > Nelson, David <> scribbled on Monday, August 28, 2006 10:28 AM: > > > > If this is a serious problem, could we simply use two tag fields, one > > to mark grouping for "data structuring" and another to mark grouping > > for "continuation"? > > That's certainly one way to do it, & simple. Another (more compact but > less simple) way would be to give away the high-order bit of the tag to > an "Attribute start flag"; this only allows 128 frags/attr (around 32K > max attribute length) however. 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. Pardon me for grumbling, but it was specifically to avoid this sort of debate that some of us suggested we adopt the Diameter attribute header. Oh well, never mind. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 18:33:04 +0000 Content-class: urn:content-classes:message Subject: Publication of RFC4668, RFC4669, RFC4670, RFC4671 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Aug 2006 21:32:54 +0300 Message-ID: Thread-Topic: Publication of RFC4668, RFC4669, RFC4670, RFC4671 Thread-Index: AcbK0F4QWA+zUBnrQtW8M5CcTMA0tQ== From: "Romascanu, Dan \(Dan\)" To: The announcements of the publication of the RADIUS Authentication Client and Server and RADIUS Accounting Client and Server MIB documents just went out. Congratulations to the WG and special thanks to David Nelson, co-chair and editor of the documents for this achievements.=20 Dan =20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 18:24:36 +0000 Date: Mon, 28 Aug 2006 11:24:30 -0700 Message-Id: <200608281824.k7SIOUJI028822@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4671 on RADIUS Accounting Server MIB for IPv6 From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4671 Title: RADIUS Accounting Server MIB for IPv6 Author: D. Nelson Status: Informational Date: August 2006 Mailbox: dnelson@enterasys.com Pages: 24 Characters: 47694 Obsoletes: RFC2621 See-Also: I-D Tag: draft-ietf-radext-rfc2621bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc4671.txt This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers. This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community. This document is a product of the RADIUS EXTensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 18:24:29 +0000 Date: Mon, 28 Aug 2006 11:23:53 -0700 Message-Id: <200608281823.k7SINrKl028810@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4669 on RADIUS Authentication Server MIB for IPv6 From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4669 Title: RADIUS Authentication Server MIB for IPv6 Author: D. Nelson Status: Standards Track Date: August 2006 Mailbox: dnelson@enterasys.com Pages: 25 Characters: 50525 Obsoletes: RFC2619 See-Also: I-D Tag: draft-ietf-radext-rfc2619bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc4669.txt This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers. This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 18:24:21 +0000 Date: Mon, 28 Aug 2006 11:23:38 -0700 Message-Id: <200608281823.k7SINc7R028803@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4668 on RADIUS Authentication Client MIB for IPv6 From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4668 Title: RADIUS Authentication Client MIB for IPv6 Author: D. Nelson Status: Standards Track Date: August 2006 Mailbox: dnelson@enterasys.com Pages: 24 Characters: 48252 Obsoletes: RFC2618 See-Also: I-D Tag: draft-ietf-radext-rfc2618bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc4668.txt This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients. This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 18:24:13 +0000 Date: Mon, 28 Aug 2006 11:24:07 -0700 Message-Id: <200608281824.k7SIO7EZ028815@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4670 on RADIUS Accounting Client MIB for IPv6 From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4670 Title: RADIUS Accounting Client MIB for IPv6 Author: D. Nelson Status: Informational Date: August 2006 Mailbox: dnelson@enterasys.com Pages: 23 Characters: 44667 Obsoletes: RFC2620 See-Also: I-D Tag: draft-ietf-radext-rfc2620bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc4670.txt This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients. This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community. This document is a product of the RADIUS EXTensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 17:50:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 10:50:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502882E82@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbKvzT7+Lw97fcuTK6RbTRi0HuQmQAArASwAAECgPAAAOxqAA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1430; t=1156787406; x=1157651406; c=relaxed/simple; s=sjdkim7002; 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 |Subject:RE=3A=20RADIUS=20Design=20Guidelines; X=v=3Dcisco.com=3B=20h=3DMXEWZLDCF4l0YWO4jpSwk9BcfVY=3D; b=eJpdILAjk+koQbEZ5pKfQyoVG/g0+coviquhZmFoo3t587eStYqBI6cGtzovYxHMqNCYP/Y3 OUyTJfKPcS1J5oHRZsC4YPKAR52JoA28TorABgkMvrr5cIXrVgT5cFby; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David <> scribbled on Monday, August 28, 2006 10:28 AM: > Glen Zorn writes... >=20 >> We already know how to send & receive XL attributes, via in-order >> fragmentation, transmission & concatenation. There is no need to use >> tags for this. >=20 > Yes, but doesn't this depend on the per-attribute textual definition? > What I mean to say is that for some attributes there can be only one > "logical" instance in a RADIUS message, and any additional instances > MUST be continuations of the first. For other attributes, having > multiple instances in messages is acceptable, and there is no > continuation ever required (or allowed). What happens if there is an > attribute that can have multiple instances *and* can have some of > them continue over multiple attributes? Don't we need the tag > (grouping) to =20 > indicate which are separate instances and which are continuations of > an instance?=20 Yup, you're right. ... >=20 > If this is a serious problem, could we simply use two tag fields, one > to mark grouping for "data structuring" and another to mark grouping > for "continuation"? =20 That's certainly one way to do it, & simple. Another (more compact but less simple) way would be to give away the high-order bit of the tag to an "Attribute start flag"; this only allows 128 frags/attr (around 32K max attribute length) however. Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 17:37:11 +0000 Date: Mon, 28 Aug 2006 13:36:58 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Design Guidelines Message-ID: <20060828173658.GA10970@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Mon, Aug 28, 2006 at 10:02:33AM -0700, Glen Zorn (gwz) wrote: > Barney Wolff <> scribbled on Monday, August 28, 2006 9:30 AM: > > > On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote: > >> > >> The currently evolving proposals for Extended Attributes, solve some > >> of the issues that have been identified in the Design Guidelines > >> draft: shortage of attribute IDs, grouping of attributes, and an > >> explicit method of fragmentation and reassembly. > > > > I'm confused. I thought the tag was being used for fragmentation and > > reassembly, which would seem to preclude its use for grouping. > > Can somebody clarify? > > > > We already know how to send & receive XL attributes, via in-order > fragmentation, transmission & concatenation. There is no need to use > tags for this. The limitation of using tags to group attributes in > conjunction w/this traditional method is that only one XL attribute of a > given (extended) type can belong to a group. If this is a serious > problem, then some method of distinguishing the beginning of a new > attribute from the middle of the previous one would be required. We do? I know that's been specified for EAP-Message, but if it's been said anywhere as applying to attributes in general I must have missed it. > > My own preference would be to use an extended-type of 0 to indicate > > continuation, rather than the tag field. > > If we use anything like the customary method of dealing w/XL attributes, > there doesn't seem to be any need for continuation indicator: an > attribute starts & continues until a) another attribute starts or b) the > end of the message is reached. Again, I'm just confused. I thought that multiple instances of a given attribute were taken as multiple instances, not fragmented pieces of a single longer attribute. I'd appreciate a pointer to an RFC stating otherwise in the general case. Certainly there's been discussion of how, if the instances are just glommed together, to parse that into multiple filter rules, for example (and again, I'd really hate to see such parsing have to be type-specific). I apologize to all if I've really missed a decision taken and documented. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 17:28:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 13:28:23 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219416@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbKvzT7+Lw97fcuTK6RbTRi0HuQmQAArASwAAECgPA= From: "Nelson, David" To: Glen Zorn writes... > We already know how to send & receive XL attributes, via=20 > in-order fragmentation, transmission & concatenation. There > is no need to use tags for this. Yes, but doesn't this depend on the per-attribute textual definition? What I mean to say is that for some attributes there can be only one "logical" instance in a RADIUS message, and any additional instances MUST be continuations of the first. For other attributes, having multiple instances in messages is acceptable, and there is no continuation ever required (or allowed). What happens if there is an attribute that can have multiple instances *and* can have some of them continue over multiple attributes? Don't we need the tag (grouping) to indicate which are separate instances and which are continuations of an instance? > The limitation of using tags to group attributes in > conjunction w/this traditional method is that only one XL=20 > attribute of a given (extended) type can belong to a group. Yes. > If this is a serious problem, then some method of distinguishing > the beginning of a new attribute from the middle of the previous > one would be required. If this is a serious problem, could we simply use two tag fields, one to mark grouping for "data structuring" and another to mark grouping for "continuation"? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 17:02:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 10:02:33 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502882E3D@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbKvzT7+Lw97fcuTK6RbTRi0HuQmQAArASw From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: , "Nelson, David" DKIM-Signature: a=rsa-sha1; q=dns; l=1586; t=1156784555; x=1157648555; 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 |Subject:RE=3A=20RADIUS=20Design=20Guidelines; X=v=3Dcisco.com=3B=20h=3DMXEWZLDCF4l0YWO4jpSwk9BcfVY=3D; b=ETVVm12bigTimJfsJl6Ao9v3Rgeg4jy3J6pgoOpR4VqACvNQaKw5GqS1pif6JgyH7J9185tQ fn8/W9J2PkO4SliUypkCIk6ZkSPxvrc/GLjzHYeC0p3aw+gVtV2c1b5g; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff <> scribbled on Monday, August 28, 2006 9:30 AM: > On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote: >>=20 >> The currently evolving proposals for Extended Attributes, solve some >> of the issues that have been identified in the Design Guidelines >> draft: shortage of attribute IDs, grouping of attributes, and an >> explicit method of fragmentation and reassembly. >=20 > I'm confused. I thought the tag was being used for fragmentation and > reassembly, which would seem to preclude its use for grouping. =20 > Can somebody clarify? =20 >=20 We already know how to send & receive XL attributes, via in-order fragmentation, transmission & concatenation. There is no need to use tags for this. The limitation of using tags to group attributes in conjunction w/this traditional method is that only one XL attribute of a given (extended) type can belong to a group. If this is a serious problem, then some method of distinguishing the beginning of a new attribute from the middle of the previous one would be required. > My own preference would be to use an extended-type of 0 to indicate > continuation, rather than the tag field. =20 If we use anything like the customary method of dealing w/XL attributes, there doesn't seem to be any need for continuation indicator: an attribute starts & continues until a) another attribute starts or b) the end of the message is reached. > But I'm just an anti-tag > bigot. =20 >=20 > -- > Barney Wolff I never met a computer I didn't like. Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 16:29:54 +0000 Date: Mon, 28 Aug 2006 12:29:33 -0400 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Design Guidelines Message-ID: <20060828162933.GA14647@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote: > > The currently evolving proposals for Extended Attributes, solve some of > the issues that have been identified in the Design Guidelines draft: > shortage of attribute IDs, grouping of attributes, and an explicit > method of fragmentation and reassembly. I'm confused. I thought the tag was being used for fragmentation and reassembly, which would seem to preclude its use for grouping. Can somebody clarify? My own preference would be to use an extended-type of 0 to indicate continuation, rather than the tag field. But I'm just an anti-tag bigot. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 15:54:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RADIUS Design Guidelines Date: Mon, 28 Aug 2006 11:54:21 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219415@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADIUS Design Guidelines Thread-Index: AcbKujnta/J5jAUoSJCIkDjMrvbekA== From: "Nelson, David" To: I've been giving some thought to the current RADIUS Design Guidelines draft, and the group consensus regarding that document and the Extended Attribute, coming out of IETF-66. The currently evolving proposals for Extended Attributes, solve some of the issues that have been identified in the Design Guidelines draft: shortage of attribute IDs, grouping of attributes, and an explicit method of fragmentation and reassembly. The one remaining issue raised in the RADIUS Design Guidelines draft not addressed is the issue of multi-part data values. Most of the RADIUS work to date has simply addressed this by defining an attribute, of base-type String, and then defining sub-fields within the string. There is nothing inherently wrong with this approach, except perhaps that it makes it more difficult to maintain data dictionary driven implementations. I have a suggestion to float, in term of the BCP for attribute design. I'd like to suggest that any value portion of a RADIUS TLV that has multiple parts be formally defined in the document as a SEQUENCE of pre-defined RADIUS base-types. I'm stealing the SMI syntax for SEQUENCE, as used in creating conceptual tables for MIB modules. It would be relatively easy for data dictionary driven implementations to automatically understand a sequence of pre-defined base types. Let me provide a contrived example. Suppose we want to define a new attribute whose value is a complex number. For those who may have forgotten, a complex number consists of a real part and an imaginary part. This is most often represented as: n + m*i, where n and m are real numbers and i is the square root of -1. Such a hypothetical attribute light look like: Complex-Number Description A complex number, consisting to two parts, a real part N and an=20 imaginary part M, such that the value is N + M*i, where i is the square root of -1. A summary of the Complex Number Attribute format is shown below. The fields are transmitted from left to right. 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 | Real-Part (N) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Real-Part (cont) | Imaginary-Part (M) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Imaginary-Part (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA for Complex-Number. Length 10 Value SEQUENCE OF Real-Part, Imaginary-Part Real-Part RADIUS base-type of Integer. The real part of the complex number. Imaginary-Part RADIUS base-type of Integer. The imaginary part of the complex number. I think there is some value here in the ability for data dictionary driven implementations to easily accommodate multi-part value fields that are simple concatenations, or sequences, of pre-defined base data types. A counter example would be an attribute with varying length fields, some maybe only one or two octets in length. These types of constructs require custom parsing code. The one additional caveat, that comes to mind, is that variable length fields would need to (a) only occur at the end of all fixed length fields, (b) have an explicit length field, or (c) have an explicit delimiter field. Comments on this line of thought? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 15:45:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Mon, 28 Aug 2006 08:44:58 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502882DD0@xmb-sjc-215.amer.cisco.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbIUm2mUKuRasF1R9Oz915gNKO7eAAAEjLwAA4dw0AAifYxEAAA3law From: "Glen Zorn \(gwz\)" To: "Nelson, David" , DKIM-Signature: a=rsa-sha1; q=dns; l=1437; t=1156779905; x=1157643905; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Glen's=20proposal=20for=20Attribute=20Extension; X=v=3Dcisco.com=3B=20h=3DIXDrJPE47xLdwGcAR7WHnL65pxI=3D; b=eMU4K/1vVqi/O0H8p7YVjmX6hwpytyYtquwOVjgzH3cpvH/e8KGOef3MMuRSIvMmheJpnJqg ChOjJIJoRAQ4D3hMjsquCYgob7RxYPHRiwW7/31HX14yj7ZgwFLSyAu4; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David <> scribbled on Monday, August 28, 2006 8:13 AM: ... > Perhaps. I'm likely reacting to the "naming thing". Somehow, the > notion of a Standard Extended Attribute format that is defined as a > special case of a Vendor Specific Attribute seems wrong to me. =20 Not sure why: it seems to have worked pretty well for other SDOs, 3GPP2 being the one with which I'm most familiar. >=20 > The value you see in using 26 as the "top-level" attribute ID is that > it re-uses existing code for generating and parsing VSAs? =20 Actually, the whole proposal reuses well understood techniques & attempt to isolate the changes to an area of the code that is likely fluid in any case. > IMHO, once > you need to make *any* code changes, you need to release new versions > of the SW/FW. I very much doubt there are many (if any) > implementations that can accomplish this with only data dictionary > changes. Having said that, what is the practical cost of assigning a > different "top-level" ID for the Extended Attribute?=20 Not sure; the rationale for making this a VSA is largely that VSA formats are often non-standard (Cisco's, for example; I believe Nortel's, as well, probably others) & therefore this (minor) change would be localized in an area of code that changes fairly often anyway, rather in the main line which I suspect changes much more rarely. =20 Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 15:13:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Mon, 28 Aug 2006 11:13:03 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219414@MABOSEVS2.ets.enterasys.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbIUm2mUKuRasF1R9Oz915gNKO7eAAAEjLwAA4dw0AAifYxEA== From: "Nelson, David" To: Glen Zorn writes... > OK. probably "minimal code changes" would be more accurate > than "no code changes. Yes. > The formats of VSAs must be well defined, even if not standard. Yes, each instance is well defined, but often highly varied. > Well, I think that it would be as clear as we wanted to make it. > If we publish an RFC that has "MUST" surrounding the formats, > that seems pretty clear to me. Perhaps. I'm likely reacting to the "naming thing". Somehow, the notion of a Standard Extended Attribute format that is defined as a special case of a Vendor Specific Attribute seems wrong to me. The value you see in using 26 as the "top-level" attribute ID is that it re-uses existing code for generating and parsing VSAs? IMHO, once you need to make *any* code changes, you need to release new versions of the SW/FW. I very much doubt there are many (if any) implementations that can accomplish this with only data dictionary changes. Having said that, what is the practical cost of assigning a different "top-level" ID for the Extended Attribute? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 Aug 2006 14:33:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Zero Tag field in Filter-Rule attribute Date: Mon, 28 Aug 2006 10:33:36 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219413@MABOSEVS2.ets.enterasys.com> Thread-Topic: Issue: Zero Tag field in Filter-Rule attribute Thread-Index: AcbKA+L7C/oXKwJiSi2rhWzjqNp2YQAqtyHg From: "Nelson, David" To: Bernard Aboba writes... > With the change, it might look like this: >=20 > The Tag field is one octet, and MUST always be present. It is used to > identify the filter rule that is represented. Where a single > filter rule exceeds 253 octets in length, the rule MUST be encoded > across multiple NAS-Filter-Rule attributes, each with the same > non-zero Tag value; non-zero Tag values MUST be unique for each > filter rule present in a RADIUS packet. The value of '0' (0x30) in > the Tag field indicates that the attribute contains a filter rule > that does not exceed 253 octets in length; as a result attributes > with a Tag value of 0x30 MUST NOT be concatenated, and one or more > Filter-Rule attributes with a tag value of 0x31 may be included > in a single RADIUS packet, each describing a single filter rule. Looks good to me, with the change to consistent use of 0x30, noted by Jouni. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 21:37:36 +0000 Date: Sun, 27 Aug 2006 17:37:11 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified Message-ID: <20060827213711.GA95041@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Sun, Aug 27, 2006 at 01:57:41PM -0700, Glen Zorn (gwz) wrote: > > > Sigh. It seems to me that 3588 4.1 at least in spirit says that a > > gateway getting an attribute with an M-bit that it cannot for > > whatever reason translate, MUST reject the message. > > In this case it would be handy if it did, but it doesn't & interpreting > it that way would violate the M-bit semantics, IMHO. Violate in what way? > > I would truly > > hate to have to specify gateway behavior for each attribute type, and > > hate even more having to implement type-specific behavior, just to > > handle message overflow - or, for that matter, for any other reason. > > Unfortunately, this problem seems to be the "elephant in the corner" of > RADIUS-Diameter interop: everybody knows about it (presupposing simple > arithmetic ability) but nobody wants to talk about it... Message overflow is a potential problem, sure. But does dealing with it actually require different logic depending on what attribute(s) don't fit? Similarly, does dealing with a single attribute of length >253 actually have to depend on the attribute type? Pfui, if so. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 20:57:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sun, 27 Aug 2006 13:57:41 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250281684C@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Diameter-RADIUS gateway behavior not completely specified Thread-Index: AcbJdl+dbLle4+ApTHmu37RafFa0VAAoq/xA From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=897; t=1156712263; x=1157576263; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Issue=3A=20Diameter-RADIUS=20gateway=20behavior=20not=20complete ly=20specified; X=v=3Dcisco.com=3B=20h=3Dm7E3Pmh6ma+lb09sBcSrQ2HAMMo=3D; b=i3M/1jjKAemo2Eko0P7rbZ2/ylAbjWLIgnSxHY58EFjG//WsoDZAJK3Jpigx+4NrCn/meC5C PkfYcMA8qz73AP3d3d0fyvuCh7n98frJJTg8oE9HFhlpptcJGFVNECFz; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff scribbled on Saturday, August 26, 2006 6:16 PM: ... > Sigh. It seems to me that 3588 4.1 at least in spirit says that a > gateway getting an attribute with an M-bit that it cannot for > whatever reason translate, MUST reject the message. =20 In this case it would be handy if it did, but it doesn't & interpreting it that way would violate the M-bit semantics, IMHO. =20 > I would truly > hate to have to specify gateway behavior for each attribute type, and > hate even more having to implement type-specific behavior, just to > handle message overflow - or, for that matter, for any other reason.=20 Unfortunately, this problem seems to be the "elephant in the corner" of RADIUS-Diameter interop: everybody knows about it (presupposing simple arithmetic ability) but nobody wants to talk about it... Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 20:35:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Zero Tag field in Filter-Rule attribute Date: Sun, 27 Aug 2006 13:35:22 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502816848@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Zero Tag field in Filter-Rule attribute Thread-Index: AcbKBTsvvB9tAXLhQ0WVV1oGuEOEEgAAaZwQAARXrxA= From: "Glen Zorn \(gwz\)" To: Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=992; t=1156710925; x=1157574925; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Issue=3A=20Zero=20Tag=20field=20in=20Filter-Rule=20attribute; X=v=3Dcisco.com=3B=20h=3D+76HfFOWQnbnvzqF477xcnV8Yq8=3D; b=sxF8zn0mSAhX2xr5rnuy8cxB7pg6c+2j5RnH18KuAmDTlUvbs5WHdN5bO40p5XxLVMuSFhHF 1m75Idq4C2fDhJBV3fSEHwWNhOBsCyK5qxuQ5am7e/DCC9uK14xP+PfR; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); jouni.korhonen@teliasonera.com <> scribbled on Sunday, August 27, 2006 11:36 AM: > [snip] >=20 >> The Tag field is one octet, and MUST always be present. It is used to >> identify the filter rule that is represented. Where a single filter >> rule exceeds 253 octets in length, the rule MUST be encoded across >> multiple NAS-Filter-Rule attributes, each with the same non-zero Tag >> value; non-zero Tag values MUST be unique for each filter rule >> present in a RADIUS packet. The value of '0' (0x30) in the Tag field >> indicates that the attribute contains a filter rule that does not >> exceed 253 octets in length; as a result attributes with a Tag value >> of 0x30 MUST NOT be concatenated, and one or more Filter-Rule >> attributes with a tag value of 0x31 may be included >=20 > Shouldn't 0x31 here be 0x30? Yup, good catch! >=20 >> in a single RADIUS packet, each describing a single filter rule. >=20 >=20 > Cheers, > Jouni Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 18:53:38 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Issue 204: Review of draft-ietf-radext-delegated-prefix-02 Date: Sun, 27 Aug 2006 11:53:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Issue 204: Review of draft-ietf-radext-delegated-prefix-02 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 27, 2006 Reference: Document: draft-ietf-radext-delegated-prefix-02 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Section 1 The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an IPv6 prefix to be delegated to the user, for use in the user's network. For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2]. [BA] Is there another potential use of the Delegated-IPv6-Prefix attribute? Suggest this be changed to: "The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an IPv6 prefix to be delegated to the user, for use in the user's network, via DHCP Prefix Delegation [2]." -------- The Framed-IPv6-Prefix attribute [4] serves a similar purpose, but may also be used for other purposes other than delegating a prefix for use in a user's network. Definition of the Delegated-IPv6-Prefix allows the simultaneous use of the Framed-IPv6-Prefix for other purposes and the Delegated-IPv6-Prefix for prefix delegation. [BA] The Framed-IPv6-Prefix attribute is used to indicate a prefix that is announced via RS/RA, which is not really a "similar" purpose. Suggest this be changed to: "The Framed-IPv6-Prefix attribute defined in [4] as not designed for use in prefix delegation, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." -------- The definition of the Delegated-IPv6-Prefix Attribute is based on the Framed-IPv6-Prefix attribute [4]. While the attributes are similar in format, they are used for different purposes. Suggest that this sentence be deleted. -------- Section 3 The following table describes which messages the Delegated-IPv6- Prefix attribute can appear in and in what quantity. +------------------------------------------------------+ | Request Accept Accounting # Attribute | | Request | | 0+ 0+ 0+ TBD Delegated-IPv6-Prefix | +------------------------------------------------------+ In this table 0+ means that zero or more instances of this attribute MAY be present in packet. This attribute MUST NOT appear in any packet not listed in the table. Please use the standard table format from RFC 3162; Attribute Tables are typically included in a separate section. Suggest the following: "4. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute 0+ 0+ 0 0 0+ TBD Delegated-IPv6-Prefix The meaning of the above table entries is as follows: 0 This attribute MUST NOT be present. 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 1+ One or more of these attributes MUST be present." Section 4 I think you need to include text on the AVP flag rules, along the lines of what is in the Framed-IPv6-Prefix attribute: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP | | |SHLD| MUST| | Attribute Name Code Value Type |MUST| MAY | NOT| NOT|Encr| ----------------------------------|----+-----+----+-----|----| Delegated-IPv6- 97 OctetString| M | P | | V | Y | Prefix | | | | | | -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 18:36:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Zero Tag field in Filter-Rule attribute Date: Sun, 27 Aug 2006 20:36:05 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E030135988D@SEHAN021MB.tcad.telia.se> Thread-Topic: Issue: Zero Tag field in Filter-Rule attribute thread-index: AcbKBTsvvB9tAXLhQ0WVV1oGuEOEEgAAaZwQ From: To: , [snip] > The Tag field is one octet, and MUST always be present. It is used to > identify the filter rule that is represented. Where a single > filter rule exceeds 253 octets in length, the rule MUST be encoded > across multiple NAS-Filter-Rule attributes, each with the same > non-zero Tag value; non-zero Tag values MUST be unique for each > filter rule present in a RADIUS packet. The value of '0' (0x30) in > the Tag field indicates that the attribute contains a filter rule > that does not exceed 253 octets in length; as a result attributes > with a Tag value of 0x30 MUST NOT be concatenated, and one or more > Filter-Rule attributes with a tag value of 0x31 may be included Shouldn't 0x31 here be 0x30? > in a single RADIUS packet, each describing a single filter rule. Cheers, Jouni -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 18:08:49 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: Issue: Zero Tag field in Filter-Rule attribute Date: Sun, 27 Aug 2006 11:08:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Question: In the interest of making it easier to enter in Filter-Rules as ASCII strings, does it make sense to make the Tag value 0x30 (The '0' character) the way to indicate that a filter rule is untagged, rather than NULL (0x00)? My understanding is that there may not be an easy way to enter in a NULL character in an ASCII string within some RADIUS server implementations, whereas entering a '0' character is easy. Here is the current text: Tag The Tag field is one octet, and MUST always be present. It is used to identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule MUST be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of zero (0) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of zero MUST NOT be concatenated, and one or more Filter-Rule attributes with a tag value of zero may be included in a single RADIUS packet, each describing a single filter rule. With the change, it might look like this: The Tag field is one octet, and MUST always be present. It is used to identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule MUST be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of '0' (0x30) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of 0x30 MUST NOT be concatenated, and one or more Filter-Rule attributes with a tag value of 0x31 may be included in a single RADIUS packet, each describing a single filter rule. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 Aug 2006 01:16:25 +0000 Date: Sat, 26 Aug 2006 21:15:53 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified Message-ID: <20060827011553.GA92206@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Sat, Aug 26, 2006 at 04:25:21PM -0700, Glen Zorn (gwz) wrote: > Barney Wolff scribbled on Saturday, August > 26, 2006 4:00 PM: > > > On Sat, Aug 26, 2006 at 01:45:00PM -0700, Glen Zorn (gwz) wrote: > >> Barney Wolff scribbled on Saturday, > >> August 26, 2006 12:34 PM: > >> > >>> I agree that the behavior should be specified. It would seem that > >>> this is an opportunity to take advantage of Diameter's M-bit in > >>> governing the gateway's behavior. > >> > >> Not sure how the M-bit helps. Can you elaborate? > > > > Sorry, I thought it was obvious: An attribute lacking the M-bit may > > legitimately be ignored, so may be eliminated in translation. Not so > > if the M-bit is set. > > Right, but RFC 4005 says that the M-bit MUST be set on the > NAS-Filter-Rule AVP... Sigh. It seems to me that 3588 4.1 at least in spirit says that a gateway getting an attribute with an M-bit that it cannot for whatever reason translate, MUST reject the message. I would truly hate to have to specify gateway behavior for each attribute type, and hate even more having to implement type-specific behavior, just to handle message overflow - or, for that matter, for any other reason. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 23:25:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sat, 26 Aug 2006 16:25:21 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502816819@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Diameter-RADIUS gateway behavior not completely specified Thread-Index: AcbJY2Y5C5mZrs1vRuiITL2Sj1db6gAACz4Q From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=802; t=1156634723; x=1157498723; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Issue=3A=20Diameter-RADIUS=20gateway=20behavior=20not=20complete ly=20specified; X=v=3Dcisco.com=3B=20h=3Dm7E3Pmh6ma+lb09sBcSrQ2HAMMo=3D; b=CgQc/9pO6MsXgyBMNxvI7qZV793ID3jAW55ao/y0qZrbM07D31COr4nJD/oHtr1ThSLUeirp 141GMLM5RJrXiffjg8C71AtDTqrd7es8xuyaOjVLC9ukG1eP5N16FRgH; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff scribbled on Saturday, August 26, 2006 4:00 PM: > On Sat, Aug 26, 2006 at 01:45:00PM -0700, Glen Zorn (gwz) wrote: >> Barney Wolff scribbled on Saturday, >> August 26, 2006 12:34 PM:=20 >>=20 >>> I agree that the behavior should be specified. It would seem that >>> this is an opportunity to take advantage of Diameter's M-bit in >>> governing the gateway's behavior. >>=20 >> Not sure how the M-bit helps. Can you elaborate? >=20 > Sorry, I thought it was obvious: An attribute lacking the M-bit may > legitimately be ignored, so may be eliminated in translation. Not so > if the M-bit is set.=20 Right, but RFC 4005 says that the M-bit MUST be set on the NAS-Filter-Rule AVP... Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 23:01:00 +0000 Date: Sat, 26 Aug 2006 19:00:10 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified Message-ID: <20060826230010.GA64829@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Sat, Aug 26, 2006 at 01:45:00PM -0700, Glen Zorn (gwz) wrote: > Barney Wolff scribbled on Saturday, August > 26, 2006 12:34 PM: > > > I agree that the behavior should be specified. It would seem that > > this is an opportunity to take advantage of Diameter's M-bit in > > governing the gateway's behavior. > > Not sure how the M-bit helps. Can you elaborate? Sorry, I thought it was obvious: An attribute lacking the M-bit may legitimately be ignored, so may be eliminated in translation. Not so if the M-bit is set. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 20:45:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sat, 26 Aug 2006 13:45:00 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502816813@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Diameter-RADIUS gateway behavior not completely specified Thread-Index: AcbJRuIBsNWZuwCMQJadLyJNOxi8+QACXyTg From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=360; t=1156625102; x=1157489102; c=relaxed/simple; s=sjdkim4002; 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 |Subject:RE=3A=20Issue=3A=20Diameter-RADIUS=20gateway=20behavior=20not=20complete ly=20specified; X=v=3Dcisco.com=3B=20h=3Dm7E3Pmh6ma+lb09sBcSrQ2HAMMo=3D; b=aWccMlyNyw5Dwty8k2y/YzhmpClMNMIPgrb8XU8E2jFTI89t7f5l+/Fjd8ke5+7FqZKj53ka UIoZnAXrQiaZHUtsOAYNdYg1OHeOHOlv1xQ8VMgRKHf73MVKU+Jzn7oL; Authentication-Results: sj-dkim-4.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff scribbled on Saturday, August 26, 2006 12:34 PM: > I agree that the behavior should be specified. It would seem that > this is an opportunity to take advantage of Diameter's M-bit in > governing the gateway's behavior. =20 Not sure how the M-bit helps. Can you elaborate? ... Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 20:39:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sat, 26 Aug 2006 13:38:32 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502816812@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Diameter-RADIUS gateway behavior not completely specified Thread-Index: AcbJSJHmvzYSF6UfQkW9+qWhmyO/jAABpDZw From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1151; t=1156624714; x=1157488714; c=relaxed/simple; s=sjdkim2002; 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 |Subject:RE=3A=20Issue=3A=20Diameter-RADIUS=20gateway=20behavior=20not=20complete ly=20specified; X=v=3Dcisco.com=3B=20h=3Dm7E3Pmh6ma+lb09sBcSrQ2HAMMo=3D; b=AkWPu32SP1cotH1xM5yWWOh7pJcE2JOY7r/XP6+sdfjn6rfrLOi7g+zZ9Wr0zUB/0BESHmL+ V3TFhvlGBU6L1y/GxhQuiOHKUnx/7lG1FNZATOsSXFMOqYNCF0nGHHkJ; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba scribbled on Saturday, August 26, 2006 12:48 PM: >> I agree that the behavior should be specified. It would seem that >> this is an opportunity to take advantage of Diameter's M-bit in >> governing the gateway's behavior. >=20 > In theory the Diameter/RADIUS gateway could discard Diameter AVPs > without the 'M' bit set in order to fit within the RADIUS packet size > limit. =20 > However if there are multiple attributes of a given type, it might > not be appropriate to discard some but not all of them. So in > practice, the rules might get quite complex. If we believe that this > is a problem which is only likely to occur due to mis-configuraiton, > then it might be better for the gateway just to indicate that a > problem has occurred to the source and destination and leave it at > that. =20 In this case, I think the problem would likely stem from misconfiguration, but in general I don't believe that that is a good assumption. I'm seeing requests to send truly huge objects via Diameter (& therefore, potentially through RADIUS) Hope this helps, ~gwz -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 19:48:26 +0000 Message-ID: From: "Bernard Aboba" To: barney@databus.com, gwz@cisco.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sat, 26 Aug 2006 12:48:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I agree that the behavior should be specified. It would seem that this >is an opportunity to take advantage of Diameter's M-bit in governing >the gateway's behavior. In theory the Diameter/RADIUS gateway could discard Diameter AVPs without the 'M' bit set in order to fit within the RADIUS packet size limit. However if there are multiple attributes of a given type, it might not be appropriate to discard some but not all of them. So in practice, the rules might get quite complex. If we believe that this is a problem which is only likely to occur due to mis-configuraiton, then it might be better for the gateway just to indicate that a problem has occurred to the source and destination and leave it at that. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 19:43:16 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com, radiusext@ops.ietf.org Bcc: Subject: RE: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sat, 26 Aug 2006 12:43:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed I think the major issue here is translation from Diameter to RADIUS in the case where the translated RADIUS packet does not fit within the maxium (4096) byte packet size. Is that correct? This problem is not unique to the NAS-Filter-Rule, so if possible I'd prefer a general solution, rather than one specific to NAS-Filter-Rule. My take is that a solution: a. Needs to notify the Diameter client or server of the problem so that it can be logged and hopefully fixed; b. Needs to avoid sending an illegal RADIUS packet. The way to think about this is that the Diameter/RADIUS proxy conceptually translates the Diameter message to a RADIUS packet and then checks whether it fits within the length constraints. If not, then it needs to translate the oversize RADIUS packet to something else rather than sending it. This problem can even occur in other scenarios, such as a RADIUS proxy which attempts to add a Proxy-State attribute but finds that the packet exceeds the 4096 octet size limit. My suggestion is to translate an oversize RADIUS Access-Accept into a RADIUS Access-Reject with an Error-Cause attribute of value 505 "Other Proxy Processing Error ". Not sure what Diameter error message would be appropriate. In the case of server-initiated messages, I think the correct thing is to translate an oversize RADIUS CoA-Request to a Disconnect-Request, also with Error-Cause value 505. ========================================================== >Description of issue: Diameter-RADIUS gateway behavior not completely >specified >Submitter name: Glen Zorn >Submitter email address: gwz@cisco.com >Date first submitted: 26 Aug 06 >Document: draft-ietf-radext-filter-01.txt >Comment type: T >Priority: 1 >Section: 4 >Rationale/Explanation of issue: The last sentence of section 4 says >"Note that since a Diameter AVP can be larger than the maximum RADIUS >packet size (4096), translation from Diameter to RADIUS may not be >possible in all cases." While this is true, the behavior of the >Diameter-RADIUS gateway in this case is left unspecified. Is the >response forwarded back toward the requests' originator without the >untranslatable AVPs? In the case of an Access-Accept message, Section >1.2 says "If a NAS conforming to this specification receives an >Access-Accept packet containing a NAS-Filter-Rule attribute which it >cannot apply, it MUST act as though it had received an Access-Reject.", >it might be reasonable for the gateway to translate the Access-Accept >into an Access-Reject, since an attribute that is missing because >untranslatable can obviously not be applied. In the case of a CoA >message with an untranslatable attribute, should the message be >translated into a Disconnect-Request or just discarded? Or in both >cases, should the gateway respond to the originating/responding Diameter >peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and >let it figure out the next step? If so, it still seems that the peers >behavior must be specified. > >-- >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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 19:36:22 +0000 Date: Sat, 26 Aug 2006 15:33:50 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: Issue: Diameter-RADIUS gateway behavior not completely specified Message-ID: <20060826193350.GA15526@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 I agree that the behavior should be specified. It would seem that this is an opportunity to take advantage of Diameter's M-bit in governing the gateway's behavior. On Sat, Aug 26, 2006 at 11:54:58AM -0700, Glen Zorn (gwz) wrote: > Description of issue: Diameter-RADIUS gateway behavior not completely > specified > Submitter name: Glen Zorn > Submitter email address: gwz@cisco.com > Date first submitted: 26 Aug 06 > Document: draft-ietf-radext-filter-01.txt > Comment type: T > Priority: 1 > Section: 4 > Rationale/Explanation of issue: The last sentence of section 4 says > "Note that since a Diameter AVP can be larger than the maximum RADIUS > packet size (4096), translation from Diameter to RADIUS may not be > possible in all cases." While this is true, the behavior of the > Diameter-RADIUS gateway in this case is left unspecified. Is the > response forwarded back toward the requests' originator without the > untranslatable AVPs? In the case of an Access-Accept message, Section > 1.2 says "If a NAS conforming to this specification receives an > Access-Accept packet containing a NAS-Filter-Rule attribute which it > cannot apply, it MUST act as though it had received an Access-Reject.", > it might be reasonable for the gateway to translate the Access-Accept > into an Access-Reject, since an attribute that is missing because > untranslatable can obviously not be applied. In the case of a CoA > message with an untranslatable attribute, should the message be > translated into a Disconnect-Request or just discarded? Or in both > cases, should the gateway respond to the originating/responding Diameter > peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and > let it figure out the next step? If so, it still seems that the peers > behavior must be specified. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 18:55:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Diameter-RADIUS gateway behavior not completely specified Date: Sat, 26 Aug 2006 11:54:58 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502816805@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Diameter-RADIUS gateway behavior not completely specified Thread-Index: AcbJQSDkls0219rNSxWRyezdu3OIdw== From: "Glen Zorn \(gwz\)" To: Cc: "Glen Zorn \(gwz\)" DKIM-Signature: a=rsa-sha1; q=dns; l=1547; t=1156618501; x=1157482501; c=relaxed/simple; s=sjdkim2002; 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 |Subject:Issue=3A=20Diameter-RADIUS=20gateway=20behavior=20not=20completely=20spe cified; X=v=3Dcisco.com=3B=20h=3DeoNuFKhaFBJ829ODjRRC99UNtKo=3D; b=Fi52CR5U1Lid3tYMGRyK5kiLGTDoWd+yrVEBgMKXP7/5qSt18CMLvw2CMKKY16g5ehwwoOOL foOqTggCI9wd4LcXFTqgGX275DEw3hXjCjBw+UxMzQIhTI8nO2icZGE7; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Description of issue: Diameter-RADIUS gateway behavior not completely specified Submitter name: Glen Zorn Submitter email address: gwz@cisco.com Date first submitted: 26 Aug 06 Document: draft-ietf-radext-filter-01.txt Comment type: T Priority: 1 Section: 4=20 Rationale/Explanation of issue: The last sentence of section 4 says "Note that since a Diameter AVP can be larger than the maximum RADIUS packet size (4096), translation from Diameter to RADIUS may not be possible in all cases." While this is true, the behavior of the Diameter-RADIUS gateway in this case is left unspecified. Is the response forwarded back toward the requests' originator without the untranslatable AVPs? In the case of an Access-Accept message, Section 1.2 says "If a NAS conforming to this specification receives an Access-Accept packet containing a NAS-Filter-Rule attribute which it cannot apply, it MUST act as though it had received an Access-Reject.", it might be reasonable for the gateway to translate the Access-Accept into an Access-Reject, since an attribute that is missing because untranslatable can obviously not be applied. In the case of a CoA message with an untranslatable attribute, should the message be translated into a Disconnect-Request or just discarded? Or in both cases, should the gateway respond to the originating/responding Diameter peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and let it figure out the next step? If so, it still seems that the peers behavior must be specified. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 17:43:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Zero Tag field in Filter-Rule attribute Date: Sat, 26 Aug 2006 10:41:48 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625028167F8@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue: Zero Tag field in Filter-Rule attribute Thread-Index: AcbJH1A8Ni1n1KlGQb2f+rA85r0TrgAFy9qw From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , DKIM-Signature: a=rsa-sha1; q=dns; l=1198; t=1156614152; x=1157478152; 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 |Subject:RE=3A=20Issue=3A=20Zero=20Tag=20field=20in=20Filter-Rule=20attribute; X=v=3Dcisco.com=3B=20h=3D+76HfFOWQnbnvzqF477xcnV8Yq8=3D; b=PUxzeKqTC8dFcKyGKy2uvEpyspLn3MupNbXhJDAGhtvgbSMcrPx95Ge7GPK2l6I43bHqIazs 1NPSE4QQBppQ9kYUPmGfw+WMSn3HAqt62RTvaS45dWDYCZu7ATO56Zn5; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> scribbled on Saturday, August 26, 2006 7:52 AM: ,,, >=20 > My suggestion is that a value of zero (0) be used to indicate a > filter-rule that is less than 253 octets, so that concenation if not > required, and multiple filter-rules can utilize the same zero (0) > value. Here is the proposed text: =20 >=20 > Tag >=20 > The Tag field is one octet, and MUST always be present. It is > used to identify the filter rule that is represented. Where a > single filter rule exceeds 253 octets in length, the rule may > be encoded across multiple NAS-Filter-Rule attributes, each > with the same non-zero Tag value; non-zero Tag values MUST be > unique for each filter rule present in a RADIUS packet. The > value of zero (0) in the Tag field indicates that the > attribute contains a filter rule that does not exceed 253 > octets in length; as a result attributes with a Tag value of > zero MUST NOT be concatenated, and multiple Filter-Rule > attributes with a tag value of zero may be included in a > single RADIUS packet.=20 Looks good to me. Hope this helps, ~gwz=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 Aug 2006 14:52:53 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Issue: Zero Tag field in Filter-Rule attribute Date: Sat, 26 Aug 2006 07:52:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Issue: Zero Tag field in Filter-Rule attribute Submitter name: David Nelson Submitter email address: dnelson at enterasys.com Date first submitted: August 26, 2006 Reference: Document: Filter-Rule-02 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: Currently the document does not describe how the Tag value of zero is handled. I would suggest that the Tag value of 0 be reserved as an indicator of un-tagged attributes. If it is not already clear from the diagram and text, we should clarify that this Tag is not optional, as it is for strings in 2868. [BA] My suggestion is that a value of zero (0) be used to indicate a filter-rule that is less than 253 octets, so that concenation if not required, and multiple filter-rules can utilize the same zero (0) value. Here is the proposed text: Tag The Tag field is one octet, and MUST always be present. It is used to identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule may be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of zero (0) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of zero MUST NOT be concatenated, and multiple Filter-Rule attributes with a tag value of zero may be included in a single RADIUS packet. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 Aug 2006 21:26:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Fri, 25 Aug 2006 14:25:54 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625028166AA@xmb-sjc-215.amer.cisco.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbIUm2mUKuRasF1R9Oz915gNKO7eAAAEjLwAA4dw0A= From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=2813; t=1156541156; x=1157405156; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Glen's=20proposal=20for=20Attribute=20Extension; X=v=3Dcisco.com=3B=20h=3DIXDrJPE47xLdwGcAR7WHnL65pxI=3D; b=HQ5Ql6z7J03Mg5n3fXWfwVcIOWXEeMnFYt9Csxpqe7w7QmBsPWmD+GZbCzyFBuqvOSX2F99s l09ZMuoJL9zrSxqHB+KqyuO6B4lwxJxC0VlWepaan1zvN/DDvvHOxLk1; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David <> scribbled on Friday, August 25, 2006 7:44 AM: > Bernard Aboba writes... >=20 >> One of the motivations for this proposal was that it could be >> implemented with no change to code on existing RADIUS servers, >> because a single octet extended type was used, making it compatible >> with the VSA format suggested in RFC 2865. >=20 > I think we need to explore the "no code change" assertion. If we are > limiting the discussion of changes to the RADIUS attribute parser > code that looks at command code and attribute ID, then it's true that > no changes, are required. However, once the parser determines that > its type 26, a second level of parsing is required. The vendor OUI > needs to be recognized as well as any vendor types. Assuming (and > this may be a big assumption) that your data dictionary driven > implementation allows you to enroll new vendor OUIs and associate > them with a list of vendor types, it may be possible to implement > this suggestion without any code changes. =20 >=20 > I think that once you add the tag, some code changes likely to be > required. We are only discussing servers here. I think we all agree > that NASes and policy-enforcing proxies need to have code changes to > encompass the semantics of the new attributes.=20 OK. probably "minimal code changes" would be more accurate than "no code changes". However, the strength of the proposal remains, I think, in that the features already exist in both clients and servers, just in different combinations. =20 >=20 >> Given that, why would the attribute type need to be changed? >=20 > One additional reason that I would like to see the VSA ID not used is > that RFC 2865 permits free-format VSAs, notwithstanding the > recommendation to re-use the basic TLV format. =20 ??? We are still talking about computers here, right? If so, to the best of my knowledge computers don't deal well with "free-form" ;-). The formats of VSAs must be well defined, even if not standard. > We need to retain > that freedom for VSAs. I would like to curtail that freedom for the > Extended RADIUS Attributes, and mandate use of the basic TLV format, > along with use of basic RADIUS data types. =20 OK. =20 >=20 > I think it's clear from the analysis in the Design Guidelines draft > that the data models for VSA and standard attribute spaces have > diverged. I thought it was a goal of the WG to bring them back > together for the extended attributes. I don't think it would be very > clear that the format restrictions apply only to VSAs with a > particular OUI value. =20 Well, I think that it would be as clear as we wanted to make it. If we publish an RFC that has "MUST" surrounding the formats, that seems pretty clear to me. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 Aug 2006 21:08:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Fri, 25 Aug 2006 14:07:55 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250281668A@xmb-sjc-215.amer.cisco.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbGJ9aNAPsrlNy0RceWpp8XQfvZDgCJVwEAAACVlkAADqNPYA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" , DKIM-Signature: a=rsa-sha1; q=dns; l=2963; t=1156540077; x=1157404077; 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 |Subject:RE=3A=20Glen's=20proposal=20for=20Attribute=20Extension; X=v=3Dcisco.com=3B=20h=3DIXDrJPE47xLdwGcAR7WHnL65pxI=3D; b=n6WnTgdMSK58V+ZQRlLFajGm4f/wg/ITV4KTwMFxycSPfCM93ZecK7Z+2DzbHMwLMsC0P3g9 QKzZ45muE/6+69ftx8yzPb4drJax8j135bzIaJDcBXSDCayYs/bsI2rG; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David <> scribbled on Friday, August 25, 2006 7:09 AM: > Uggh! Let me try again, to get the ASCII art aligned. I really > dislike the line-wrap behavior of my current e-mail client, when it > comes to plain text messages, with ">" quoting characters inserted. =20 >=20 > Glen has also suggested, as have others, that a fixed tag field > could/should be used to address issues of attribute grouping. The > tag does not show up in this layout. =20 >=20 >> 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 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >=20 > If we were to add it, would the format look like this? Yes, sorry for the confusion. >=20 > 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... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >=20 > An additional question -- are we suggesting that this format is a > MUST for the Extended RADIUS Attributes, as opposed to the merely > suggested format for VSAs? I think we should do so. =20 Me, too. >=20 > I also think that maybe we want to not use the VSA attribute type > (26) for this purpose.=20 Not sure why... >=20 >>=20 >> Type >>=20 >> 26 for Vendor-Specific. >>=20 >> Length >>=20 >> >=3D 7 >>=20 >> Vendor-Id >>=20 >> 0 (for Extended Attributes) >>=20 >> Extended Type >>=20 >> 0: Reserved >> 1-250: Allocated by IANA >> 250-255: Reserved >>=20 >> Length2 >>=20 >> >=3D0 >>=20 >> Multiple subattributes MAY be encoded within a single Extended >> Attribute, although they do not have to be. >=20 > Tag >=20 > 0: Not Used (i.e. attribute is untagged) > 1-255: Tag value used to aggregate attributes into groups >=20 > The value of the Tag field MAY be limited to printable ASCII values, > for ease of human entry and interpretation.=20 >=20 >> For Diameter compatibility, the RADIUS Extended Type attributes >> would need to be allocated within the Diameter AVP space. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 Aug 2006 14:44:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Fri, 25 Aug 2006 10:44:27 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219410@MABOSEVS2.ets.enterasys.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbIUm2mUKuRasF1R9Oz915gNKO7eAAAEjLw From: "Nelson, David" To: Bernard Aboba writes... > One of the motivations for this proposal was that it could be implemented > with no change to code on existing RADIUS servers, because a single octet > extended type was used, making it compatible with the VSA format suggested > in RFC 2865. I think we need to explore the "no code change" assertion. If we are limiting the discussion of changes to the RADIUS attribute parser code that looks at command code and attribute ID, then it's true that no changes, are required. However, once the parser determines that its type 26, a second level of parsing is required. The vendor OUI needs to be recognized as well as any vendor types. Assuming (and this may be a big assumption) that your data dictionary driven implementation allows you to enroll new vendor OUIs and associate them with a list of vendor types, it may be possible to implement this suggestion without any code changes. I think that once you add the tag, some code changes likely to be required. We are only discussing servers here. I think we all agree that NASes and policy-enforcing proxies need to have code changes to encompass the semantics of the new attributes. > Given that, why would the attribute type need to be changed? One additional reason that I would like to see the VSA ID not used is that RFC 2865 permits free-format VSAs, notwithstanding the recommendation to re-use the basic TLV format. We need to retain that freedom for VSAs. I would like to curtail that freedom for the Extended RADIUS Attributes, and mandate use of the basic TLV format, along with use of basic RADIUS data types. I think it's clear from the analysis in the Design Guidelines draft that the data models for VSA and standard attribute spaces have diverged. I thought it was a goal of the WG to bring them back together for the extended attributes. I don't think it would be very clear that the format restrictions apply only to VSAs with a particular OUI value.=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 Aug 2006 14:26:19 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: Glen's proposal for Attribute Extension Date: Fri, 25 Aug 2006 07:26:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I also think that maybe we want to not use the VSA attribute type (26) >for this purpose. One of the motivations for this proposal was that it could be implemented with no change to code on existing RADIUS servers, because a single octet extended type was used, making it compatible with the VSA format suggested in RFC 2865. Given that, why would the attribute type need to be changed? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 Aug 2006 14:09:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Fri, 25 Aug 2006 10:09:25 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021940F@MABOSEVS2.ets.enterasys.com> Thread-Topic: RE: Glen's proposal for Attribute Extension Thread-Index: AcbGJ9aNAPsrlNy0RceWpp8XQfvZDgCJVwEAAACVlkA= From: "Nelson, David" To: Uggh! Let me try again, to get the ASCII art aligned. I really dislike the line-wrap behavior of my current e-mail client, when it comes to plain text messages, with ">" quoting characters inserted. Glen has also suggested, as have others, that a fixed tag field could/should be used to address issues of attribute grouping. The tag does not show up in this layout. > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- If we were to add it, would the format look like this? 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- An additional question -- are we suggesting that this format is a MUST for the Extended RADIUS Attributes, as opposed to the merely suggested format for VSAs? I think we should do so. I also think that maybe we want to not use the VSA attribute type (26) for this purpose. =20 >=20 > Type >=20 > 26 for Vendor-Specific. >=20 > Length >=20 > >=3D 7 >=20 > Vendor-Id >=20 > 0 (for Extended Attributes) >=20 > Extended Type >=20 > 0: Reserved > 1-250: Allocated by IANA > 250-255: Reserved >=20 > Length2 >=20 > >=3D0 >=20 > Multiple subattributes MAY be encoded within a single Extended > Attribute, although they do not have to be. Tag 0: Not Used (i.e. attribute is untagged) 1-255: Tag value used to aggregate attributes into groups The value of the Tag field MAY be limited to printable ASCII values, for ease of human entry and interpretation. =20 > For Diameter compatibility, the RADIUS Extended Type attributes would need > to be allocated within the Diameter AVP space. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 Aug 2006 13:59:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Fri, 25 Aug 2006 09:59:13 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021940E@MABOSEVS2.ets.enterasys.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbGJ9aNAPsrlNy0RceWpp8XQfvZDgCJVwEA From: "Nelson, David" To: Glen has also suggested, as have others, that a fixed tag field could/should be used to address issues of attribute grouping. The tag does not show up in this layout. > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- If we were to add it, would the format look like this? 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 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Extended type | Length2 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- An additional question -- are we suggesting that this format is a MUST for the Extended RADIUS Attributes, as opposed to the merely suggested format for VSAs? I think we should do so. I also think that maybe we want to not use the VSA attribute type (26) for this purpose. =20 >=20 > Type >=20 > 26 for Vendor-Specific. >=20 > Length >=20 > >=3D 7 >=20 > Vendor-Id >=20 > 0 (for Extended Attributes) >=20 > Extended Type >=20 > 0: Reserved > 1-250: Allocated by IANA > 250-255: Reserved >=20 > Length2 >=20 > >=3D0 >=20 > Multiple subattributes MAY be encoded within a single Extended > Attribute, although they do not have to be. Tag 0: Not Used (i.e. attribute is untagged) 1-255: Tag value used to aggregate attributes into groups The value of the Tag field MAY be limited to printable ASCII values, for ease of human entry and interpretation. =20 > For Diameter compatibility, the RADIUS Extended Type attributes would need > to be allocated within the Diameter AVP space. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 Aug 2006 19:27:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Glen's proposal for Attribute Extension Date: Thu, 24 Aug 2006 12:27:13 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625028161F0@xmb-sjc-215.amer.cisco.com> Thread-Topic: Glen's proposal for Attribute Extension Thread-Index: AcbGJ7iY1qSLMMaETemBGsImW/57VQBi016A From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1541; t=1156447634; x=1157311634; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Glen's=20proposal=20for=20Attribute=20Extension; X=v=3Dcisco.com=3B=20h=3DIXDrJPE47xLdwGcAR7WHnL65pxI=3D; b=e/itB7Kj6+p1JFYJBYhifitpP8VYzzC9Sb2jz6nn27Jjmmyrz192Y2UsjE35nGwDcFyUCRFK E69iMXKBv/tH0CwGZznL2ColOEAmFno4G3HiFQsxJSwEjX8EZjE6NxDw; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba scribbled on Tuesday, August 22, 2006 1:15 PM: Sorry for the tardy response: my laptop's been in the shop getting upgraded to WinXP. Anyway, yes, I think that pretty much covers it. Thanks for drawing it! > Is the below a reasonable description of your proposal? >=20 > 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 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20 > Type | Length | Vendor-Id > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vendor-Id (cont) | Extended type | Length2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20 > Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =20 >=20 > Type >=20 > 26 for Vendor-Specific. >=20 > Length >=20 > >=3D 7 >=20 > Vendor-Id >=20 > 0 (for Extended Attributes) >=20 > Extended Type >=20 > 0: Reserved > 1-250: Allocated by IANA > 250-255: Reserved >=20 > Length2 >=20 > >=3D0 >=20 > Multiple subattributes MAY be encoded within a single Extended > Attribute, although they do not have to be. >=20 >=20 > For Diameter compatibility, the RADIUS Extended Type attributes would > need to be allocated within the Diameter AVP space.=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 23 Aug 2006 13:39:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Review of draft-chowdhury-mip6-radius-02 Date: Wed, 23 Aug 2006 16:38:07 +0300 Message-ID: Thread-Topic: Issue: Review of draft-chowdhury-mip6-radius-02 Thread-Index: AcbGuV4pD8VLF9eZT/eQ1Xmve2bmaw== From: To: Cc: Review of draft-chowdhury-mip6-radius-02 Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 23, 2006 Reference:=20 Document: draft-chowdhury-mip6-radius-02 Comment type: T/E Priority: 1 Section: various Rationale/Explanation of issue: 1) The document should give all new attributes short names that=20 don't contain spaces (e.g. "MIP6-Home-Link-Prefix" or just "Home-Link-Prefix"). 2) Section 5: "The attributes MAY be present in the Access-Accept and the Accounting-Request." The accounting part is too ambiguous; does e.g. requesting DNS update really make sense for accounting messages? At the very least, the document should explicitly say what is=20 included in accounting messages and what it means. 3) Section 5.2: This attribute should use the same data type as other attributes containing FQDNs (i.e., just the FQDN, without the zeroes in the beginning). 4) Section 5.3: This attribute should use the same data type as other attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix=20 in RFC 3162). 5) Section 5.5: This section should describe that the status code field uses values defined in "draft-ietf-mip6-bootstrapping-split-02"; now it gives the impression that totally number space is created (but doesn't give any IANA considerations on how to manage it). 6) Section 5.5 first says "response to the request MAY not carry a FQDN value" but then changes its mind "The data field MUST contain a FQDN". 7) Section 5.5: This attribute should probably be split to 2..3 separate attributes (e.g. DNS-Update-FQDN and DNS-Update-Result); this would be better in line with other recent RADIUS documents. 8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits=20 MUST be initialized to zero by the sender, and MUST be ignored by=20 the receiver." 9) Section 8: According to Section 5, the first four attributes are sent by the RADIUS server to the NAS, so the first column should be=20 "0" instead of "0-1" (alternatively, Section 5 needs to specify what=20 these attributes mean in Access-Requests).=20 10) Section 8: The table should probably include accounting messages and CoA-Request as well. 11) For the split scenario, the document should define what to=20 put in Service-Type and NAS-Port-Type attributes (and maybe also Calling-Station-Id and Called-Station-Id). 12) The document talks about doing EAP authentication over RADIUS, but never mentions RFC 3579?=20 13) The document should either point to RFC 2548, or explicitly say that this document does not contain an interoperable solution for the split scenario, since it does not specify (either here or by referencing some other document) how to send the MSK from the RADIUS server to the HA. 14) The document should probably have at least informative=20 reference to RFC 4306. 15) And last (but not least, as everyone who has followed=20 RADEXT knows :-): the document does not have a Diameter considerations section. Best regards, Pasi -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 23 Aug 2006 07:41:38 +0000 Message-ID: <44EC066B.6010607@gmx.net> Date: Wed, 23 Aug 2006 09:40:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Nelson, David" CC: radiusext@ops.ietf.org Subject: Re: FW: [Geopriv] I-D ACTION:draft-ietf-geopriv-radius-lo-08.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David, after submitting the -08 version Pasi sent me some more comments. I have incorporated them as well and I am about to submit -09. Ciao Hannes Nelson, David schrieb: > WGLC on this draft in GEOPRIV and RADEXT has completed. The revised I-D > purports to addresses all comments received during WGLC. > > (Forwarded Message) > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Geographic Location/Privacy Working > Group of the IETF. > > Title : Carrying Location Objects in RADIUS > Author(s) : H. Tschofenig, et al. > Filename : draft-ietf-geopriv-radius-lo-08.txt > Pages : 57 > Date : 2006-8-14 > > This document describes RADIUS attributes for conveying access > network ownership and location information based on a civic and > geospatial location format. > > The distribution of location information is a privacy sensitive task. > Dealing with mechanisms to preserve the user's privacy is important > and addressed in this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-08.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-geopriv-radius-lo-08.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-geopriv-radius-lo-08.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 22:24:44 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: Glen's proposal for Attribute Extension cc: radiusext@ops.ietf.org Date: Tue, 22 Aug 2006 18:16:05 -0400 Message-Id: <20060822221605.1738916CBC@mail.nitros9.org> "Bernard Aboba" wrote: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Vendor-Id (cont) | Extended type | Length2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This doesn't solve the length problem, even if the extended types are allowed to span multiple VSA's. The attribute lengths are still limited to 253 bytes of data. And I'm a little leery of yet another 8-bit type field. I know the 8 bits in the current space aren't exhausted, and they've been sufficient for a decade. A 16-bit type would have little additional impact on the packet length, but would make attribute allocation much more open. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 21:14:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6C62F.F8E23E59" Subject: FW: [Geopriv] I-D ACTION:draft-ietf-geopriv-radius-lo-08.txt Date: Tue, 22 Aug 2006 17:14:36 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193FD@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Geopriv] I-D ACTION:draft-ietf-geopriv-radius-lo-08.txt Thread-Index: Aca/3XTuAV1O6reHQMGrlXcFCB9eywGUgTZw From: "Nelson, David" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C62F.F8E23E59 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC on this draft in GEOPRIV and RADEXT has completed. The revised I-D purports to addresses all comments received during WGLC. (Forwarded Message) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Carrying Location Objects in RADIUS Author(s) : H. Tschofenig, et al. Filename : draft-ietf-geopriv-radius-lo-08.txt Pages : 57 Date : 2006-8-14 =09 This document describes RADIUS attributes for conveying access network ownership and location information based on a civic and geospatial location format. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and addressed in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-08.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-radius-lo-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-radius-lo-08.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C6C62F.F8E23E59 Content-Type: application/octet-stream; name="draft-ietf-geopriv-radius-lo-08.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-geopriv-radius-lo-08.URL Content-Disposition: attachment; filename="draft-ietf-geopriv-radius-lo-08.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWdlb3ByaXYtcmFkaXVzLWxvLTA4LnR4dA0K ------_=_NextPart_001_01C6C62F.F8E23E59-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 21:14:26 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed Resolution to Issue 199: Attribute Length Date: Tue, 22 Aug 2006 14:13:59 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This issue pointed out that a single rule cannot be less than 32 octets in length. However, with the proposed Tag format, it is possible for a rule fragment to be included in the value field of a NAS-Filter-Rule attribute. Such a fragment could be as small as 1 octet. Therefore the minimum length of the modified NAS-Filter-Rule attribute appears to be 4 octets. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 21:06:32 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for Review: draft-ietf-radext-filter-01.txt Date: Tue, 22 Aug 2006 14:06:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The Filter document has been updated to address Issues 198 and 199. The latest version is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-01.txt Comments welcome. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 21:02:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Request from MIP6 WG on a Radius I-D Date: Tue, 22 Aug 2006 17:01:04 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193FB@MABOSEVS2.ets.enterasys.com> Thread-Topic: Request from MIP6 WG on a Radius I-D Thread-Index: AcbGIOiVJwjqrjIUEduldAARJNUNiAAAE7+AAAHkxSAAASUkqAAAB/8Q From: "Nelson, David" To: "Basavaraj Patil" , Basavaraj Patil writes... > Just for my own clarification here, are you recommending that the > I-D be considered as a MIP6 WG document but go through a cross-WG > review? Yes. We've done this with a RADIUS document in the GEOPRIV WG. Cross-WG review is requested, and simultaneous WGLC on the draft is held in each WG. > In which case the MIP6 WG would be responsbile for the process of > advancing the I-D. Yes, once WGLC comments from both MIP6 and RADEXT have been satisfactorily resolved. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 20:30:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Request from MIP6 WG on a Radius I-D Date: Tue, 22 Aug 2006 16:30:07 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193F9@MABOSEVS2.ets.enterasys.com> Thread-Topic: Request from MIP6 WG on a Radius I-D Thread-Index: AcbGIOiVJwjqrjIUEduldAARJNUNiAAAE7+AAAHkxSA= From: "Nelson, David" To: Cc: "Basavaraj Patil" A point of clarification. > We (MIP6 WG chairs) would like to request that this I-D=20 > be reviewed and advanced in the RADEXT WG. The RADEXT WG chairs are interpreting this as a request for Cross-WG review. The subject draft is not on the charter for the RADEXT WG, but I believe it is on the charter of the MIP6 WG. Therefore, document is not eligible for advancement in the RADEXT WG. However, the RADEXT WG members are requested to review and comment upon the MIP6 RADIUS draft, much as we have done previously for the GEOPRIV RADIUS draft. =20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 20:15:46 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com, radiusext@ops.ietf.org Bcc: Subject: Glen's proposal for Attribute Extension Date: Tue, 22 Aug 2006 13:15:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Is the below a reasonable description of your proposal? 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 26 for Vendor-Specific. Length >= 7 Vendor-Id 0 (for Extended Attributes) Extended Type 0: Reserved 1-250: Allocated by IANA 250-255: Reserved Length2 >=0 Multiple subattributes MAY be encoded within a single Extended Attribute, although they do not have to be. For Diameter compatibility, the RADIUS Extended Type attributes would need to be allocated within the Diameter AVP space. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 Aug 2006 19:40:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FW: Request from MIP6 WG on a Radius I-D Date: Tue, 22 Aug 2006 15:39:59 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193F7@MABOSEVS2.ets.enterasys.com> Thread-Topic: Request from MIP6 WG on a Radius I-D Thread-Index: AcbGIOiVJwjqrjIUEduldAARJNUNiAAAE7+A From: "Nelson, David" To: Forwarded Message From: Basavaraj Patil The MIP6 WG has been working on developing bootstrapping solutions over the last 18+ months. The Bootstrapping solution specified in the MIP6 WG is a framework that includes building blocks using various protocols. One of the building blocks therein is Radius (interaction between the HA and the AAA server). The MIP6 WG bootstrapping I-Ds are: 1. Problem Statement for bootstrapping Mobile IPv6 (In the RFC Editor Queue) http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-05.txt 2. Mobile IPv6 bootstrapping in split scenario (I-D Exists) http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- 02.txt 3. MIP6-bootstrapping via DHCPv6 for the Integrated Scenario (I-D Exists) http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr ated-dhc-01.txt The Radius specific I-D is draft-chowdhury-mip6-radius-02.txt, and this is required for the overall bootstrapping solution. (I-D Exists) http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-radius-02.txt We (MIP6 WG chairs) would like to request that this I-D be reviewed and advanced in the RADEXT WG. The MIP6 WG itself has been asked to review and comment on it and no issues have been identified. If you need any MIP6 specific help in reviewing this I-D, please let us know.=20 Please direct comments to the RADEXT WG list, and use the Issue Tracker template found at: http://www.drizzle.com/~aboba/RADEXT/ -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 21 Aug 2006 23:20:58 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-filter-01.txt Message-Id: Date: Mon, 21 Aug 2006 18:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Filter Rule Attribute Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-filter-01.txt Pages : 9 Date : 2006-8-21 This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS), equivalent to the Diameter NAS-Filter-Rule AVP described in RFC 4005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-filter-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-filter-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-21151549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-filter-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-filter-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-21151549.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 18 Aug 2006 21:25:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Fri, 18 Aug 2006 14:24:56 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279DA12@xmb-sjc-215.amer.cisco.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfbfsgSY0sfPKTVaAD2JqLWmFJQAqlCbgAA5wBBAAJReEQAAFf+YQ From: "Glen Zorn \(gwz\)" To: "Nelson, David" , DKIM-Signature: a=rsa-sha1; q=dns; l=1736; t=1155936299; x=1156800299; c=relaxed/simple; s=sjdkim5002; 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 |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=MREyoHBWNmNOj2E4I61lDhzOOCP0uHQIIWixi7Az0Lx9zoDJ3aGtwFVYAJ1f31VJjM5fOiDB D8IT/GPEuc1l17edxfCa0LUnjb6vbZKnN1h1ZpWx4rWdtZP9ItwKMlxq; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David <> supposedly scribbled: > Glen Zorn writes... >=20 >>> (2) A standard method of encoding "over-size" attributes (those >>> greater than 253 but less than the RADIUS PDU size). >>=20 >> Didn't we already have that? >=20 > Not in a formally specified, generic way. As a common practice, and > for specific attributes, sure.=20 IIRC, it was one of the major reasons for specifying that attributes may = not be re-ordered by proxies. How formal and generic do you want it to = be? >=20 >> One problem it doesn't solve, though, is that of requiring code >> changes in servers & clients. I'm still wondering why we think that >> 2 bytes are really needed for "Extended Type". >=20 > One reason is to be very sure that we solve the shortage of standard > attribute IDs for all time. Let's do this once, and be done with it. > The proposal to define an Extended Type ID of zero as the > "continuation" =20 > flag would probably create the need for revised code, even if the > Extended Length field were limited to one octet.=20 Just one more reason that it's not that good of an idea. >=20 >> Also (just to note), the lack of a second Length field means that >> extended attributes can't be packed, unlike VSAs. >=20 > Is that a bad thing? An unreasonable restriction? It's a useful feature that is not lost w/my proposal. >=20 >> Grouping could be handled w/tags, a la RFC 2868. >=20 > Yes, I agree, with the caveat that the tag fields are fixed, and not > optional. I think you expressed a similar sentiment.=20 Yup. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 18 Aug 2006 18:53:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Fri, 18 Aug 2006 14:52:09 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193EA@MABOSEVS2.ets.enterasys.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfbfsgSY0sfPKTVaAD2JqLWmFJQAqlCbgAA5wBBAAJReEQA== From: "Nelson, David" To: Glen Zorn writes... > > (2) A standard method of encoding "over-size" attributes (those > > greater than 253 but less than the RADIUS PDU size). >=20 > Didn't we already have that? Not in a formally specified, generic way. As a common practice, and for specific attributes, sure. > One problem it doesn't solve, though, is that of requiring code changes in > servers & clients. I'm still wondering why we think that 2 bytes are > really needed for "Extended Type". One reason is to be very sure that we solve the shortage of standard attribute IDs for all time. Let's do this once, and be done with it. The proposal to define an Extended Type ID of zero as the "continuation" flag would probably create the need for revised code, even if the Extended Length field were limited to one octet. > Also (just to note), the lack of a second Length field means that > extended attributes can't be packed, unlike VSAs. Is that a bad thing? An unreasonable restriction? > Grouping could be handled w/tags, a la RFC 2868. Yes, I agree, with the caveat that the tag fields are fixed, and not optional. I think you expressed a similar sentiment. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 18 Aug 2006 01:36:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Thu, 17 Aug 2006 18:36:26 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D83F@xmb-sjc-215.amer.cisco.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfD29X6mvHghmRliIfgbpb5fo0wA6GcqA From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1423; t=1155864988; x=1156728988; c=relaxed/simple; s=sjdkim7002; 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 |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=gibVDsUdqB06BgcH81XmdJ8Q6jKUXeTgcNQnjCcYWZsKc8UmPmK5+rq17Iy5jYWXp5qQyNfy HkoJWFSFY3OXBWShAUyewhaWLQrQ4xZfJdwnB9pLbmuUElH96hOTGwM/; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba supposedly scribbled: ... > 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. =20 I don't think it does, but I don't know why it would be any different = than the way normal attributes work. > One way to address this is via a tagging scheme. =20 Not sure why this would be necessary. If you think of the Vendor-Type = field as just an extension :-) of the standard Type field, then on = reception just cat all attributes w/the same "type" (in this case 26 + = Vendor-Type) together in order, creating one massive attribute. Where = this scheme falls apart is if there are more than one XXL attribute of = the same type in a message. I think that tags can fix this, though, as = well as providing a rudimentary attribute grouping capability. With = tags, the algorithm becomes "cat all the attributes w/the same = (Type+ExtType) and Tag together in order"; again, this only allows one = XXL attribute of a given (Type+ExtType) per attribute group, but I = suspect that that is probably adequate. ... 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 18 Aug 2006 01:21:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Thu, 17 Aug 2006 18:20:56 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D836@xmb-sjc-215.amer.cisco.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfbfsgSY0sfPKTVaAD2JqLWmFJQAqlCbgAA5wBBA= From: "Glen Zorn \(gwz\)" To: "Nelson, David" , DKIM-Signature: a=rsa-sha1; q=dns; l=1250; t=1155864060; x=1156728060; c=relaxed/simple; s=sjdkim2002; 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 |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=nvd4ocbUaY2EaSf6xicqqyhqWCdL3hmxLMgYjkHZE/3T0QLhR2v3i4JX0fwhrjhXT3FUmMBr isGhK8YXvBVFNHAbpy5N9k7EjrIFGkmgSeMsHcKSlR0f0qcxx9dQBuX4; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David <> supposedly scribbled: ... >=20 > This solves two problems: >=20 > (1) Exhaustion of ID space. >=20 > (2) A standard method of encoding "over-size" attributes (those > greater than 253 but less than the RADIUS PDU size).=20 Didn't we already have that? >=20 > I think this meets the requirements we've agreed to for Extended > Attributes.=20 One problem it doesn't solve, though, is that of requiring code changes = in servers & clients. I'm still wondering why we think that 2 bytes are = really needed for "Extended Type". Also (just to note), the lack of a = second Length field means that extended attributes can't be packed, = unlike VSAs. >=20 > There are other issues that we have *not* yet agreed to, such as how > to standardize structured data (grouping, sub-types, etc.).=20 Grouping could be handled w/tags, a la RFC 2868. >=20 > While we agreed to solve one problem at a time, I note there are > drafts waiting in the wings that need to take advantage of grouping > features, or at least are currently designed to use them. =20 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 17 Aug 2006 21:25:27 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Questions on RADIUS Extended attributes cc: radiusext@ops.ietf.org Date: Thu, 17 Aug 2006 17:17:03 -0400 Message-Id: <20060817211703.DC52716CBC@mail.nitros9.org> "Nelson, David" wrote: > By "list of such attributes", do you mean a sequence comprising an > initial attribute and continuation (concatenation) attributes? I was > thinking that removing one or more continuation attributes from the > middle of a sequence would be very bad. Yes, and yes. But most proxies either (1) forward everything unchanged, or (b) implement local policy. > Mangling by whom? Noticed by whom? It would certainly seem to me that > the NAS or the Server would notice! A proxying server that implements local policy enforcement has no business forwarding attributes it doesn't understand. A proxying server that does nothing more than routing or aggregation has no business changing the policies it's transporting. A NAS that expects Extended-Type has a trust relationship with a local RADIUS server. If that server doesn't understand Extended-Type, it (a) won't send Extended-Type to the NAS, or (b) has no business forwarding Extended-Type from a home server to the NAS. > Tagging would support grouping, but not nested grouping. Do we think > that single-level grouping is sufficient to solve the "80% problem"? I believe so. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 17 Aug 2006 19:36:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Thu, 17 Aug 2006 15:35:48 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193E9@MABOSEVS2.ets.enterasys.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbCMGpbiSdqEZ+aSJ6nRd1jEtSu2QAApYtA From: "Nelson, David" To: Alan DeKok writes... > The requirement to not add or delete the attributes is limited > to only those proxies that are unaware of the new attribute=20 > format. Those proxies might remove an Extended-Type attribute=20 > from the *middle* of a list of such attributes, which would be=20 > bad. By "list of such attributes", do you mean a sequence comprising an initial attribute and continuation (concatenation) attributes? I was thinking that removing one or more continuation attributes from the middle of a sequence would be very bad. > 2) policy-limiting forwarders. These servers act as forwarders > that authenticate remotely, but enforce local policy. In that case, > the Extended-Type attributes will either be understood locally (and > thus not mangled), or not understood (in which case mangling won't=20 > be noticed). Mangling by whom? Noticed by whom? It would certainly seem to me that the NAS or the Server would notice! > The main problem with this proposal is that it doesn't easily > support nested grouping. For that to work would require defining=20 > yet another attribute packing format. Or, Emile's tag suggestion=20 > would seem to work. Tagging would support grouping, but not nested grouping. Do we think that single-level grouping is sufficient to solve the "80% problem"? > My only requirement for a tagged format is that as Glen pointed=20 > out, the tags MUST ALWAYS exist. Optional tags are a nightmare. I absolutely agree. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 17 Aug 2006 19:07:58 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Questions on RADIUS Extended attributes cc: radiusext@ops.ietf.org Date: Thu, 17 Aug 2006 14:59:34 -0400 Message-Id: <20060817185934.B4C0116CBC@mail.nitros9.org> "Nelson, David" wrote: > And we clearly require that attributes of type TBD never be re-ordered, > added or deleted by proxies. The re-ordering requirement is already in RADIUS, of course. The requirement to not add or delete the attributes is limited to only those proxies that are unaware of the new attribute format. Those proxies might remove an Extended-Type attribute from the *middle* of a list of such attributes, which would be bad. We can try to work around that problem by increasing the complexity of the solution, or we can see if that problem exists today. Personally, I don't see it as much of a problem. Proxies generally fall into one of two categories: 1) blind forwarders who serve as aggregation points and/or application-layer routers. These forwarders don't modify the packet contents. The Extended-Type proposal doesn't affect these. 2) policy-limiting forwarders. These servers act as forwarders that authenticate remotely, but enforce local policy. In that case, the Extended-Type attributes will either be understood locally (and thus not mangled), or not understood (in which case mangling won't be noticed) > There are other issues that we have *not* yet agreed to, such as how to > standardize structured data (grouping, sub-types, etc.). The main problem with this proposal is that it doesn't easily support nested grouping. For that to work would require defining yet another attribute packing format. Or, Emile's tag suggestion would seem to work. My only requirement for a tagged format is that as Glen pointed out, the tags MUST ALWAYS exist. Optional tags are a nightmare. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 17 Aug 2006 18:15:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Thu, 17 Aug 2006 14:15:10 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193E8@MABOSEVS2.ets.enterasys.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfbfsgSY0sfPKTVaAD2JqLWmFJQAqlCbg From: "Nelson, David" To: Bernard Aboba writes... > Yes. So your proposal looks like this, no? >=20 > 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 | Extended-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value... > +-+-+-+-+-+-+-+-+ >=20 > Type >=20 > TBD (not 26) >=20 > Length >=20 > >=3D 4 >=20 > Extended-Type >=20 > Two octets. >=20 > 0: Concatenation > 1-255: Reserved > 255-65530: Allocated by IANA > 65531-65535: Reserved >=20 > Value >=20 > 0-251 octets (Length - 4). >=20 > Only a single RADIUS Extended-Type attribute may be included within > a RADIUS attribute of Type TBD. Where the value of the Extended- > Type field is zero (0), this indicates that the content of the value > field is to be concatenated with the contents of the value field in > the previous attribute of Type TBD. And we clearly require that attributes of type TBD never be re-ordered, added or deleted by proxies. This solves two problems: (1) Exhaustion of ID space. (2) A standard method of encoding "over-size" attributes (those greater than 253 but less than the RADIUS PDU size). I think this meets the requirements we've agreed to for Extended Attributes. There are other issues that we have *not* yet agreed to, such as how to standardize structured data (grouping, sub-types, etc.). While we agreed to solve one problem at a time, I note there are drafts waiting in the wings that need to take advantage of grouping features, or at least are currently designed to use them. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 17 Aug 2006 17:57:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Thu, 17 Aug 2006 13:56:44 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193E7@MABOSEVS2.ets.enterasys.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfGDoYdNJaFjtRj6VEt/0T6uZWgAqcTPw From: "Nelson, David" To: Bernard Aboba writes... > One way to address this is via a tagging scheme. I think=20 > the question is whether we'd want to *require* tags in each=20 > Extended attribute, or not. I'd say yes. I think the simplicity of a fixed field trades off well against one extra octet on the wire. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 22:26:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: Define some new NAS-Port-Type Date: Wed, 16 Aug 2006 17:26:37 -0500 Message-ID: Thread-Topic: Define some new NAS-Port-Type Thread-index: Aca11bl1ErXe6SxAQaWEpq2r3MJiFQAGQJwAArs2i2AAH1YAIAACTn2gAAgoHfA= From: "Congdon, Paul T (ProCurve)" To: "Glen Zorn (gwz)" Cc: "Bernard Aboba" , "CTO YAN Renxiang" , , I was out in the weeds in my comment. I was thinking about something = else and Bernard's comment about access networks threw me. Not sure why = a PAN isn't considered an access network, if a PAN access controller is = connected to something larger. Just ignore the comment...=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Wednesday, August 16, 2006 11:33 AM > To: Congdon, Paul T (ProCurve) > Cc: Bernard Aboba; CTO YAN Renxiang; dnelson@enterasys.com;=20 > radiusext@ops.ietf.org > Subject: RE: Define some new NAS-Port-Type >=20 > Congdon, Paul T (ProCurve) <> supposedly scribbled: >=20 > > People do use RADIUS to authenticate infrastructure devices as well >=20 > True, but the conjunction of the terms "infrastructure" &=20 > "Personal Area Network" has me confused. Would you mind elaborating? >=20 > >=20 > >> -----Original Message----- > >> From: owner-radiusext@ops.ietf.org > >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > >> Sent: Tuesday, August 15, 2006 7:30 PM > >> To: 'CTO YAN Renxiang'; dnelson@enterasys.com;=20 > radiusext@ops.ietf.org > >> Subject: RE: Define some new NAS-Port-Type > >>=20 > >> Typically a NAS-Port-Type value is only needed for access=20 > >> technologies that may need to use RADIUS. I don't think that > >> 802.15 fits into that category (though lots of other wireless=20 > >> technologies do). > >>=20 > >> -----Original Message----- > >> From: owner-radiusext@ops.ietf.org > >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of CTO YAN Renxiang > >> Sent: Tuesday, August 01, 2006 10:13 PM > >> To: Bernard Aboba; dnelson@enterasys.com; radiusext@ops.ietf.org > >> Subject: re: Define some new NAS-Port-Type > >>=20 > >> Hi, David and Bernard, > >>=20 > >> Thanks for your comments. > >>=20 > >> I think stating as work in progress in Informative Reference is ok. > >> Many RFC documents are also written in this way, as follows, > >>=20 > >> 5.2 Informative References > >>=20 > >> [802.20] Mobile Broadband Wireless Access (MBWA), IEEE > >> Standard, Work > >> in Progress. > >>=20 > >> [802.22] Wireless Regional Area Networks (WRAN), IEEE > >> Standard, Work > >> in Progress. > >>=20 > >> How do you think about that? > >>=20 > >> BTW, do you think we need to define a NAS-Port-Type for 802.15 > >> (WPAN) also?=20 > >>=20 > >> Renxiang > >>=20 > >>=20 > >>> -----=D4=AD=CA=BC=D3=CA=BC=FE----- > >>> =B7=A2=BC=FE=C8=CB: Bernard Aboba = [mailto:bernard_aboba@hotmail.com] > >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04 > >>> =CA=D5=BC=FE=C8=CB: dnelson@enterasys.com; CTO YAN Renxiang;=20 > radiusext@ops.ietf.org > >>> =D6=F7=CC=E2: RE: Define some new NAS-Port-Type > >>>=20 > >>>=20 > >>>> I understand the > >>>> difficulty of referencing draft IEEE standards, so I'm not sure=20 > >>>> exactly what to suggest as an alternative. > >>>=20 > >>> I think they can reference IEEE 802 work-in-progress as an=20 > >>> Informative Reference. > >>>=20 > >>>=20 > >>>=20 > >>=20 > >> -- > >> to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > >>=20 > >>=20 > >> -- > >> to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: >=20 > Hope this helps, >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 22:25:40 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 18:17:27 -0400 Message-Id: <20060816221727.63C1A16CBC@mail.nitros9.org> "Bernard Aboba" wrote: > Yes. So your proposal looks like this, no? Yes. I just don't do ASCII art well. :) 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 22:10:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 15:10:44 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D496@xmb-sjc-215.amer.cisco.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBfD29X6mvHghmRliIfgbpb5fo0wAA7wQQ From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: 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 |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=pdiN0Y0jMMqNa5bnAjbG+Wd+aZHIYCaQk8jEr03aQxfvGalaM35agkjDi/VUy5wYlTkHFICb WZJfbZMI5Dt0sUliH/D4vgUyfMHx8nrTRZwKQi3fwme0SP711yZ4sPxi; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba supposedly scribbled: >> I know that a couple of people stated that preference on the list >> recently, but without any technical justification. >=20 > 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... =20 >=20 >> 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... >=20 > 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=20 > field). =20 Yes, sorry, I should have been more explicit. > However, the Lior & Li proposal was for a larger > Extended-Type=20 > space, and I presume that this would require code changes. >=20 >> 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. >=20 > 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.=20 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 21:48:20 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 14:48:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Therefore, my proposal is the following. L2 is unnecessary, so we >drop it. The format is now: > > T L T2 data... > > We still have the problem of data length, though. We can solve this >by saying "if T2 is zero, then the data for this extended type is >concatenated to the data for the previous one". e.g. > > T L T2 data1... T L 0000 data2... > > The format of Extended-Type is now always 'T2 data...', which seems >good to me. The length of T2 is derived from from the lengths of the >encapsulating Extended-Type attribute. And the concatatenation can >only occur if the first Extended-Type attribute has L=255, and even >then, only if the next Extended-Type attribute exists, AND has T2 != 0000. > > I hope that's a little clearer. Yes. So your proposal looks like this, no? 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 | Extended-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+ Type TBD (not 26) Length >= 4 Extended-Type Two octets. 0: Concatenation 1-255: Reserved 255-65530: Allocated by IANA 65531-65535: Reserved Value 0-251 octets (Length - 4). Only a single RADIUS Extended-Type attribute may be included within a RADIUS attribute of Type TBD. Where the value of the Extended-Type field is zero (0), this indicates that the content of the value field is to be concatenated with the contents of the value field in the previous attribute of Type TBD. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 21:38:27 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 14:37:53 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >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. >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). 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. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 18:33:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: Define some new NAS-Port-Type Date: Wed, 16 Aug 2006 11:33:10 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D3C6@xmb-sjc-215.amer.cisco.com> Thread-Topic: Define some new NAS-Port-Type Thread-Index: Aca11bl1ErXe6SxAQaWEpq2r3MJiFQAGQJwAArs2i2AAH1YAIAACTn2g From: "Glen Zorn \(gwz\)" To: "Congdon, Paul T \(ProCurve\)" Cc: "Bernard Aboba" , "CTO YAN Renxiang" , , DKIM-Signature: a=rsa-sha1; q=dns; l=2899; t=1155753192; x=1156617192; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Define=20some=20new=20NAS-Port-Type; X=v=3Dcisco.com=3B=20h=3DEHYHYo3YXUAytdUuU/p5IzHj1PM=3D; b=f6hVauPVZoDiNPWa5FaWH0+yCbIA3V+p4XNoYlBZS7GBQQlL5rRFDkvH7ryWsx257w8oBVIB S7yiDiTzm3fHfUDdgl5DP25ucQBHK4G6ItZ2J3QuDzKG+zw8vnx2g52P; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Congdon, Paul T (ProCurve) <> supposedly scribbled: > People do use RADIUS to authenticate infrastructure devices as well True, but the conjunction of the terms "infrastructure" & "Personal Area = Network" has me confused. Would you mind elaborating? >=20 >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >> Sent: Tuesday, August 15, 2006 7:30 PM >> To: 'CTO YAN Renxiang'; dnelson@enterasys.com; radiusext@ops.ietf.org >> Subject: RE: Define some new NAS-Port-Type >>=20 >> Typically a NAS-Port-Type value is only needed for access >> technologies that may need to use RADIUS. I don't think that >> 802.15 fits into that category (though lots of other wireless >> technologies do).=20 >>=20 >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of CTO YAN Renxiang >> Sent: Tuesday, August 01, 2006 10:13 PM >> To: Bernard Aboba; dnelson@enterasys.com; radiusext@ops.ietf.org >> Subject: re: Define some new NAS-Port-Type >>=20 >> Hi, David and Bernard, >>=20 >> Thanks for your comments. >>=20 >> I think stating as work in progress in Informative Reference is ok. >> Many RFC documents are also written in this way, as follows, >>=20 >> 5.2 Informative References >>=20 >> [802.20] Mobile Broadband Wireless Access (MBWA), IEEE >> Standard, Work >> in Progress. >>=20 >> [802.22] Wireless Regional Area Networks (WRAN), IEEE >> Standard, Work >> in Progress. >>=20 >> How do you think about that? >>=20 >> BTW, do you think we need to define a NAS-Port-Type for 802.15 >> (WPAN) also?=20 >>=20 >> Renxiang >>=20 >>=20 >>> -----=D4=AD=CA=BC=D3=CA=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04 >>> =CA=D5=BC=FE=C8=CB: dnelson@enterasys.com; CTO YAN Renxiang; = radiusext@ops.ietf.org >>> =D6=F7=CC=E2: RE: Define some new NAS-Port-Type >>>=20 >>>=20 >>>> I understand the >>>> difficulty of referencing draft IEEE standards, so I'm not sure >>>> exactly what to suggest as an alternative. >>>=20 >>> I think they can reference IEEE 802 work-in-progress as an >>> Informative Reference.=20 >>>=20 >>>=20 >>>=20 >>=20 >> -- >> 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: >>=20 >>=20 >> -- >> 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: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 17:27:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: Define some new NAS-Port-Type Date: Wed, 16 Aug 2006 12:26:54 -0500 Message-ID: Thread-Topic: Define some new NAS-Port-Type Thread-index: Aca11bl1ErXe6SxAQaWEpq2r3MJiFQAGQJwAArs2i2AAH1YAIA== From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , "CTO YAN Renxiang" , , People do use RADIUS to authenticate infrastructure devices as well > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, August 15, 2006 7:30 PM > To: 'CTO YAN Renxiang'; dnelson@enterasys.com; radiusext@ops.ietf.org > Subject: RE: Define some new NAS-Port-Type >=20 > Typically a NAS-Port-Type value is only needed for access=20 > technologies that may need to use RADIUS. I don't think that=20 > 802.15 fits into that category (though lots of other wireless=20 > technologies do).=20 >=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of CTO YAN Renxiang > Sent: Tuesday, August 01, 2006 10:13 PM > To: Bernard Aboba; dnelson@enterasys.com; radiusext@ops.ietf.org > Subject: re: Define some new NAS-Port-Type >=20 > Hi, David and Bernard, >=20 > Thanks for your comments. >=20 > I think stating as work in progress in Informative Reference=20 > is ok. Many RFC documents are also written in this way, as follows, >=20 > 5.2 Informative References >=20 > [802.20] Mobile Broadband Wireless Access (MBWA), IEEE=20 > Standard, Work > in Progress. >=20 > [802.22] Wireless Regional Area Networks (WRAN), IEEE=20 > Standard, Work > in Progress. >=20 > How do you think about that? >=20 > BTW, do you think we need to define a NAS-Port-Type for=20 > 802.15 (WPAN) also?=20 >=20 > Renxiang >=20 >=20 > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04 > > =CA=D5=BC=FE=C8=CB: dnelson@enterasys.com; CTO YAN Renxiang; = radiusext@ops.ietf.org > > =D6=F7=CC=E2: RE: Define some new NAS-Port-Type > >=20 > >=20 > > >I understand the > > >difficulty of referencing draft IEEE standards, so I'm not > > sure exactly > > >what to suggest as an alternative. > >=20 > > I think they can reference IEEE 802 work-in-progress as an=20 > Informative=20 > > Reference. > >=20 > >=20 > >=20 >=20 > -- > 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: >=20 >=20 > -- > 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: >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 16:34:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Possible Resolution to Issue 198: Attribute Concatenation/Splitting Date: Wed, 16 Aug 2006 09:34:18 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D309@xmb-sjc-215.amer.cisco.com> Thread-Topic: Possible Resolution to Issue 198: Attribute Concatenation/Splitting Thread-Index: AcbA4AISLdEdqQRoSECyY39JYUcOJwAcVT3w From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1339; t=1155746060; x=1156610060; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Possible=20Resolution=20to=20Issue=20198=3A=20=20Attribute=20Con catenation/Splitting; X=v=3Dcisco.com=3B=20h=3DJN3qXHvuLdJImrQTRfpXOtJVcGk=3D; b=pedcVJuE93+wk1M+6bTLucW4mj6MTPuX9vxkCB+Dy72PL3BeIPgSkrnIqQEZrMRP8qCWWVxe CXirZyVBc7zYuLgBDVVOlqYil6RK2L8vcslFzcrYyIEj9456j3lMn1HK; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> supposedly scribbled: > I am wondering if the following approach to the > concatenation/splitting problem with NAS-Filter-Rule might work:=20 >=20 > a. Add a single octet Tag field: >=20 > 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 > =20 > =20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20 > Type | Length | Tag | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 >=20 > b. Specify that a multiple NAS-Filter-Rule attributes with the same > value of the Tag field represent a single rule and are to be > concatenated when translating to Diameter NAS-Filter-Rule. =20 >=20 > c. Prohibit reordering of NAS-Filter-Rule attributes. >=20 > d. Suggest that ASCII values (e.g. '1'=3D0x31, etc.) be used in the = tag > field so they can be entered easily.=20 This sounds very similar to what was discussed in Montreal. I think = that this would work fine, and particularly well with the VSA method of = extending the attribute space. ... 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 16:29:29 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 09:29:20 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D2FB@xmb-sjc-215.amer.cisco.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBQFQ4CPNx+QB5RWuzT1CjF7goBQAEGCZw From: "Glen Zorn \(gwz\)" To: "Alan DeKok" , "Bernard Aboba" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1006; t=1155745762; x=1156609762; c=relaxed/simple; s=sjdkim1002; 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 |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes=20; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=T0FlO/z+vxXIi6m+gHwGUZjA2CEo2fpCCi4fX+AQp3L5ugvtCiaTWKssVcmH2/PQkXi+rkHm +iQS2cCIOgTpaOxCgDfY7WcwMEcqDQXlrD9DaHqy8LBziMvkrB+DZDHs; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Alan DeKok <> supposedly scribbled: > "Bernard Aboba" wrote: >> 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. =20 >> Opinions solicited.=20 >=20 > I think 2 octets is OK. There are nowhere near 64k RADIUS > attributes in existence today, even including VSA's. So 64k would > seem to be sufficient for a while. =20 A master of understatement ;-). Actually, I suspect that another 256 = would be more than enough, if there was a rational (or any) AAA = development strategy in the IETF; probably even without one. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 16:21:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 09:21:17 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D2F3@xmb-sjc-215.amer.cisco.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbA4vorXOkCHOhkQLqF7sVstIxjVgAa9r0A From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: 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; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Questions=20on=20RADIUS=20Extended=20attributes; X=v=3Dcisco.com=3B=20h=3DozUL88US95ffVhpOEaM8mzvE0qI=3D; b=WfMjJ59ZfdtQlM3pcGdIM1g1NisR+rHW6v4pCpe/TkZOtvrN0gIAESOnkuGxs5vwM4AL6zsX 0AIk64XgJpLiCBdHl2gGg9ZTDE5iwtRMrxxSCnEvYhygNMjW4obXV/CL; Authentication-Results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> supposedly scribbled: > At IETF 66, we discussed how to extend the RADIUS attribute space.=20 > 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: =20 >=20 > = http://www.watersprings.org/pub/id/draft-lior-radius-attribute-type-exten= sion-00.txt >=20 > 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).=20 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. =20 >=20 > Taking that into account, find below a strawman proposal for what the > Extended-Type attribute would look like.=20 >=20 > Some questions: >=20 > 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. =20 > Opinions solicited.=20 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... =20 >=20 > b. Should the second length field include the Extended-Type field or > not?=20 > 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. =20 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. =20 >=20 > 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?=20 Ditto. =20 ... 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 15:35:00 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Questions on RADIUS Extended attributes cc: radiusext@ops.ietf.org Date: Wed, 16 Aug 2006 11:26:25 -0400 Message-Id: <20060816152625.D2B5316CBC@mail.nitros9.org> "Nelson, David" wrote: > > The issue of data length can be addressed, for example, by reserving > > 0 for "concatenate values to the end of the previous Extended-Type". > > This allows the values to extend past 251 octets, and makes the format > > of the attribute constant. > > Please elaborate. What field contains the "zero" that indicates > concatenation? Do I understand correctly that this is a mechanism for > fragmentation and reassembly? Some additional detail would be helpful. The proposed format for the Extended-Type is (in short) T L T2 L2 data... Where T and L are the RADIUS type and length. T2 is the proposed 2 or 4 octet extended type, and L2 is the length of the encapsulated data. Since we have L, L2 isn't strictly necessary. But even with L2, the length of the data is limited to less than 253 bytes, which is a problem for long data strings. We could fix the data length problem by allow L2 to be larger than 253, and relying on that to indicate concatenation. e.g. T L T2 L2 data1... T L data2... Where L2 is the length of data1 + data2. However, this makes parsing the Extended-Type problematic, as the data in Extended-Type is sometimes 'T2 L2 data', and sometimes just 'data..' I've run into these issues in the past, and they're awkward and problematic to deal with. Therefore, my proposal is the following. L2 is unnecessary, so we drop it. The format is now: T L T2 data... We still have the problem of data length, though. We can solve this by saying "if T2 is zero, then the data for this extended type is concatenated to the data for the previous one". e.g. T L T2 data1... T L 0000 data2... The format of Extended-Type is now always 'T2 data...', which seems good to me. The length of T2 is derived from from the lengths of the encapsulating Extended-Type attribute. And the concatatenation can only occur if the first Extended-Type attribute has L=255, and even then, only if the next Extended-Type attribute exists, AND has T2 != 0000. I hope that's a little clearer. My main reason for getting rid of L2 is that allowing it to be larger than L is a nightmare. i.e. the encapsulated structure indicates it's larger than the structure that is performing the encapsulation. That's a recipe for buffer overflows, bugs, incompatibilities, etc. I'm rating developer efficiency as a higher priority than network efficiency. I have *rarely* seen packet size be a problem in RADIUS, and I've seen many bugs and incompatibilities in implementations. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 15:01:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on RADIUS Extended attributes Date: Wed, 16 Aug 2006 11:01:05 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193E0@MABOSEVS2.ets.enterasys.com> Thread-Topic: Questions on RADIUS Extended attributes Thread-Index: AcbBQJsyeQcC4fE8RrSpfjI1Ni8wuQAA3eog From: "Nelson, David" To: Alan DeKok writes... > The issue of data length can be addressed, for example, by reserving > 0 for "concatenate values to the end of the previous Extended-Type". > This allows the values to extend past 251 octets, and makes the format > of the attribute constant. Please elaborate. What field contains the "zero" that indicates concatenation? Do I understand correctly that this is a mechanism for fragmentation and reassembly? Some additional detail would be helpful. > If we don't include a length, no. I think if you explain the suggestion above, it will also answer my questions on this statement. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 14:29:01 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: Questions on RADIUS Extended attributes cc: radiusext@ops.ietf.org Date: Wed, 16 Aug 2006 10:20:21 -0400 Message-Id: <20060816142021.C99D716CBC@mail.nitros9.org> "Bernard Aboba" wrote: > 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. I think 2 octets is OK. There are nowhere near 64k RADIUS attributes in existence today, even including VSA's. So 64k would seem to be sufficient for a while. > b. Should the second length field include the Extended-Type field or not? > 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. I would say the length field does not need to be included. The issue of data length can be addressed, for example, by reserving 0 for "concatenate values to the end of the previous Extended-Type". This allows the values to extend past 251 octets, and makes the format of the attribute constant. > 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? If we include a length, yes. We should then say that all implementations MUST support it. If we don't include a length, no. 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 03:20:50 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Questions on RADIUS Extended attributes Date: Tue, 15 Aug 2006 20:20:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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: http://www.watersprings.org/pub/id/draft-lior-radius-attribute-type-extension-00.txt 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). 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. b. Should the second length field include the Extended-Type field or not? 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. 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? ================================================== Proposed Extended-Type Attribute 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 | Extended-Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended-Type | Length2 | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (not 26) Length >= 7 Extended-Type Four octets. Values <= 255: Reserved Values > 255: To be allocated by IANA Length2 0-255 (doesn't include the Extended-Type field) Value 0 or more octets as defined by the Length2 field. More than one RADIUS Extended-Type attribute may be included within a RADIUS attribute of Type TBD. If more than one RADIUS attribute of Type TBD is included, then they are to be concatenated (allowing an Extended-Type attribute to be split between two RADIUS attributes). -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 02:59:30 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Possible Resolution to Issue 198: Attribute Concatenation/Splitting Date: Tue, 15 Aug 2006 19:59:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed I am wondering if the following approach to the concatenation/splitting problem with NAS-Filter-Rule might work: a. Add a single octet Tag field: 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 | Tag | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ b. Specify that a multiple NAS-Filter-Rule attributes with the same value of the Tag field represent a single rule and are to be concatenated when translating to Diameter NAS-Filter-Rule. c. Prohibit reordering of NAS-Filter-Rule attributes. d. Suggest that ASCII values (e.g. '1'=0x31, etc.) be used in the tag field so they can be entered easily. --------------------------------------------------------------------- Issue 198: Attribute Concatenation/Splitting Submitter names: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: June 30, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00640.html Document: Filter-00 Comment type: 'T'echnical Priority: S Section: 2 and 4 Rationale/Explanation of issue: Section 2 currently says that "Where more than one NAS-Filter-Rule attribute is included in a RADIUS packet, the attributes MUST be consecutive and it is assumed that the attributes are to be concatenated to form a single filter list." I guess this means that a single long rule can be split into multiple NAS-Filter-Rule attributes? And a single NAS-Filter-Rule attribute could contain pieces of multiple rules? If so, I'd recommend separating the individual rules somehow. In the current version of NAS-Traffic-Rule each individual rule ends with LF, making it easy to determine where one rule ends and another one begins. I'd suggest adopting this same convention for RADIUS NAS-Filter-Rule. This concatenation/splitting has also implications for Diameter translation (Section 4): AVPs coming from Diameter side may have to be split to several RADIUS attributes (and rule delimiters added), and attributes coming from RADIUS side have to be concatenated/split to Diameter AVPs (and rule delimiter removed). [Pasi Eronen] >BTW, do the same issues also apply to the NAS-Filter-Rule AVP defined in >RFC 4005? As far as I can tell, no: in RFC 4005, a single AVP always contains one complete rule (long rules are not split into multiple AVPs, and one AVP never contains multiple rules). [Rajith R] AFAIK, splitting & concatenation are necessitated by the 255 byte limit for RADIUS attributes. So it would be better to split at 253 byte (for the attribute payload) boundary rather than LF or some other attribute specific delimiter, I think this would have the advantage of * same & simple logic for concatenation/splitting of any suitable RADIUS attribute of length > 255 * packing efficiency in the message, though not a principal concern [Pasi Eronen] This simple concatenation/splitting works when you need to include a single, potentially long data item (e.g. EAP-Message) in a RADIUS message. But it gets complex if you need to include multiple, potentially long data items of the same type (in this case, individual filter rules) and you need to maintain the boundaries between the individual data items somehow. In particular, if we decide to support individual filter rules longer than 253 characters, it looks like a RADIUS-to-Diameter translation agent will need code specific to NAS-Filter-Rule no matter how we choose to do the concatenation/splitting on the RADIUS side. The difference is just how complex that code needs to be (e.g., is it sufficient just to recognize "LF", or understand the full filter rule syntax). -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 16 Aug 2006 02:30:01 +0000 Message-ID: From: "Bernard Aboba" To: "'CTO YAN Renxiang'" , , Subject: RE: Define some new NAS-Port-Type Date: Tue, 15 Aug 2006 19:29:48 -0700 Message-ID: <007401c6c0db$d802a2a0$8807e7e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Thread-index: Aca11bl1ErXe6SxAQaWEpq2r3MJiFQAGQJwAArs2i2A= Content-language: en-us Typically a NAS-Port-Type value is only needed for access technologies = that may need to use RADIUS. I don't think that 802.15 fits into that = category (though lots of other wireless technologies do).=20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On Behalf Of CTO YAN Renxiang Sent: Tuesday, August 01, 2006 10:13 PM To: Bernard Aboba; dnelson@enterasys.com; radiusext@ops.ietf.org Subject: re: Define some new NAS-Port-Type Hi, David and Bernard, Thanks for your comments. I think stating as work in progress in Informative Reference is ok. Many = RFC documents are also written in this way, as follows, 5.2 Informative References [802.20] Mobile Broadband Wireless Access (MBWA), IEEE Standard, Work in Progress. [802.22] Wireless Regional Area Networks (WRAN), IEEE Standard, Work in Progress. How do you think about that? BTW, do you think we need to define a NAS-Port-Type for 802.15 (WPAN) = also?=20 Renxiang > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04 > =CA=D5=BC=FE=C8=CB: dnelson@enterasys.com; CTO YAN Renxiang; = radiusext@ops.ietf.org > =D6=F7=CC=E2: RE: Define some new NAS-Port-Type >=20 >=20 > >I understand the > >difficulty of referencing draft IEEE standards, so I'm not=20 > sure exactly > >what to suggest as an alternative. >=20 > I think they can reference IEEE 802 work-in-progress as an=20 > Informative=20 > Reference. >=20 >=20 >=20 -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 11 Aug 2006 20:00:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Draft of RADEXT WG Minutes for IETF-66 Date: Fri, 11 Aug 2006 15:59:55 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193CF@MABOSEVS2.ets.enterasys.com> Thread-Topic: Draft of RADEXT WG Minutes for IETF-66 Thread-Index: Aca9gLbQAGkCE8AHQhOTUaDizSEeeQ== From: "Nelson, David" To: This is the draft RADEXT WG session minutes, as submitted for the IETF-66 Proceedings. Please review these minutes and reply to the list with any error or omissions. Thanks! IETF-66 RADEXT WG Meeting Minutes 9:00 AM - 11:30 AM Monday, July 10, 2006 Montreal, Quebec, Canada Note takers: Mauricio Sanchez, David Mitton. Edited by: David Nelson. 1. Agenda bashing: no changes proposed 2. Document status (Bernard) Since last IETF eight (almost nine) documents are completed 3. NAS-Traffic-Rules, NAS-Filter-Rule (Mauricio) Comment (Glen Z): You can always parse the beginning of a rule. The end is harder to recognize. Suggest that you enhance the Diameter filter rules, as it's not that good. Comment (Dave N): Suggest that we don't pack multiple rules into one attribute. Comment (Bernard A): We need to clarify the issues. Comment (Glen Z): With NAS-Traffic-Rule you will have to translate strings. Answer: We'll we have a proposal coming. Comment (Dave N): 3GPP has already deployed Diameter, and requested the NAS-Filter-Rule capability in RADIUS. We need to meet that requirement. Issue: RADEXT Issue 170 -- Precedence and order of server-provided rules to local NAS-provide rules. Comment (Bernard A): This is an issue if NASes have local rules and policies. This has been around forever. Comment (Dave N): We are about policy provisioning, not policy definition. Comment: The principle should be interoperability of features. Poll (Bernard A): Who thinks the NAS-Filter-Rules draft is ready last call?=20 Response: 1 Poll (Bernard A) Who thinks the NAS-Traffic-Rules draft is ready for last call? Response: 0 Comment (Bernard A): We all need to read and submit comments so we can move forward. 4. Pre-Authentication AAA Requirements (Yoshiro Ohba) Yoshiro presented two basic requirements identified in the IETF-65 BoF. Yoshiro presented technical issues related to pre-authentication. There is a dependency between moving between pre-auth and auth states and key caching. Comment (Bernard A.): Key caching was addressed 802.11i and it was decided that key caching was not going to be managed individually by user, it is a global parameter. Given it's a global parameter its there's no need to control via RADIUS. Each system is configured with key cache timeout. Comment (Nancy C-W): Says that 802.11 revisiting topic and considering to use something else other than Session-Timeout as a means to signal when to expire keys. In 802.11i, there is no notion of session lifetime, just a key lifetime. Comment (Bernard A): Asserts that the meaning of the Session-Timeout attribute is too overloaded.=20 Comment (Nancy C-W): Yes this is an issue. Says that 802.11r has no notion of pre-authentication. We are looking at making this more explicit but it's not done. Comment (Pat C): Points out that there is no signaling between authenticator and server about the pre-auth state. You are trying to do some sort of signaling on the transition from Pre-Auth to active? It's not clear that these events exist, and they are not RADIUS issues. Comment (Bernard A): Points out that no accounting is generated prior to session setup. Accounting is used to know when session starts and ends. We need to ask implementers what they do. This is discussed in RFC 3780. Comment (Pat C): Not sure this is practical for wireless roaming. Concerned that a client may pre-auth with many APs and if it moves just a bit... Comment: Calling-Station-ID - What value shall it take on with pre-authentication? Yoshiro presents a summary: Drives home message that pre-auth requires a lot of work in EAP and AAA layers. Most work to be done in HOAKEY. Comment: Someone asks scope of HOAKEY. Answer: HOAKEY will define requirements that will need work in respective working groups. 5. WLAN Attributes (Bernard) Bernard presented the notion of a pre-auth specific timeout attribute. Comment (Yoshiro O): Asks whether the absence of pre-auth attribute should be considered always as a normal session? Answer (Bernard A): It depends. The presence of the attribute in an Access-Request means it is a pre-auth session. However, when absent, it's not always pre-auth. Need to use RFC3580 behavior. Comment: Asks about key cache lifetime? Answer (Bernard A): Thinks that 802.11i drives the lifetime based on the session-timeout value. Comment (Dorothy S): Validates Bernard's assertion; states that work on wireless attributes is good to clear up gaps of understanding. Bernard asks how to work with other standards groups on open questions/issues. =20 Comment (Dorothy S): Responds that groups should work with liaison representatives by generating lists of questions/issues. Comment (Dan R): Points out that the discussion a number of times this morning has been topics out of scope of RADEXT, e.g. data format for Diameter's filter rule, 802.11i discussion. Dan feels we need figure out how not to talk about issues that other groups need to resolve. Comment (Pat C): Looked at RFC 3780. Accounting is not required to go to same server as Authentication. Comment (Bernard A): If you want state, you setup a server that keeps state that both Authentication and Accounting talk to. Comment (Pat C): Does this presume a common backend? Answer (Bernard A): Yes. Bernard presented the SSID attribute. 6. RADIUS Attribute Design Guidelines (Dave N. for Greg W.) Dave presented an overview of document. Dave presented the open issues. Comment (Glen Z): Wondering why use by an independent SDO is an issue. Glen asserts that most SDOs are just looking for IANA code-point numbers. This could be solved by giving blanket permission. Neither Dave nor Glen believe this is good practice. Dave presented RADIUS attribute guidelines (section 7 of the draft). Comment (Glen Z): Believes all problems have been solved over the years. Dave asks in which documents problems have been solved. Glenn feels that problems should be solved just once, if there are existing solutions elsewhere, they should be deprecated. There should be only one solution. Comment (Dan R): Questions whether this document is to be a BCP. Dave says yes, that is the plan. Comment (Dan R): Says same problem happened with MIBs. The felling there was that a guidelines document would make it easier for new people to ramp up on standards development. Comment (Glen Z): Asserts that solutions exist in a protocol called Diameter. He points out that most of the problems in design guidelines were fundamental problems addressed in Diameter. Sees no need to re-solve problems that have already been solved once. Comment (Bernard A): Points out that the guidelines document should strictly be about BCP, not defining new extensions to RADIUS. =20 Dave describes examples of where several new document rely on complex data structures, such as GEOPRIV, where having design guideline document would be (have been) beneficial.=20 Dave opens up discussion to group on how to move forward. Comment (Bernard A): Points out that design guidelines document has taken on two hard problems, BCP and designing new RADIUS protocol extensions (i.e. extended attributes), that will make it difficult to make progress. He suggests that problems be split up into two individual documents. =20 Comment (Glen Z): Agrees with Bernard's suggestion to split up document. Having a BCP would be beneficial. Comment (Hannes T): Says that time is of essence for this document as SDOs continue to make progress and they may use non-optimal designs.=20 Dave asks group to consider the suggestion to remove any references to extended attributes. Extended attributes would be treated in separate effort. There seems to be rough consensus in the room. We will confirm this direction on the WG mailing list.=20 7. RADIUS Attribute Space Exhaustion (Bernard) Bernard presented summary of RADIUS attribute exhaustion issues. Bernard presented possible outcomes of the discussion. Bernard opened up the discussion to floor to discuss whether solution is desired, where work should be performed, and whether there any other problems to solve. Comment (Pat C): Believes that RADIUS should not be used for new applications, but extensions should be allowed for existing applications. Doesn't care whether RADEXT tackles problem. Comment (Dave N): Believes the problem should be solved. Believes that SDOs and implementers will continue to use RADIUS even if IETF stops work on it. Believes that the attribute exhaustion solution work should be done in RADEXT. Unsure whether there are any additional problems that need work. =20 Comment (Dave N): Puts out radical suggestion of reclaiming blocks of reserved but ill-defined attribute code-points, such as the experimental or implementation-specific blocks. Bernard says it needs to be investigated. Comment (Glen Z): Says that problems have already been solved (i.e. Diameter). He's OK with solving problem, again. However, does not feel RADIUS attribute space should be extended. Feels RADEXT is the right place to do the work, if other solutions are thrown out.=20 Comment: Believes that attribute space should be extended, RADEXT is the right place, and does believe extended attributes is the only problem. Comment (Glen Z): Disagrees with Dave N. The IETF has more power to stop people from doing work than we think we do. The SDOs use the IETF to talk to each other and standardize interoperation. If there is no RFC, this will challenge them. Comment: (Pasi E): Repeats Glen's claim that problem has already been solved. However, feels usage of vendor-specific attributes offers an infinite space. Comment: Points out that allowing on certain applications to use RADIUS and not Bernard does straw poll of group on three questions: Is the problem worth solving? 13 in favor, 6 against Is RADEXT the right place to do the work? 18 in favor, 0 against Should the extended attribute ID space be the only problem to be solved? 6 in favor, 3 against We will confirm this rough consensus on the WG mailing list. Bernard recaps existing proposals. 8. Extended RADIUS Attributes (Bernard A. for Barney W.) Bernard presented the motivation for this work.=20 Bernard presented usage of Diameter AVP format as the extended RADIUS Attribute format. Bernard opens up to the floor for comments. Comment (Glen Z): Mapping Diameter AVP formats in RADIUS brings up the RADIUS PDU length problems. Comment (Dave M): Yes, maybe it is a bad idea in general. But it may work for some things. I think we should start saying things like "This feature is limited, and if that's a problem, use something else, i.e. Diameter". Comment (Dave M): I like the characterization of the issues. This provides a good basis for tradeoffs. We need to make decisions and perhaps say we don't do some of it. Comment (Dave N): This draft is proposing solutions rather than just hand-waving. Asserts that the backbone of RADEXT will be tested on whether to address these problems. Comment (Glen Z): Points out that entire network will have to be upgraded to support Barney's draft. Questions why it would be easier to force a RADIUS forklift upgrade than going to Diameter. Comment (Dave N): Asks for opinions from RADIUS server vendors. Questions what server vendor will support all functionality. Comment (Bernard A): Points out the fundamental change this draft would have to the RADIUS data-dictionary. We'd be nearly 75% of the way to Diameter if this draft is approved. Comment (Yoshiro O): Believes RADIUS should remain simple and not take on Diameter like parsing. Comment (Joe S): Re-iterates that this draft takes RADIUS nearly all the way to Diameter. Agrees with Glen that this is not good. =20 Comment (Glen Z): It's still possible to do some grouping using tags. Comment (Dave N): Asks the group whether group feels that the RADIUS tagging mechanism is sufficient for all attribute grouping? Bernard does straw poll: How many people favor addressing extended attributes using limited solution proposed by Lior? 8 in favor, 1 against This seems to be a solid consensus of the room. We'll verify this on the WG mailing list. 9. Issues & Fixes (Bernard for Alan DeKok) Bernard presented a summary. Not much discussion. We need to get more people to read the draft and comment on the list. 10. RADIUS Attribute for Management Authorization (Dave N.) Dave presented the background and motivation. Dave presented current attribute proposals. Dave asks group whether document is ready for adoption as a WG work item? Bernard asks how many people have read document? One person in the room has. The obvious outcome is that additional people need to read document and comment on the list. 11. GEOPRIV (Hannes T.) Hannes described the status of GEOPRIV work. Many changes between the current and previous version. Open issue on encoding of location attributes, split complex attributes into two, wrong references corrected and lot of cleanup work. Bernard asks how work should progress towards completion, given it's been around so long. Decided that next step is that when document goes last call in GEOPRIV that RADEXT should also review document from a last call perspective. Bernard suggests that RADEXT group submit issues prior to GEOPRIV last call. 12. ISMS WG requirements for RADIUS (Dave N.) Dave described motivation for Authorize Only operations. Dave described motivation for an Asserted Identity. Comment (Hannes T): ISMS requirements seem similar to requirements he's hearing in other groups. Seems similar to the SIP problem. Should look at that. Comment (Dave N): ISMS is interested in RADIUS because it integrates something people already have. Comment (Bernard A): Points out that the document is making a leap by integrating technologies like Kerberos and RADIUS. Questions how these technologies will be re-conciliated. =20 Answer (Dave N): Responds that Jeff H. (Kerberos WG Chair) believes that authentication and authorization services should be split. In his mind, the authentication and authorization services are/should be decoupled and independent. =20 Comment (Bernard A): Curious to hear whether the security considerations hve been investigated thoroughly. Comment (Bernard A): Points out that ISMS requirements seem to violate basic key distribution principles, feels it's very ad-hoc, and changes Kerberos in a fundamental way. Kerberos tickets are bound to capabilities. Bernard would like agreement from the Kerberos WG before ratifying such a fundamental change. Comment (Dave N): This comes from specific deployment requirements in ISMS, and this situation is not an integration of Kerberos and RADIUS. Comment: Kerberos does have optional authorization fields, some may be used or not. This should be looked at carefully. Don't know if anyone does that.... Comment (Joe S): Agrees that additional thought is necessary. Comment (Hannes T): Questions the viability of splitting authentication and authorization services, given that most technologies bind authentication and authorization together. SAML has similar mechanisms. Comment (Dave N): Will take this feedback to ISMS WG and see how they wish to proceed. 13. Wrap-up/final comments Comment (Glen Z): Would like the crypto-agility work item to be clarified. What is the problem, the issues, etc.? The WG should decide to make this into a formal work item, if that is deemed necessary. Answer (Dave N): It is already a WG milestone, but we should look at whether charter language, scope, etc. also needs revision. End of the meeting. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 02 Aug 2006 05:13:24 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Subject: re: Define some new NAS-Port-Type Date: Wed, 2 Aug 2006 13:12:40 +0800 Message-ID: <9570C1261494D54D9D3115BC2C83429A0BB854@asbmail2.sbell.com.cn> Thread-Topic: Define some new NAS-Port-Type Thread-Index: Aca11bl1ErXe6SxAQaWEpq2r3MJiFQAGQJwA From: "CTO YAN Renxiang" To: "Bernard Aboba" , , Hi, David and Bernard, Thanks for your comments. I think stating as work in progress in Informative Reference is ok. Many = RFC documents=20 are also written in this way, as follows, 5.2 Informative References [802.20] Mobile Broadband Wireless Access (MBWA), IEEE Standard, Work in = Progress. [802.22] Wireless Regional Area Networks (WRAN), IEEE Standard, Work in = Progress. How do you think about that? BTW, do you think we need to define a NAS-Port-Type for 802.15 (WPAN) = also?=20 Renxiang > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA8=D4=C22=C8=D5 9:04 > =CA=D5=BC=FE=C8=CB: dnelson@enterasys.com; CTO YAN Renxiang;=20 > radiusext@ops.ietf.org > =D6=F7=CC=E2: RE: Define some new NAS-Port-Type >=20 >=20 > >I understand the > >difficulty of referencing draft IEEE standards, so I'm not=20 > sure exactly > >what to suggest as an alternative. >=20 > I think they can reference IEEE 802 work-in-progress as an=20 > Informative=20 > Reference. >=20 >=20 >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 02 Aug 2006 01:04:54 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, Renxiang.Yan@alcatel-sbell.com.cn, radiusext@ops.ietf.org Bcc: Subject: RE: Define some new NAS-Port-Type Date: Tue, 01 Aug 2006 18:04:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I understand the >difficulty of referencing draft IEEE standards, so I'm not sure exactly >what to suggest as an alternative. I think they can reference IEEE 802 work-in-progress as an Informative Reference. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 01 Aug 2006 15:22:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Define some new NAS-Port-Type Date: Tue, 1 Aug 2006 11:22:31 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602193AF@MABOSEVS2.ets.enterasys.com> Thread-topic: Define some new NAS-Port-Type Thread-Index: Aca1MnykFxCozhbkS1yLUP1FOl7uQgASzoFA From: "Nelson, David" To: "CTO YAN Renxiang" , > A draft to define some new NAS-Port-Type for wireless > http://www.ietf.org/internet-drafts/draft-yan-radext-port-type-00.txt >=20 > Could you please comment on it? The NAS-Port-Type assignments look OK. I note, however, that the informative references for 802.20 and 802.22 are to the WG web sites, which don't seem to be an appropriate, stable reference. For example, will the site exist after the WG has closed? I understand the difficulty of referencing draft IEEE standards, so I'm not sure exactly what to suggest as an alternative. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 01 Aug 2006 15:03:24 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Subject: Define some new NAS-Port-Type Date: Tue, 1 Aug 2006 14:20:29 +0800 Message-ID: <9570C1261494D54D9D3115BC2C83429A0202C6F7@asbmail2.sbell.com.cn> Thread-Topic: Define some new NAS-Port-Type Thread-Index: Aca1MnykFxCozhbkS1yLUP1FOl7uQg== From: "CTO YAN Renxiang" To: Cc: , "Bernard Aboba" Hi, A draft to define some new NAS-Port-Type for wireless=20 http://www.ietf.org/internet-drafts/draft-yan-radext-port-type-00.txt Could you please comment on it? Thanks and regards, Renxiang -- 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: