Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Dec 2003 18:44:14 +0000 Message-ID: From: Avi Lior To: 'Richard Perlman' , Avi Lior Cc: "BLACK,CHUCK (HP-Roseville,ex1)" , "CONGDON,PAUL (HP-Roseville,ex1)" , radiusext@ops.ietf.org Subject: RE: Encoding of Location-Id and Location-Name in draft-black-radi us-lanedge-00.txt Date: Tue, 30 Dec 2003 13:43:27 -0500 MIME-Version: 1.0 Content-Type: text/plain Richard, First, maybe for an enterpirse level RADIUS sever performance is not an issue but for a carrier grade products performance is definetly an issue. I don't think I would load up the location attributes in a dictionary. TLVs just make it easier to extract the attribute. Instead of parsing " location-name = foobar, address = 123 Main Street, " ; we have using the TLV encoding 0106foobar0215123 Main Street Where 01 is the location-name followed by the length of 6 and the value "foobar" 2 is the address field etc... This is far quicker to parse and more compact. In both cases you will use the hash tables etc.... The only thing you add to the dictionary is the type 1 for location-name 2 for address etc... > -----Original Message----- > From: Richard Perlman [mailto:perl@lucent.com] > Sent: December 29, 2003 12:50 PM > To: 'Avi Lior' > Cc: BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL > (HP-Roseville,ex1); radiusext@ops.ietf.org > Subject: Re: Encoding of Location-Id and Location-Name in > draft-black-radius-lanedge-00.txt > > > Avi: > > I am not sure that the parsing of a string is all that much > more difficult. Given an arbitrarily large base of locations, > you would probably search a hashed list anyways, and strings > are a lot easier for people to manage in some table or file > rather than having to add value assignments to a dictionary. > > Richard > > On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" > > wrote: > > > Hi Avi, > > > > The encoding of Location-ID is identical to that proposed > by the Wi-Fi > > Alliance in it's WISPr document in section 5.2 for their > "Location-ID" > > attribute. I'm not sure where that encoding originated, so I'm not > > sure if there are other applications which make use of it or not. > > > > There have been discussions regarding making attributes such as > > Location-ID into a common (not vendor-specific) attribute. > Since it > > may be used widely, whichever encoding format is preferable (the > > current WISPr or else TLV) should be chosen. Perhaps there > are others > > who have knowledge of why and how the WISPr Location-ID format was > > chosen, and could add their input here. > > > > /chuck > > > > > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Monday, December 22, 2003 2:03 PM > > To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK > (HP-Roseville,ex1); > > radiusext@ops.ietf.org > > Subject: Encoding of Location-Id and Location-Name in > > draft-black-radius-l anedge-00.txt > > > > > > Hi Paul, Chuck > > > > I have an issue with Location-ID and Location-Name. > > > > Since these attribute may appear in an Access-Request message, I > > assume that they would be used by RADIUS in evaluating policy. > > Therefore I would not want these encoded as a string the > way you have > > it. I would rather see a more efficient encoding scheme, one that > > would make it faster for RADIUS to parse. > > > > In discussions on this list I proposed to use a single > attribute that > > is of type string (the same as yours) that would encode the > > information using TLV. Both of these schemes provide for > extensibility > > and optionality. But the TLV approach as an advantage that it is > > easier to parse for RADIUS ( we don't want to slow RADIUS > down), and > > is more compact. The encoding approach in your document is human > > readable. > > > > IMO the string encoding you propose would be okay if it > already has an > > application that expects this type of encoding. > > > > -- > > 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: Mon, 29 Dec 2003 17:50:48 +0000 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 29 Dec 2003 09:50:16 -0800 Subject: Re: Encoding of Location-Id and Location-Name in draft-black-radius-lanedge-00.txt From: Richard Perlman To: "'Avi Lior'" CC: "BLACK,CHUCK (HP-Roseville,ex1)" , "CONGDON,PAUL (HP-Roseville,ex1)" , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Avi: I am not sure that the parsing of a string is all that much more difficult. Given an arbitrarily large base of locations, you would probably search a hashed list anyways, and strings are a lot easier for people to manage in some table or file rather than having to add value assignments to a dictionary. Richard On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" wrote: > Hi Avi, > > The encoding of Location-ID is identical to that proposed by the Wi-Fi > Alliance in it's WISPr document in section 5.2 for their "Location-ID" > attribute. I'm not sure where that encoding originated, so I'm not sure if > there are other applications which make use of it or not. > > There have been discussions regarding making attributes such as Location-ID > into a common (not vendor-specific) attribute. Since it may be used widely, > whichever encoding format is preferable (the current WISPr or else TLV) > should be chosen. Perhaps there are others who have knowledge of why and > how the WISPr Location-ID format was chosen, and could add their input here. > > /chuck > > > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Monday, December 22, 2003 2:03 PM > To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1); > radiusext@ops.ietf.org > Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l > anedge-00.txt > > > Hi Paul, Chuck > > I have an issue with Location-ID and Location-Name. > > Since these attribute may appear in an Access-Request message, I assume that > they would be used by RADIUS in evaluating policy. Therefore I would not > want these encoded as a string the way you have it. I would rather see a > more efficient encoding scheme, one that would make it faster for RADIUS to > parse. > > In discussions on this list I proposed to use a single attribute that is of > type string (the same as yours) that would encode the information using TLV. > Both of these schemes provide for extensibility and optionality. But the > TLV approach as an advantage that it is easier to parse for RADIUS ( we > don't want to slow RADIUS down), and is more compact. The encoding approach > in your document is human readable. > > IMO the string encoding you propose would be okay if it already has an > application that expects this type of encoding. > > -- > 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: Mon, 29 Dec 2003 17:18:01 +0000 Message-ID: <7A371016E109114EA47C89370296278B01CA0836@xrose01.rose.hp.com> From: "BLACK,CHUCK (HP-Roseville,ex1)" To: 'Avi Lior' , "CONGDON,PAUL (HP-Roseville,ex1)" , "BLACK,CHUCK (HP-Roseville,ex1)" , radiusext@ops.ietf.org Subject: RE: Encoding of Location-Id and Location-Name in draft-black-radi us-l anedge-00.txt Date: Mon, 29 Dec 2003 12:17:17 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Avi, The encoding of Location-ID is identical to that proposed by the Wi-Fi Alliance in it's WISPr document in section 5.2 for their "Location-ID" attribute. I'm not sure where that encoding originated, so I'm not sure if there are other applications which make use of it or not. There have been discussions regarding making attributes such as Location-ID into a common (not vendor-specific) attribute. Since it may be used widely, whichever encoding format is preferable (the current WISPr or else TLV) should be chosen. Perhaps there are others who have knowledge of why and how the WISPr Location-ID format was chosen, and could add their input here. /chuck -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Monday, December 22, 2003 2:03 PM To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1); radiusext@ops.ietf.org Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l anedge-00.txt Hi Paul, Chuck I have an issue with Location-ID and Location-Name. Since these attribute may appear in an Access-Request message, I assume that they would be used by RADIUS in evaluating policy. Therefore I would not want these encoded as a string the way you have it. I would rather see a more efficient encoding scheme, one that would make it faster for RADIUS to parse. In discussions on this list I proposed to use a single attribute that is of type string (the same as yours) that would encode the information using TLV. Both of these schemes provide for extensibility and optionality. But the TLV approach as an advantage that it is easier to parse for RADIUS ( we don't want to slow RADIUS down), and is more compact. The encoding approach in your document is human readable. IMO the string encoding you propose would be okay if it already has an application that expects this type of encoding. -- 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, 28 Dec 2003 11:36:04 +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: QoS attributes Date: Sun, 28 Dec 2003 13:35:15 +0200 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPJes2SrKi/91yxRkyynBQSGACIFgDu2wHA From: To: , Hi Avi, > There are two problems with this approach is certain conditions: >=20 > Dealing with a QoS Class Id only only addresses static arrangements = where > both parties agree apriori on the contents of that are represented by = a > particular instance of the QoS Class Id. This is useful but its not = the > only model. > In some cases the QoS maybe more dynamic, we therefore need the = flexibility > to transfer the QoS Class Id and/or QoS parameters. Agreed, however the more dynamic model is something that is probably beyond RADext to standardize. > Something that I understand is Bandwidth. Two parties can agree on = how to > bill for bandwidth without having to agree on descrete bundles of = bandwidth. > We bill bandwidth on bits/second. So, why are we not discussing Bandwidth? If I understand, you want to support a bandwidth attribute. If so, I think that a more comprehensive proposal would be good, one which discusses the trade-offs, etc. QoS is probably a swamp if we start at supporting multiple attributes. > Also I am very surprised about the resistance to do this. If we = justify > doing Credit Control over AAA why is this a problem?=20 I don't see the comparison, actually. The Credit Control is trying to standardized a token based approach for doing AAA authorization. It is not standardizing (or at least trying to carefully work with) billing models, etc. =20 John -- 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, 24 Dec 2003 16:51:02 +0000 Date: Wed, 24 Dec 2003 09:06:58 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: SIP/RADIUS work? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII So far, this list has had discussion on a variety of topics, but very little relating to SIP authentication, authorization or accounting. What work, if any, relating to SIP should be contemplated? Is this work best done in RADEXT or in SIPPING? Are there specific drafts that could become WG work items? If so, is there interest in ceding change control to the IETF, or is the desire to publish these as individual submissions? -- 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, 23 Dec 2003 23:07:19 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Tue, 23 Dec 2003 18:06:43 -0500 MIME-Version: 1.0 Content-Type: text/plain David Nelson writes: > I have not participated in the Credit Control over AAA > discussions, but what I have learned of it from speaking with > you, I suspect I would categorize it as a Bad Idea (tm). It > sounds way more complicated than is really necessary. Yes, > you can contrive a business model that requires that much > complexity. However, not all business models make sense or > will be successful in the market. Therefore, Credit Control > may not be the best precedent to cite. The good news is David, that the business model for prepaid and credit control is viable. There is demand we and other companies are delivering products today. So Credit Control is the *best* precedent to cite. > If the partners in a roaming consortium can't agree on a few, > simple classes of service for QoS that will be comprehensible > to the customer as he/she roams, and will be amenable to > straightforward billing and reconciliation at the end of the > month, then the business model is profoundly broken, and no > protocol in the world is going to fix it. In a simple world the only relationships you have are bilateral relationships. In the real-world there are other relationships. Often the home network has a relationships with intermediaries and the service is actually provided by other parites. You can expect everyone in these cases to know what a Gold User looks like. Or what Filter-Id "foobar" means. > At least that's my > view of the situation. Sometimes too much flexibility is a > severe impediment to scalability, especially across multiple > organizations. I think maybe the KISS model applies here. I am a big beliver in the KISS model. Keep in mind that things that seem simple at the surface may actually be broken. Filter ID concept seems simple enough but we know that it is broken today in that it doesn't scale. > Authorizing a user to obtain or negotiate for a "class of > service" seems within the scope of AAA. Provisioning the > detailed parameters of those "service classes", both at the > NAS and on end-to-end basis, seems out of scope for AAA. Similar arguments were made about filers and filter-ids. What you propose is not always a viable solution - its broken. And in the case of the filter-id, Diameter fixed that. Avi -- 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, 23 Dec 2003 20:59: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: RE: QoS attributes Date: Tue, 23 Dec 2003 12:59:13 -0800 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPJKe2VJfg6rN5ESFuwonlIYc56RwAae5iQ From: "Bari, Farooq" To: , Cc: , So as I suspected the scenarios can be many and complex. However I feel that the situation can be simplified if we consider business models that are likely to exist. My thinking is that in general we will have two types of authentication / authorizations and associated QoS values 1) authentication/authorization for accessing the network. QoS information carried in this part is tightly coupled to user's account / subscription with his home operator. So this value can be the general QoS class (e.g. something that indicates the user subscription to real time services or the user is a gold user etc.). Since the WISP does the financial settlements for this access by the user with his home network, the WISP uses this user's QoS profile value provided by his home network as an upper bound for any other QoS requests made by individual services later on initiated by the user. 2) authentication/authorization for the service that the user decides to use after he has been authenticated/authorized to access the network. This value is provided by the service provider (possibly a 3rd party) and its value and the way it is negotiated and signaled is independent of AAA interactions with user's home network for accessing the network. This QoS value can be more specific e.g. it may identify specific bandwidth values etc. However the QoS values will be upper bound by the (1) since the WISP can only charge and therefore provide a QoS that is within the user's QoS profile provided by the home network at the time of network access authentication/authorization.=20 If the WISP and service provide have direct business (roaming) agreement, then I would consider it the case where the service provider is also directly (in a way) paying for the extra QoS to the WISP and therefore home network's authentication /authorization of subscribed QoS can be over ruled. Farooq -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, December 22, 2003 11:53 PM To: john.loughney@nokia.com Cc: farooq.bari@attws.com; radiusext@ops.ietf.org Subject: Re: QoS attributes john.loughney@nokia.com wrote: > Farooq, >=20 >=20 >>A question for my clarification. What happens if the service >>that needs a specific QoS is a third party Service i.e. it is not being >>delivered/offered by the home network and therefore W/ISP=20 >>does not have a AAA relationship as such with the 3rd party. >=20 >=20 > If there is no roaming in place, then there probably is no service.=20 > The user would then have to pay to the visited network via some=20 > mechanism. I think there are several cases: 1. Service is provided free of charge, QoS set is just used to ensure that e.g. those who start the video download can also complete and get enough bandwidth while downloading. In this case there are no AAA issues. Some QoS signaling can take place between the user and the 3rd party service. 2. The 3rd party service has its own authentication and billing. The user initiates this authentication in addition to the one done at access level. Example: SIP layer authentication in addition to WLAN access. In this case there is AAA involved, but its local to the 3rd party service i.e. no roaming to the home network. Subscriber pays two bills. 3. The 3rd party service employs authentication with a roaming agreement to the home network. Here too the service authentication and access authentication are separate, but both may use the same credentials and be authenticated to the same home server. Subscriber pays just one bill. 4. The 3rd party service employs authentication with a roaming agreement to the local access network. This is like alternative 3, but the roaming path goes through the access network. 5. The 3rd party service and the local access network can somehow agree to provide QoS services to the access network's users. Perhaps based on the block of IP addresses allocated to the access network, or something like that. Information about the provided QoS is exchanged between the networks for billing purposes. --Jari -- 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, 23 Dec 2003 20:54:43 +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: QoS attributes Date: Tue, 23 Dec 2003 15:53:56 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPJkekx2f0EY9s3SJuETuHkv0jH9wAAaTEA From: "Nelson, David" To: Joel writes... > This presume a very simple consortium model. [DBN] Perhaps, but I do have a bias. As a potential customer for roaming access services, I like simple. :-) > At the very least I would > expect hot spot operators to be planning to participate in multiple > consortia, so as to offer service to the widest range of customers. Those > distinct consortia are not likely to have the same collections of QoS > sets. [DBN] I understand the apparent attractiveness of provisioning detailed QoS parameters in AAA messages. It means that all knowledge can be centralized in a Home AAA Server. There is only one place where the operator has to go to twiddle the knobs, to define or re-define the classes of service for QoS. It also means that you don't have to deal with other protocols for provisioning QoS definitions on your NASes, such as CLI, SNMP or COPS. [DBN] The problem with this vision is that it requires a level of conformity in product offerings that is going to be very hard to achieve, and it does not account for the end-to-end nature of QoS. It does not indicate how the static AAA-provisioned QoS parameters interact with the dynamic, negotiated QoS parameters. IMHO, this is like the story of The Emperor's New Clothes.=20 -- Dave =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, 23 Dec 2003 20:17:34 +0000 Message-Id: <5.1.0.14.0.20031223151536.01a2cdf0@localhost> Date: Tue, 23 Dec 2003 15:17:13 -0500 To: From: "Joel M. Halpern" Subject: RE: QoS attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This presume a very simple consortium model. At the very least I would expect hot spot operators to be planning to participate in multiple consortia, so as to offer service to the widest range of customers. Those distinct consortia are not likely to have the same collections of QoS sets. Yours, Joel M. Halpern At 03:02 PM 12/23/2003 -0500, Nelson, David wrote: >If the partners in a roaming consortium can't agree on a few, simple >classes of service for QoS that will be comprehensible to the customer >as he/she roams, and will be amenable to straightforward billing and >reconciliation at the end of the month, then the business model is >profoundly broken, and no protocol in the world is going to fix it. At >least that's my view of the situation. Sometimes too much flexibility >is a severe impediment to scalability, especially across multiple >organizations. I think maybe the KISS model applies here. -- 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, 23 Dec 2003 20:03: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: QoS attributes Date: Tue, 23 Dec 2003 15:02:02 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPJezZ0GmFkf015TmOzKpVg4HtdsAAEV+Ag From: "Nelson, David" To: Avi writes... > Also I am very surprised about the resistance to do this. If we justify > doing Credit Control over AAA why is this a problem? You probably shouldn't be surprised. The point that is being made is that AAA is used to authorize users to access services. Specifically, services that are pretty much static, pre-defined, and well-understood. There are other protocols for negotiating dynamic service parameters, e.g. in this instance we are talking about QoS parameters. There is no good reason to duplicate the functionality of QoS negotiation protocols within AAA, and there are probably a host of reasons to avoid doing so. I have not participated in the Credit Control over AAA discussions, but what I have learned of it from speaking with you, I suspect I would categorize it as a Bad Idea (tm). It sounds way more complicated than is really necessary. Yes, you can contrive a business model that requires that much complexity. However, not all business models make sense or will be successful in the market. Therefore, Credit Control may not be the best precedent to cite. If the partners in a roaming consortium can't agree on a few, simple classes of service for QoS that will be comprehensible to the customer as he/she roams, and will be amenable to straightforward billing and reconciliation at the end of the month, then the business model is profoundly broken, and no protocol in the world is going to fix it. At least that's my view of the situation. Sometimes too much flexibility is a severe impediment to scalability, especially across multiple organizations. I think maybe the KISS model applies here. Authorizing a user to obtain or negotiate for a "class of service" seems within the scope of AAA. Provisioning the detailed parameters of those "service classes", both at the NAS and on end-to-end basis, seems out of scope for AAA. -- Dave -- 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, 23 Dec 2003 17:33:59 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , Avi Lior , radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Tue, 23 Dec 2003 12:32:43 -0500 MIME-Version: 1.0 Content-Type: text/plain John, > > But I don't belive that those are the only use cases. What > > about when the QoS classes are not configured such in > cases when we cross > > administrative domains where we don't have the QoS class configured > > or completely configured. You would then need to actually > transport > > the actual parameters. After all, isnt the QoS class an > alias for QoS > > parameters? > > One would hope that if parties have agreements in place for > roaming, then they would also have some agreements on service > classes as well. They would still > have to have some agreement on policy, for example, to know > if the roaming > user was authorized for certain types of service, I would guess. There are two problems with this approach is certain conditions: Dealing with a QoS Class Id only only addresses static arrangements where both parties agree apriori on the contents of that are represented by a particular instance of the QoS Class Id. This is useful but its not the only model. In some cases the QoS maybe more dynamic, we therefore need the flexibility to transfer the QoS Class Id and/or QoS parameters. Something that I understand is Bandwidth. Two parties can agree on how to bill for bandwidth without having to agree on descrete bundles of bandwidth. We bill bandwidth on bits/second. Also I am very surprised about the resistance to do this. If we justify doing Credit Control over AAA why is this a problem? > John > -- 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, 23 Dec 2003 07:57:14 +0000 Message-ID: <3FE7F510.9030500@piuha.net> Date: Tue, 23 Dec 2003 09:56:00 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: john.loughney@nokia.com Cc: radiusext@ops.ietf.org Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Jari, > > >>>My issue still is (without getting into specifics of QoS or WLAN >>>parameters) how can bundle the parameters in a way that not every >>>single parameter has to be listed in a RADIUS RFC? >> >>Oh that's easy -- we can just put it in some opaque string, vendor >>specific attribute, or design some OID hierarchy around the >>parameters. > > > Not that easy. Lets take the case of bandwidth. Lets say we allow > a single QoS parameter called bandwidth. Sounds simple. What does > the parameter denote? Average bandwidth (over what time?), instanteous > bw, minimum bw, maximum bw, maximum sustained bw, bw from the point of > monitor, bw to the end user? How do the roaming partners agree on this. > > After we settle this, I am sure some folks will want to add more QoS > paramter, like delay, jitter, packet loss, throughput, goodput ... > and so on. At the end of the day, this becomes extremely complex and > (IMO) unmanagable. I agree -- but I was just responding that it is easy to provide parameter space so that it doesn't have to be listed in the IETF RFCs. Its another question if that would make sense, and yet another question if we could agree what the parameters are in the first place. --Jari -- 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, 23 Dec 2003 07:54:10 +0000 Message-ID: <3FE7F450.9060105@piuha.net> Date: Tue, 23 Dec 2003 09:52:48 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: john.loughney@nokia.com Cc: farooq.bari@attws.com, radiusext@ops.ietf.org Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Farooq, > > >>A question for my clarification. What happens if the service >>that needs a specific QoS is a third party Service i.e. it is not being >>delivered/offered by the home network and therefore W/ISP >>does not have a AAA relationship as such with the 3rd party. > > > If there is no roaming in place, then there probably is no service. > The user would then have to pay to the visited network via some > mechanism. I think there are several cases: 1. Service is provided free of charge, QoS set is just used to ensure that e.g. those who start the video download can also complete and get enough bandwidth while downloading. In this case there are no AAA issues. Some QoS signaling can take place between the user and the 3rd party service. 2. The 3rd party service has its own authentication and billing. The user initiates this authentication in addition to the one done at access level. Example: SIP layer authentication in addition to WLAN access. In this case there is AAA involved, but its local to the 3rd party service i.e. no roaming to the home network. Subscriber pays two bills. 3. The 3rd party service employs authentication with a roaming agreement to the home network. Here too the service authentication and access authentication are separate, but both may use the same credentials and be authenticated to the same home server. Subscriber pays just one bill. 4. The 3rd party service employs authentication with a roaming agreement to the local access network. This is like alternative 3, but the roaming path goes through the access network. 5. The 3rd party service and the local access network can somehow agree to provide QoS services to the access network's users. Perhaps based on the block of IP addresses allocated to the access network, or something like that. Information about the provided QoS is exchanged between the networks for billing purposes. --Jari -- 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, 23 Dec 2003 07:41:24 +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: QoS attributes Date: Tue, 23 Dec 2003 09:39:48 +0200 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPIx2fEuiDbWXPcQ0abxCTNhR22EgAX+Y+A From: To: , Cc: Hi Jari, > > My issue still is (without getting into specifics of QoS or WLAN=20 > > parameters) how can bundle the parameters in a way that not every > > single parameter has to be listed in a RADIUS RFC? >=20 > Oh that's easy -- we can just put it in some opaque string, vendor > specific attribute, or design some OID hierarchy around the=20 > parameters. Not that easy. Lets take the case of bandwidth. Lets say we allow a single QoS parameter called bandwidth. Sounds simple. What does the parameter denote? Average bandwidth (over what time?), instanteous bw, minimum bw, maximum bw, maximum sustained bw, bw from the point of monitor, bw to the end user? How do the roaming partners agree on this. After we settle this, I am sure some folks will want to add more QoS paramter, like delay, jitter, packet loss, throughput, goodput ... and so on. At the end of the day, this becomes extremely complex and (IMO) unmanagable. John -- 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, 23 Dec 2003 07:35: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: QoS attributes Date: Tue, 23 Dec 2003 09:35:03 +0200 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPIp5VwouMqeGwhSh2/UvnP8B1ADwAD10nAABwOC1A= From: To: , , , Farooq, > A question for my clarification. What happens if the service=20 > that needs a specific QoS is a third party Service i.e. it is not = being > delivered/offered by the home network and therefore W/ISP=20 > does not have a AAA relationship as such with the 3rd party. If there is no roaming in place, then there probably is no service. The user would then have to pay to the visited network via some mechanism. John -- 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, 23 Dec 2003 07:34:28 +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: QoS attributes Date: Tue, 23 Dec 2003 09:33:57 +0200 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPIp09Ww+q5EwjXRUOFwnKzDmDFzwAf5OXg From: To: , , Avi, > Okay we are starting to converge here a bit. >=20 > I understand the concept of having AAA authorize a certain=20 > QoS class. And I agree with you on that. >=20 > The simple use cases (if I got it right ) would be: > Joe authenticates and the Access Accept message returns back a QoS = class; > alternatively Joe requests a new service instance with a certain QoS = class,=20 > and the NAS authorizes the use of a QoS class with the AAA using an = Authorize=20 > Only scheme. >=20 > This is all good. >=20 > But I don't belive that those are the only use cases. What=20 > about when the QoS classes are not configured such in cases when we = cross=20 > administrative domains where we don't have the QoS class configured=20 > or completely configured. You would then need to actually transport=20 > the actual parameters. After all, isnt the QoS class an alias for QoS = > parameters? One would hope that if parties have agreements in place for roaming, = then they would also have some agreements on service classes as well. They would = still=20 have to have some agreement on policy, for example, to know if the = roaming=20 user was authorized for certain types of service, I would guess. John -- 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, 22 Dec 2003 22:03:40 +0000 Message-ID: From: Avi Lior To: "'CONGDON,PAUL (HP-Roseville,ex1)'" , "BLACK,CHUCK (HP-Roseville,ex1)" , radiusext@ops.ietf.org Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l anedge-00.txt Date: Mon, 22 Dec 2003 17:02:59 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Paul, Chuck I have an issue with Location-ID and Location-Name. Since these attribute may appear in an Access-Request message, I assume that they would be used by RADIUS in evaluating policy. Therefore I would not want these encoded as a string the way you have it. I would rather see a more efficient encoding scheme, one that would make it faster for RADIUS to parse. In discussions on this list I proposed to use a single attribute that is of type string (the same as yours) that would encode the information using TLV. Both of these schemes provide for extensibility and optionality. But the TLV approach as an advantage that it is easier to parse for RADIUS ( we don't want to slow RADIUS down), and is more compact. The encoding approach in your document is human readable. IMO the string encoding you propose would be okay if it already has an application that expects this type of encoding. -- 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, 22 Dec 2003 20:39:50 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'jari.arkko@piuha.net'" , Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Mon, 22 Dec 2003 14:39:02 -0600 MIME-Version: 1.0 Content-Type: text/plain -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, December 22, 2003 2:07 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org Subject: Re: QoS attributes Nakhjiri Madjid-MNAKHJI1 wrote: > My issue still is (without getting into specifics of QoS or WLAN > parameters) how can bundle the parameters in a way that not every > single parameter has to be listed in a RADIUS RFC? Oh that's easy -- we can just put it in some opaque string, vendor specific attribute, or design some OID hierarchy around the parameters. Madjid>>I wonder if we could something in between. I.e. It would be nice to have a hierarchy, where the server would recognize that an attribute is a QoS or L2 definition (WLAN, CDMA..) attribute and then leave the details either as opague stings or VSAs? Currently (correct me if I am wrong), it seems that if something is Vendor specific, only a vendor ID is provided, but it does not say anything further. But the question is do we want to? The hard issue is how all this works without buying the whole network from one vendor. Or how a home server can control parameters in a roaming situation when it has never even heard of the link technology that the foreign network uses. Essentially, there would have to standardization of the parameters. Whether or not that happens inside a particular IETF RFC is another question. Madjid>> Again, VSA kind of force you to buy from one vendor, they don't promote interoperability. It seems they don't allow for negotiations between vendors either. However, if you had a method where the servers would at least know that the issue is QoS or an L2 attribute, they may be able to query an entity that knows, for instance a QoS manager or a mobility manager. I don't think we should require AAA server to understand all QoS techs and all L2 techs and all mobility techs and so on, but many architectures do require that AAA server talks to other entities in the network (QoS manager or Mobile IP HA). Maybe the best we can do at the moment is this Gold-Silver-Etc service level classification. Madjid>> Based on the discussions we had, Generic service level classes are starting to appeal to me. However, I like to see categorizations that have come out of IETF and are widely accepted, such as ToS or DSCP (I am not sure how MPLS does classifications) and with many levels (DSCP has ~64) so anybody can use them as they see fit (like DSCP bits), rather than too few levels such as Gold-Silver,bronz, unless we run them all the way to alkali metals :) Did I miss any RFC that defines things in Gold-Silver-Bronz?? Madjid Or perhaps we could do that, and the specific, more detailed parameters for a popular link layer, such as 802.11 wireless LANs. --Jari -- 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, 22 Dec 2003 20:39:42 +0000 Date: Mon, 22 Dec 2003 12:56:05 -0800 (PST) From: Bernard Aboba To: "Joel M. Halpern" cc: radiusext@ops.ietf.org Subject: Re: QoS attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I suppose that we could assert that the interpretation of the QoS colors by > the roamer is to be influenced by the domain of the subscriber. But that > seems to be asking an awful lot of other parts of the system. > > Am I misunderstanding the discussion? I think you understand it pretty well. Note that none of this is knew. We had the same issue come up with respect to the Filter-Id attribute defined in RFC 2865. If the Filter-Id is understood by all parties, it works. If there are no prior arrangements, sending a Filter-Id in a roaming situation can produce unpredictable results. One reason that *only* Filter-Id was supported in RFC 2865 is that vendors had introduced their own distinct ways of handling explicit filters. In Diameter, standardized filter rules (for both packet filters and QoS) were introduced. -- 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, 22 Dec 2003 20:34:29 +0000 Date: Mon, 22 Dec 2003 12:50:21 -0800 (PST) From: Bernard Aboba To: Nagi cc: radiusext@ops.ietf.org Subject: Re: Reply-Message/EAP-Message attributes in RFC-3576 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > There is no equivalent acknowledgement defined for a Reply-Message. > > If no equivalent acknowledgement for Reply-Message, doesn't that mean user > cannot confirm the service. Is that acceptable behavior? Also Do these > attributes make sense in Disconnect requests? I suppose that saying "you are > now being logged off" doesn't make sense. May be, that the ISP can display a > message "Your service is over. Talk to customer care over the phone" does > make sense. Reply-Message attribute delivers a displayable message. This could be useful in a Disconnect-Request in that the reason for the disconnection could be explained to the user (as in your example). Even the EAP Notification-Response only acknowledges that the Notification-Request was received, not that the user "responded" in any way. It is therefore only a transport-level acknowledgement. -- 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, 22 Dec 2003 20:26:50 +0000 Message-Id: <5.1.0.14.0.20031222152020.01b1b158@localhost> Date: Mon, 22 Dec 2003 15:26:10 -0500 To: radiusext@ops.ietf.org From: "Joel M. Halpern" Subject: Re: QoS attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have been watching this exchange, and I am somewhat puzzled. We all seem to agree that the interesting case is roaming. There then seem to be a set of unstate assumptions about what the business relationships are between the roaming and home operators, and their relationship to the promises made to the customer. I can imagine a model in which sending platinum / gold / silver / tin / copper is meaningful. But that is a specific model where the customer has been told "you will get the negotiated corresponding service level from roaming partners", and part of the business negotiation is to define what the correspondences are. THis is a defensible model. It can even be extended to consortia, etc. But it seems unlikely to be the only model. One could easily imagine a model where the business relationship says "as a roaming operator we will support whatever QoS you would like to give your customers, and here is the price list." Without a lot of work this does not map to a colored service model, since the relationship does not require picking levels in the business relationship, and the services to different roaming partners may well be chosen differently by those partners. I suppose that we could assert that the interpretation of the QoS colors by the roamer is to be influenced by the domain of the subscriber. But that seems to be asking an awful lot of other parts of the system. Am I misunderstanding the discussion? Yours, Joel M. Halpern At 10:06 PM 12/22/2003 +0200, Jari Arkko wrote: >Nakhjiri Madjid-MNAKHJI1 wrote: > >>My issue still is (without getting into specifics of QoS or WLAN >>parameters) how can bundle the parameters in a way that not every >>single parameter has to be listed in a RADIUS RFC? > >Oh that's easy -- we can just put it in some opaque string, vendor >specific attribute, or design some OID hierarchy around the parameters. > >But the question is do we want to? The hard issue is how all this works >without buying the whole network from one vendor. Or how a home server >can control parameters in a roaming situation when it has never even >heard of the link technology that the foreign network uses. Essentially, >there would have to standardization of the parameters. Whether or not >that happens inside a particular IETF RFC is another question. > >Maybe the best we can do at the moment is this Gold-Silver-Etc >service level classification. Or perhaps we could do that, and >the specific, more detailed parameters for a popular link layer, >such as 802.11 wireless LANs. > >--Jari > > >-- >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: Mon, 22 Dec 2003 20:08:12 +0000 Message-ID: <3FE74ED8.1050809@piuha.net> Date: Mon, 22 Dec 2003 22:06:48 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > My issue still is (without getting into specifics of QoS or WLAN > parameters) how can bundle the parameters in a way that not every > single parameter has to be listed in a RADIUS RFC? Oh that's easy -- we can just put it in some opaque string, vendor specific attribute, or design some OID hierarchy around the parameters. But the question is do we want to? The hard issue is how all this works without buying the whole network from one vendor. Or how a home server can control parameters in a roaming situation when it has never even heard of the link technology that the foreign network uses. Essentially, there would have to standardization of the parameters. Whether or not that happens inside a particular IETF RFC is another question. Maybe the best we can do at the moment is this Gold-Silver-Etc service level classification. Or perhaps we could do that, and the specific, more detailed parameters for a popular link layer, such as 802.11 wireless LANs. --Jari -- 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, 22 Dec 2003 18:16:20 +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: QoS attributes Date: Mon, 22 Dec 2003 10:12:51 -0800 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPIp5VwouMqeGwhSh2/UvnP8B1ADwAD10nA From: "Bari, Farooq" To: "Avi Lior" , , , A question for my clarification. What happens if the service that needs a specific QoS is a third party Service i.e. it is not being delivered/offered by the home network and therefore W/ISP does not have a AAA relationship as such with the 3rd party. Farooq -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Monday, December 22, 2003 8:19 AM To: 'john.loughney@nokia.com'; Avi Lior; dnelson@enterasys.com; radiusext@ops.ietf.org Subject: RE: QoS attributes John, Okay we are starting to converge here a bit. I understand the concept of having AAA authorize a certain QoS class. And I agree with you on that. The simple use cases (if I got it right ) would be: Joe authenticates and the Access Accept message returns back a QoS class; alternatively Joe requests a new service instance with a certain QoS class, and the NAS authorizes the use of a QoS class with the AAA using an Authorize Only scheme. This is all good. But I don't belive that those are the only use cases. What about when the QoS classes are not configured such in cases when we cross administrative domains where we don't have the QoS class configured or completely configured. You would then need to actually transport the actual parameters. After all, isnt the QoS class an alias for QoS parameters? > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: December 22, 2003 2:26 AM > To: avi@bridgewatersystems.com; dnelson@enterasys.com;=20 > radiusext@ops.ietf.org > Subject: RE: QoS attributes >=20 >=20 > Hi Avi, >=20 > > I agree that we need a QoS Class Id, (or QoS-Bundle-Id). > >=20 > > Would RADIUS only ever transport the QoS-Class-Id? >=20 > My thoughts are that a AAA system would only authorize for > a certain QoS Class, not necessarily authorize specific > QoS parameters. > =20 > > Also reading through some of the drafts you point to. I noticed=20 > > that COPS is used. I think that at least in certain cases that =20 > > RADIUS/Diameter should be utilized instead of COPS. There certainly > > have been discussion on this. >=20 > I agree. I don't think that COPS is the proper mechanism, > though some people use it. Most of the discussions I have=20 > heard, as of late, seem to be about migrating to AAA=20 > mechanisms for QoS authorization. >=20 > John >=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: Mon, 22 Dec 2003 17:57:02 +0000 Message-ID: <3FE73045.2B764736@alcatel.be> Date: Mon, 22 Dec 2003 18:56:21 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Reply-Message/EAP-Message attributes in RFC-3576 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard, Thanks for the response. Please see comments inline. Bernard Aboba wrote: > > i) Can somebody educate me how are these attributes used. I'm wondering > > how these messages are delivered to the user. > > They are there to allow the server to send a displayable message. For > example, a CoA-Request with an EAP-Message/Notification-Request stating > "You have now been authorized for the Foo Service." > > How they are delivered to the user depends on the type of access they > have. If the client supports EAP, they can be sent as an > EAP-Message/Notification-Request; otherwise a Reply-Message attribute > might be used. Got the point. How can the user request a service? > > > > ii) Why is that Reply-Message not there in ACK messages where as the > > EAP-Message can be there in ACKs as well. > > An EAP-Message attribute may be present in ACK messages so that an > EAP-Message/Notification-Response can be sent back to the server, > acknowledging receipt. > > There is no equivalent acknowledgement defined for a Reply-Message. If no equivalent acknowledgement for Reply-Message, doesn't that mean user cannot confirm the service. Is that acceptable behavior? Also Do these attributes make sense in Disconnect requests? I suppose that saying "you are now being logged off" doesn't make sense. May be, that the ISP can display a message "Your service is over. Talk to customer care over the phone" does make sense. Thanks a lot, Nagi. -- 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, 22 Dec 2003 17:17:01 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Avi Lior'" , john.loughney@nokia.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Mon, 22 Dec 2003 11:16:05 -0600 MIME-Version: 1.0 Content-Type: text/plain Hi Avi, John, "I agree that we need a QoS Class Id, (or QoS-Bundle-Id)." It seems that this is the closest we got to my question at least, which was: how do RADIUS-NAS convey a variety of information, containing a large number of parameters, between each other without the RADIUS community having to assign an attribute to each parameter. Is the "Class Id" (or bundle-ID) a Diameter notion? How is grouping handled in Diameter? Although I agree that this list neither is chartered nor has time to solve all the QoS problems (the way NSIS does), I must say that QoS type issues, or more specific authorization issues are AAA issues and not just NSIS issues. A call control architecture (such as SIP) should talk to both AAA servers and QoS managers before it sets up a call. The problem is that authorization is not as clear cut for standards as say authentication, since it depends on the QoS technology and service contracts. So as Dave said, we need to leave a lot of it to VSAs. My issue still is (without getting into specifics of QoS or WLAN parameters) how can bundle the parameters in a way that not every single parameter has to be listed in a RADIUS RFC? Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior Sent: Friday, December 19, 2003 11:06 AM To: john.loughney@nokia.com; dnelson@enterasys.com; radiusext@ops.ietf.org Subject: RE: QoS attributes Hi John, I agree that we need a QoS Class Id, (or QoS-Bundle-Id). Would RADIUS only ever transport the QoS-Class-Id? Also reading through some of the drafts you point to. I noticed that COPS is used. I think that at least in certain cases that RADIUS/Diameter should be utilized instead of COPS. There certainly have been discussion on this. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: December 18, 2003 4:40 AM > To: dnelson@enterasys.com; radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > Hi all, > > My 2 cents are as follows: RADext/AAAext (or whatever) > shouldn't define QoS signaling, > NSIS is already doing that: > http://www.ietf.org/html.charters/nsis-charter.html There has been some discussion on AAA issues for QoS: http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-0 0.txt Looking into QoS issues, my feeling is that we want to specify QoS classes. These classes may support a set of QoS parameters. I think that QoS will be an area that vendors try to differentiate on; service providers may create services that support different QoS parameters, etc. I don't think that we can get into the QoS signaling / provisioning / definition of QoS parameters, as that excedes the scope of AAA (either RADIUS or Diameter). I would prefer that RADIUS / Diameter would contain a QoS class parameter, which could make use something like a IANA QoS class registry. Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have defined seperate QOS classes. One could imagine registering these classes in IANA, and service providers could support, in various degrees, different QoS classes. It would then be in scope of AAA to provide authorization for these classes. John -- 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: Mon, 22 Dec 2003 16:50:28 +0000 Date: Mon, 22 Dec 2003 09:06:43 -0800 (PST) From: Bernard Aboba To: Nagi cc: radiusext@ops.ietf.org Subject: Re: Reply-Message/EAP-Message attributes in RFC-3576 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > i) Can somebody educate me how are these attributes used. I'm wondering > how these messages are delivered to the user. They are there to allow the server to send a displayable message. For example, a CoA-Request with an EAP-Message/Notification-Request stating "You have now been authorized for the Foo Service." How they are delivered to the user depends on the type of access they have. If the client supports EAP, they can be sent as an EAP-Message/Notification-Request; otherwise a Reply-Message attribute might be used. > ii) Why is that Reply-Message not there in ACK messages where as the > EAP-Message can be there in ACKs as well. An EAP-Message attribute may be present in ACK messages so that an EAP-Message/Notification-Response can be sent back to the server, acknowledging receipt. There is no equivalent acknowledgement defined for a Reply-Message. -- 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, 22 Dec 2003 16:19:43 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , Avi Lior , dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Mon, 22 Dec 2003 11:18:54 -0500 MIME-Version: 1.0 Content-Type: text/plain John, Okay we are starting to converge here a bit. I understand the concept of having AAA authorize a certain QoS class. And I agree with you on that. The simple use cases (if I got it right ) would be: Joe authenticates and the Access Accept message returns back a QoS class; alternatively Joe requests a new service instance with a certain QoS class, and the NAS authorizes the use of a QoS class with the AAA using an Authorize Only scheme. This is all good. But I don't belive that those are the only use cases. What about when the QoS classes are not configured such in cases when we cross administrative domains where we don't have the QoS class configured or completely configured. You would then need to actually transport the actual parameters. After all, isnt the QoS class an alias for QoS parameters? > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: December 22, 2003 2:26 AM > To: avi@bridgewatersystems.com; dnelson@enterasys.com; > radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > Hi Avi, > > > I agree that we need a QoS Class Id, (or QoS-Bundle-Id). > > > > Would RADIUS only ever transport the QoS-Class-Id? > > My thoughts are that a AAA system would only authorize for > a certain QoS Class, not necessarily authorize specific > QoS parameters. > > > Also reading through some of the drafts you point to. I > > noticed that COPS is used. I think that at least in certain > > cases that RADIUS/Diameter should be utilized instead of > > COPS. There certainly have been discussion on this. > > I agree. I don't think that COPS is the proper mechanism, > though some people use it. Most of the discussions I have > heard, as of late, seem to be about migrating to AAA > mechanisms for QoS authorization. > > John > -- 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, 22 Dec 2003 16:05:08 +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: QoS attributes Date: Mon, 22 Dec 2003 11:03:58 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A05CAB02C@ACCLUST02EVS1.ugd.att.com> Thread-Topic: QoS attributes Thread-Index: AcPGUmeyLB/sqpffRXOG09PMka+qkACCiZ2AABGwbrA= From: "Roy, Radhika R, ALABS" To: Cc: , , John: I think that COPS is a policy protocol, and policies related to QOS can = also be used for distribution and enforcements. Similar may also be the = case for security and accounting. However, DIAMETER/RADIUS is also used for authentication, authorization, = and accounting (AAA). Here are the interesting points:=20 1. COPS for policies of authentication, authorization, and accounting = including QOS. 2. DIAMETER/RADIUS for offering actual services for authentication, = authorization, and accounting including QoS. In item 2, I am lacking clear wordings here. The question is this: Can we not develop standards complementing both = COPS and DIAMETER/RADIUS as they are also a part of IETF standard = protocols? BR, Radhika R. Roy rrroy@att.com -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, December 22, 2003 2:26 AM To: avi@bridgewatersystems.com; dnelson@enterasys.com; radiusext@ops.ietf.org Subject: RE: QoS attributes Hi Avi, > I agree that we need a QoS Class Id, (or QoS-Bundle-Id). >=20 > Would RADIUS only ever transport the QoS-Class-Id? My thoughts are that a AAA system would only authorize for a certain QoS Class, not necessarily authorize specific QoS parameters. =20 > Also reading through some of the drafts you point to. I=20 > noticed that COPS is used. I think that at least in certain=20 > cases that RADIUS/Diameter should be utilized instead of=20 > COPS. There certainly have been discussion on this. I agree. I don't think that COPS is the proper mechanism, though some people use it. Most of the discussions I have heard, as of late, seem to be about migrating to AAA mechanisms for QoS authorization. John -- 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: Mon, 22 Dec 2003 15:23:32 +0000 Message-ID: <3FE6C326.16DC007B@alcatel.be> Date: Mon, 22 Dec 2003 11:10:46 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: "BLACK,CHUCK (HP-Roseville,ex1)" CC: radiusext@ops.ietf.org Subject: Re: questions/comments on draft-black-radius-lanedge-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chuck, See the comment inline. > > > 3) The draft proposes a new Time attribute (along with Location-ID > > and Location Name). Why can't we use Event-TimeStamp define in RFC-2869 > > which is also in UTC format? Is there a specific reason to have a new > attribute > > defined here again? > > The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request > packet attribute. Perhaps for standardization this attribute could be > carried in either an Access-Request or an Accounting-Request packet? > RFC-3576 ( Dynamic authorization extensions) does recommend Event Time Stamp to support replay detection. I believe the restriction is already lifted for Disconnect and CoA messages. Perhaps this is the right time to make the attribute applicable to all messages. Regards Nagi. -- 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, 22 Dec 2003 14:39:27 +0000 Message-ID: <3FE6F532.2C38C190@alcatel.be> Date: Mon, 22 Dec 2003 14:44:18 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Reply-Message/EAP-Message attributes in RFC-3576 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a question regarding the Reply-Message and EAP-message attributes that can be present in the Disconnect (or CoA) request. i) Can somebody educate me how are these attributes used. I'm wondering how these messages are delivered to the user. ii) Why is that Reply-Message not there in ACK messages where as the EAP-Message can be there in ACKs as well. Thanks in advance, Nagi. -- 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, 22 Dec 2003 14:39:06 +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: QoS attributes Date: Mon, 22 Dec 2003 09:26:08 +0200 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPGUmeyLB/sqpffRXOG09PMka+qkACCiZ2A From: To: , , Hi Avi, > I agree that we need a QoS Class Id, (or QoS-Bundle-Id). >=20 > Would RADIUS only ever transport the QoS-Class-Id? My thoughts are that a AAA system would only authorize for a certain QoS Class, not necessarily authorize specific QoS parameters. =20 > Also reading through some of the drafts you point to. I=20 > noticed that COPS is used. I think that at least in certain=20 > cases that RADIUS/Diameter should be utilized instead of=20 > COPS. There certainly have been discussion on this. I agree. I don't think that COPS is the proper mechanism, though some people use it. Most of the discussions I have heard, as of late, seem to be about migrating to AAA mechanisms for QoS authorization. John -- 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, 21 Dec 2003 12:38:45 +0000 From: "Hannes Tschofenig" To: , Cc: "Avi Lior" , Subject: AW: QoS attributes Date: Sun, 21 Dec 2003 13:45:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit hi jari, thanks for raising this problem with cops. theoretically it also provides roaming with the same concepts. however, from a deployment point of view it was only used within a local domain. most operators don't want to setup the same infrastructure (cops and radius/diameter) for inter-domain communication only to support authorization for qos requests. this is one of the problems we discovered when we looked at how rsvp provides authorization for qos requests (there are other issues which are described in the 'rsvp security properties' draft). hence, we started working on the draft which john mentioned. john might have some additional comments beyond my description of the history behind this draft. ciao hannes > -----Ursprüngliche Nachricht----- > Von: Jari Arkko [mailto:jari.arkko@piuha.net] > Gesendet: Freitag, 19. Dezember 2003 19:24 > An: 'john.loughney@nokia.com' > Cc: Avi Lior; radiusext@ops.ietf.org > Betreff: Re: QoS attributes > > > > Avi wrote: > > > ... COPS ... RADIUS/Diameter > > Interesting. > > John, perhaps you can educate me a little bit regarding the use > of COPS in these environments. How does roaming work? That is, > if my home operator is in Finland but I'm in California and use > a local ISP's QoS and COPS-based services -- does COPS have a > concept similar to AAA proxies and multiple parties that take > part in the "transaction"? > > --Jari > > > -- > 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, 19 Dec 2003 18:25:06 +0000 Message-ID: <3FE34232.9050509@piuha.net> Date: Fri, 19 Dec 2003 20:23:46 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "'john.loughney@nokia.com'" Cc: Avi Lior , radiusext@ops.ietf.org Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi wrote: > ... COPS ... RADIUS/Diameter Interesting. John, perhaps you can educate me a little bit regarding the use of COPS in these environments. How does roaming work? That is, if my home operator is in Finland but I'm in California and use a local ISP's QoS and COPS-based services -- does COPS have a concept similar to AAA proxies and multiple parties that take part in the "transaction"? --Jari -- 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, 19 Dec 2003 17:07:43 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Fri, 19 Dec 2003 12:05:57 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi John, I agree that we need a QoS Class Id, (or QoS-Bundle-Id). Would RADIUS only ever transport the QoS-Class-Id? Also reading through some of the drafts you point to. I noticed that COPS is used. I think that at least in certain cases that RADIUS/Diameter should be utilized instead of COPS. There certainly have been discussion on this. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: December 18, 2003 4:40 AM > To: dnelson@enterasys.com; radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > Hi all, > > My 2 cents are as follows: RADext/AAAext (or whatever) > shouldn't define QoS signaling, > NSIS is already doing that: > http://www.ietf.org/html.charters/nsis-charter.html There has been some discussion on AAA issues for QoS: http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-0 0.txt Looking into QoS issues, my feeling is that we want to specify QoS classes. These classes may support a set of QoS parameters. I think that QoS will be an area that vendors try to differentiate on; service providers may create services that support different QoS parameters, etc. I don't think that we can get into the QoS signaling / provisioning / definition of QoS parameters, as that excedes the scope of AAA (either RADIUS or Diameter). I would prefer that RADIUS / Diameter would contain a QoS class parameter, which could make use something like a IANA QoS class registry. Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have defined seperate QOS classes. One could imagine registering these classes in IANA, and service providers could support, in various degrees, different QoS classes. It would then be in scope of AAA to provide authorization for these classes. John -- 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: Thu, 18 Dec 2003 19:15: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: questions/comments on draft-black-radius-lanedge-00.txt Date: Thu, 18 Dec 2003 14:14:48 -0500 Message-ID: Thread-Topic: questions/comments on draft-black-radius-lanedge-00.txt Thread-Index: AcPFk4dERDIlk0z7Rpew3e61lUichwABDKpA From: "Nelson, David" Cc: Comments on this thread --- On NAS-Identifier vs. Location-ID: If the proposed Location-ID is defined to contain X.500 format location information, and the syntax is standardized and interoperable, it makes sense to add this as a separate attribute and leave NAS-Identifier alone (as it is typically the FQDN of the NAS). On the new time attribute vs. Event-Timestamp: Allowing an existing attribute, Event-Timestamp, to be included in other packet types is preferable to creating a new attribute. On Port-VLAN-ID vs. Tunnel-Private-Group-ID: I have a mixed opinion on this one. over-loading existing attributes for new uses is less than desirable. However, if the new use is relatively compatible with the original use, and the exact usage is absolutely clear from context (as it is in this case), I think that the "protocol neatness" obtained from having a separate and distinct Port-VLAN-ID, in preference to the Tunnel-Private-Group-ID is somewhat marginal. I could probably support either way, although we should be clear on the status of the RFC 3580 usage -- are we going to deprecate it? Will we support the use of both attributes? It should be made clear what is the correct behavior if both attributes are contained in a single Access-Accept and do not contain exactly the same value.=20 On IP-Filter-Name vs. Filter-ID: I think that the new attribute is redundant and Filter-ID works just fine for this purpose. If one was to suggest (and I'm not doing so) that it was desirable to have separately specified L2 and L3 filters working "in series connection", this might make sense, but I don't think that was the initial intent. On the Bandwidth attributes: If these are part of the over-all QoS solution, then I favor an attribute or attributes that specify an authorized class of QoS for the user, and favor leaving the provisioning of specific parameters and rules to implement the various QoS classes to a more appropriate protocol. I don't think that detailed QoS parameter provisioning falls into the scope of AAA protocols. On etymology: As to the colloquial phrase "passes muster", it evolves from military terminology, in which early militias would "muster" and be inspected by the command staff for battle readiness and other military fitness requirements. What I meant in using this phrase is that the proposed attributes obtain broad Internet Community consensus and demonstrate multi-vendor interoperability. -- Dave -- 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, 18 Dec 2003 18:37:10 +0000 From: "Ed Van Horne" To: "'nagi reddy jonnala'" , "'BLACK,CHUCK \(HP-Roseville,ex1\)'" Cc: Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt Date: Thu, 18 Dec 2003 10:36:46 -0800 Organization: Cisco Systems Message-ID: <003801c3c595$e425fe40$8b696540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nagi, Based on discussions within and outside of IETF, I believe that both LocationId and NAS-Identifier are useful. In the case of LocationId, the contents of the field will be standardized, increasing the opportunities for interoperability and the richness of the information conveyed. While something similar could be done with NAS-Identifier, it would likely not be interoperable. Regards, Ed Ed Van Horne Building Broadband Solutions Unit - San Diego Cisco Systems 10935 Vista Sorrento Parkway San Diego, CA 92130 858.526.1152 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of nagi reddy jonnala Sent: Thursday, December 18, 2003 10:16 AM To: BLACK,CHUCK (HP-Roseville,ex1) Cc: radiusext@ops.ietf.org Subject: Re: questions/comments on draft-black-radius-lanedge-00.txt Hi Chuck, Thanks for your responses. See my comments inline. > > 1) Do access devices (such as IP DSLAMs) come under > > LAN Edge switches? What exactly does a LAN Edge device mean? > > The intent of the document is to attempt to define the delivery of > 'edge'-type attributes -- VLANs, ACLs, QoS, bandwidth -- for delivery > via RADIUS reply to the RADIUS client (NAS or switch). Your > suggestion of considering these attributes for a broadband environment > such as IP DSLAM is interesting and, assuming those DSLAM devices > support some or all of those attributes, they may as well be a good > fit. I believe it does make sense to consider the access devices such as IP DSLAM since they do connect the IPoE users using 802.1x authentication. More or less the attributes you mentioned are applicable to these devices as well. I'll have to work out what more attributes are needed in these environments. > > > > 2) When do we use the Location-ID and Location-Name attributes. I > > guess they are used in wireless networks. Can't NAS-ID be used to > > identify the Location? Can you explain little further. > > This document was really following the lead of the wireless > specification WISPr, which proposes the wireless attributes for > Location-ID and Location-Name. It is possible that there should be > standard RADIUS attributes for these. The NAS-Identifier attribute of > standard RADIUS does not define a specification of the format of the > string; the Location-ID does specify a format > (isocc=,cc=, ...). > > I guess I'll leave it at that. Either Location-ID or NAS-Identifier > is fine, as long as the format is specified so that we can all agree > on and use the same string. > > > 3) The draft proposes a new Time attribute (along with Location-ID > > and Location Name). Why can't we use Event-TimeStamp define in > > RFC-2869 which is also in UTC format? Is there a specific reason to > > have a new > attribute > > defined here again? > The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request > packet attribute. Perhaps for standardization this attribute could be > carried in either an Access-Request or an Accounting-Request packet? I think it doesn't harm if we make this attribute applicable to any packet. To be future safe, I propose to make the Event-TimeStamp attribute applicable to any type of packet. > > > > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of > > Tunnel-Type=VLAN (13), Tunnel-Medium- Type=802, and > > Tunnel-Private-Group-ID=VLANID as described in RFC 3580. I'm > > wondering how can a VSA which is by definition an optional can > > replace the use of some thing that was > standardized > > before. I also feel that Tunnel Type usage doesn't look nice to > > carry > VLAN-IDs. > > But I suggest that we define a standard attribute to carry VLAN-ID > > which can replace Tunnel Type usage. > > Since RFC-3580 is informational and regards suggested usage, it was > hoped that a new attribute, categorized as a part of a set of "LAN > Edge" attributes, would be a preferable solution. So the question is: > should we overload an old attribute which was not intended to carry > VLAN information in the first place (as in RFC-3580), or should we be > redundant and define a new one (as in this document)? Perhaps the > best option is along the lines of what was suggested by another > reviewer here in this forum, wherein we create a better categorization > of attributes, including common and domain-specific. I agree with you. Though it is redundant, better define new attribute. I disagree if you say the new one is VSA. > > > > 5) I'm trying to undertand the difference between PVID and > > Egress-VID. You mean, PVID is the default-VLAN-ID and Egree-VIDs are > > allowed list of VLAN-IDs. Right? > > You are absolutely correct. I favored using that terminology, but my > friend and colleague Paul Congdon, a confirmed IEEE 802 guy, favored > the more technically-precise but obtuse terminology you see there. > :-) I don't have any concerns if the message is clear to all. Paul, can we use the terminology that we are familiar atleast inside the explanation :-) > > > > 6) Section 2.3.6- How do we map the user-priority-generation-table? > > How is a byte (rather than a bit) is useful to re-map the > > priorities. > > The idea is that we send down an entire table of prioritization > mapping, which will tell the edge device how to map any of the > incoming priorities. Thus if byte 0's value is 4, and byte 1's value > is 2, and byte 2's value is 8, then incoming packets with priority 0 > will be set to priority 4, incoming packets with priority 1 will be > set to priority 2, and incoming packets with priority 2 will be set to > priority 8, and so on. If all packets are to be forced to fixed > priority, then all eight bytes of the table will have that same value. > > I hope that I understood your question and that this explains the > intent of the table. Yes, I got it. > > > > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute > > for > this? > > Can't we use the Filter-ID defined in the standard. I agree that it > doesn't > > explicitly mean what filter it is. > > This is again the issue of whether to re-use an existing attribute, or > define a new one within the domain ("LAN Edge") where it best belongs. I see your point. My argument is that it is more work to the implementors. Is it worth? > > > > 8) I guess Bandwidth attributes "passes muster". I don't think the > > standardization of these attributes cause any problem to the > > implementors nor does it compell the radius client / proxy > > implementations to support these attributes. In the "Table of > > attributes" section, we can specify if > the > > attribute may not be present at all. > > Agreed. Although your use of the phrase "passes muster" makes me > wonder where that phrase came from. I guess it's time to visit the > word-etymology web site... > > Even I had to refer the idiom in dictionary.com but I thought that was the common usage and borrowed it from David Nelson ;-) David, what are your comments on both the phrase and the bandwidth attributes :-) Regards Nagi. > > > -----Original Message----- > From: njonnala@sh.bel.alcatel.be [mailto:njonnala@sh.bel.alcatel.be] > On Behalf Of nagi reddy jonnala > Sent: Thursday, December 18, 2003 1:54 AM > To: BLACK,CHUCK (HP-Roseville,ex1) > Cc: radiusext@ops.ietf.org > Subject: questions/comments on draft-black-radius-lanedge-00.txt > > I've read > http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt > > and have some questions and comments: > > 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? > What exactly does a LAN Edge device mean? > > 2) When do we use the Location-ID and Location-Name attributes. I > guess they are used in wireless networks. Can't NAS-ID be used to > identify the Location? Can you explain little further. > > 3) The draft proposes a new Time attribute (along with Location-ID and > Location Name). Why can't we use Event-TimeStamp define in RFC-2869 > which is also in UTC format? Is there a specific reason to have a new > attribute defined here again? > > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of > Tunnel-Type=VLAN (13), Tunnel-Medium- > Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC > 3580. I'm wondering how can a VSA which is by definition an optional > can replace the use of some thing that was standardized before. I also > feel that Tunnel Type usage doesn't look nice to carry VLAN-IDs. But I > suggest that we define a standard attribute to carry VLAN-ID which > can replace Tunnel Type usage. > > 5) I'm trying to undertand the difference between PVID and Egress-VID. > You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list > of VLAN-IDs. Right? > > 6) Section 2.3.6- How do we map the user-priority-generation-table? > How is a byte (rather than a bit) is useful to re-map the priorities. > > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute > for this? Can't we use the Filter-ID defined in the standard. I agree > that it doesn't explicitly mean what filter it is. > > 8) I guess Bandwidth attributes "passes muster". I don't think the > standardization of these attributes cause any problem to the > implementors nor does it compell the radius client / proxy > implementations to support these attributes. In the "Table of > attributes" section, we can specify if the attribute may not be > present at all. > > Comments welcome. > > Regards > Nagi. > > -- > 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: Thu, 18 Dec 2003 18:16:57 +0000 Message-ID: <3FE1EEFC.9891953C@alcatel.be> Date: Thu, 18 Dec 2003 19:16:28 +0100 From: nagi reddy jonnala Organization: Alcatel Telecom MIME-Version: 1.0 To: "BLACK,CHUCK (HP-Roseville,ex1)" CC: radiusext@ops.ietf.org Subject: Re: questions/comments on draft-black-radius-lanedge-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Chuck, Thanks for your responses. See my comments inline. > > 1) Do access devices (such as IP DSLAMs) come under > > LAN Edge switches? What exactly does a LAN Edge device mean? > > The intent of the document is to attempt to define the delivery of > 'edge'-type attributes -- VLANs, ACLs, QoS, bandwidth -- for delivery via > RADIUS reply to the RADIUS client (NAS or switch). Your suggestion of > considering these attributes for a broadband environment such as IP DSLAM is > interesting and, assuming those DSLAM devices support some or all of those > attributes, they may as well be a good fit. I believe it does make sense to consider the access devices such as IP DSLAM since they do connect the IPoE users using 802.1x authentication. More or less the attributes you mentioned are applicable to these devices as well. I'll have to work out what more attributes are needed in these environments. > > > > 2) When do we use the Location-ID and Location-Name attributes. > > I guess they are used in wireless networks. Can't NAS-ID be used > > to identify the Location? Can you explain little further. > > This document was really following the lead of the wireless specification > WISPr, which proposes the wireless attributes for Location-ID and > Location-Name. It is possible that there should be standard RADIUS > attributes for these. The NAS-Identifier attribute of standard RADIUS does > not define a specification of the format of the string; the Location-ID does > specify a format (isocc=,cc=, ...). > > I guess I'll leave it at that. Either Location-ID or NAS-Identifier is > fine, as long as the format is specified so that we can all agree on and use > the same string. > > > 3) The draft proposes a new Time attribute (along with Location-ID > > and Location Name). Why can't we use Event-TimeStamp define in RFC-2869 > > which is also in UTC format? Is there a specific reason to have a new > attribute > > defined here again? > The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request > packet attribute. Perhaps for standardization this attribute could be > carried in either an Access-Request or an Accounting-Request packet? I think it doesn't harm if we make this attribute applicable to any packet. To be future safe, I propose to make the Event-TimeStamp attribute applicable to any type of packet. > > > > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of > > Tunnel-Type=VLAN (13), Tunnel-Medium- > > Type=802, and Tunnel-Private-Group-ID=VLANID > > as described in RFC 3580. I'm wondering how can a VSA which is by > > definition an optional can replace the use of some thing that was > standardized > > before. I also feel that Tunnel Type usage doesn't look nice to carry > VLAN-IDs. > > But I suggest that we define a standard attribute to carry VLAN-ID which > > can replace Tunnel Type usage. > > Since RFC-3580 is informational and regards suggested usage, it was hoped > that a new attribute, categorized as a part of a set of "LAN Edge" > attributes, would be a preferable solution. So the question is: should we > overload an old attribute which was not intended to carry VLAN information > in the first place (as in RFC-3580), or should we be redundant and define a > new one (as in this document)? Perhaps the best option is along the lines > of what was suggested by another reviewer here in this forum, wherein we > create a better categorization of attributes, including common and > domain-specific. I agree with you. Though it is redundant, better define new attribute. I disagree if you say the new one is VSA. > > > > 5) I'm trying to undertand the difference between PVID and Egress-VID. > > You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list > > of VLAN-IDs. Right? > > You are absolutely correct. I favored using that terminology, but my friend > and colleague Paul Congdon, a confirmed IEEE 802 guy, favored the more > technically-precise but obtuse terminology you see there. :-) I don't have any concerns if the message is clear to all. Paul, can we use the terminology that we are familiar atleast inside the explanation :-) > > > > 6) Section 2.3.6- How do we map the user-priority-generation-table? > > How is a byte (rather than a bit) is useful to re-map the priorities. > > The idea is that we send down an entire table of prioritization mapping, > which will tell the edge device how to map any of the incoming priorities. > Thus if byte 0's value is 4, and byte 1's value is 2, and byte 2's value is > 8, then incoming packets with priority 0 will be set to priority 4, incoming > packets with priority 1 will be set to priority 2, and incoming packets with > priority 2 will be set to priority 8, and so on. If all packets are to be > forced to fixed priority, then all eight bytes of the table will have that > same value. > > I hope that I understood your question and that this explains the intent of > the table. Yes, I got it. > > > > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for > this? > > Can't we use the Filter-ID defined in the standard. I agree that it > doesn't > > explicitly mean what filter it is. > > This is again the issue of whether to re-use an existing attribute, or > define a new one within the domain ("LAN Edge") where it best belongs. I see your point. My argument is that it is more work to the implementors. Is it worth? > > > > 8) I guess Bandwidth attributes "passes muster". I don't think the > > standardization of these attributes cause any problem to the implementors > > nor does it compell the radius client / proxy implementations to support > > these attributes. In the "Table of attributes" section, we can specify if > the > > attribute may not be present at all. > > Agreed. Although your use of the phrase "passes muster" makes me wonder > where that phrase came from. I guess it's time to visit the word-etymology > web site... > > Even I had to refer the idiom in dictionary.com but I thought that was the common usage and borrowed it from David Nelson ;-) David, what are your comments on both the phrase and the bandwidth attributes :-) Regards Nagi. > > > -----Original Message----- > From: njonnala@sh.bel.alcatel.be [mailto:njonnala@sh.bel.alcatel.be] On > Behalf Of nagi reddy jonnala > Sent: Thursday, December 18, 2003 1:54 AM > To: BLACK,CHUCK (HP-Roseville,ex1) > Cc: radiusext@ops.ietf.org > Subject: questions/comments on draft-black-radius-lanedge-00.txt > > I've read > http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt > > and have some questions and comments: > > 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What > exactly does a LAN Edge device mean? > > 2) When do we use the Location-ID and Location-Name attributes. I guess they > are used in wireless networks. Can't NAS-ID be used to identify the > Location? Can you explain little further. > > 3) The draft proposes a new Time attribute (along with Location-ID and > Location Name). Why can't we use Event-TimeStamp define in RFC-2869 which > is also in UTC format? Is there a specific reason to have a new attribute > defined here again? > > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of > Tunnel-Type=VLAN (13), Tunnel-Medium- > Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580. > I'm wondering how can a VSA which is by definition an optional can replace > the use of some thing that was standardized before. I also feel that Tunnel > Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define > a standard attribute to carry VLAN-ID which can replace Tunnel Type usage. > > 5) I'm trying to undertand the difference between PVID and Egress-VID. You > mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of > VLAN-IDs. Right? > > 6) Section 2.3.6- How do we map the user-priority-generation-table? How is a > byte (rather than a bit) is useful to re-map the priorities. > > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for > this? Can't we use the Filter-ID defined in the standard. I agree that it > doesn't explicitly mean what filter it is. > > 8) I guess Bandwidth attributes "passes muster". I don't think the > standardization of these attributes cause any problem to the implementors > nor does it compell the radius client / proxy implementations to support > these attributes. In the "Table of attributes" section, we can specify if > the attribute may not be present at all. > > Comments welcome. > > Regards > Nagi. > > -- > 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: Thu, 18 Dec 2003 17:47:30 +0000 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "BLACK,CHUCK (HP-Roseville,ex1)" , radiusext@ops.ietf.org Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt Date: Thu, 18 Dec 2003 12:46:45 -0500 MIME-Version: 1.0 Content-Type: text/plain I have a few comments and clarifications below... > Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt > > > Hi Nagi, > > Thanks for the comments. Here are my replies: > > > 1) Do access devices (such as IP DSLAMs) come under > > LAN Edge switches? What exactly does a LAN Edge device mean? > > The intent of the document is to attempt to define the > delivery of 'edge'-type attributes -- VLANs, ACLs, QoS, > bandwidth -- for delivery via RADIUS reply to the RADIUS > client (NAS or switch). Your suggestion of considering these > attributes for a broadband environment such as IP DSLAM is > interesting and, assuming those DSLAM devices support some or > all of those attributes, they may as well be a good fit. > The primary focus has been on IEEE 802 devices like Ethernet switches and 802.11 Access Points. Thus the term 'LAN'. We are searching for 'standardized' management controls in 802 devices that we can configure with these attributes. Unfortunately, many of the things we want to configure don't have standard controls. That said, I see no reason why other 'edge' devices couldn't take advantage of these attributes. The first choice, however, is to configure 'standardized' 802 management controls. I'm not sure if IP DSLAMs overload these controls or not. I'm guessing they have their own. > > 2) When do we use the Location-ID and Location-Name attributes. > > I guess they are used in wireless networks. Can't NAS-ID be used > > to identify the Location? Can you explain little further. > > This document was really following the lead of the wireless > specification WISPr, which proposes the wireless attributes > for Location-ID and Location-Name. It is possible that there > should be standard RADIUS attributes for these. The > NAS-Identifier attribute of standard RADIUS does not define a > specification of the format of the string; the Location-ID > does specify a format > (isocc=,cc=, ...). > > I guess I'll leave it at that. Either Location-ID or > NAS-Identifier is fine, as long as the format is specified so > that we can all agree on and use the same string. > We certainly want to stick with the X.500 stuff for location specification. I think NAS-Id typically contains a domain name and doesn't have specific location information unless the string is formatted for this. Location-ID seems like the best idea to get specific location data. > > > 5) I'm trying to undertand the difference between PVID and > Egress-VID. > > You mean, PVID is the default-VLAN-ID and Egree-VIDs are > allowed list > > of VLAN-IDs. Right? > > You are absolutely correct. I favored using that > terminology, but my friend and colleague Paul Congdon, a > confirmed IEEE 802 guy, favored the more technically-precise > but obtuse terminology you see there. :-) > Actually, this isn't entirely correct. The PVID is the default VLAN for untagged traffic received at the port. The Egress list contains the VLANs that can be transmitted out of the port (in either tagged or untagged format). Familiarity with IEEE 802.1Q helps a lot here. If 'Ingress Filters' are enabled, then the egress list kind of also becomes the list of 'allowed' VLANs to be received as well. So, to confuse everyone here, VLANs are sort of asymmetric unless Ingress Filters are turned on. With untagged traffic (which is what is typically at the 'edge' anyway), it is possible to have many VLANs egress a port, but all received untagged traffic is mapped to a single VLAN denoted by the PVID. Since the traffic is untagged, the different VLANs egressing the port aren't really apparent to the end stations on that link. This is really just a tricky way for switches to do some forms of filtering. With tagged traffic, the VLANs are explicitly labeled, so everyone knows what VLAN the frame belongs to. When 'ingress filters' are enabled, the tagged frames received must be members of the VLANs that are listed on the egress list. Paul -- 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, 18 Dec 2003 16:49:09 +0000 Message-ID: <7A371016E109114EA47C89370296278B26373B@xrose01.rose.hp.com> From: "BLACK,CHUCK (HP-Roseville,ex1)" To: radiusext@ops.ietf.org Cc: "BLACK,CHUCK (HP-Roseville,ex1)" Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt Date: Thu, 18 Dec 2003 08:48:23 -0800 MIME-Version: 1.0 Content-Type: text/plain Hi Nagi, Thanks for the comments. Here are my replies: > 1) Do access devices (such as IP DSLAMs) come under > LAN Edge switches? What exactly does a LAN Edge device mean? The intent of the document is to attempt to define the delivery of 'edge'-type attributes -- VLANs, ACLs, QoS, bandwidth -- for delivery via RADIUS reply to the RADIUS client (NAS or switch). Your suggestion of considering these attributes for a broadband environment such as IP DSLAM is interesting and, assuming those DSLAM devices support some or all of those attributes, they may as well be a good fit. > 2) When do we use the Location-ID and Location-Name attributes. > I guess they are used in wireless networks. Can't NAS-ID be used > to identify the Location? Can you explain little further. This document was really following the lead of the wireless specification WISPr, which proposes the wireless attributes for Location-ID and Location-Name. It is possible that there should be standard RADIUS attributes for these. The NAS-Identifier attribute of standard RADIUS does not define a specification of the format of the string; the Location-ID does specify a format (isocc=,cc=, ...). I guess I'll leave it at that. Either Location-ID or NAS-Identifier is fine, as long as the format is specified so that we can all agree on and use the same string. > 3) The draft proposes a new Time attribute (along with Location-ID > and Location Name). Why can't we use Event-TimeStamp define in RFC-2869 > which is also in UTC format? Is there a specific reason to have a new attribute > defined here again? The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request packet attribute. Perhaps for standardization this attribute could be carried in either an Access-Request or an Accounting-Request packet? > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of > Tunnel-Type=VLAN (13), Tunnel-Medium- > Type=802, and Tunnel-Private-Group-ID=VLANID > as described in RFC 3580. I'm wondering how can a VSA which is by > definition an optional can replace the use of some thing that was standardized > before. I also feel that Tunnel Type usage doesn't look nice to carry VLAN-IDs. > But I suggest that we define a standard attribute to carry VLAN-ID which > can replace Tunnel Type usage. Since RFC-3580 is informational and regards suggested usage, it was hoped that a new attribute, categorized as a part of a set of "LAN Edge" attributes, would be a preferable solution. So the question is: should we overload an old attribute which was not intended to carry VLAN information in the first place (as in RFC-3580), or should we be redundant and define a new one (as in this document)? Perhaps the best option is along the lines of what was suggested by another reviewer here in this forum, wherein we create a better categorization of attributes, including common and domain-specific. > 5) I'm trying to undertand the difference between PVID and Egress-VID. > You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list > of VLAN-IDs. Right? You are absolutely correct. I favored using that terminology, but my friend and colleague Paul Congdon, a confirmed IEEE 802 guy, favored the more technically-precise but obtuse terminology you see there. :-) > 6) Section 2.3.6- How do we map the user-priority-generation-table? > How is a byte (rather than a bit) is useful to re-map the priorities. The idea is that we send down an entire table of prioritization mapping, which will tell the edge device how to map any of the incoming priorities. Thus if byte 0's value is 4, and byte 1's value is 2, and byte 2's value is 8, then incoming packets with priority 0 will be set to priority 4, incoming packets with priority 1 will be set to priority 2, and incoming packets with priority 2 will be set to priority 8, and so on. If all packets are to be forced to fixed priority, then all eight bytes of the table will have that same value. I hope that I understood your question and that this explains the intent of the table. > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for this? > Can't we use the Filter-ID defined in the standard. I agree that it doesn't > explicitly mean what filter it is. This is again the issue of whether to re-use an existing attribute, or define a new one within the domain ("LAN Edge") where it best belongs. > 8) I guess Bandwidth attributes "passes muster". I don't think the > standardization of these attributes cause any problem to the implementors > nor does it compell the radius client / proxy implementations to support > these attributes. In the "Table of attributes" section, we can specify if the > attribute may not be present at all. Agreed. Although your use of the phrase "passes muster" makes me wonder where that phrase came from. I guess it's time to visit the word-etymology web site... Thanks again for the comments, /chuck -----Original Message----- From: njonnala@sh.bel.alcatel.be [mailto:njonnala@sh.bel.alcatel.be] On Behalf Of nagi reddy jonnala Sent: Thursday, December 18, 2003 1:54 AM To: BLACK,CHUCK (HP-Roseville,ex1) Cc: radiusext@ops.ietf.org Subject: questions/comments on draft-black-radius-lanedge-00.txt I've read http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt and have some questions and comments: 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What exactly does a LAN Edge device mean? 2) When do we use the Location-ID and Location-Name attributes. I guess they are used in wireless networks. Can't NAS-ID be used to identify the Location? Can you explain little further. 3) The draft proposes a new Time attribute (along with Location-ID and Location Name). Why can't we use Event-TimeStamp define in RFC-2869 which is also in UTC format? Is there a specific reason to have a new attribute defined here again? 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of Tunnel-Type=VLAN (13), Tunnel-Medium- Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580. I'm wondering how can a VSA which is by definition an optional can replace the use of some thing that was standardized before. I also feel that Tunnel Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define a standard attribute to carry VLAN-ID which can replace Tunnel Type usage. 5) I'm trying to undertand the difference between PVID and Egress-VID. You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of VLAN-IDs. Right? 6) Section 2.3.6- How do we map the user-priority-generation-table? How is a byte (rather than a bit) is useful to re-map the priorities. 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for this? Can't we use the Filter-ID defined in the standard. I agree that it doesn't explicitly mean what filter it is. 8) I guess Bandwidth attributes "passes muster". I don't think the standardization of these attributes cause any problem to the implementors nor does it compell the radius client / proxy implementations to support these attributes. In the "Table of attributes" section, we can specify if the attribute may not be present at all. Comments welcome. Regards Nagi. -- 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, 18 Dec 2003 13:17:04 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0524@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Thu, 18 Dec 2003 14:16:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" thank you john for the pointers. qos is more than just shuffling some bandwidth parameters around. comments to the drafts are highly appreciated. ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, December 18, 2003 10:40 AM > To: dnelson@enterasys.com; radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > Hi all, > > My 2 cents are as follows: RADext/AAAext (or whatever) > shouldn't define QoS signaling, > NSIS is already doing that: > > http://www.ietf.org/html.charters/nsis-charter.html > > There has been some discussion on AAA issues for QoS: > > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt > http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos- > authz-issues-00.txt > > Looking into QoS issues, my feeling is that we want to > specify QoS classes. > These classes may support a set of QoS parameters. I think that QoS > will be an area that vendors try to differentiate on; service > providers > may create services that support different QoS parameters, > etc. I don't > think that we can get into the QoS signaling / provisioning / > definition > of QoS parameters, as that excedes the scope of AAA (either RADIUS or > Diameter). I would prefer that RADIUS / Diameter would contain a > QoS class parameter, which could make use something like a IANA QoS > class registry. > > Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have > defined seperate QOS classes. One could imagine registering > these classes > in IANA, and service providers could support, in various > degrees, different > QoS classes. It would then be in scope of AAA to provide > authorization for > these classes. > > John > > -- > 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: Thu, 18 Dec 2003 09:54:07 +0000 Message-ID: <3FE17926.7780171A@alcatel.be> Date: Thu, 18 Dec 2003 10:53:42 +0100 From: nagi reddy jonnala Organization: Alcatel Telecom MIME-Version: 1.0 To: "BLACK,CHUCK (HP-Roseville,ex1)" CC: radiusext@ops.ietf.org Subject: questions/comments on draft-black-radius-lanedge-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've read http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt and have some questions and comments: 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What exactly does a LAN Edge device mean? 2) When do we use the Location-ID and Location-Name attributes. I guess they are used in wireless networks. Can't NAS-ID be used to identify the Location? Can you explain little further. 3) The draft proposes a new Time attribute (along with Location-ID and Location Name). Why can't we use Event-TimeStamp define in RFC-2869 which is also in UTC format? Is there a specific reason to have a new attribute defined here again? 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of Tunnel-Type=VLAN (13), Tunnel-Medium- Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580. I'm wondering how can a VSA which is by definition an optional can replace the use of some thing that was standardized before. I also feel that Tunnel Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define a standard attribute to carry VLAN-ID which can replace Tunnel Type usage. 5) I'm trying to undertand the difference between PVID and Egress-VID. You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of VLAN-IDs. Right? 6) Section 2.3.6- How do we map the user-priority-generation-table? How is a byte (rather than a bit) is useful to re-map the priorities. 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for this? Can't we use the Filter-ID defined in the standard. I agree that it doesn't explicitly mean what filter it is. 8) I guess Bandwidth attributes "passes muster". I don't think the standardization of these attributes cause any problem to the implementors nor does it compell the radius client / proxy implementations to support these attributes. In the "Table of attributes" section, we can specify if the attribute may not be present at all. Comments welcome. Regards Nagi. -- 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, 18 Dec 2003 09:40:26 +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: QoS attributes Date: Thu, 18 Dec 2003 11:39:34 +0200 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEHWO6PtNWYO0/Sq2k0cS+cloq9QAAp9MQAB0cCbA= From: To: , Hi all, My 2 cents are as follows: RADext/AAAext (or whatever) shouldn't define = QoS signaling,=20 NSIS is already doing that: http://www.ietf.org/html.charters/nsis-charter.html There has been some discussion on AAA issues for QoS: http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issue= s-00.txt Looking into QoS issues, my feeling is that we want to specify QoS = classes. These classes may support a set of QoS parameters. I think that QoS will be an area that vendors try to differentiate on; service providers may create services that support different QoS parameters, etc. I don't think that we can get into the QoS signaling / provisioning / definition of QoS parameters, as that excedes the scope of AAA (either RADIUS or Diameter). I would prefer that RADIUS / Diameter would contain a=20 QoS class parameter, which could make use something like a IANA QoS class registry.=20 Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have defined seperate QOS classes. One could imagine registering these = classes in IANA, and service providers could support, in various degrees, = different QoS classes. It would then be in scope of AAA to provide authorization = for these classes. John -- 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, 18 Dec 2003 08:30:24 +0000 Message-ID: <3FE1655A.1050502@piuha.net> Date: Thu, 18 Dec 2003 10:29:14 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > The attribute space is certainly finite. My perception is that RADIUS Yes. I would add that extending attribute space is always possible later, as long as you have at least one free number left... this was by the way the approach taken in EAP, RFC 2284bis. > Let's come to consensus on the list of attributes that "pass muster", > and then we can take a head-count to see if the attribute address space > is in imminent risk of exhaustion. I agree. --Jari -- 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, 18 Dec 2003 08:23:59 +0000 Message-ID: <3FE163C8.4050503@piuha.net> Date: Thu, 18 Dec 2003 10:22:32 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Avi Lior Cc: "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question regarding IP Filter Rule Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > Hi Jari, > > You could use Framed-Route but now all traffic would be routed to the Portal > etc..... > > I think it would be more appropriate to introduce a new attribute so that: > > A) the NAS would deal with the routing functions (as it always does) and the > Portal does not have to do it. > > B) We would have the flexibility to decide whether to route all traffic or > just some traffic. Perhaps. Are the redirection schemes used for payment? I.e. I need to log in to the web page before I can continue? Or for something else? There is a difference because if its used for payment, redirecting just some protocols may leave a hole to the protocols. For instance, I have sometimes succeeded in doing all my e-mail over SSH even if there was some http-directing thing that prevented all web traffic. --Jari -- 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, 17 Dec 2003 22:21:32 +0000 From: "Ed Van Horne" To: "'Avi Lior'" , Subject: RE: QoS attributes Date: Wed, 17 Dec 2003 14:20:08 -0800 Organization: Cisco Systems Message-ID: <006901c3c4eb$ee1b96d0$8b696540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Avi, I agree with you on there being more than one type of QoS attribute. In particular, robust support of VoIP, which seems to be taking off in the market place, demands a way to prioritize and perhaps even reserve bandwidth. VoIP is very sensitive to dropouts and jitter. The current state of the art is rather variable voice quality depending on network load, etc. (There was an interesting discussion of VoIP on PBS Talk of the Nation recently.) So far this lack of a consistent level of service is acceptable because VoIP is dirt cheap. Fixing this is much more than a RADIUS issue, since consistent technology to prioritize and reserve bandwidth is needed end to end. The whole things falls apart if even one intermediate device does not support QoS. Most of this is out of scope for this discussion, but we could discuss the RADIUS piece that determines whether a user is *allowed* to use this hypothetical service. My $.02, Ed Ed Van Horne Building Broadband Solutions Unit - San Diego Cisco Systems 10935 Vista Sorrento Parkway San Diego, CA 92130 858.526.1152 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Tuesday, December 16, 2003 9:29 AM To: 'radiusext@ops.ietf.org' Subject: QoS attributes I noticed that we are talking about QoS on the list. In the current drafts folks are talking about QoS but are only specifying Bandwidth attributes. There are other QoS attributes. The problem is that there are a lot of different QoS attributes and different flavours as well. The question is which attributes and flavours should be modelled. I think we need a RADIUS QoS Draft in general. I started to write one and stopped to see what was going on in a couple of other areas. (For example Diameter and as well, work in 3GPP2 where the interface between the PDSN and the AAA will be used to query and transport QoS attributes). For example, one of the useful things about the CoA is that now I can change the QoS attributes of a session mid stream. So it would be useful to define these attributes (and not just Bandwidth). Any comments would be greatly appreciated. > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, December 16, 2003 11:45 AM > To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid > Subject: RE: Comments on > draft-adrangi-radius-extension-for-pwlan-00.txt > > > > > > -----Original Message----- > Jari wrote: > > o I dislike the Sect 2.2 string syntax, as it is hard > to make this really work in a consistent manner across > vendors and organizations. A standardized bit pattern > approach would be better, IMHO. Then again, I'm not sure > whether we should really extend RADIUS with a feature > capabilities discovery. > > Avi's reply: > > A bit mask maybe a better approach. > > Capability advertizing is important in certain situations > such a prepaid. We need to be able to ensure that AAA server > can make policy decision based on the capabilities that are > supported by the NAS. In prepaid we need to know whether the > NAS can actually do that 'counting' and enforce the policy > that is required. If the NAS did not then the AAA can decide > on a different tack for providing service to a prepaid > client. For example it can ask the NAS to tunnel the client > to another device that can enforce the policy. > > We also need to know whether the NAS supports POD or COA > (3576) messages. Again this is improtant for prepaid etc.... > > Whether or not this is standardized or not it is important > for the prepaid feature and hence its also part of the prepaid 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: > -- 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: Wed, 17 Dec 2003 18:51:15 +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: QoS attributes Date: Wed, 17 Dec 2003 10:49:55 -0800 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEx+Te7aL0tYAqSN6WWaZWZzUDZgAAPlcQ From: "Bari, Farooq" To: "nagi reddy jonnala" , "Nelson, David" , Hi Nagi, I am not sure what does subtitles have to do with QoS but If I understood your example in 3) correctly, you want to see movie over the internet and have same experience as in DVD. If this is correct then you would be using something similar to RTSP in the control plane (RTSP provides VCR like functionality of start, stop, forward, rewind, Pause etc.). As part of the session setup, RTSP provides / negotiates codec information along with bandwidth using SDP protocol. RADIUS does not get involved in this process. I am trying to understand now, how you are thinking of using RADIUS in the whole process. Are you suggesting that after the session setup negotiations, the RTSP server (or the client ?) talks to the RADIUS server, the RADIUS server then talks to RADIUS client, the RADIUS client then talks to the policy enforcement point ?=20 Regards, Farooq -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of nagi reddy jonnala Sent: Wednesday, December 17, 2003 9:58 AM To: Nelson, David; radiusext@ops.ietf.org Subject: Re: QoS attributes David & All, 1) Yes, Attribute space is limited: I believe everybody thinks the attribute space is precious and I think the reasonable proposals are questioned based on this reason not because of their merits/de-merits. If the attribute space is not precious, then why is that the draft dealing with LAN and WLAN specific attributes are not standardized. I think the reason is VSA provide subtypes and this draft wants to introduce handful of attributes which we don't have space. Right? 2) QoS attributes: Even I don't believe in adding the all the QoS attributes under the sun. At the sametime, I see a possibility for the need to change the QoS attributes dynamically and it doesn't take much effort to standardize them if we have some way to group them in one attribute. 3) Why should we handle QoS attributes in Radius: It is a matter of choice and flexibility provided. For example, when I watch a French movie DVD, I would like to see English subtitles. I can switch on the subtitles using my remote and the english menu is provided by the DVD player (or) I can select an option in the movie menu provided by the particular movie DVD. I like this option because I don't understand French movie menu. It is upto the Vendors to choose if they support this way handling the QoS attributes or not. My argument is that why does the standard body put the restriction? Regards Nagi -- 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: Wed, 17 Dec 2003 18:44:18 +0000 Message-ID: From: Avi Lior To: "'marco.stura@nokia.com'" , Avi Lior Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 13:43:52 -0500 MIME-Version: 1.0 Content-Type: text/plain Yes. But you also need the same in Diameter (I think? Well DCC did right?) > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Wednesday, December 17, 2003 12:03 PM > To: avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > > You have to invent a new attribute or use Framed-IP-Route to > > do redirects. > > Are you talking about RADIUS attribute? > > > -----Original Message----- > > From: ext Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: 17 December, 2003 18:58 > > To: Stura Marco (NET/Helsinki); Avi Lior > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > > > > Scratch that. I was mistaken. IPFW does not support redirects. > > > > You have to invent a new attribute or use Framed-IP-Route to > > do redirects. > > > > > -----Original Message----- > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > > > Sent: Wednesday, December 17, 2003 2:20 AM > > > To: avi@bridgewatersystems.com > > > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > > > > > > > Avi Lior wrote > > > > > > > The Black I-D and PWLAN draft prompted me to check > something out. > > > > > > > > It seems to me that something is missing in Diameter. > Using the > > > > filter specification in 3588 its not clear how I force > a forward. > > > > The only actions > > > > supported are permit or deny whereas ipfw supports a forward > > > > mechanism as > > > > well. > > > > > > > > The motivation for this is the requirement in (WLAN for > > > > example) whereby I > > > > want to force all http traffic to a specific portal and > > > deny all other > > > > traffic until the portal instructs the NAS otherwise. This > > > > needs to be done > > > > either during an Access Accept or mid-session using COA. > > > > > > How to redirect user traffic (e.g. http) is implementation > > > specific and I think is not a Diameter business. If you want > > > to indicate redirect traffic to a specific address, in > > > Diameter applications you can define a grouped AVP to realize > > > the functionality. One example could be the > > > Final-Unit-Indication in the DCC application. > > > > > > Regards > > > Marco > > > > > > -- 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, 17 Dec 2003 18:16:26 +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: QoS attributes Date: Wed, 17 Dec 2003 13:15:32 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEx1vd847rCiGvSI+NSa6BpNIw4gAAB2mA From: "Nelson, David" To: Nagi writes... > If the attribute space is not precious, then why is that the draft dealing > with LAN and WLAN specific attributes are not standardized. I think the > reason is VSA provide subtypes and this draft wants to introduce handful > of attributes which we don't have space. Right? The attribute space is certainly finite. My perception is that RADIUS has a finite lifetime (remember we do have Diameter) and that the "good ideas" for standard attributes will run out before the attribute space runs out. The limited address space is a secondary, consideration, IMHO. Of course, future events may prove me wrong. So why are some proposals "good ideas" and some not? Well, items that have broad Internet Community consensus should be standardized. Items that are special "tweaks" that allow one vendor to differentiate itself from the competition (in non interoperable ways) are what the VSA attribute is for. In between those extremes, we have the gray areas, i.e. proposals that are of interest to a specific industry or market segment or are of interest to a specific vendor. It an attribute "passes muster" for broad Internet Community consensus and multi-vendor interoperability it deserves to be a stand-alone, standardized attribute. If it does not pass that muster, it should be a VSA. Trying to "have it both ways" and bury multiple attributes in one standard attribute, via sub-types, sub-fields, or whatever, is simply a disservice to the RADIUS community, IMHO. Allowing "bad ideas" to be standardized places an extra burden on the implementers of RADIUS Clients, Servers and Proxies, who will be pressured to support the new attributes. That's why the RADUIS IANA considerations talks about the requirement for IETF Standards Action. Let's come to consensus on the list of attributes that "pass muster", and then we can take a head-count to see if the attribute address space is in imminent risk of exhaustion. =20 -- Dave -- 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, 17 Dec 2003 17:59:54 +0000 Message-ID: <3FE09935.B97E2AFD@alcatel.be> Date: Wed, 17 Dec 2003 18:58:13 +0100 From: nagi reddy jonnala Organization: Alcatel Telecom MIME-Version: 1.0 To: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David & All, 1) Yes, Attribute space is limited: I believe everybody thinks the attribute space is precious and I think the reasonable proposals are questioned based on this reason not because of their merits/de-merits. If the attribute space is not precious, then why is that the draft dealing with LAN and WLAN specific attributes are not standardized. I think the reason is VSA provide subtypes and this draft wants to introduce handful of attributes which we don't have space. Right? 2) QoS attributes: Even I don't believe in adding the all the QoS attributes under the sun. At the sametime, I see a possibility for the need to change the QoS attributes dynamically and it doesn't take much effort to standardize them if we have some way to group them in one attribute. 3) Why should we handle QoS attributes in Radius: It is a matter of choice and flexibility provided. For example, when I watch a French movie DVD, I would like to see English subtitles. I can switch on the subtitles using my remote and the english menu is provided by the DVD player (or) I can select an option in the movie menu provided by the particular movie DVD. I like this option because I don't understand French movie menu. It is upto the Vendors to choose if they support this way handling the QoS attributes or not. My argument is that why does the standard body put the restriction? Regards Nagi -- 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, 17 Dec 2003 17:28: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: QoS attributes Date: Wed, 17 Dec 2003 09:27:55 -0800 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEu9SoVx6spR5aRYWBvXRnbFyU/wABClbw From: "Bari, Farooq" To: "Avi Lior" , "Bari, Farooq" , "Nelson, David" , Hi Avi, Most of the QoS sensitive services / applications have their own control plane and corresponding protocols e.g. SIP, RTSP etc are used for multimeida sessions and streaming. The QoS / bandwidth requirements etc. are exchanged through them as part of session setup / modification and in my opinion it is this control plane that should then be responsible for informing the QoS enforcement point of the need for a specific QoS / bandwidth for a specific service session. In many cases the enforcement point may not actually be informed about it directly and the services can for example do diffserv / bit coloring. The enforcement point will however have to ensure that the request from a particular user for QoS for certain service session does not fall outside the access network capability or the user's QoS profile provided by the home network. In the example that you gave, I would be quite surprised if operators have such tight admission control whereby they can guarantee certain minimum bandwidth for the last mile on a per user basis. I however think average bandwidth to certain user can be achieved if the user was classified for example as gold user who can if needed prioritize its traffic by bit coloring and therefore can have higher allowed average bandwidth. That I believe can be done by just downloading user QoS profile initially (that for example allows bit coloring from this user to be honored in the access network) and later allowing applications to use DSCP (no control protocol needed in this case). Therefore I still think RADIUS QoS / bandwidth attribute is somewhat static information to be used to define the overall bounds for a user - the QoS individual for services has to be within these bounds but RADIUS is not in the path of negotiating QoS for the services. Regards Farooq -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Wednesday, December 17, 2003 8:36 AM To: 'Bari, Farooq'; Avi Lior; 'Nelson, David'; 'radiusext@ops.ietf.org' Subject: RE: QoS attributes Hi Farooq, I will give you a real usecase in DSL/Cable systems that we are involved with. A user wants to download a movie from a content provider. The Operator offers a service whereby the user can extend his bandwidth for a period of time for a fee. This is called bandwidth on demand or BOD. This is done using two mechanisms: either by pressing a "turbo" button or by going to a website. In either case, the system validates that the subscriber is allowed to request for more bandwidth, if so it then checks to see what is available (not in scope for RADIUS but there are ways to do this), and grants the user the bandwidth by sending the network element a RADIUS CoA message (RFC 3576) instructing the device to open up the user's pipe. All of this is done mid-session. This was an example where the user has initiated the request. A similar scenario can happen when the Content Provider can request that the user's pipe be opened for a period of time. Finally, there are examples that we are exploring now where a new IP flow is requested mid session and the QoS has to be negotiated. RADIUS is involved because RADIUS know who the subscriber is and what the subscriber is allowed. Other elements are involved such as a Policy Decision Function (PDF) as well. Still trying to figure out the details for this one. But I hope that this gave you an insight that shows that these things need to be addressed mid session as well as at the start of the session. > -----Original Message----- > From: Bari, Farooq [mailto:farooq.bari@attws.com] > Sent: December 16, 2003 5:05 PM > To: Avi Lior; Nelson, David; radiusext@ops.ietf.org > Subject: RE: QoS attributes >=20 >=20 > Hi Avi, all >=20 > We need to have some consensus on what is the rationale/use > of QoS attributes for RADIUS/DIAMETER before moving forward=20 > on the topic. It seems that we have more than one perspective=20 > on it. I for example see it as static information during an=20 > authorized session i.e. QoS information gets exchanged only=20 > during session setup where AN informs AAA of its capabilities=20 > and AAA server tells the AN of user QoS susbcription. I do=20 > not think RADIUS/DIAMETER servers should be involved in=20 > provisioning QoS for individual services running in an=20 > already authorized session later on. However Avi's email=20 > suggests it is somewhat more dynamic than this. Avi, can you=20 > pls clarify if I understood your comments correctly..... >=20 > Farooq >=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Avi Lior >=20 > Sent: Tuesday, December 16, 2003 1:42 PM > To: 'Nelson, David'; radiusext@ops.ietf.org > Subject: RE: QoS attributes >=20 >=20 >=20 > David Nelso wrote: >=20 > > Provisioning detailed, and more importantly, potentially > dynamic, QoS > > parameters as authorization information in RADIUS or any other AAA > > protocol is probably not the right thing to do. What ought to be=20 > > provisioned is a "level of service" indication (e.g.=20 > bronze, silver, > > gold, platinum) that can be used by each NAS to modify the QoS > > parameter negotiation process for each session. >=20 > It requires that each Hot Spot for example understand what to > deliver to a Bronze User or a Gold user etc..... >=20 > Like filter id, this just does not scale! >=20 > We need a way to explicitly push attributes down to the NAS. > Equally important is to make sure that the NAS tell us what=20 > it can currently honour. This will alow the home RADIUS to=20 > make an appropriate policy decision. >=20 >=20 >=20 > -- > to unsubscribe send a message to > 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, 17 Dec 2003 17:01:10 +0000 Message-ID: From: Avi Lior To: 'Jari Arkko' , Avi Lior Cc: "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 12:00:48 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Jari, You could use Framed-Route but now all traffic would be routed to the Portal etc..... I think it would be more appropriate to introduce a new attribute so that: A) the NAS would deal with the routing functions (as it always does) and the Portal does not have to do it. B) We would have the flexibility to decide whether to route all traffic or just some traffic. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Tuesday, December 16, 2003 4:47 PM > To: Avi Lior > Cc: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Question regarding IP Filter Rule > > > Avi Lior wrote: > > The Black I-D and PWLAN draft prompted me to check something out. > > > > It seems to me that something is missing in Diameter. Using the > > filter specification in 3588 its not clear how I force a > forward. The > > only actions supported are permit or deny whereas ipfw supports a > > forward mechanism as well. > > > > The motivation for this is the requirement in (WLAN for example) > > whereby I want to force all http traffic to a specific > portal and deny > > all other traffic until the portal instructs the NAS > otherwise. This > > needs to be done either during an Access Accept or > mid-session using > > COA. > > Does it have to be http specific? You could set Framed-Route > and then do Re-Authz when the routing changes. But > Framed-Route is not specific to a protocol or port. > > --Jari > -- 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, 17 Dec 2003 16:58:28 +0000 Message-ID: From: Avi Lior To: "'marco.stura@nokia.com'" , Avi Lior Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 11:58:05 -0500 MIME-Version: 1.0 Content-Type: text/plain Scratch that. I was mistaken. IPFW does not support redirects. You have to invent a new attribute or use Framed-IP-Route to do redirects. > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Wednesday, December 17, 2003 2:20 AM > To: avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > Avi Lior wrote > > > The Black I-D and PWLAN draft prompted me to check something out. > > > > It seems to me that something is missing in Diameter. Using > > the filter > > specification in 3588 its not clear how I force a forward. > > The only actions > > supported are permit or deny whereas ipfw supports a forward > > mechanism as > > well. > > > > The motivation for this is the requirement in (WLAN for > > example) whereby I > > want to force all http traffic to a specific portal and > deny all other > > traffic until the portal instructs the NAS otherwise. This > > needs to be done > > either during an Access Accept or mid-session using COA. > > How to redirect user traffic (e.g. http) is implementation > specific and I think is not a Diameter business. If you want > to indicate redirect traffic to a specific address, in > Diameter applications you can define a grouped AVP to realize > the functionality. One example could be the > Final-Unit-Indication in the DCC application. > > Regards > Marco > -- 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, 17 Dec 2003 16:49:48 +0000 Message-ID: From: Avi Lior To: "'marco.stura@nokia.com'" , Avi Lior Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Wed, 17 Dec 2003 11:49:27 -0500 MIME-Version: 1.0 Content-Type: text/plain Thanx Marco, I am familiar with DCC. My point was/is that IPFilterRules would have been one way to do this and the IPFW appears to support this capability. Its too bad that IPFilterRules don't support this capability because now we have to build it into our applications. For RADIUS prepaid and PWLAN etc we will have to define a new AVP to do redirects. Alternatively, we could define an IPFilterRule attribute that has the forwarding capability that went missing in Diameter. But now we would have a compatibility issue with Diameter. > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Wednesday, December 17, 2003 2:20 AM > To: avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule > > > Avi Lior wrote > > > The Black I-D and PWLAN draft prompted me to check something out. > > > > It seems to me that something is missing in Diameter. Using > > the filter > > specification in 3588 its not clear how I force a forward. > > The only actions > > supported are permit or deny whereas ipfw supports a forward > > mechanism as > > well. > > > > The motivation for this is the requirement in (WLAN for > > example) whereby I > > want to force all http traffic to a specific portal and > deny all other > > traffic until the portal instructs the NAS otherwise. This > > needs to be done > > either during an Access Accept or mid-session using COA. > > How to redirect user traffic (e.g. http) is implementation > specific and I think is not a Diameter business. If you want > to indicate redirect traffic to a specific address, in > Diameter applications you can define a grouped AVP to realize > the functionality. One example could be the > Final-Unit-Indication in the DCC application. > > Regards > Marco > -- 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, 17 Dec 2003 16:36:05 +0000 Message-ID: From: Avi Lior To: "'Bari, Farooq'" , Avi Lior , "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: QoS attributes Date: Wed, 17 Dec 2003 11:35:44 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Farooq, I will give you a real usecase in DSL/Cable systems that we are involved with. A user wants to download a movie from a content provider. The Operator offers a service whereby the user can extend his bandwidth for a period of time for a fee. This is called bandwidth on demand or BOD. This is done using two mechanisms: either by pressing a "turbo" button or by going to a website. In either case, the system validates that the subscriber is allowed to request for more bandwidth, if so it then checks to see what is available (not in scope for RADIUS but there are ways to do this), and grants the user the bandwidth by sending the network element a RADIUS CoA message (RFC 3576) instructing the device to open up the user's pipe. All of this is done mid-session. This was an example where the user has initiated the request. A similar scenario can happen when the Content Provider can request that the user's pipe be opened for a period of time. Finally, there are examples that we are exploring now where a new IP flow is requested mid session and the QoS has to be negotiated. RADIUS is involved because RADIUS know who the subscriber is and what the subscriber is allowed. Other elements are involved such as a Policy Decision Function (PDF) as well. Still trying to figure out the details for this one. But I hope that this gave you an insight that shows that these things need to be addressed mid session as well as at the start of the session. > -----Original Message----- > From: Bari, Farooq [mailto:farooq.bari@attws.com] > Sent: December 16, 2003 5:05 PM > To: Avi Lior; Nelson, David; radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > Hi Avi, all > > We need to have some consensus on what is the rationale/use > of QoS attributes for RADIUS/DIAMETER before moving forward > on the topic. It seems that we have more than one perspective > on it. I for example see it as static information during an > authorized session i.e. QoS information gets exchanged only > during session setup where AN informs AAA of its capabilities > and AAA server tells the AN of user QoS susbcription. I do > not think RADIUS/DIAMETER servers should be involved in > provisioning QoS for individual services running in an > already authorized session later on. However Avi's email > suggests it is somewhat more dynamic than this. Avi, can you > pls clarify if I understood your comments correctly..... > > Farooq > > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Avi Lior > > Sent: Tuesday, December 16, 2003 1:42 PM > To: 'Nelson, David'; radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > > David Nelso wrote: > > > Provisioning detailed, and more importantly, potentially > dynamic, QoS > > parameters as authorization information in RADIUS or any other AAA > > protocol is probably not the right thing to do. What ought to be > > provisioned is a "level of service" indication (e.g. > bronze, silver, > > gold, platinum) that can be used by each NAS to modify the QoS > > parameter negotiation process for each session. > > It requires that each Hot Spot for example understand what to > deliver to a Bronze User or a Gold user etc..... > > Like filter id, this just does not scale! > > We need a way to explicitly push attributes down to the NAS. > Equally important is to make sure that the NAS tell us what > it can currently honour. This will alow the home RADIUS to > make an appropriate policy decision. > > > > -- > 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: Wed, 17 Dec 2003 16:32:22 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Wed, 17 Dec 2003 11:32:03 -0500 MIME-Version: 1.0 Content-Type: text/plain Well I disagree.... The example you use is perfect. Frequent flyers programs a mile is a mile is a mile. But when you claim your ticket although they all measure a mile to be the same distance, one airline offers an economy ticket for 30,000 miles to europe another offers 40,000 miles. It's the same for bandwidth. They will all measure the bandwidth the same, but a Gold user at one company will probably get more bandwidth then a gold user in another company. Although they belong to the same consortium they still compete and differentiate themselves whereever and whenever they can -- and as Martha would say, "this is a good thing". The IETF should support protocols that will enable businesses to compete and not prevent businesses from competing. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, December 17, 2003 11:00 AM > To: radiusext@ops.ietf.org > Subject: RE: QoS attributes > > > > Avi writes... > > > Do you actually believe that operators will come to a > common agreement > > about what is a Gold profile? > > I believe that operators that have a roaming agreement (i.e. > part of the same consortium) would do so. I liken this to > the "partnerships" that the airlines have forged. My > frequent flyer miles accumulate whenever I fly any of the > partners, and they honor each other frequent flyer status levels, etc. > > Competitors would not easily come to agreement, but then > competitors may not want to allow transparent roaming across > each others infrastructure, so that point seems somewhat moot. > > > Doesn't the very essence of competition require that they > would have a > > disagreement about what a Gold Profile is? > > Yes, but it's not the competitors I'm addressing (see above). > > -- Dave > > > > -- > 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: Wed, 17 Dec 2003 16:02:20 +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: QoS attributes Date: Wed, 17 Dec 2003 11:00:16 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEqPvLwHVkmWmzRHKquOQsCWrUWwADVDnw From: "Nelson, David" To: Avi writes... =20 > Do you actually believe that operators will come to a common agreement > about what is a Gold profile? I believe that operators that have a roaming agreement (i.e. part of the same consortium) would do so. I liken this to the "partnerships" that the airlines have forged. My frequent flyer miles accumulate whenever I fly any of the partners, and they honor each other frequent flyer status levels, etc. Competitors would not easily come to agreement, but then competitors may not want to allow transparent roaming across each others infrastructure, so that point seems somewhat moot. > Doesn't the very essence of competition require that they would have a > disagreement about what a Gold Profile is? Yes, but it's not the competitors I'm addressing (see above). -- Dave -- 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, 17 Dec 2003 01:21: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: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Date: Tue, 16 Dec 2003 17:20:38 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BB45@orsmsx410.jf.intel.com> Thread-Topic: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Thread-Index: AcPDtg/tykk4PSNrT4WaW1bZ42F9LgAf+VYw From: "Adrangi, Farid" To: Cc: Hi Jari, Thanks for the dialogue - please see my commens inline. BR, Farid > I guess part of my confusion comes from the fact that I don't=20 > know if IP Address Type Options =3D Public and Private in an=20 > Access-Accept means >=20 [FA] I think there is a misunderstanding here - "public and private"=20 will be used only in the AccessRequest message to indicate that an Access Network is capable of doing both options. And I think the text is very specific about this fact. [FA] > (1) The home server does not care > (2) The home server wants both types of addresses to be assigned. >=20 > Option 1 sounds logical to me. >=20 > >>3) I get a bit worried that lack of enforcement is going to cause=20 > >>problems. Is it a general approach for AAA attributes from the home=20 > >>server to be hints? > >=20 > > [FA] I would not consider this as a hint, rather a explicit=20 > request.=20 > > Because, this enforcement attribute is in response to the=20 > > advertisement in the access-request. Please note that the=20 > enforcement=20 > > attribute should not be sent if the advertisement attribute is not=20 > > present. [FA] >=20 > It does indeed help if you only send the enforcement=20 > attribute after seeing an advertisement in access-request.=20 > Then we at least know the NAS supports this function, and we=20 > know what address types are available. Also, you wrote earlier: >=20 [FA] That's the intent. [FA] > > The other is how the Access Network is going to enforce the=20 > specified=20 > > address type option (private or public address) when the=20 > client does=20 > > a DHCP request - which IMO, this is outside the scope of=20 > the document=20 > > and perhaps we should be more explicit about it. >=20 > So I guess what you mean is that you *will* enforce the=20 > address type. The only missing things are how the NAS will=20 > tell the DHCP server about this, and whether the client and=20 > the DHCP server need some protocol enhancements to get this=20 > done. And you consider these issues to be out of scope for=20 > this draft, which sounds reasonable. >=20 > Is my understanding correct? >=20 [FA] Yes, correct. [FA] > --Jari >=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: Tue, 16 Dec 2003 23:15: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: QoS attributes Date: Tue, 16 Dec 2003 18:14:19 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEKGaGiF7dO1ZDQmywVa4QgihjaQAAIGmA From: "Nelson, David" To: Madjid writes... =20 > Madjid>>Again, seeing the number of attribute proposals in this BoF > so far and your notion of "reasonable" to me indicates that people hold > dear to the address space. And just what do you think my notion of "reasonable" is, pray tell? :-) > Madjid>>Isn't levels of service, like bronze, silver... really depend > on what is on the service contract in a specific scenario? Is what is > bronze in one system, also bronze in another? Do all systems have > the same number of levels. I don't see how this helps the problem scale? I think it helps the problem scale because it reduces it to relatively simple "business domain" terminology. If we had to worry about exact levels of QoS, it's unlikely that we would ever come to agreement as to when requirements effectively matched capabilities. Sometimes too much granularity is a bad thing. The fact of the mater is that is that all the players in a roaming consortium will have contractual relationships. I assert this to be true, because there is virtually no other way that each player can be confident that they will receive their share of the revenue stream. Given that business agreements will exist, coming to a common agreement about the range of QoS parameters in each level of service category (Bronze, Silver, Gold, Platinum, Unattanium, etc.) should not be a very difficult problem to solve. Let's not make thinks more complicated than they absolutely need to be. -- Dave -- 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, 16 Dec 2003 22:11:48 +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: QoS attributes Date: Tue, 16 Dec 2003 17:10:51 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEHWO6PtNWYO0/Sq2k0cS+cloq9QAAp9MQ From: "Nelson, David" To: Avi writes... =20 > It requires that each Hot Spot for example understand what to deliver to a > Bronze User or a Gold user etc..... >=20 > Like filter id, this just does not scale! Given the variety of possible parameters and capabilities, based on the NAS, and its uplinks, getting too specific doesn't scale either. If the description is too loose, the customer may get "less" than they expect. Or conversely, the customer may get "more" that their home provider thinks the customer is entitled to. For example, if the "minimum" guaranteed bandwidth is 1.5 MB/s, and the NAS can only provide 1.0 MB/s at that time, should the session set-up fail? Would the customer rather have the 1.0 MB/s then and there, or would they rather be forced to seek an alternate roaming provider? The possible "negotiations" and "exceptions" could become daunting for any of the parties to handle in an effective and predictable fashion. > We need a way to explicitly push attributes down to the NAS. Equally > important is to make sure that the NAS tell us what it can currently > honour. Do we want the AAA protocol to also be the QoS parameter provisioning protocol? We went down that road with COPS-PR. Or do we simply want the AAA protocol to bind authorized users to general classes of QoS that are provisioned by some more appropriate protocol? -- Dave -- 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, 16 Dec 2003 22:05:20 +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: QoS attributes Date: Tue, 16 Dec 2003 14:04:43 -0800 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEHZRRY/uL6ocGTiWjG4UhvM7LYgAAEK8Q From: "Bari, Farooq" To: "Avi Lior" , "Nelson, David" , Hi Avi, all We need to have some consensus on what is the rationale/use of QoS attributes for RADIUS/DIAMETER before moving forward on the topic. It seems that we have more than one perspective on it. I for example see it as static information during an authorized session i.e. QoS information gets exchanged only during session setup where AN informs AAA of its capabilities and AAA server tells the AN of user QoS susbcription. I do not think RADIUS/DIAMETER servers should be involved in provisioning QoS for individual services running in an already authorized session later on. However Avi's email suggests it is somewhat more dynamic than this. Avi, can you pls clarify if I understood your comments correctly..... Farooq -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Tuesday, December 16, 2003 1:42 PM To: 'Nelson, David'; radiusext@ops.ietf.org Subject: RE: QoS attributes David Nelso wrote: > Provisioning detailed, and more importantly, potentially > dynamic, QoS parameters as authorization information in=20 > RADIUS or any other AAA protocol is probably not the right=20 > thing to do. What ought to be provisioned is a "level of=20 > service" indication (e.g. bronze, silver, gold, platinum)=20 > that can be used by each NAS to modify the QoS parameter=20 > negotiation process for each session.=20 It requires that each Hot Spot for example understand what to deliver to a Bronze User or a Gold user etc..... Like filter id, this just does not scale! We need a way to explicitly push attributes down to the NAS. Equally important is to make sure that the NAS tell us what it can currently honour. This will alow the home RADIUS to make an appropriate policy decision. -- 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, 16 Dec 2003 21:43:49 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP Date: Tue, 16 Dec 2003 16:43:21 -0500 MIME-Version: 1.0 Content-Type: text/plain Okay I knew that but I didn't make the context connection. Thanx. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, December 16, 2003 3:58 PM > Cc: radiusext@ops.ietf.org > Subject: RE: kickstart and SSPP > > > Avi writes... > > > Not sure what you mean by no flixibility in secret lookup? > > Shared secrets are looked-up on a hop-by-hop basis using the > Source IP Address of the incoming RADIUS packet as the look-up index. > > -- Dave > > > > -- > 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, 16 Dec 2003 21:41:58 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Tue, 16 Dec 2003 16:41:30 -0500 MIME-Version: 1.0 Content-Type: text/plain David Nelso wrote: > Provisioning detailed, and more importantly, potentially > dynamic, QoS parameters as authorization information in > RADIUS or any other AAA protocol is probably not the right > thing to do. What ought to be provisioned is a "level of > service" indication (e.g. bronze, silver, gold, platinum) > that can be used by each NAS to modify the QoS parameter > negotiation process for each session. It requires that each Hot Spot for example understand what to deliver to a Bronze User or a Gold user etc..... Like filter id, this just does not scale! We need a way to explicitly push attributes down to the NAS. Equally important is to make sure that the NAS tell us what it can currently honour. This will alow the home RADIUS to make an appropriate policy decision. -- 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, 16 Dec 2003 21:36:02 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Avi Lior Cc: "'radiusext@ops.ietf.org'" Subject: RE: QoS attributes Date: Tue, 16 Dec 2003 16:35:40 -0500 MIME-Version: 1.0 Content-Type: text/plain > I think that at least the first approach makes sense. You > Avi have looked into it more deeply, what do you think? > Can we find a reasonable QoS attribute set without spending > too much time? As you say, there are so many and that's why I stopped (for a bit anyway). Until I get a better lay of the land. I noticed the Pat had a Diameter Draft on QoS way back in 98 ( I think). The easy ones are the bandwidth parameters and once we can agree what "minimum" means and what "maximum" means we are pretty well off to the races for services today. The other ones that we would need are a way to associate a session with a QoS bundle either by assigning a QoS bundle id which then translates to a QoS parameters or specifically assigning a QoS bundle. This is akeen to the IP filter rules and IP filter rule ids. A QoS bundle would contain a bunch of QoS related attributes. The QoS bundle Id can also be used for billing. Because there are so many different attributes I was hoping that we come up with a mechanism that could then be extended. Not doing something about this will create a situation that I am starting to see where folks are just going to be creating VSAs and we will never have interoperability. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, December 16, 2003 4:09 PM > To: Avi Lior > Cc: 'radiusext@ops.ietf.org' > Subject: Re: QoS attributes > > > Avi Lior wrote: > > > In the current drafts folks are talking about QoS but are only > > specifying Bandwidth attributes. There are other QoS > attributes. The > > problem is that there are a lot of different QoS attributes and > > different flavours as well. The question is which attributes and > > flavours should be modelled. > > > > I think we need a RADIUS QoS Draft in general. I started > to write one > > and stopped to see what was going on in a couple of other > areas. (For > > example Diameter and as well, work in 3GPP2 where the interface > > between the PDSN and the AAA will be used to query and > transport QoS > > attributes). > > > > For example, one of the useful things about the CoA is that > now I can > > change the QoS attributes of a session mid stream. So it would be > > useful to define these attributes (and not just Bandwidth). > > > > Any comments would be greatly appreciated. > > I agree that there are other QoS attributes. In fact, there > are so many and so different that this may be a problem. > > Define just a limited set of bandwidth qos attributes and > be satisfied with limited capabilities this offers? Or > define link layer specific detailed qos attributes, and > deal with the lack of server-side understanding of new > link layers and the diversity of the parameters for different > links? Or try to come up with a general definition that suits > everyone, and probably take a long time to finish? ;-) > > I think that at least the first approach makes sense. You > Avi have looked into it more deeply, what do you think? > Can we find a reasonable QoS attribute set without spending > too much time? > > --Jari > -- 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, 16 Dec 2003 21:33: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: Comments on draft-black-radius-lanedge-00.txt Date: Tue, 16 Dec 2003 13:31:57 -0800 Message-ID: Thread-Topic: Comments on draft-black-radius-lanedge-00.txt Thread-Index: AcPDXtmihwqNzzmyRMGuoXsx9V1D3QAvMGRw From: "Bari, Farooq" To: , "BLACK,CHUCK (HP-Roseville,ex1)" Cc: I support Jari's idea of renaming the group RADEXT to AAAEXT - this I believe will reflect the true nature of the work and will also help allay any concerns. Farooq -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Jari Arkko Sent: Monday, December 15, 2003 2:55 PM To: BLACK,CHUCK (HP-Roseville,ex1) Cc: radiusext@ops.ietf.org Subject: Re: Comments on draft-black-radius-lanedge-00.txt BLACK,CHUCK (HP-Roseville,ex1) wrote: > From: Jari Arkko [mailto:jari.arkko@piuha.net] >=20 >=20 >> o In general I support this type of a specification that would >> define WLAN or LAN specific attributes for AAA. We need this. >=20 >=20 > Good, it seemed that there would be interest in this, and the=20 > intention was to generate discussion and arrive at some sort of=20 > consensus. Yes. Thanks for your response. >> o The attributes should be done in a general fashion, in one >> document, and be applicable for both RADIUS and Diameter. >> With translation, if necessary, described in the document. >=20 >=20 > Would you consider that this RADIUSEXT WG is the appropriate place for > this discussion then, since many of the folks involved with RADIUS are > also involved with Diameter? Yes -- though I would probably name RADEXT to AAAEXT and avoid unnecessary focus to RADIUS only. Not that the name defines what the group will do, but... >> o Section 2.3.7, attribute IP-Filter-Name: What is the difference >> between this attribute and the Filter-Id attribute from RFC 2865? >> Do we need another one? >=20 >=20 > There is no fundamental difference between the current typical usage=20 > of the Filter-Id attribute and the new IP-Filter-Name. However, this=20 > is also true, based on RFC 3580, of the VLAN attributes, which are=20 > using the Tunnel attributes to specify VLAN information (see section=20 > 3.9 of RFC 3580 for Filter-Id usage, and section 3.31 for Tunnel/VLAN=20 > usage). >=20 > The intent was to extract the common LAN edge attributes and place=20 > them together. At the risk, as you mention, of redundancy. I'm not=20 > sure argument should prevail, so some discussion on the matter will=20 > help to decide the issue. I think its fine to document all the attributes relevant for LANs together -- but you should then make a distinction of those attributes that you are now introducing in this document, and those that you just import from other documents. This would help those readers who know both documents, would help IANA, and would make it clear what document is normative wrt to a given attribute. >> Also, it would be better to hightlight the relationship of >> the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP. >> Note that this AVP has a code 400 which means it is not directly >> RADIUS compatible. But if the definitions are aligned otherwise >> then translation should at least be possible. >=20 >=20 > This may be true. The Diameter IPFilterRule was chosen because of its > immediate likeness to the layer 3 inclinations of the IP-Filter-Raw=20 > attribute. It seems like using the NAS-Filter-Rule AVP would be more=20 > inclusive; is that a desired direction? There may be other reasons=20 > for using NAS-Filter-Rule of which I am unaware. The definitions appear to have the same contents, given that you refer to Diameter data type. I think the semantics are also the same. Perhaps you should just state that this is like the NAS-Filter-Rule AVP -- and maybe name it NAS-Filter-Rule-Radius or something like that to make it obvious. --Jari -- 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, 16 Dec 2003 21:10:14 +0000 Message-ID: <3FDF7469.8050904@piuha.net> Date: Tue, 16 Dec 2003 23:08:57 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Avi Lior Cc: "'radiusext@ops.ietf.org'" Subject: Re: QoS attributes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > In the current drafts folks are talking about QoS but are only specifying > Bandwidth attributes. There are other QoS attributes. The problem is that > there are a lot of different QoS attributes and different flavours as well. > The question is which attributes and flavours should be modelled. > > I think we need a RADIUS QoS Draft in general. I started to write one and > stopped to see what was going on in a couple of other areas. (For example > Diameter and as well, work in 3GPP2 where the interface between the PDSN and > the AAA will be used to query and transport QoS attributes). > > For example, one of the useful things about the CoA is that now I can change > the QoS attributes of a session mid stream. So it would be useful to define > these attributes (and not just Bandwidth). > > Any comments would be greatly appreciated. I agree that there are other QoS attributes. In fact, there are so many and so different that this may be a problem. Define just a limited set of bandwidth qos attributes and be satisfied with limited capabilities this offers? Or define link layer specific detailed qos attributes, and deal with the lack of server-side understanding of new link layers and the diversity of the parameters for different links? Or try to come up with a general definition that suits everyone, and probably take a long time to finish? ;-) I think that at least the first approach makes sense. You Avi have looked into it more deeply, what do you think? Can we find a reasonable QoS attribute set without spending too much time? --Jari -- 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, 16 Dec 2003 21:00:13 +0000 Message-ID: From: Avi Lior To: 'Nakhjiri Madjid-MNAKHJI1' , Avi Lior , radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Tue, 16 Dec 2003 15:59:42 -0500 MIME-Version: 1.0 Content-Type: text/plain Thanx for the comments. See my replies in line: > > Not having much prior RADIUS experience and having looked at > the activities in this group, I have been wondering why > RADIUS needs to define every single parameter as an > attributes. Given that there are so many customers for > RADIUS: we have seen SIPPING, WLAN community, QoS and so > forth. Shouldn't there be a method to bundle paramters > regarding each application, given the fact that attribute > space is so limited?? The concept of applications has been addressed in Diameter. The concept of grouping related has been address in Diameter as well. However, if you look at some of the emails you will see some discussion on subtypes that I have been pushing for. > But that aside, to comment on the QoS issue, isn't the issue > that how the RADIUS server configure the NAS (which is > typically the same as the device at the edge of the network) > to know how to handle user's traffic? If so then it depends > on what kind of edge device the NAS is. Also each user may > have various kinds of sessions, for each it may get > different QoS treatment, so the QoS will be tied to SIP or other call > control protocols. > If it is a Diffserv router(filter), it needs to have DSCP for > each flow the user is using (not just one per user). If it is > a L2 device, it may need to have a whole bunch of access > technology specific paramters, such as > slots, etc. Yes I agree that this is a difficult issue and there may not be away for doing this other than to address specific requirements. > So again the question is, whether there needs to be one > attribute for every QoS parameter under the sun, or is there > a way to do grouping? > > my 2/100s > > Madjid > > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior > Sent: Tuesday, December 16, 2003 11:29 AM > To: radiusext@ops.ietf.org > Subject: QoS attributes > > > I noticed that we are talking about QoS on the list. > > In the current drafts folks are talking about QoS but are > only specifying Bandwidth attributes. There are other QoS > attributes. The problem is that there are a lot of different > QoS attributes and different flavours as well. The question > is which attributes and flavours should be modelled. > > I think we need a RADIUS QoS Draft in general. I started to > write one and stopped to see what was going on in a couple of > other areas. (For example Diameter and as well, work in 3GPP2 > where the interface between the PDSN and the AAA will be used > to query and transport QoS attributes). > > For example, one of the useful things about the CoA is that > now I can change the QoS attributes of a session mid stream. > So it would be useful to define these attributes (and not > just Bandwidth). > > Any comments would be greatly appreciated. > > > > > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Tuesday, December 16, 2003 11:45 AM > > To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid > > Subject: RE: Comments on > > draft-adrangi-radius-extension-for-pwlan-00.txt > > > > > > > > > > > -----Original Message----- > > Jari wrote: > > > > o I dislike the Sect 2.2 string syntax, as it is hard > > to make this really work in a consistent manner across > > vendors and organizations. A standardized bit pattern > > approach would be better, IMHO. Then again, I'm not sure > > whether we should really extend RADIUS with a feature > > capabilities discovery. > > > > Avi's reply: > > > > A bit mask maybe a better approach. > > > > Capability advertizing is important in certain situations > > such a prepaid. We need to be able to ensure that AAA server > > can make policy decision based on the capabilities that are > > supported by the NAS. In prepaid we need to know whether the > > NAS can actually do that 'counting' and enforce the policy > > that is required. If the NAS did not then the AAA can decide > > on a different tack for providing service to a prepaid > > client. For example it can ask the NAS to tunnel the client > > to another device that can enforce the policy. > > > > We also need to know whether the NAS supports POD or COA > > (3576) messages. Again this is improtant for prepaid etc.... > > > > Whether or not this is standardized or not it is important > > for the prepaid feature and hence its also part of the > prepaid 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: > > > > -- > 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, 16 Dec 2003 20:59:01 +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: kickstart and SSPP Date: Tue, 16 Dec 2003 15:58:09 -0500 Message-ID: Thread-Topic: kickstart and SSPP Thread-Index: AcPEFu+Ey/CBuL0GSoO63zJ4HoSKcAAACCLA From: "Nelson, David" Cc: Avi writes... > Not sure what you mean by no flixibility in secret lookup? Shared secrets are looked-up on a hop-by-hop basis using the Source IP Address of the incoming RADIUS packet as the look-up index. -- Dave -- 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, 16 Dec 2003 20:56:40 +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: QoS attributes Date: Tue, 16 Dec 2003 15:55:42 -0500 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPEE6sFAp1K91DjSY++q2ou9s5A0QAAiq9g From: "Nelson, David" To: Nakhjiri writes... =20 > Shouldn't there be > a method to bundle paramters regarding each application, given the fact > that attribute space is so limited?? I don't think it has been demonstrated that the current attribute address space will be exhausted by the set of current [reasonable] proposals. Given that, I see no great pressure for sub-types, sub-encodings or other methods to "bundle" multiple parameters in a single attribute. > So again the question is, whether there needs to be one attribute > for every QoS parameter under the sun, or is there a way to do grouping? Provisioning detailed, and more importantly, potentially dynamic, QoS parameters as authorization information in RADIUS or any other AAA protocol is probably not the right thing to do. What ought to be provisioned is a "level of service" indication (e.g. bronze, silver, gold, platinum) that can be used by each NAS to modify the QoS parameter negotiation process for each session.=20 -- Dave -- 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, 16 Dec 2003 20:55:46 +0000 Message-ID: From: Avi Lior To: 'Nakhjiri Madjid-MNAKHJI1' , Avi Lior , "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP Date: Tue, 16 Dec 2003 15:55:19 -0500 MIME-Version: 1.0 Content-Type: text/plain Not sure what you mean by no flixibility in secret lookup? > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, December 16, 2003 3:32 PM > To: 'Avi Lior'; Nakhjiri Madjid-MNAKHJI1; 'Nelson, David' > Cc: radiusext@ops.ietf.org > Subject: RE: kickstart and SSPP > > > Thanks for the comments. > > Ok, so it seems that there is some flexibility as far as > methods of representing NAS (its ID). but no flexibility in > secret lookup (has to be done based on IP address and nothing else). > > Madjid > > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, December 16, 2003 11:18 AM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Nelson, David' > Cc: radiusext@ops.ietf.org > Subject: RE: kickstart and SSPP > > > The home radius server may store the NAS ID and/or the NAS IP > as well as other information. > > Remember that RADIUS is stateless so what is stored by RADIUS > is highly dependant on the deployment or the use of the AAA. > > For example, if the home network wanted to issue a Disconnect > Message or a Change of Authorization message (see RFC 3576) > then it would need the NAS identity and user session > identities inorder to issue these messages. > > Hope this helps. > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Friday, December 12, 2003 5:07 PM > > To: 'Nelson, David'; Nakhjiri Madjid-MNAKHJI1 > > Cc: radiusext@ops.ietf.org > > Subject: RE: kickstart and SSPP > > > > > > Hi Dave, > > > > Thank you for your answers. > > > > What types of ID does the NAS use (beside IP address) in the > > NAS ID field? Would the RADIUS server then later store this > > ID or the NAS IP address in its database? Also I am wondering > > if the RADIUS server keeps any entry about the user's IP address? > > > > Thanks in advance, > > > > Madjid > > P.S. It seems that the SSPP and kick start drafts have found > > a new home in Enroll WG. > > > > > > The NAS has a transitive trust relationship with the home > > server, via the proxy server chain, but no direct trust > > relationship. Each proxy server will generally validate the > > NAS identity before forwarding a request. If you have a > > "rogue" proxy in the chain, security problems will obviously exist. > > > > > > The NAS ID is the of originating client, not the proxy. > > > > > > Madjid>>So are you saying the packet carries both an IP > address (for > > the > > > proxy or NAS) and a NAS ID for originating NAS? > > > > Yes. The packet's source IP address is in the IP header and > > the NAS ID (or NAS IP Address) is in the packet payload. It > > is the Source IP address from the IP header that is used to > > look up the shared secret. > > > > > > -- > > 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, 16 Dec 2003 20:32:24 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Avi Lior'" , Nakhjiri Madjid-MNAKHJI1 , "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP Date: Tue, 16 Dec 2003 14:31:46 -0600 MIME-Version: 1.0 Content-Type: text/plain Thanks for the comments. Ok, so it seems that there is some flexibility as far as methods of representing NAS (its ID). but no flexibility in secret lookup (has to be done based on IP address and nothing else). Madjid -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Tuesday, December 16, 2003 11:18 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Nelson, David' Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP The home radius server may store the NAS ID and/or the NAS IP as well as other information. Remember that RADIUS is stateless so what is stored by RADIUS is highly dependant on the deployment or the use of the AAA. For example, if the home network wanted to issue a Disconnect Message or a Change of Authorization message (see RFC 3576) then it would need the NAS identity and user session identities inorder to issue these messages. Hope this helps. > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, December 12, 2003 5:07 PM > To: 'Nelson, David'; Nakhjiri Madjid-MNAKHJI1 > Cc: radiusext@ops.ietf.org > Subject: RE: kickstart and SSPP > > > Hi Dave, > > Thank you for your answers. > > What types of ID does the NAS use (beside IP address) in the > NAS ID field? Would the RADIUS server then later store this > ID or the NAS IP address in its database? Also I am wondering > if the RADIUS server keeps any entry about the user's IP address? > > Thanks in advance, > > Madjid > P.S. It seems that the SSPP and kick start drafts have found > a new home in Enroll WG. > > > The NAS has a transitive trust relationship with the home > server, via the proxy server chain, but no direct trust > relationship. Each proxy server will generally validate the > NAS identity before forwarding a request. If you have a > "rogue" proxy in the chain, security problems will obviously exist. > > > > The NAS ID is the of originating client, not the proxy. > > > > Madjid>>So are you saying the packet carries both an IP address (for > the > > proxy or NAS) and a NAS ID for originating NAS? > > Yes. The packet's source IP address is in the IP header and > the NAS ID (or NAS IP Address) is in the packet payload. It > is the Source IP address from the IP header that is used to > look up the shared secret. > > > -- > 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, 16 Dec 2003 20:29:41 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Avi Lior'" , radiusext@ops.ietf.org Subject: RE: QoS attributes Date: Tue, 16 Dec 2003 14:28:44 -0600 MIME-Version: 1.0 Content-Type: text/plain Not having much prior RADIUS experience and having looked at the activities in this group, I have been wondering why RADIUS needs to define every single parameter as an attributes. Given that there are so many customers for RADIUS: we have seen SIPPING, WLAN community, QoS and so forth. Shouldn't there be a method to bundle paramters regarding each application, given the fact that attribute space is so limited?? But that aside, to comment on the QoS issue, isn't the issue that how the RADIUS server configure the NAS (which is typically the same as the device at the edge of the network) to know how to handle user's traffic? If so then it depends on what kind of edge device the NAS is. Also each user may have various kinds of sessions, for each it may get different QoS treatment, so the QoS will be tied to SIP or other call control protocols. If it is a Diffserv router(filter), it needs to have DSCP for each flow the user is using (not just one per user). If it is a L2 device, it may need to have a whole bunch of access technology specific paramters, such as slots, etc. So again the question is, whether there needs to be one attribute for every QoS parameter under the sun, or is there a way to do grouping? my 2/100s Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Avi Lior Sent: Tuesday, December 16, 2003 11:29 AM To: radiusext@ops.ietf.org Subject: QoS attributes I noticed that we are talking about QoS on the list. In the current drafts folks are talking about QoS but are only specifying Bandwidth attributes. There are other QoS attributes. The problem is that there are a lot of different QoS attributes and different flavours as well. The question is which attributes and flavours should be modelled. I think we need a RADIUS QoS Draft in general. I started to write one and stopped to see what was going on in a couple of other areas. (For example Diameter and as well, work in 3GPP2 where the interface between the PDSN and the AAA will be used to query and transport QoS attributes). For example, one of the useful things about the CoA is that now I can change the QoS attributes of a session mid stream. So it would be useful to define these attributes (and not just Bandwidth). Any comments would be greatly appreciated. > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, December 16, 2003 11:45 AM > To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid > Subject: RE: Comments on > draft-adrangi-radius-extension-for-pwlan-00.txt > > > > > > -----Original Message----- > Jari wrote: > > o I dislike the Sect 2.2 string syntax, as it is hard > to make this really work in a consistent manner across > vendors and organizations. A standardized bit pattern > approach would be better, IMHO. Then again, I'm not sure > whether we should really extend RADIUS with a feature > capabilities discovery. > > Avi's reply: > > A bit mask maybe a better approach. > > Capability advertizing is important in certain situations > such a prepaid. We need to be able to ensure that AAA server > can make policy decision based on the capabilities that are > supported by the NAS. In prepaid we need to know whether the > NAS can actually do that 'counting' and enforce the policy > that is required. If the NAS did not then the AAA can decide > on a different tack for providing service to a prepaid > client. For example it can ask the NAS to tunnel the client > to another device that can enforce the policy. > > We also need to know whether the NAS supports POD or COA > (3576) messages. Again this is improtant for prepaid etc.... > > Whether or not this is standardized or not it is important > for the prepaid feature and hence its also part of the prepaid 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: > -- 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, 16 Dec 2003 20:11:02 +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: QoS attributes Date: Tue, 16 Dec 2003 12:10:33 -0800 Message-ID: Thread-Topic: QoS attributes Thread-Index: AcPD+nhlw0qQ+a7HS82CGN379180xwAFSbsA From: "Bari, Farooq" To: "Avi Lior" , Hi Avi, My opinion on this issue is that RADIUS or DIAMETER attributes on QoS should reflect a more static type of QoS information that does not change during an authorized session like * the access network capabilities (e.g. does it support 11e or admission control or if it can provide any, min/max bandwidth guarantees for session, jitter, latency, delay, packet drop guarantees etc.)=20 * user subscribed to QoS e.g. is the user bronze, silver, gold customer and based on that what QoS should the user be provided. The dynamic QoS for a particular service that the user decides to use during an authorized session I believe is not something the RADIUS should be used for. There are better mechanisms e.g. based on SDP information in SIP or RTSP based services that should be utilized for that purpose.=20 BR, Farooq =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Tuesday, December 16, 2003 9:29 AM To: 'radiusext@ops.ietf.org' Subject: QoS attributes I noticed that we are talking about QoS on the list. In the current drafts folks are talking about QoS but are only specifying Bandwidth attributes. There are other QoS attributes. The problem is that there are a lot of different QoS attributes and different flavours as well. The question is which attributes and flavours should be modelled. I think we need a RADIUS QoS Draft in general. I started to write one and stopped to see what was going on in a couple of other areas. (For example Diameter and as well, work in 3GPP2 where the interface between the PDSN and the AAA will be used to query and transport QoS attributes). For example, one of the useful things about the CoA is that now I can change the QoS attributes of a session mid stream. So it would be useful to define these attributes (and not just Bandwidth). Any comments would be greatly appreciated. > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, December 16, 2003 11:45 AM > To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid > Subject: RE: Comments on=20 > draft-adrangi-radius-extension-for-pwlan-00.txt >=20 >=20 >=20 >=20 > > -----Original Message----- > Jari wrote: >=20 > o I dislike the Sect 2.2 string syntax, as it is hard > to make this really work in a consistent manner across > vendors and organizations. A standardized bit pattern > approach would be better, IMHO. Then again, I'm not sure > whether we should really extend RADIUS with a feature > capabilities discovery. >=20 > Avi's reply: >=20 > A bit mask maybe a better approach. >=20 > Capability advertizing is important in certain situations > such a prepaid. We need to be able to ensure that AAA server=20 > can make policy decision based on the capabilities that are=20 > supported by the NAS. In prepaid we need to know whether the=20 > NAS can actually do that 'counting' and enforce the policy=20 > that is required. If the NAS did not then the AAA can decide=20 > on a different tack for providing service to a prepaid=20 > client. For example it can ask the NAS to tunnel the client=20 > to another device that can enforce the policy. >=20 > We also need to know whether the NAS supports POD or COA > (3576) messages. Again this is improtant for prepaid etc.... >=20 > Whether or not this is standardized or not it is important > for the prepaid feature and hence its also part of the prepaid draft. >=20 > -- > to unsubscribe send a message to > 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: -- 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, 16 Dec 2003 20:03:51 +0000 Message-ID: From: Avi Lior To: 'Christopher Richards' , Avi Lior , "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Date: Tue, 16 Dec 2003 15:03:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C40F.AC0AD350" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3C40F.AC0AD350 Content-Type: text/plain Chris, Okay so forgive me but how do I specify where to redirect user traffic in diameter. Which attributes do that. Note I am not talking about where to redirect AAA traffic. Avi -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: Tuesday, December 16, 2003 2:32 PM To: 'Avi Lior'; 'radiusext@ops.ietf.org'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question regarding IP Filter Rule Hi Avi, The Diameter RFC (And applications) specify where to redirect user traffic - not how. The "how" is implementation specific. Best Regards, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com ] Sent: Tuesday, December 16, 2003 1:23 PM To: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu Subject: [AAA-WG]: Question regarding IP Filter Rule The Black I-D and PWLAN draft prompted me to check something out. It seems to me that something is missing in Diameter. Using the filter specification in 3588 its not clear how I force a forward. The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well. The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise. This needs to be done either during an Access Accept or mid-session using COA. ------_=_NextPart_001_01C3C40F.AC0AD350 Content-Type: text/html Message
Chris,
 
Okay so forgive me but how do I specify where to redirect user traffic in diameter.  Which attributes do that.  Note I am not talking about where to redirect AAA traffic.
 
Avi
-----Original Message-----
From: Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: Tuesday, December 16, 2003 2:32 PM
To: 'Avi Lior'; 'radiusext@ops.ietf.org'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule

Hi Avi,

The Diameter RFC (And applications) specify where to redirect user traffic - not how. The "how" is implementation specific.

Best Regards,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281


-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, December 16, 2003 1:23 PM
To: 'radiusext@ops.ietf.org'; aaa-wg@merit.edu
Subject: [AAA-WG]: Question regarding IP Filter Rule


The Black I-D and PWLAN draft prompted me to check something out.

It seems to me that something is missing in Diameter.  Using the filter specification in 3588 its not clear how I force a forward.  The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well.

The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise.  This needs to be done either during an Access Accept or mid-session using COA.

------_=_NextPart_001_01C3C40F.AC0AD350-- -- 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, 16 Dec 2003 19:23:52 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" , aaa-wg@merit.edu Subject: Question regarding IP Filter Rule Date: Tue, 16 Dec 2003 14:22:54 -0500 MIME-Version: 1.0 Content-Type: text/plain The Black I-D and PWLAN draft prompted me to check something out. It seems to me that something is missing in Diameter. Using the filter specification in 3588 its not clear how I force a forward. The only actions supported are permit or deny whereas ipfw supports a forward mechanism as well. The motivation for this is the requirement in (WLAN for example) whereby I want to force all http traffic to a specific portal and deny all other traffic until the portal instructs the NAS otherwise. This needs to be done either during an Access Accept or mid-session using COA. -- 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, 16 Dec 2003 17:28:52 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Subject: QoS attributes Date: Tue, 16 Dec 2003 12:28:31 -0500 MIME-Version: 1.0 Content-Type: text/plain I noticed that we are talking about QoS on the list. In the current drafts folks are talking about QoS but are only specifying Bandwidth attributes. There are other QoS attributes. The problem is that there are a lot of different QoS attributes and different flavours as well. The question is which attributes and flavours should be modelled. I think we need a RADIUS QoS Draft in general. I started to write one and stopped to see what was going on in a couple of other areas. (For example Diameter and as well, work in 3GPP2 where the interface between the PDSN and the AAA will be used to query and transport QoS attributes). For example, one of the useful things about the CoA is that now I can change the QoS attributes of a session mid stream. So it would be useful to define these attributes (and not just Bandwidth). Any comments would be greatly appreciated. > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Tuesday, December 16, 2003 11:45 AM > To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid > Subject: RE: Comments on > draft-adrangi-radius-extension-for-pwlan-00.txt > > > > > > -----Original Message----- > Jari wrote: > > o I dislike the Sect 2.2 string syntax, as it is hard > to make this really work in a consistent manner across > vendors and organizations. A standardized bit pattern > approach would be better, IMHO. Then again, I'm not sure > whether we should really extend RADIUS with a feature > capabilities discovery. > > Avi's reply: > > A bit mask maybe a better approach. > > Capability advertizing is important in certain situations > such a prepaid. We need to be able to ensure that AAA server > can make policy decision based on the capabilities that are > supported by the NAS. In prepaid we need to know whether the > NAS can actually do that 'counting' and enforce the policy > that is required. If the NAS did not then the AAA can decide > on a different tack for providing service to a prepaid > client. For example it can ask the NAS to tunnel the client > to another device that can enforce the policy. > > We also need to know whether the NAS supports POD or COA > (3576) messages. Again this is improtant for prepaid etc.... > > Whether or not this is standardized or not it is important > for the prepaid feature and hence its also part of the prepaid 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: > -- 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, 16 Dec 2003 17:18:18 +0000 Message-ID: From: Avi Lior To: 'Nakhjiri Madjid-MNAKHJI1' , "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP Date: Tue, 16 Dec 2003 12:17:43 -0500 MIME-Version: 1.0 Content-Type: text/plain The home radius server may store the NAS ID and/or the NAS IP as well as other information. Remember that RADIUS is stateless so what is stored by RADIUS is highly dependant on the deployment or the use of the AAA. For example, if the home network wanted to issue a Disconnect Message or a Change of Authorization message (see RFC 3576) then it would need the NAS identity and user session identities inorder to issue these messages. Hope this helps. > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, December 12, 2003 5:07 PM > To: 'Nelson, David'; Nakhjiri Madjid-MNAKHJI1 > Cc: radiusext@ops.ietf.org > Subject: RE: kickstart and SSPP > > > Hi Dave, > > Thank you for your answers. > > What types of ID does the NAS use (beside IP address) in the > NAS ID field? Would the RADIUS server then later store this > ID or the NAS IP address in its database? Also I am wondering > if the RADIUS server keeps any entry about the user's IP address? > > Thanks in advance, > > Madjid > P.S. It seems that the SSPP and kick start drafts have found > a new home in Enroll WG. > > > The NAS has a transitive trust relationship with the home > server, via the proxy server chain, but no direct trust > relationship. Each proxy server will generally validate the > NAS identity before forwarding a request. If you have a > "rogue" proxy in the chain, security problems will obviously exist. > > > > The NAS ID is the of originating client, not the proxy. > > > > Madjid>>So are you saying the packet carries both an IP address (for > the > > proxy or NAS) and a NAS ID for originating NAS? > > Yes. The packet's source IP address is in the IP header and > the NAS ID (or NAS IP Address) is in the packet payload. It > is the Source IP address from the IP header that is used to > look up the shared secret. > > > -- > 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, 16 Dec 2003 16:45:23 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , "'radiusext@ops.ietf.org'" , "Adrangi, Farid" Subject: RE: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Date: Tue, 16 Dec 2003 11:45:04 -0500 MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- Jari wrote: o I dislike the Sect 2.2 string syntax, as it is hard to make this really work in a consistent manner across vendors and organizations. A standardized bit pattern approach would be better, IMHO. Then again, I'm not sure whether we should really extend RADIUS with a feature capabilities discovery. Avi's reply: A bit mask maybe a better approach. Capability advertizing is important in certain situations such a prepaid. We need to be able to ensure that AAA server can make policy decision based on the capabilities that are supported by the NAS. In prepaid we need to know whether the NAS can actually do that 'counting' and enforce the policy that is required. If the NAS did not then the AAA can decide on a different tack for providing service to a prepaid client. For example it can ask the NAS to tunnel the client to another device that can enforce the policy. We also need to know whether the NAS supports POD or COA (3576) messages. Again this is improtant for prepaid etc.... Whether or not this is standardized or not it is important for the prepaid feature and hence its also part of the prepaid 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, 16 Dec 2003 16:37:46 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , "'radiusext@ops.ietf.org'" , "Adrangi, Farid" Subject: RE: Comments on draft-adrangi-radius-issues-in-pwlan-roaming-00.t xt Date: Tue, 16 Dec 2003 11:37:10 -0500 MIME-Version: 1.0 Content-Type: text/plain See my comments inline. > From: Jari Arkko [mailto:jari.arkko@piuha.net] > > o The lack of Identity for Accounting Purposes (sect. 3.1): I agree > that this is an issue where things like EAP-AKA which > has identity > protection or PEAP which hides the identity are used. Perhaps > draft-ietf-aaa-eap should discuss this. But since the issue is > in fact common to both Diameter and RADIUS, we could > also describe > it separately. "Accounting Considerations for Identity > Privicy" I-D? This is not strictly an accounting problem either. An alias for the user needs to be included in both Access and Accounting type messages. If it were an accounting problem only then the Class attribute would probably suffice in this case. Intermediaries need to be able to have an alias for subscriber as well (which nulls out the use of the Class attribute). Username re-writing capability could work here. -- 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, 16 Dec 2003 09:22:15 +0000 Message-ID: <3FDECE84.2070302@piuha.net> Date: Tue, 16 Dec 2003 11:21:08 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: Re: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Adrangi, Farid wrote: >>1) Presumably, lack of indication about the address type from the >>home network would be taken as either type being acceptable? If >>yes, public+private option may not be necessary. >> > > [FA] The lack of indication about the address type from the home > network would most likely be taken as private address assignment > (i.e., the default option). I think it would be taken as the default option (but I'm not sure that would be private address assignment in all cases). >>2) If you were to *enforce* the selection from the home network, >>then public+private option would not work. >> > > > [FA] Why wouldn't work? Sorry, I think I am missing your point > here. The home network specifies the preferred address type only > if it sees the Advertisement in the access-request indicating that > the access network can either assign public or private address to > a given WLAN client that is trying to connect. [FA] I guess part of my confusion comes from the fact that I don't know if IP Address Type Options = Public and Private in an Access-Accept means (1) The home server does not care (2) The home server wants both types of addresses to be assigned. Option 1 sounds logical to me. >>3) I get a bit worried that lack of enforcement is going to >>cause problems. Is it a general approach for AAA attributes >>from the home server to be hints? > > [FA] I would not consider this as a hint, rather a explicit request. > Because, this enforcement attribute is in response to the advertisement > in the access-request. Please note that the enforcement attribute should > not be sent if the advertisement attribute is not present. [FA] It does indeed help if you only send the enforcement attribute after seeing an advertisement in access-request. Then we at least know the NAS supports this function, and we know what address types are available. Also, you wrote earlier: > The other is how the Access Network is going to enforce the > specified address type option (private or public address) when the > client does a DHCP request - which IMO, this is outside the scope > of the document and perhaps we should be more explicit about it. So I guess what you mean is that you *will* enforce the address type. The only missing things are how the NAS will tell the DHCP server about this, and whether the client and the DHCP server need some protocol enhancements to get this done. And you consider these issues to be out of scope for this draft, which sounds reasonable. Is my understanding correct? --Jari -- 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, 16 Dec 2003 08:52: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: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Date: Tue, 16 Dec 2003 00:52:03 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC242@orsmsx410.jf.intel.com> Thread-Topic: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Thread-Index: AcPDXWm5ysCxr7I7Smq697wnwOE9twAT/gjQ From: "Adrangi, Farid" To: Cc: Hi Jari, Thanks. Please see my replies in line. BR, Farid > > [FA] There are two aspects to this feature. One is to enable Access > > Network > > to advertise its capability about private or public address=20 > assignment > > for a > > given WLAN client, and to enable the home RADIUS server to=20 > specify the > > desired > > address type option. The other is how the Access Network=20 > is going to > > enforce > > the specified address type option (private or public=20 > address) when the > > client=20 > > does a DHCP request - which IMO, this is outside the scope of the > > document and=20 > > perhaps we should be more explicit about it. Which aspect of the > > feature do=20 > > you have problem with? [FA] >=20 > 1) Presumably, lack of indication about the address type from the > home network would be taken as either type being acceptable? If > yes, public+private option may not be necessary. >=20 [FA] The lack of indication about the address type from the home=20 network would most likely be taken as private address assignment (i.e., the default option). =20 > 2) If you were to *enforce* the selection from the home network, > then public+private option would not work. >=20 [FA] Why wouldn't work? Sorry, I think I am missing your point=20 here. The home network specifies the preferred address type only=20 if it sees the Advertisement in the access-request indicating that the access network can either assign public or private address to a given WLAN client that is trying to connect. [FA] > 3) I get a bit worried that lack of enforcement is going to > cause problems. Is it a general approach for AAA attributes > from the home server to be hints? [FA] I would not consider this as a hint, rather a explicit request. Because, this enforcement attribute is in response to the advertisement in the access-request. Please note that the enforcement attribute should not be sent if the advertisement attribute is not present. [FA] > Is someone's billing going > to be based on a public or private address being provided? [FA] Most likely, Yes. [FA] > Or is this simply a result of backwards compatibility i.e. > we do not wish to disable access from NASes that do not > yet support these new attributes? >=20 >=20 > --Jari >=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: Mon, 15 Dec 2003 22:55:41 +0000 Message-ID: <3FDE3BA8.3090702@piuha.net> Date: Tue, 16 Dec 2003 00:54:32 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "BLACK,CHUCK (HP-Roseville,ex1)" Cc: radiusext@ops.ietf.org Subject: Re: Comments on draft-black-radius-lanedge-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit BLACK,CHUCK (HP-Roseville,ex1) wrote: > From: Jari Arkko [mailto:jari.arkko@piuha.net] > > >> o In general I support this type of a specification that would >> define WLAN or LAN specific attributes for AAA. We need this. > > > Good, it seemed that there would be interest in this, and the intention > was to generate discussion and arrive at some sort of consensus. Yes. Thanks for your response. >> o The attributes should be done in a general fashion, in one >> document, and be applicable for both RADIUS and Diameter. >> With translation, if necessary, described in the document. > > > Would you consider that this RADIUSEXT WG is the appropriate > place for this discussion then, since many of the folks involved > with RADIUS are also involved with Diameter? Yes -- though I would probably name RADEXT to AAAEXT and avoid unnecessary focus to RADIUS only. Not that the name defines what the group will do, but... >> o Section 2.3.7, attribute IP-Filter-Name: What is the difference >> between this attribute and the Filter-Id attribute from RFC 2865? >> Do we need another one? > > > There is no fundamental difference between the current typical > usage of the Filter-Id attribute and the new IP-Filter-Name. > However, this is also true, based on RFC 3580, of the VLAN > attributes, which are using the Tunnel attributes to specify > VLAN information (see section 3.9 of RFC 3580 for Filter-Id > usage, and section 3.31 for Tunnel/VLAN usage). > > The intent was to extract the common LAN edge attributes and > place them together. At the risk, as you mention, of redundancy. > I'm not sure argument should prevail, so some discussion > on the matter will help to decide the issue. I think its fine to document all the attributes relevant for LANs together -- but you should then make a distinction of those attributes that you are now introducing in this document, and those that you just import from other documents. This would help those readers who know both documents, would help IANA, and would make it clear what document is normative wrt to a given attribute. >> Also, it would be better to hightlight the relationship of >> the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP. >> Note that this AVP has a code 400 which means it is not directly >> RADIUS compatible. But if the definitions are aligned otherwise >> then translation should at least be possible. > > > This may be true. The Diameter IPFilterRule was chosen because of its > immediate likeness to the layer 3 inclinations of the IP-Filter-Raw > attribute. It seems like using the NAS-Filter-Rule AVP would be more > inclusive; is that a desired direction? There may be other reasons > for using NAS-Filter-Rule of which I am unaware. The definitions appear to have the same contents, given that you refer to Diameter data type. I think the semantics are also the same. Perhaps you should just state that this is like the NAS-Filter-Rule AVP -- and maybe name it NAS-Filter-Rule-Radius or something like that to make it obvious. --Jari -- 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, 15 Dec 2003 22:47:40 +0000 Message-ID: <3FDE39C8.3000401@piuha.net> Date: Tue, 16 Dec 2003 00:46:32 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: Re: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Adrangi, Farid wrote: > 1) Define a format/syntax by which the information can be represented > (i.e., what > is currently being defined in the draft) > 2) Use Subtypes (there has been some discussion on the mailing list; > however, I > am not sure about the final conclusion) > 3) Separate attributes > > We are not locked on a particular approach and open to ideas and > suggestions. Do > you have any suggestion how we can reach consensus on this? Do you want > me to revise > the draft to include all three format/syntax with pros and cons of each? Not really. One way is enough. Its up to the WG what that way is of course -- my preference is alt 3. >> o Address type "Public and Private": I have trouble >> seeing how this works in IPv4. >> > > > [FA] There are two aspects to this feature. One is to enable Access > Network > to advertise its capability about private or public address assignment > for a > given WLAN client, and to enable the home RADIUS server to specify the > desired > address type option. The other is how the Access Network is going to > enforce > the specified address type option (private or public address) when the > client > does a DHCP request - which IMO, this is outside the scope of the > document and > perhaps we should be more explicit about it. Which aspect of the > feature do > you have problem with? [FA] 1) Presumably, lack of indication about the address type from the home network would be taken as either type being acceptable? If yes, public+private option may not be necessary. 2) If you were to *enforce* the selection from the home network, then public+private option would not work. 3) I get a bit worried that lack of enforcement is going to cause problems. Is it a general approach for AAA attributes from the home server to be hints? Is someone's billing going to be based on a public or private address being provided? Or is this simply a result of backwards compatibility i.e. we do not wish to disable access from NASes that do not yet support these new attributes? >> o Sect 2.7 overlaps with draft-black. I liked the >> draft-black approach better. >> > > > [FA] Yes, there is an overlap between two drafts. We should definitely > discuss which > method is better - we also think there is a need for an access network > to advertise > its network rate capability as well. I am currently making some changes > to the text > and the format/syntax. [FA] Ok. Thanks for your response. --Jari -- 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, 15 Dec 2003 22:31:38 +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: General comments on the LAN attributes work Date: Mon, 15 Dec 2003 14:30:52 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BB35@orsmsx410.jf.intel.com> Thread-Topic: General comments on the LAN attributes work Thread-Index: AcPDC857L7VNXgs6QDWkKuzBVSXtXAATAubQ From: "Adrangi, Farid" To: Cc: "Bernard Aboba" , , , "Bari, Farooq" , "Korhonen Jouni" Hi Jari, Please see my comments inline. BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Jari Arkko > Sent: Monday, December 15, 2003 5:02 AM > To: Bernard Aboba; 'radiusext@ops.ietf.org'; dnelson@enterasys.com > Subject: General comments on the LAN attributes work >=20 >=20 >=20 > 1) The world has evolved a lot since the RADIUS attributes > were defined, as we mainly had dial-in in mind back then. > New link layers, their new capabilities, and roaming imply > that there is a need for new AAA attributes as well. I support > extension work to define such attributes. >=20 > 2) Most of the proposed new functions are valid. Not quite > sure about _all_ them, such as capabilities negotiation for > RADIUS. >=20 [FA] If you are referring to Application-Based capability in our draft,=20 I wouldn't put it as capabilities negotiation, rather as capabilities=20 Advertisement. [FA] > 3) Almost everything in the drafts that I read applies to > both Diameter and RADIUS. There were a few exceptions, such > as some attributes which already existed in RADIUS. I believe > it would be a serious design mistake to make the drafts apply > just for RADIUS. As these functions are mainly about new=20 > attributes, > they should be documented in such a way that they apply to > both Diameter and RADIUS. Please make it so. In one draft. >=20 > There may be a few cases where translation becomes an issue. > If so, those need to be documented. But there is simply no > excuse to making this work RADIUS-specific. >=20 [FA] You have a point here. [FA] > 4) It may be worthwhile to think about the organization of > the attribute definitions into different documents, if > we get to standardizing them. Some of this stuff is > more general than LAN. >=20 > Personally, I'd prefer a set of multiple smaller specifications. > Say, an RFC on location attributes for AAA. I think we could > get them done sooner and it would be easier for vendors to > document what they support. >=20 [FA] Yes. In fact, we (Farooq and I) discussed this with Bernard=20 after the RadiusExt BoF in IETF#58. We specifically discussed this in=20 the context of location information as there is an urgency to get the attributes finalized by GSMA. This was also suggested in the last GSMA meeting, and we are planning to submit the finalized version in a separate draft. [FA] > --Jari >=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: Mon, 15 Dec 2003 22:06:29 +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: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Date: Mon, 15 Dec 2003 14:05:54 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BB34@orsmsx410.jf.intel.com> Thread-Topic: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Thread-Index: AcPDCuQvZ1y3eWmlT8WLNdenG9G/iAAPMGkw From: "Adrangi, Farid" To: Cc: Hello Jari, Thanks for taking time and reading the draft, and for your excellent=20 comments (as always). Although these attributes were motivated by=20 PWLAN roaming, they could be used as a general LAN attributes - a we agreed in BoF, we need to change the wording to make this clear though. we are currently working with GSMA and PA3 to finalize the details=20 of these attributes and we will also have some additional attributes. We are planning to send out a revised version to the RadiusExt mailing List before Jan 31 of 2004 for review/discussion. Please see my replies inline. =20 BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, December 15, 2003 4:56 AM > To: 'radiusext@ops.ietf.org'; Adrangi, Farid > Subject: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt >=20 >=20 >=20 > I have read >=20 > =20 > http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten > sion-for-pwlan-00.txt >=20 > and have some questions and comments: >=20 > o I have stated previously that I would in general like to > see separate attributes rather than a new syntax within > a value. The location attribute would be more useful with > separate attributes for city etc, imho. >=20 > And again, this is pretty general, not tied to PWLANs... >=20 [FA] I understand your point. We also debated this among us, we are not locked on a particular Format /syntax to indicate the location related information.=20 We discussed three possibilities (not in any particular order) in the time when we are working on the first version: 1) Define a format/syntax by which the information can be represented (i.e., what is currently being defined in the draft) 2) Use Subtypes (there has been some discussion on the mailing list; however, I am not sure about the final conclusion) 3) Separate attributes We are not locked on a particular approach and open to ideas and suggestions. Do=20 you have any suggestion how we can reach consensus on this? Do you want me to revise the draft to include all three format/syntax with pros and cons of each? Since the submission of this draft, we have made some changes to the attributes based on the discussions that we had in recent GSMA meetings. We will be submitting a=20 revised version soon. [FA] > o I dislike the Sect 2.2 string syntax, as it is hard > to make this really work in a consistent manner across > vendors and organizations. A standardized bit pattern > approach would be better, IMHO. Then again, I'm not sure > whether we should really extend RADIUS with a feature > capabilities discovery. >=20 [FA] Ok. So, I suggest we discuss the usefulness of this attribute before we dive into the syntax (which we are open to suggestions and ideas). =20 Why do you think this is not a useful attribute? [FA] > o I like the address range accounting control attributes. >=20 > o Sect 2.6 (address type) does not describe what to do > for IPv6... make it clear that it applies to IPv4 > only, or? >=20 [FA] Ok. Will do so. [FA] > o Address type "Public and Private": I have trouble > seeing how this works in IPv4. >=20 [FA] There are two aspects to this feature. One is to enable Access Network to advertise its capability about private or public address assignment for a given WLAN client, and to enable the home RADIUS server to specify the desired address type option. The other is how the Access Network is going to enforce the specified address type option (private or public address) when the client=20 does a DHCP request - which IMO, this is outside the scope of the document and=20 perhaps we should be more explicit about it. Which aspect of the feature do=20 you have problem with? [FA] > o Sect 2.7 overlaps with draft-black. I liked the > draft-black approach better. >=20 [FA] Yes, there is an overlap between two drafts. We should definitely discuss which method is better - we also think there is a need for an access network to advertise its network rate capability as well. I am currently making some changes to the text=20 and the format/syntax. [FA] > --Jari >=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: Mon, 15 Dec 2003 18:14:33 +0000 Message-ID: <7A371016E109114EA47C89370296278B2636F5@xrose01.rose.hp.com> From: "BLACK,CHUCK (HP-Roseville,ex1)" To: radiusext@ops.ietf.org Cc: "BLACK,CHUCK (HP-Roseville,ex1)" Subject: RE: Comments on draft-black-radius-lanedge-00.txt Date: Mon, 15 Dec 2003 13:13:59 -0500 MIME-Version: 1.0 Content-Type: text/plain From: Jari Arkko [mailto:jari.arkko@piuha.net] > o In general I support this type of a specification that would > define WLAN or LAN specific attributes for AAA. We need this. Good, it seemed that there would be interest in this, and the intention was to generate discussion and arrive at some sort of consensus. > o The attributes should be done in a general fashion, in one > document, and be applicable for both RADIUS and Diameter. > With translation, if necessary, described in the document. Would you consider that this RADIUSEXT WG is the appropriate place for this discussion then, since many of the folks involved with RADIUS are also involved with Diameter? > o Section 2.3.7, attribute IP-Filter-Name: What is the difference > between this attribute and the Filter-Id attribute from RFC 2865? > Do we need another one? There is no fundamental difference between the current typical usage of the Filter-Id attribute and the new IP-Filter-Name. However, this is also true, based on RFC 3580, of the VLAN attributes, which are using the Tunnel attributes to specify VLAN information (see section 3.9 of RFC 3580 for Filter-Id usage, and section 3.31 for Tunnel/VLAN usage). The intent was to extract the common LAN edge attributes and place them together. At the risk, as you mention, of redundancy. I'm not sure argument should prevail, so some discussion on the matter will help to decide the issue. >o Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute > length may reduce the usefulness of this attribute. I think > Filter-Id may have to be sufficient where this is an issue. This is unfortunate but true. > Also, it would be better to hightlight the relationship of > the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP. > Note that this AVP has a code 400 which means it is not directly > RADIUS compatible. But if the definitions are aligned otherwise > then translation should at least be possible. This may be true. The Diameter IPFilterRule was chosen because of its immediate likeness to the layer 3 inclinations of the IP-Filter-Raw attribute. It seems like using the NAS-Filter-Rule AVP would be more inclusive; is that a desired direction? There may be other reasons for using NAS-Filter-Rule of which I am unaware. > ... > o It may be worthwhile to think a little bit how to divide the work > into documents if we get to standardizing this. Maybe one draft > on general access attributes, another one on 802, and we already have > one one that clarifies the use of existing attributes in 802.1X (RFC > 3580). These are also good suggestions. It would be useful to have a more organized and intentional categorization of attributes into their intended domains. /chuck -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, December 15, 2003 4:54 AM To: radiusext@ops.ietf.org; chuck.black@hp.com Subject: Comments on draft-black-radius-lanedge-00.txt I have read http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt and have some questions and comments: o In general I support this type of a specification that would define WLAN or LAN specific attributes for AAA. We need this. o The attributes should be done in a general fashion, in one document, and be applicable for both RADIUS and Diameter. With translation, if necessary, described in the document. o Section 2.3.7, attribute IP-Filter-Name: What is the difference between this attribute and the Filter-Id attribute from RFC 2865? Do we need another one? o Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute length may reduce the usefulness of this attribute. I think Filter-Id may have to be sufficient where this is an issue. Also, it would be better to hightlight the relationship of the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP. Note that this AVP has a code 400 which means it is not directly RADIUS compatible. But if the definitions are aligned otherwise then translation should at least be possible. o The Bandwidth-*-* attributes: I like these attributes. This seems like a general set of attributes which may even be used outside LANs. o It may be worthwhile to think a little bit how to divide the work into documents if we get to standardizing this. Maybe one draft on general access attributes, another one on 802, and we already have one one that clarifies the use of existing attributes in 802.1X (RFC 3580). --Jari -- 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, 15 Dec 2003 13:03:10 +0000 Message-ID: <3FDDB0CF.3060403@piuha.net> Date: Mon, 15 Dec 2003 15:02:07 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Bernard Aboba , "'radiusext@ops.ietf.org'" , dnelson@enterasys.com Subject: General comments on the LAN attributes work Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 1) The world has evolved a lot since the RADIUS attributes were defined, as we mainly had dial-in in mind back then. New link layers, their new capabilities, and roaming imply that there is a need for new AAA attributes as well. I support extension work to define such attributes. 2) Most of the proposed new functions are valid. Not quite sure about _all_ them, such as capabilities negotiation for RADIUS. 3) Almost everything in the drafts that I read applies to both Diameter and RADIUS. There were a few exceptions, such as some attributes which already existed in RADIUS. I believe it would be a serious design mistake to make the drafts apply just for RADIUS. As these functions are mainly about new attributes, they should be documented in such a way that they apply to both Diameter and RADIUS. Please make it so. In one draft. There may be a few cases where translation becomes an issue. If so, those need to be documented. But there is simply no excuse to making this work RADIUS-specific. 4) It may be worthwhile to think about the organization of the attribute definitions into different documents, if we get to standardizing them. Some of this stuff is more general than LAN. Personally, I'd prefer a set of multiple smaller specifications. Say, an RFC on location attributes for AAA. I think we could get them done sooner and it would be easier for vendors to document what they support. --Jari -- 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, 15 Dec 2003 13:00:02 +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: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Date: Mon, 15 Dec 2003 14:59:43 +0200 Message-ID: Thread-Topic: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Thread-Index: AcPDCx7/eT2XBxTTQai0QXxF8iQ5+QAABEdQ From: To: , , Jari, > o I have stated previously that I would in general like to > see separate attributes rather than a new syntax within > a value. The location attribute would be more useful with > separate attributes for city etc, imho. >=20 > And again, this is pretty general, not tied to PWLANs... Location is a contentious issue in the IETF - I wonder if there is any relation to the GEOPRIV work that is on-going. John -- 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, 15 Dec 2003 12:56:55 +0000 Message-ID: <3FDDAF59.40606@piuha.net> Date: Mon, 15 Dec 2003 14:55:53 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" , "Adrangi, Farid" Subject: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have read http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-pwlan-00.txt and have some questions and comments: o I have stated previously that I would in general like to see separate attributes rather than a new syntax within a value. The location attribute would be more useful with separate attributes for city etc, imho. And again, this is pretty general, not tied to PWLANs... o I dislike the Sect 2.2 string syntax, as it is hard to make this really work in a consistent manner across vendors and organizations. A standardized bit pattern approach would be better, IMHO. Then again, I'm not sure whether we should really extend RADIUS with a feature capabilities discovery. o I like the address range accounting control attributes. o Sect 2.6 (address type) does not describe what to do for IPv6... make it clear that it applies to IPv4 only, or? o Address type "Public and Private": I have trouble seeing how this works in IPv4. o Sect 2.7 overlaps with draft-black. I liked the draft-black approach better. --Jari -- 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, 15 Dec 2003 12:56:14 +0000 Message-ID: <3FDDAF30.7060509@piuha.net> Date: Mon, 15 Dec 2003 14:55:12 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" , "Adrangi, Farid" Subject: Comments on draft-adrangi-radius-issues-in-pwlan-roaming-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have read http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roaming-00.txt and have some questions and comments: o This is a good document and useful input for the kinds of problems the IETF should look at. o The lack of Identity for Accounting Purposes (sect. 3.1): I agree that this is an issue where things like EAP-AKA which has identity protection or PEAP which hides the identity are used. Perhaps draft-ietf-aaa-eap should discuss this. But since the issue is in fact common to both Diameter and RADIUS, we could also describe it separately. "Accounting Considerations for Identity Privicy" I-D? o The lack of Standard (sect. 3.2): I agree that it is troublesome to arrange global naming of filters in a roaming scenario. Diameter does help this by allowing the home network to define the filters; draft-black has a similar scheme but limited in packet size. I would support some standardization of basic filter sets, and their naming. This could be either an IETF effort, or maybe something done in, say, WiFi alliance. o Access Network Location (sect. 3.4): I would like to do this in a manner which is as independent as possible from the given access network type. There seems to be two separate issues: geographic location (draft-black) and identity of the NAS. o Type of address (sect. 3.5): Yes, this would be useful. This is again general, not tied to wireless LANs. I think there may be ip address pool attributes somewhere that could also be used for this purpose. o QoS parameters (sect. 3.8): Yes, I agree that something like that is needed. Draft-black has some basic attributes for it. What parameters specifically would you need? o The document should be focused around "AAA", not just RADIUS, issues in PWLAN roaming. It would be helpful to identify which issues are common (most are) and which are specific to a particular AAA protocol. o Non-ascii characters in the text (at least quotes). --Jari -- 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, 15 Dec 2003 12:55:38 +0000 Message-ID: <3FDDAEE7.9040907@piuha.net> Date: Mon, 15 Dec 2003 14:53:59 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: radiusext@ops.ietf.org, chuck.black@hp.com Subject: Comments on draft-black-radius-lanedge-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have read http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt and have some questions and comments: o In general I support this type of a specification that would define WLAN or LAN specific attributes for AAA. We need this. o The attributes should be done in a general fashion, in one document, and be applicable for both RADIUS and Diameter. With translation, if necessary, described in the document. o Section 2.3.7, attribute IP-Filter-Name: What is the difference between this attribute and the Filter-Id attribute from RFC 2865? Do we need another one? o Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute length may reduce the usefulness of this attribute. I think Filter-Id may have to be sufficient where this is an issue. Also, it would be better to hightlight the relationship of the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP. Note that this AVP has a code 400 which means it is not directly RADIUS compatible. But if the definitions are aligned otherwise then translation should at least be possible. o The Bandwidth-*-* attributes: I like these attributes. This seems like a general set of attributes which may even be used outside LANs. o It may be worthwhile to think a little bit how to divide the work into documents if we get to standardizing this. Maybe one draft on general access attributes, another one on 802, and we already have one one that clarifies the use of existing attributes in 802.1X (RFC 3580). --Jari -- 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, 12 Dec 2003 22:08:10 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Nelson, David'" , Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP Date: Fri, 12 Dec 2003 16:07:27 -0600 MIME-Version: 1.0 Content-Type: text/plain Hi Dave, Thank you for your answers. What types of ID does the NAS use (beside IP address) in the NAS ID field? Would the RADIUS server then later store this ID or the NAS IP address in its database? Also I am wondering if the RADIUS server keeps any entry about the user's IP address? Thanks in advance, Madjid P.S. It seems that the SSPP and kick start drafts have found a new home in Enroll WG. The NAS has a transitive trust relationship with the home server, via the proxy server chain, but no direct trust relationship. Each proxy server will generally validate the NAS identity before forwarding a request. If you have a "rogue" proxy in the chain, security problems will obviously exist. > > The NAS ID is the of originating client, not the proxy. > > Madjid>>So are you saying the packet carries both an IP address (for the > proxy or NAS) and a NAS ID for originating NAS? Yes. The packet's source IP address is in the IP header and the NAS ID (or NAS IP Address) is in the packet payload. It is the Source IP address from the IP header that is used to look up the shared secret. -- 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, 09 Dec 2003 23:05:53 +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: kickstart and SSPP Date: Tue, 9 Dec 2003 18:05:12 -0500 Message-ID: Thread-Topic: kickstart and SSPP Thread-Index: AcO+ppMcNY+S8YNPQGKcUVXqrhgSlgAAUKYg From: "Nelson, David" To: "Nakhjiri Madjid-MNAKHJI1" Cc: Madjid writes... > Thank you for your response. Let me try to understand your reponse: > please see inserts. > > General question first, why did RADIUS madated the use > > of source IP address from the UDP packet as a way of shared > > secret look up in the first place. >=20 > Because shared secrets in RADIUS are hop-by-hop, and the only reliable > way to look up the shared secret for a proxy server is via the source IP > address. >=20 > Madjid>>if the shared secret is hop by hop and there are proxies on the > way, does that mean the NAS will not have a shared secret with the home=20 > RADIUS server? Yes. The NAS will share a RADIUS secret with any first-hop RADIUS server it contacts, but will generally not share a secret with the ultimate home RADIUS server, in proxy deployments. > This means the home server will not have any trust relationship > with the NAS that accepting users on behalf of that server? The NAS has a transitive trust relationship with the home server, via the proxy server chain, but no direct trust relationship. Each proxy server will generally validate the NAS identity before forwarding a request. If you have a "rogue" proxy in the chain, security problems will obviously exist. > > The NAS ID is the of originating client, not the proxy. >=20 > Madjid>>So are you saying the packet carries both an IP address (for the > proxy or NAS) and a NAS ID for originating NAS? Yes. The packet's source IP address is in the IP header and the NAS ID (or NAS IP Address) is in the packet payload. It is the Source IP address from the IP header that is used to look up the shared secret. -- 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, 09 Dec 2003 22:49:07 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP Date: Tue, 9 Dec 2003 16:46:38 -0600 MIME-Version: 1.0 Content-Type: text/plain Hi Dave, Thank you for your response. Let me try to understand your reponse: please see inserts. Regards, Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David Sent: Saturday, December 06, 2003 9:27 AM Cc: radiusext@ops.ietf.org Subject: RE: kickstart and SSPP > General question first, why did RADIUS madated the use > of source IP address from the UDP packet as a way of shared > secret look up in the first place. Because shared secrets in RADIUS are hop-by-hop, and the only reliable way to look up the shared secret for a proxy server is via the source IP address. Madjid>>if the shared secret is hop by hop and there are proxies on the way, does that mean the NAS will not have a shared secret with the home RADIUS server? This means the home server will not have any trust relationship with the NAS that accepting users on behalf of that server? The NAS ID is the of originating client, not the proxy. Madjid>>So are you saying the packet carries both an IP address (for the proxy or NAS) and a NAS ID for originating NAS? Regards, Dave David B. Nelson Wireless & AAA Architect, Office of the CTO Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 (978) 684-1330 dnelson@enterasys.com -- 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: Mon, 08 Dec 2003 22:54:33 +0000 Message-ID: <6809B34C3BFED511BC83000103C42C9401B5B520@mail.funk.com> From: Mike Santoro To: "'radiusext@ops.ietf.org'" Subject: This is my test to see if I am on the list Date: Mon, 8 Dec 2003 17:53:59 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BDDE.2AEF6FB0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BDDE.2AEF6FB0 Content-Type: text/plain I just wanted to check and see if the List was functional from my mail server. Michael Santoro Systems Engineer Funk Software Inc. 617-497-6339 x220 ------_=_NextPart_001_01C3BDDE.2AEF6FB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I just wanted to check and = see if the List was functional from my mail server.

 

Michael Santoro

Systems Engineer

Funk Software = Inc.

617-497-6339 x220

 

------_=_NextPart_001_01C3BDDE.2AEF6FB0-- -- 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, 06 Dec 2003 15:28:31 +0000 Subject: RE: kickstart and SSPP MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Dec 2003 10:27:20 -0500 content-class: urn:content-classes:message Message-ID: Thread-Topic: kickstart and SSPP Thread-Index: AcO7geHLcLxwyJ/USr2aLQRIFBPQeQAiyjVA From: "Nelson, David" Cc: > General question first, why did RADIUS madated the use > of source IP address from the UDP packet as a way of shared > secret look up in the first place. Because shared secrets in RADIUS are hop-by-hop, and the only reliable way to look up the shared secret for a proxy server is via the source IP address. The NAS ID is the of originating client, not the proxy. Regards, Dave David B. Nelson Wireless & AAA Architect, Office of the CTO Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 (978) 684-1330 dnelson@enterasys.com =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, 05 Dec 2003 22:47:53 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org Subject: kickstart and SSPP Date: Fri, 5 Dec 2003 16:46:27 -0600 MIME-Version: 1.0 Content-Type: text/plain Hi, First one question for the public and then a few for the authors of kickstart draft. General question first, why did RADIUS madated the use of source IP address from the UDP packet as a way of shared secret look up in the first place. Can't that requirement be changed, seems like a solution of comparable complexity, no? This proposal is creating new messages (access boot, access booted) already (if I understand it correctly) and that is a comparable change... Second, why SSPP and not IKE, I am not a cryptographer, but from what I can see there are several round trips involved here and then SSPP throws the confusing SSPP client=RADIUS server... thing in there and there are plenty of computations. Also I know I need to read the SSPP and kickstart drafts one more time to understand the issues, but according to the author it does not prevent the case there can be wireless and unprotected route between client and server, doesn't IKE provision for this? It seems like there was a BoF in Minneapolis on IKEv2 for Mobile IP seems like that work would be more generic. I am sorry if I am blunt, I just heard my 11-month old daughter has started walking so I am rushing home to see it:) Thanks and Regards, Madjid -- 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, 03 Dec 2003 23:00:08 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Bernard Aboba'" Cc: radiusext@ops.ietf.org Subject: RE: irtf-aaaarch-handoff-02 draft Date: Wed, 3 Dec 2003 16:57:18 -0600 MIME-Version: 1.0 Content-Type: text/plain Thanks, What about the context transfer draft? BR, Madjid -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Tuesday, December 02, 2003 9:33 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org Subject: Re: irtf-aaaarch-handoff-02 draft This work is ongoing within IRTF, and a request was made by the lead author (Bill Arbaugh) that work continue there. On Tue, 2 Dec 2003, Nakhjiri Madjid-MNAKHJI1 wrote: > Question for the chair, > > The expertimental handoff extension draft was in the few first agendas > for the IETF BoF, but it seems to have later on fell off the agenda. > > Care for any explanation? I am sorry if this had been discussed earlier, > I am a newcomer on this list. > > Regards, > > Madjid Nakhjiri > > -- > 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: Wed, 03 Dec 2003 03:14:23 +0000 Date: Tue, 2 Dec 2003 19:32:42 -0800 (PST) From: Bernard Aboba To: Nakhjiri Madjid-MNAKHJI1 cc: radiusext@ops.ietf.org Subject: Re: irtf-aaaarch-handoff-02 draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This work is ongoing within IRTF, and a request was made by the lead author (Bill Arbaugh) that work continue there. On Tue, 2 Dec 2003, Nakhjiri Madjid-MNAKHJI1 wrote: > Question for the chair, > > The expertimental handoff extension draft was in the few first agendas > for the IETF BoF, but it seems to have later on fell off the agenda. > > Care for any explanation? I am sorry if this had been discussed earlier, > I am a newcomer on this list. > > Regards, > > Madjid Nakhjiri > > -- > 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, 02 Dec 2003 22:18:46 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: radiusext@ops.ietf.org Subject: irtf-aaaarch-handoff-02 draft Date: Tue, 2 Dec 2003 16:14:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Question for the chair, The expertimental handoff extension draft was in the few first agendas for the IETF BoF, but it seems to have later on fell off the agenda. Care for any explanation? I am sorry if this had been discussed earlier, I am a newcomer on this list. Regards, Madjid Nakhjiri -- 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, 01 Dec 2003 19: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: Subtypes Date: Mon, 1 Dec 2003 14:24:21 -0500 Message-ID: Thread-Topic: Subtypes Thread-Index: AcO4P5o9rfM5KHpATNS006jV+CXsSQAAE/Fg From: "Nelson, David" Cc: Avi Lior writes... > Which approach? > The approach of forcing an X.500 to be encoded using separate attributes. > Or the set of tests I defined above? The former. > Actually I will make a stronger statement: there is no distinction between > the two. =20 I respectfully disagree. > One man's garbage is another man's treasure; Well that's true, and I guess I tend to fall more in the camp of considering multiple, ASCII-delimited, implicit-length, sub-type fields in a single attribute as "garbage". Sorry. > But what is wrong with justifying existing implmentation for the sake of > convience to early adopters. That should also be taken into account. no? > If the attribute as been in wide use and there is no good reason to change > it then lets not. Doesn't that make common sense. All else being equal, yes, it would make sense. However, in this case, I don't see all else actually being equal. I see a serious protocol design quality issue. -- Dave -- 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, 01 Dec 2003 19:16:35 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: Subtypes Date: Mon, 1 Dec 2003 14:16:09 -0500 MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, December 01, 2003 12:06 PM > Cc: radiusext@ops.ietf.org > Subject: RE: Subtypes > > > Avi Lior writes... > > > I would rather see a test that considers the following: > > A) Are subcomponents of the attribute useful to intermediaries; > > B) Should subcomponent be "promoted" because they are useful. > > C) If a RADIUS server needs to parse the attributes, does it make > > sense to encode them using subTLVs. There could be other "tests" or > > guidelines. > > > > If I wanted to be pendantic about the feedback I am getting on > > this list; your X.500 MUST be encoded using separate attributes. > > Fine. I would not object to that approach. Which approach? The approach of forcing an X.500 to be encoded using separate attributes. Or the set of tests I defined above? > My point was > that multi-part data entities that comprise a *single* entity > in a well-defined ASCII (UTF-8) syntax, such as FQDNs, are > perfectly "normal" as string-valued attribute content. A > group of *related* data entities encoded in a similar fashion > is simply sub-types in disguise. I agree > that the distinction can be a fine one to attempt to codify, > however. Actully I will make a stronger statement: there is no distinction between the two. One man's garbage is another man's treasure; > > Using my test we can decide what the best action to take on an > > attribute by attribute basis. > > Well, please forgive my directness, but your suggested rules > seem designed to justify existing implementation, for the > sake of convenience to the early adopters, rather than > focusing on good protocol design principles. I understand > that this is also a somewhat subjective analysis -- but I > think it's one of those "I know it when I see it." sort of things. Not for the sake of convenience to early adopters at all. But I think a pragmatic approach to a problem. BTW, my rules are not complete just something I came up with on the fly - if that is the right approach lets create a set of rules/guidelines that do make sense. But what is wrong with justifying existing implmentation for the sake of convience to early adopters. That should also be taken into account. no? If the attribute as been in wide use and there is no good reason to change it then lets not. Doesn't that make common sense. > Regards, > > Dave > > David B. Nelson > Wireless & AAA Architect, Office of the CTO > Enterasys Networks, Inc. > 50 Minuteman Road > Andover, MA 01810-1008 > Phone: (978) 684-1330 > E-mail: dnelson@enterasys.com > > > > -- > 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: Mon, 01 Dec 2003 17:06: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: Subtypes Date: Mon, 1 Dec 2003 12:05:40 -0500 Message-ID: Thread-Topic: Subtypes Thread-Index: AcO4Kz0WheR3uYC8TrumP+XF/hmTwQAAKaaA From: "Nelson, David" Cc: Avi Lior writes... > I would rather see a test that considers the following: > A) Are subcomponents of the attribute useful to intermediaries; > B) Should subcomponent be "promoted" because they are useful. > C) If a RADIUS server needs to parse the attributes, does it make > sense to encode them using subTLVs. > There could be other "tests" or guidelines. >=20 > If I wanted to be pendantic about the feedback I am getting on=20 > this list; your X.500 MUST be encoded using separate attributes. Fine. I would not object to that approach. My point was that multi-part data entities that comprise a *single* entity in a well-defined ASCII (UTF-8) syntax, such as FQDNs, are perfectly "normal" as string-valued attribute content. A group of *related* data entities encoded in a similar fashion is simply sub-types in disguise. I agree that the distinction can be a fine one to attempt to codify, however. =20 > Using my test we can decide what the best action to take on an=20 > attribute by attribute basis. Well, please forgive my directness, but your suggested rules seem designed to justify existing implementation, for the sake of convenience to the early adopters, rather than focusing on good protocol design principles. I understand that this is also a somewhat subjective analysis -- but I think it's one of those "I know it when I see it." sort of things. Regards, =20 Dave =20 David B. Nelson Wireless & AAA Architect, Office of the CTO Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330 =20 E-mail: dnelson@enterasys.com =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, 01 Dec 2003 16:51:40 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: Subtypes Date: Mon, 1 Dec 2003 11:50:15 -0500 MIME-Version: 1.0 Content-Type: text/plain > like this: > > > > Operator-name=GSM:T-Mobile, location-ID=44,location- > > name=starbucks-4,location-type=coffee shop, city= seattle, > > state=Washington,country=us > String-valued attributes containing a single, well-defined > entity, such as a Fully-Qualified Domain Name or an X.500 > Distinguished Name, would seem to be perfectly appropriate. > However, attempting to create new "entities" in an effort to > encode sub-types in an ASCII-delimited, implicit-length > protocol encoding, would be a Very Bad Thing (tm), IMHO. Your argument which relies on the premise that something that is well defined is okay to be encoded as a subtype vs something that is not well defined is not okay is problematic to me. Why, because whether something is well defined or not is hugely debateable. The authors of the above can argue that the example is a well defined entity. I will argue that my Prepaid attribute is a well defined entity and in fact it is. I would rather see a test that considers the following: A) Are subcomponents of the attribute useful to intermediaries; B) Should subcomponent be "promoted" because they are useful. C) If a RADIUS server needs to parse the attributes, does it make sense to encode them using subTLVs. There could be other "tests" or guidelines. If I wanted to be pendantic about the feedback I am getting on this list; your X.500 MUST be encoded using separate attributes. Using my test we can decide what the best action to take on an attribute by attribute basis. -- 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, 01 Dec 2003 15:38:01 +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: Subtypes Date: Mon, 1 Dec 2003 10:37:11 -0500 Message-ID: Thread-Topic: Subtypes Thread-Index: AcO0/i4gN86CqekoRdiPVjzrfiYLWQDIeRFQ From: "Nelson, David" Cc: Avi Lior writes... > I didn't hear too many folks complain about > draft-adrangi-radius-extension-for-pwlan-00.txt PWLAN Location Information > Attribute (2.1) the proposed encoding in that document would yield an > attribute that contained a string that would look something like this: >=20 > Operator-name=3DGSM:T-Mobile, location-ID=3D44,location- > name=3Dstarbucks-4,location-type=3Dcoffee shop, city=3D = seattle, > state=3DWashington,country=3Dus >=20 > We want this now to be encoded using subTLV. What is wrong with that? It > saves space and it saves parsing time (when it needs to be parsed) Well, perhaps we simply haven't attempted to "fry that fish" yet... :-) String-valued attributes containing a single, well-defined entity, such as a Fully-Qualified Domain Name or an X.500 Distinguished Name, would seem to be perfectly appropriate. However, attempting to create new "entities" in an effort to encode sub-types in an ASCII-delimited, implicit-length protocol encoding, would be a Very Bad Thing (tm), IMHO. Regards, =20 Dave =20 David B. Nelson Wireless & AAA Architect, Office of the CTO Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330 =20 E-mail: dnelson@enterasys.com -- 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, 01 Dec 2003 15:16:29 +0000 Message-ID: <3FCB5B14.F26880DF@alcatel.be> Date: Mon, 01 Dec 2003 16:15:32 +0100 From: nagi reddy jonnala Organization: Alcatel Telecom MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Comments/questions on Prepaid-draft-02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Prepaid authors & all, I hope not having a chartered WG is not a restriction to discuss the drafts. Please let me know if I have the wrong assumption. Here are the comments/questions on prepaid-draft-02. 1) I'm not really convinced with the way *Service Element" work? How can an element sits in between access device and a Prepaid server *disconnect* a session on the access device? I can unserstand it can meter the things but can not disconnect sessions. You can argue that Service element asks/updates the quotas. How do you handle the re-authorizations that are supposed to be initiated by access devices. Can you explain little further of its significance and how it works? 2) Doesn't PP draft *standardize* the servic keys? I would assume that it is really important for interoperation. 3) Always, Termination-Action MUST be set to Radius-Request to make sure that access device will ask for another quota rather than disconnecting the session (it is the case if Termination-Action = default). 4) Section 4.2 talks about sending User-Password attribute while sending the message from HAAA to Prepaid server for more security. I disagree with this. What are we doing here? Are we making PP server another authentication server? 5) Sections 4.2.1 and 4.4, Ascend-data-filter was mentioned separately. I guess we can remove this. 6) Section 4.4, Mid-Session Operation - doesn't consider if there are Broker AAAs in between. For example, You may need to add IP addresses of PP servers to the Access-Requests. 7) Section 4.4, Mid-Session operation: Isn't it possible that the operator wants to update his services and wants to notify the access points. 8) Section 4.5.1. says "Each AAA MUST route the Disconnect Request packet. How the routing decision is made is an implementation detail. " Can you explain how can a Disconnect message initiated by PP server will reach the Access Device? I mean what are the attributes involved to make the packet reach its destination through the proxies. 9) what does a PP server do if it receives Disconnect-NAK? Does it keep billing? 10) Section 4.5.1 "Once the Disconnect Request packet reaches AAA that is in the same network as the serving Access Device, if the Access Device supports Disconnect-Request (as per [RFC3576]), it sends the message directly to the Access Device; otherwise it uses other mechanisms such as SNMP or Telnet to command the Access Device to terminate the session." - How does a AAA server know that if the access point supports Disconnect (or) CoA messages? Is this also out of scope? :) - How does Telnet/SNMP work in this scenario. Can you further explain? 11) Should there be a threshold value always ( with Volume/Time quota). Is it possible that an access device choose not to implement this attribute? 12) Section 5.3. "Sub-Type (=3): Sub-Type for VolumeQuotaOverflow Length: length of VolumeQuotaOverflow attribute (= 4 octets) VolumeQuotaOverflow (VQO): The optional VolumeQuotaOverflow Sub-Type is used to indicate how many times the VolumeQuota counter has wrapped around 2^32 over the course of the service being provided. " Is this present in access-request (or) access-accept? Its worth mentioning who sends to whom. Regards Nagi. PS: Can you tell us what does it take to flatten the attributes. Roughly, how many new attributes are needed? I believe it is really important to debate this topic to make progress. -- 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: