Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Sep 2003 20:45: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: RADIUS BOF agenda Date: Tue, 30 Sep 2003 13:44:57 -0700 Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC34C@orsmsx410.jf.intel.com> Thread-Topic: RADIUS BOF agenda Thread-Index: AcOHKm4VIDIT3+ZYQKKNDKYuiTSCZAAZGFKQ From: "Adrangi, Farid" To: "Bernard Aboba" , Hello Bernard, Regarding WLAN related RADIUS issues (the work item below), yes there is a progress. We have been looking at some of requirements from 3GPP, 3GPP2, and GSMA WLAN inter-working studies to complete the issues list. In order to do a thorough job, an unofficial design team (includes members who are active participants or key contributors in the aforementioned standard bodies) was formed. We are planning to submit our final work in the next 2-3 weeks - the contribution will contain a solution. We have also identified another work-item: Guidelines for RADIUS Packet Source Routing, which we are planning to submit a contribution on it for the next IETF. This is not currently part of the agenda - and hopefully the contribution will help us determine whether or not it should be added. Please let me know if you have any questions. Best regards, Farid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, September 30, 2003 12:36 AM To: radiusext@ops.ietf.org Subject: RADIUS BOF agenda An IETF WG does not cause work to be done. Rather, it is a forum for people already doing work to further that work. To determine whether there is sufficient interest for a RADIUSEXT WG, a good gauge is progress on the individual submissions that could become the focus of a WG. Below are some drafts relating to RADIUS. To judge whether formation of a WG is worth considering, we need to know whether there has been progress on these items lately, and if not, why we should expect progress if a WG is formed. draft-adrangi-radius-issues-in-pwlan-roaming-00.txt Has there been any followup in terms of concrete proposals to fix the issues discussed in this 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, 30 Sep 2003 20:20:32 +0000 Message-Id: <43240544763FB8479F1529372F6197CF053CC9B8@G8PQC.blf01.telekom.de> From: "Liess, Laura" To: aboba@internaut.com Cc: radiusext@ops.ietf.org, aland@ox.org Subject: AW: RADIUS BOF agenda Date: Tue, 30 Sep 2003 22:19:43 +0200 MIME-Version: 1.0 Content-Type: text/plain >> draft-sterman-aaa-sip-00.txt >> As far as I can see, there has been no work on this draft in quite a >> while. Is there any interest in continuing to work on it? > > There are multiple interoperable implementations, so it looks pretty >much done. However, I believe it's subject to MITM attacks, so it >probably needs updating. What about trying to contact the authors? Laura > >> draft-moskowitz-radius-client-kickstart-00.txt >> Little progress recently on this. Any interest in moving forward? > > There are many networks where administrators have been using bad >hacks to support clients with dynamic IP's. e.g. Shared secrets for an >entire network, looking up clients based on RADIUS attributes, etc. > > This proposal addresses a problem which currently exists in the >deployment and use of RADIUS. I'm in favour of moving it forward. > > > I don't, as yet, have comments on the other drafts. > > Alan DeKok. > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- 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, 30 Sep 2003 16:45:55 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: RADIUS BOF agenda Date: Tue, 30 Sep 2003 12:45:26 -0400 Message-Id: Randy Bush wrote: > please explain how multiple interoperable implementations produce a > high quality draft. It doesn't. My use of the word "done" was in the context of "at the end of it's life", and not "finished and polished". My later comments indicated that if people wish to continue using related authentication methods, that those methods should be designed properly. > excuse the sarcasm, but what it seems is needed here, among other > things, is serious draft authors and reviewers. So far, the silence is deafening. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Sep 2003 16:18:49 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: RADIUS BOF agenda Date: Tue, 30 Sep 2003 12:16:55 -0400 Message-Id: Bernard Aboba wrote: > Are you volunteering? Not to update draft-sterman. > > > draft-moskowitz-radius-client-kickstart-00.txt ... > Are you willing to work on it? Yes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Sep 2003 16:10:07 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 30 Sep 2003 09:09:07 -0700 To: "Alan DeKok" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS BOF agenda Message-Id: >> draft-sterman-aaa-sip-00.txt >> As far as I can see, there has been no work on this draft in quite a >> while. Is there any interest in continuing to work on it? > There are multiple interoperable implementations, so it looks pretty > much done. please explain how multiple interoperable implementations produce a high quality draft. > However, I believe it's subject to MITM attacks, so it probably > needs updating. an understatement. excuse the sarcasm, but what it seems is needed here, among other things, is serious draft authors and reviewers. randy -- 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, 30 Sep 2003 16:03:18 +0000 Date: Tue, 30 Sep 2003 08:28:11 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: RADIUS BOF agenda Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There are multiple interoperable implementations, so it looks pretty > much done. However, I believe it's subject to MITM attacks, so it > probably needs updating. Are you volunteering? > > draft-moskowitz-radius-client-kickstart-00.txt > > Little progress recently on this. Any interest in moving forward? > > There are many networks where administrators have been using bad > hacks to support clients with dynamic IP's. e.g. Shared secrets for an > entire network, looking up clients based on RADIUS attributes, etc. > > This proposal addresses a problem which currently exists in the > deployment and use of RADIUS. I'm in favour of moving it forward. Are you willing to work on it? -- 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, 30 Sep 2003 15:59:05 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: RADIUS BOF agenda Date: Tue, 30 Sep 2003 11:58:46 -0400 Message-Id: Bernard Aboba wrote: > draft-sterman-aaa-sip-00.txt > As far as I can see, there has been no work on this draft in quite a > while. Is there any interest in continuing to work on it? There are multiple interoperable implementations, so it looks pretty much done. However, I believe it's subject to MITM attacks, so it probably needs updating. > draft-moskowitz-radius-client-kickstart-00.txt > Little progress recently on this. Any interest in moving forward? There are many networks where administrators have been using bad hacks to support clients with dynamic IP's. e.g. Shared secrets for an entire network, looking up clients based on RADIUS attributes, etc. This proposal addresses a problem which currently exists in the deployment and use of RADIUS. I'm in favour of moving it forward. I don't, as yet, have comments on the other drafts. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Sep 2003 15:09:38 +0000 Date: Tue, 30 Sep 2003 07:33:57 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Call for Agenda items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a call for agenda items for the RADIUSEXT BOF scheduled for Minneapolis. If you're interested in presenting, please send to the list: a. The name of your draft. b. How much time you need. -- 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, 30 Sep 2003 08:11:13 +0000 Date: Tue, 30 Sep 2003 00:36:01 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADIUS BOF agenda Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII An IETF WG does not cause work to be done. Rather, it is a forum for people already doing work to further that work. To determine whether there is sufficient interest for a RADIUSEXT WG, a good gauge is progress on the individual submissions that could become the focus of a WG. Below are some drafts relating to RADIUS. To judge whether formation of a WG is worth considering, we need to know whether there has been progress on these items lately, and if not, why we should expect progress if a WG is formed. draft-lior-radius-prepaid-extensions-01.txt This draft is incompatible with the RADIUS dictonary as defined in [RFC2865]. Will a version fixing this issue be available in the near future? draft-lior-radius-reliable-accounting-00.txt How is work coming on addressing the issues raised by Glen Zorn? draft-schulzrinne-sipping-radius-accounting-00.txt Is work on this draft still ongoing or has it been abandoned? draft-sterman-aaa-sip-00.txt As far as I can see, there has been no work on this draft in quite a while. Is there any interest in continuing to work on it? draft-adrangi-radius-issues-in-pwlan-roaming-00.txt Has there been any followup in terms of concrete proposals to fix the issues discussed in this draft? draft-irtf-aaaarch-handoff-02.txt Is there any interest in actually implementing this, or is it strictly research? draft-moskowitz-radius-client-kickstart-00.txt Little progress recently on this. Any interest in moving forward? draft-heinanen-radius-pe-discovery-04.txt There was some interest in this in the PPVPN WG. Is work continuing in the successor WGs, or if not, is there interest in working on this in a RADIUSEXT WG? draft-lonvick-sobgp-radius-03.txt There seems to be continued work on this. Any interest in pursuing this in RADIUSEXT WG? -- 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, 26 Sep 2003 15:18:48 +0000 Message-ID: From: Avi Lior To: 'Randy Bush' , Avi Lior Cc: "'radiusext@ops.ietf.org'" Subject: RE: Approval for RADIUS extension working group Date: Fri, 26 Sep 2003 11:18:11 -0400 MIME-Version: 1.0 Content-Type: text/plain If we need to change it we will. It will have to wrestle with my co-authors. It's a bit too early to tell. Lets see how the the WLAN prepaid work progresses. I will post a "subtype" message specifically so we can debate the merits of subtype in the Prepaid context. > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, September 26, 2003 10:46 AM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: RE: Approval for RADIUS extension working group > > > > Are we going to have a BOF in MN? > > i think that is the plan > > > We (the authors of the Prepaid Draft) wanted to describe how 3GPP2 > > does prepaid ... > > Regarding the subtypes that is used. I am not wedded to subtypes > > and if we have to change them so be it. > > so you are documenting current practice, but you will change it? > > randy > -- 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, 26 Sep 2003 14:46:11 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 2003 07:46:04 -0700 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Approval for RADIUS extension working group Message-Id: > Are we going to have a BOF in MN? i think that is the plan > We (the authors of the Prepaid Draft) wanted to describe how > 3GPP2 does prepaid > ... > Regarding the subtypes that is used. I am not wedded to subtypes > and if we have to change them so be it. so you are documenting current practice, but you will change it? randy -- 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, 26 Sep 2003 14:41:44 +0000 Message-ID: From: Avi Lior To: 'Randy Bush' , 'Bernard Aboba' Cc: "'radiusext@ops.ietf.org'" Subject: RE: Approval for RADIUS extension working group Date: Fri, 26 Sep 2003 10:40:44 -0400 MIME-Version: 1.0 Content-Type: text/plain Thanx Randy for the clarification. Are we going to have a BOF in MN? Regarding Prepaid (Note I am not the official voice of 3GPP2) We (the authors of the Prepaid Draft) wanted to describe how 3GPP2 does prepaid so that others wont re-invent RADIUS based prepaid and so that 3GPP2 would have some interoperability. Since the prepaid scheme has already been standardized in IS-835C it would never appear in the 3GPP2 dependency list. Driven by WLAN 3GPP2 Interoperability work, in the next few months 3GPP2 *may* have some dependency on RADIUS prepaid solution. Regarding the subtypes that is used. I am not wedded to subtypes and if we have to change them so be it. Regarding prepaid for WLAN. There is interest in that. It was expressed by IEEE at the meeting in Wein, by customers that we are talking too and by a handfull of vendors and operators that we are talking with. As I said before a bunch of us are working on this very issue. We are looking at the various models of prepaid that are appropriate for WLAN and to see which one's make sense etc... Avi > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, September 24, 2003 5:06 PM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: RE: Approval for RADIUS extension working group > > > >> What are the hurdles that keep us from having a RADIUS > Extension WG? > > a. Need to demonstrate interest (e.g. a BOF with consensus > on forming a > > WG) > > there is always 'interest.' what is hard is finding real > will-do-work interest within a clear and very tightly-scoped charter. > > > b. Need to have a charter acceptable to the ADs. > > i think we have been pretty clear on this. i believe it has > been summed up in the following (plagarized): > > -- Complete the specification of the Diameter/RADIUS gateway. > This is part of the NASREQ specification, which is on the > verge of being sent off to the IESG. If this specification > is very important to 3GPP/3GPP2, which is not clear, it > would be helpful if we could get input from those > organizations to make sure it is right. This is being > pursued. > > -- Define new RADIUS attributes for WLAN. Several > organizations are now involved in this (IEEE 802.1, IEEE > 802.11, WFA, etc.) and there is the potential for > fragmentation. Since this effort is happening anyway, it > makes sense to me to do it in the IETF where an > interoperable standard can be created. Diameter AVPs can > be defined at the same time, so that RADIUS/Diameter > interoperation can be maintained. > > -- Define better RADIUS transport behavior. Retransmission > behavior is undefined in [RFC2865], and this has caused > problems in deployed implementations. Achieving more > reasonable behavior makes sense. However, this goal does > NOT extend to attempting to achieve Diameter-level > reliability in RADIUS; that is out of scope. > > Things not yet clear include: > > -- Pre-Paid. This work item is being considered largely > because of a possible, but not completely clear, request > from 3GPP2. But, the draft on the table does not conform > to the RADIUS dictionary types defined in RFC 2865. For > example, it creates a new RADIUS attribute format including > support for "sub-attributes," supposedly because the draft > would otherwise require so many attributes that it would > exhaust the entire RADIUS attribute space. Therefore if > the "sub-type" approach is not permitted, the claim is that > an expanded RADIUS attribute space is required. We are in > the process of finding out if there really is a requirement > for this work in 3GPP2. If so, has the impact of this > draft on RADIUS/Diameter compatibility/transition been > considered? > > > c. Need to have drafts fitting within the charter. > > yup > > > d. Need to have competent, committed people signed up to do the work > > described in the charter. > > yup, both authors and reviewers. > > randy > > > -- > 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, 24 Sep 2003 23:55:46 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 2003 14:05:33 -0700 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Approval for RADIUS extension working group Message-Id: >> What are the hurdles that keep us from having a RADIUS Extension WG? > a. Need to demonstrate interest (e.g. a BOF with consensus on forming a > WG) there is always 'interest.' what is hard is finding real will-do-work interest within a clear and very tightly-scoped charter. > b. Need to have a charter acceptable to the ADs. i think we have been pretty clear on this. i believe it has been summed up in the following (plagarized): -- Complete the specification of the Diameter/RADIUS gateway. This is part of the NASREQ specification, which is on the verge of being sent off to the IESG. If this specification is very important to 3GPP/3GPP2, which is not clear, it would be helpful if we could get input from those organizations to make sure it is right. This is being pursued. -- Define new RADIUS attributes for WLAN. Several organizations are now involved in this (IEEE 802.1, IEEE 802.11, WFA, etc.) and there is the potential for fragmentation. Since this effort is happening anyway, it makes sense to me to do it in the IETF where an interoperable standard can be created. Diameter AVPs can be defined at the same time, so that RADIUS/Diameter interoperation can be maintained. -- Define better RADIUS transport behavior. Retransmission behavior is undefined in [RFC2865], and this has caused problems in deployed implementations. Achieving more reasonable behavior makes sense. However, this goal does NOT extend to attempting to achieve Diameter-level reliability in RADIUS; that is out of scope. Things not yet clear include: -- Pre-Paid. This work item is being considered largely because of a possible, but not completely clear, request from 3GPP2. But, the draft on the table does not conform to the RADIUS dictionary types defined in RFC 2865. For example, it creates a new RADIUS attribute format including support for "sub-attributes," supposedly because the draft would otherwise require so many attributes that it would exhaust the entire RADIUS attribute space. Therefore if the "sub-type" approach is not permitted, the claim is that an expanded RADIUS attribute space is required. We are in the process of finding out if there really is a requirement for this work in 3GPP2. If so, has the impact of this draft on RADIUS/Diameter compatibility/transition been considered? > c. Need to have drafts fitting within the charter. yup > d. Need to have competent, committed people signed up to do the work > described in the charter. yup, both authors and reviewers. randy -- 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 Sep 2003 16:36:51 +0000 Date: Wed, 24 Sep 2003 09:02:18 -0700 (PDT) From: Bernard Aboba To: "Adrangi, Farid" cc: Avi Lior , radiusext@ops.ietf.org Subject: RE: Approval for RADIUS extension working group Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > What are the hurdles that keep us from having a RADIUS Extension WG? I think they're the standard hurdles: a. Need to demonstrate interest (e.g. a BOF with consensus on forming a WG) b. Need to have a charter acceptable to the ADs. c. Need to have drafts fitting within the charter. d. Need to have competent, committed people signed up to do the work described in the charter. -- 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 Sep 2003 16:22:18 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C382B7.B24F9B2F" Subject: RE: Approval for RADIUS extension working group Date: Wed, 24 Sep 2003 09:19:57 -0700 Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC327@orsmsx410.jf.intel.com> Thread-Topic: Approval for RADIUS extension working group Thread-Index: AcOBXdAQswHAXg3bSci7YE+ydXBK9gBWH7KA From: "Adrangi, Farid" To: "Avi Lior" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C382B7.B24F9B2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I haven't seen any responses to this mail. I am hoping that we hear something from Bernard, Randy, or David N on this. BR, Farid =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Monday, September 22, 2003 3:58 PM To: 'radiusext@ops.ietf.org' Subject: Approval for RADIUS extension working group =20 What are the hurdles that keep us from having a RADIUS Extension WG? =20 =20 ------_=_NextPart_001_01C382B7.B24F9B2F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

 

I haven’t seen any responses = to this mail.  I am hoping that we hear something from Bernard, Randy, or = David N on this.

BR,

Farid

 

-----Original = Message-----
From: = owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
Sent: Monday, September = 22, 2003 3:58 PM
To: = 'radiusext@ops.ietf.org'
Subject: Approval for = RADIUS extension working group

 

What are the hurdles that = keep us from having a RADIUS Extension WG?

 

 

=00 ------_=_NextPart_001_01C382B7.B24F9B2F-- -- 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 Sep 2003 22:58:40 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Subject: Approval for RADIUS extension working group Date: Mon, 22 Sep 2003 18:57:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3815C.E6CFAC90" 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_01C3815C.E6CFAC90 Content-Type: text/plain What are the hurdles that keep us from having a RADIUS Extension WG? ------_=_NextPart_001_01C3815C.E6CFAC90 Content-Type: text/html Message
What are the hurdles that keep us from having a RADIUS Extension WG?
 
 
------_=_NextPart_001_01C3815C.E6CFAC90-- -- 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 Sep 2003 20:44:09 +0000 Message-Id: <6.0.0.22.2.20030912133946.01bdea60@127.0.0.1> Date: Fri, 12 Sep 2003 13:42:36 -0700 To: Avi Lior , "'Bernard Aboba'" , Avi Lior From: Richard Perlman Subject: RE: minneapolis Cc: "'gwz@cisco.com'" , "'Randy Bush'" , "'radius list'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Avi: I tend to agree with you on this. For example, at present Termination-Action does not require that the same IP address be used on the subsequent session. And I think there is general agreement that misuse of accounting for pre-paid control is a bad idea. Richard At 01:21 PM 9/12/2003, Avi Lior wrote: >My comments are inline. > >But let me summarize here. > >To use Termination-Action for a general prepaid solution is risky. We agree >that it could work however, the specifications are ambiguious (as per our >exchanges below). RFC3580 tightens the standard but it is only applicable >to WLAN. > >The use of accounting messages also introduce risk (see our exchanges >below). Prepaid solution that relies on accounting messages would require >that Proxies provide real-time delivery of accounting message. Otherwise as >we show the operators will incure revenue leakages. Note: you could >elliminate the need for accounting. > >We don't think we are re-inventing the wheel. If you read the I-D we >address issues that go beyond just how you replenish quotas etc.... > > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Thursday, September 11, 2003 5:50 PM > > To: Avi Lior > > Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list' > > Subject: RE: minneapolis > > > >Avi writes: > > >What we see in the dial world is the session go away. That is the user is >gone. > >Bernard writes: > > If the session goes away, why would it make sense to send a > > RADIUS Access-Request after the user is no longer present? > >According to the words in 2865 > >5.24 State Attribute: > >"This Attribute is available to be sent by the server to the client >in an Access-Accept that also includes a Termination-Action >Attribute with the value of RADIUS-Request. If the NAS performs >the Termination-Action by sending a new Access-Request upon >termination of the current session, it MUST include the State >attribute unchanged in that Access-Request." > >Key word here is session. Termination of a session means the user goes away >right? > >One reason for firing back the Access Request after the user is gone >(session is terminated) is so that a RADIUS server that is tracking sessions >but not receiving accounting messages can be notified that the session went >away. > > > > There is nothing in RFC 2865 that says that > > Termination-Action=RADIUS refers to authentication only. > > Your interpretation seems to imply that > > Termination-Action=RADIUS yields exactly the same result as > > Termination-Action=Default. If so, why did RFC 2865 include > > two separate values if they mean the same thing? > >The difference is at the NAS. > > > > > There are two values for Termination-Action. The value > > Default means to terminate the session. The value RADIUS > > means to keep the user online and do a conventional RADIUS > > Access-Request. > >I can not derive that from 2865. > >Do you interpret the user hanging (ie, termination of their session) as a >termination of a service as well? If yes, then according to 2865 >" If the Value is set to RADIUS-Request, upon termination of the > specified service the NAS MAY send a new Access-Request to the > RADIUS server, including the State attribute if any. >" > >RFC3580 is much cleaner than 2865. 3580 implies that you can only send the >Termination-Action = RADIUS-Request(1) if Session-Timeout is sent as well. > >"The value RADIUS-Request (1) indicates that re-authentication should occur >on expiration of the Session-Time. The value Default (0) indicates that the >session should terminate." > > >The Service-Type value is used to indicate > > whether this is authentication-only or not; this is not > > implied by default. > > > > > Does the user see a continous service. > > > > If Termination-Action=RADIUS, yes. > >For WIFI yes. WIFI defines the behavior explicitly. For other deployments >we are not sure. If you look at 2865 the definition of Session Timeout is: > >"The field is 4 octets, containing a 32-bit unsigned integer with > the maximum number of seconds this user should be allowed to > remain connected by the NAS." > >How do you interpert "connected"? > > > > The revenue leakage comes from the fact that a subsequent login may > > > occur before the arrival of the Accounting Stop record. o my point > > > was (is) that you can do it using the RFC but you have > > issues such as > > > revenue leakage. > > > > How does changing the model prevent leakage? > >Changing the model may not prevent leakage but it can certainly reduce it >(which is what I said originally). > > > > The other issue relates to the use of Accounting messages. > > The simple > > > prepaid solution requires Accounting messages. Accounting messages > > > are not real-time. Do all access points support accounting > > messages? > > > > It seems quite reasonable to say that access Points that wish > > to support accounting (including prepaid) need to support > > accounting messages. > >Agreed. But for prepaid it depends on the model you use. Our model does >not require the use of accounting messages. > > > > 1- It does not rely on accounting messages. > > > > Inventing something new to avoid depending on existing > > functionality does not make much sense. > >We are not avoiding using existing functionality. Where do I say this? > >Accounting message do not have to be real-time (RFC 2866). Our model allows >us to deploy a Prepaid solution that does not require any changes in >Proxy-Chains. > > > > 2- Prepaid using existing RFC can only be based on time and not > > > Volume. You need to support either or both. > > > > This can be done by adding one more attributes. No need for > > "sub-types". > > > >Agreed. > > > > As for sub-attribute refers to earlier conversation regarding > > > Attribute Extension. I would be okay without the use of > > > sub-atttributes (but 3GPP2 did it that way -- so we have to figure > > > something out). Sub-attributes don't hurt they don't create > > > incompatibilities. > > > > Yes, they do "hurt" -- because sub-attributes require RADIUS > > code changes, which is why RFC 2865 invented the dictionary > > and has well defined attribute types. > > > > If sub-attributes are required for 3GPP2 backward > > compatibility, then I'd agree with Glen that the best thing > > would be to leave this in 3GPP2, rather than standardizing > > such a radical change to an existing protocol. > > > >They only "hurt" the client and the end server -- not the proxy chains. I >agree with the avoidance of sub-attributes. > > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- 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 Sep 2003 20:22:52 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: "'gwz@cisco.com'" , 'Randy Bush' , 'radius list' Subject: RE: minneapolis Date: Fri, 12 Sep 2003 16:21:56 -0400 MIME-Version: 1.0 Content-Type: text/plain My comments are inline. But let me summarize here. To use Termination-Action for a general prepaid solution is risky. We agree that it could work however, the specifications are ambiguious (as per our exchanges below). RFC3580 tightens the standard but it is only applicable to WLAN. The use of accounting messages also introduce risk (see our exchanges below). Prepaid solution that relies on accounting messages would require that Proxies provide real-time delivery of accounting message. Otherwise as we show the operators will incure revenue leakages. Note: you could elliminate the need for accounting. We don't think we are re-inventing the wheel. If you read the I-D we address issues that go beyond just how you replenish quotas etc.... > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, September 11, 2003 5:50 PM > To: Avi Lior > Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list' > Subject: RE: minneapolis > Avi writes: >What we see in the dial world is the session go away. That is the user is gone. Bernard writes: > If the session goes away, why would it make sense to send a > RADIUS Access-Request after the user is no longer present? According to the words in 2865 5.24 State Attribute: "This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State attribute unchanged in that Access-Request." Key word here is session. Termination of a session means the user goes away right? One reason for firing back the Access Request after the user is gone (session is terminated) is so that a RADIUS server that is tracking sessions but not receiving accounting messages can be notified that the session went away. > There is nothing in RFC 2865 that says that > Termination-Action=RADIUS refers to authentication only. > Your interpretation seems to imply that > Termination-Action=RADIUS yields exactly the same result as > Termination-Action=Default. If so, why did RFC 2865 include > two separate values if they mean the same thing? The difference is at the NAS. > > There are two values for Termination-Action. The value > Default means to terminate the session. The value RADIUS > means to keep the user online and do a conventional RADIUS > Access-Request. I can not derive that from 2865. Do you interpret the user hanging (ie, termination of their session) as a termination of a service as well? If yes, then according to 2865 " If the Value is set to RADIUS-Request, upon termination of the specified service the NAS MAY send a new Access-Request to the RADIUS server, including the State attribute if any. " RFC3580 is much cleaner than 2865. 3580 implies that you can only send the Termination-Action = RADIUS-Request(1) if Session-Timeout is sent as well. "The value RADIUS-Request (1) indicates that re-authentication should occur on expiration of the Session-Time. The value Default (0) indicates that the session should terminate." The Service-Type value is used to indicate > whether this is authentication-only or not; this is not > implied by default. > > > Does the user see a continous service. > > If Termination-Action=RADIUS, yes. For WIFI yes. WIFI defines the behavior explicitly. For other deployments we are not sure. If you look at 2865 the definition of Session Timeout is: "The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to remain connected by the NAS." How do you interpert "connected"? > > The revenue leakage comes from the fact that a subsequent login may > > occur before the arrival of the Accounting Stop record. o my point > > was (is) that you can do it using the RFC but you have > issues such as > > revenue leakage. > > How does changing the model prevent leakage? Changing the model may not prevent leakage but it can certainly reduce it (which is what I said originally). > > The other issue relates to the use of Accounting messages. > The simple > > prepaid solution requires Accounting messages. Accounting messages > > are not real-time. Do all access points support accounting > messages? > > It seems quite reasonable to say that access Points that wish > to support accounting (including prepaid) need to support > accounting messages. Agreed. But for prepaid it depends on the model you use. Our model does not require the use of accounting messages. > > 1- It does not rely on accounting messages. > > Inventing something new to avoid depending on existing > functionality does not make much sense. We are not avoiding using existing functionality. Where do I say this? Accounting message do not have to be real-time (RFC 2866). Our model allows us to deploy a Prepaid solution that does not require any changes in Proxy-Chains. > > 2- Prepaid using existing RFC can only be based on time and not > > Volume. You need to support either or both. > > This can be done by adding one more attributes. No need for > "sub-types". > Agreed. > > As for sub-attribute refers to earlier conversation regarding > > Attribute Extension. I would be okay without the use of > > sub-atttributes (but 3GPP2 did it that way -- so we have to figure > > something out). Sub-attributes don't hurt they don't create > > incompatibilities. > > Yes, they do "hurt" -- because sub-attributes require RADIUS > code changes, which is why RFC 2865 invented the dictionary > and has well defined attribute types. > > If sub-attributes are required for 3GPP2 backward > compatibility, then I'd agree with Glen that the best thing > would be to leave this in 3GPP2, rather than standardizing > such a radical change to an existing protocol. > They only "hurt" the client and the end server -- not the proxy chains. I agree with the avoidance of sub-attributes. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Sep 2003 18:53:34 +0000 Message-Id: <6.0.0.22.2.20030912114707.01b95080@127.0.0.1> Date: Fri, 12 Sep 2003 11:50:51 -0700 To: , "'Avi Lior'" From: Richard Perlman Subject: RE: minneapolis Cc: "'Randy Bush'" , "'radius list'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Glenn: The TIA WG is probably not willing to reconsider the IS-835-C prepay spec, although, IMO, such a review is needed since the spec is flawed (for one thing it uses VSAs with compound content requiring custom encoding/decoding for each VSA). Richard At 11:44 AM 9/11/2003, Glen Zorn wrote: >Is 3GPP2 going to change their pre-paid implementation based upon the >(proposed) WG review? If _technical_ review is desired, then this task >would make sense as a (proposed) WG work item; if not, I'm sure that >3GPP2 is quite capable of checking their own spelling and grammar... -- 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 Sep 2003 17:18:34 +0000 Date: Fri, 12 Sep 2003 09:45:18 -0700 (PDT) From: Bernard Aboba To: "Lortz, Victor" cc: radius list , =?iso-8859-1?Q?Raquel_Rodr=EDguez?= Subject: RE: minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 3GPP WLAN interworking as specified by SA2 for Release 6 will include conversion from > RADIUS to Diameter (TS 23.234 mentions this, and CN4 work on this topic > is happening as well). OK. That sounds like Diameter NASREQ, which includes specification for the RADIUS/Diameter gateway. NASREQ-13a has just been put out, and is likely to be finished up soon. >Although it is not clear whether prepaid services will be a requirement for WLAN >interworking, network initiated disconnect with RADIUS is being considered by CN4. Translation of network initiated disconnect is also covered in Diameter NASREQ. -- 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 Sep 2003 16:20:11 +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: minneapolis Date: Fri, 12 Sep 2003 09:19:19 -0700 Message-ID: Thread-Topic: minneapolis Thread-Index: AcN5SZ55ThyO33pzSqCT33H1/+IrgA== From: "Lortz, Victor" To: "Bernard Aboba" , "radius list" Cc: =?iso-8859-1?Q?Raquel_Rodr=EDguez?= 3GPP WLAN interworking as specified by SA2 for Release 6 will include = conversion from RADIUS to Diameter (TS 23.234 mentions this, and CN4 = work on this topic is happening as well). Although it is not clear = whether prepaid services will be a requirement for WLAN interworking, = network initiated disconnect with RADIUS is being considered by CN4. Regards, Vic -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Friday, September 12, 2003 7:25 AM To: Glen Zorn Cc: 'radius list' Subject: RE: minneapolis > Is 3GPP2 going to change their pre-paid implementation based upon the > (proposed) WG review? If _technical_ review is desired, then this = task > would make sense as a (proposed) WG work item; if not, I'm sure that > 3GPP2 is quite capable of checking their own spelling and grammar... I've checked the 3GPP2 IETF dependency web page at: http://www.3gpp2.org/Public_html/IETF/IETF_dependencies.cfm and there is no mention of RADIUS pre-paid, only Diameter Credit Control. So from an official standpoint, there is no request from 3GPP2 (or any other SDO) for RADIUS pre-paid work. -- 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, 12 Sep 2003 14:58:48 +0000 Date: Fri, 12 Sep 2003 07:24:57 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: "'radius list'" Subject: RE: minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is 3GPP2 going to change their pre-paid implementation based upon the > (proposed) WG review? If _technical_ review is desired, then this task > would make sense as a (proposed) WG work item; if not, I'm sure that > 3GPP2 is quite capable of checking their own spelling and grammar... I've checked the 3GPP2 IETF dependency web page at: http://www.3gpp2.org/Public_html/IETF/IETF_dependencies.cfm and there is no mention of RADIUS pre-paid, only Diameter Credit Control. So from an official standpoint, there is no request from 3GPP2 (or any other SDO) for RADIUS pre-paid work. -- 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, 11 Sep 2003 22:22:31 +0000 Date: Thu, 11 Sep 2003 14:49:50 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'gwz@cisco.com'" , "'Randy Bush'" , "'radius list'" Subject: RE: minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The session is complete and therefore the above refers to authentication and > not reauthentication and certainly not re-authorization. What we see in the > dial world is the session go away. That is the user is gone. If the session goes away, why would it make sense to send a RADIUS Access-Request after the user is no longer present? There is nothing in RFC 2865 that says that Termination-Action=RADIUS refers to authentication only. Your interpretation seems to imply that Termination-Action=RADIUS yields exactly the same result as Termination-Action=Default. If so, why did RFC 2865 include two separate values if they mean the same thing? > What do other similar devices do when this occurs? Do they hold the > session. There are two values for Termination-Action. The value Default means to terminate the session. The value RADIUS means to keep the user online and do a conventional RADIUS Access-Request. The Service-Type value is used to indicate whether this is authentication-only or not; this is not implied by default. > Does the user see a continous service. If Termination-Action=RADIUS, yes. > Where does the NAS get the credentials for the subsequent authentication > request? The same place it got the original ones. Most link-layers (PPP, IEEE 802.1X) support re-authentication. > Whats a prompt? A "prompt" refers to Service-Type="NAS Prompt" or "Callback NAS Prompt" > Why would I "prompt" when the quota needs replenishment? You'd do this if the Service-Type required that, otherwise not. > I would question the need for reauthentication in the first place. Why > go through that expense when all that is really needed is re-authorization (and > hence at least AUTHORIZE-ONLY message from 3576). Why does the client have > to be involved. If you don't re-authenticate, then it may not be clear that the user remains the same. If you only want to re-authorize, just use an alternate Service-Type in the Access-Request (e.g. Authorize-Only). > The revenue leakage comes from the fact that a subsequent login may occur > before the arrival of the Accounting Stop record. o my point was (is) that > you can do it using the RFC but you have issues such as revenue leakage. How does changing the model prevent leakage? > The other issue relates to the use of Accounting messages. The simple > prepaid solution requires Accounting messages. Accounting messages are not > real-time. Do all access points support accounting messages? It seems quite reasonable to say that access Points that wish to support accounting (including prepaid) need to support accounting messages. > 1- It does not rely on accounting messages. Inventing something new to avoid depending on existing functionality does not make much sense. > 2- Prepaid using existing RFC can only be based on time and not Volume. You > need to support either or both. This can be done by adding one more attributes. No need for "sub-types". > 3- It also introduces a threshold parameter that allows us to negotiate a > quota before the quota runs out. > > 4- It can be extended to provide other types of prepaid features such as > tarrif switching (supported by 3GPP2 and 3GPP). > > As for sub-attribute refers to earlier conversation regarding Attribute > Extension. I would be okay without the use of sub-atttributes (but 3GPP2 did > it that way -- so we have to figure something out). Sub-attributes don't > hurt they don't create incompatibilities. Yes, they do "hurt" -- because sub-attributes require RADIUS code changes, which is why RFC 2865 invented the dictionary and has well defined attribute types. If sub-attributes are required for 3GPP2 backward compatibility, then I'd agree with Glen that the best thing would be to leave this in 3GPP2, rather than standardizing such a radical change to an existing protocol. -- 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, 11 Sep 2003 21:57:41 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: "'gwz@cisco.com'" , 'Randy Bush' , 'radius list' Subject: RE: minneapolis Date: Thu, 11 Sep 2003 17:56:39 -0400 MIME-Version: 1.0 Content-Type: text/plain See inline. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, September 11, 2003 1:27 PM > To: Avi Lior > Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list' > Subject: RE: minneapolis > > > > You can assign Session-Timeout a portion of X but then the > NAS would > > boot the user off. Terminate-Action is not usable since it is sent > > after the NAS kicks the user off. > > > > If the Value is set to RADIUS-Request, upon termination of the > > specified service the NAS MAY send a new Access-Request to > the RADIUS > > server, including the State attribute if any." > > > > > > In WLAN its different. > > How is it different? The above paragraph in RFC 2865 refers > to re-authentication. It is different in WLAN because 3850 specifies precisely how to do re-authentication when these attributes are sent back in an access accept. In 2865 its not so clear. The exact wording in 2865: This Attribute indicates what action the NAS should take when the specified service is completed. It is only used in Access-Accept packets. The key words are "is completed". The session is complete and therefore the above refers to authentication and not reauthentication and certainly not re-authorization. What we see in the dial world is the session go away. That is the user is gone. What do other similar devices do when this occurs? Do they hold the session. Does the user see a continous service. If not this is a poor (at best) mechanism to use for prepaid in a general context. IMHO, I think the mechanims in 2865 raises more questions then answers. For instance where does the NAS get the credentials for the subsequent authentication request? >From 2865 Session-Timeout: This Attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. Whats a prompt? Why would I "prompt" when the quota needs replenishment? I would question the need for reauthencation in the first place. Why go through that expense when all that is really needed is re-authorization (and hence at least AUTHORIZE-ONLY message from 3576). Why does the client have to be involved. > > In other words, it appears that in WLAN there is a reauthentication > > mechanism that we can use to get another quota. > > This is just the mechanism described in RFC 2865. > > > If what is meant by simple prepaid solution is a solution > that works > > with existing deployements then this is not a simple > prepaid solution > > that works without changes. > > Actually, it sounds like you've just shown that a prepaid > solution can be implemented based on RFC 2865 with no changes > at all -- and no revenue leakage, without even requiring a > dependency on RFC 3576. The revenue leakage comes from the fact that a subsequent login may occur before the arrival of the Accounting Stop record. o my point was (is) that you can do it using the RFC but you have issues such as revenue leakage. The other issue relates to the use of Accounting messages. The simple prepaid solution requires Accounting messages. Accounting messages are not real-time. Do all access points support accounting messages? > > Hope this clears things up. > > Actually, this makes things even more unclear. Not only does > the prepaid draft invent a new RADIUS attribute format for > "sub-attributes" but now it appears that it is also > reinventing functionality already supported in RFC 2865. What is being reinvented? Our draft is useful: 1- It does not rely on accounting messages. 2- Prepaid using existing RFC can only be based on time and not Volume. You need to support either or both. 3- It also introduces a threshold parameter that allows us to negotiate a quota before the quota runs out. 4- It can be extended to provide other types of prepaid features such as tarrif switching (supported by 3GPP2 and 3GPP). As for sub-attribute refers to earlier conversation regarding Attribute Extension. I would be okay without the use of sub-atttributes (but 3GPP2 did it that way -- so we have to figure something out). Sub-attributes don't hurt they don't create incompatibilities. -- 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, 11 Sep 2003 18:45:06 +0000 Reply-To: From: "Glen Zorn" To: "'Avi Lior'" Cc: "'Randy Bush'" , "'radius list'" Subject: RE: minneapolis Date: Thu, 11 Sep 2003 11:44:00 -0700 Organization: Cisco Systems Message-ID: <00b901c37894$bc7282e0$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Avi Lior writes: >> Hope this helps, > > Not really. Sorry to hear that. ... > > Aside, there is nothing in Diameter that makes it more capable then > RADIUS when it comes to prepaid. What makes it more capable? You forgot the smiley, right? > > Other people want to do prepaid and they don't want Diameter. > > I think there are many good reasons for having a WG. The least of > which is a place where people can review the documents. Is 3GPP2 going to change their pre-paid implementation based upon the (proposed) WG review? If _technical_ review is desired, then this task would make sense as a (proposed) WG work item; if not, I'm sure that 3GPP2 is quite capable of checking their own spelling and grammar... > > Putting it in the same light as your comment. If 3GPP is the only > SDO who want Diameter why do we have to have an IETF AAA-WG for it? > Let them do the work there. As I'm sure you are aware, the Diameter work started in the IETF long before 3GPP was a glimmer in ETSI's eye...in any case, my statement referred to the 3GPP2 version of pre-paid _as a work item_, not to the formation of a WG per se. > > > > >> -----Original Message----- >> From: Glen Zorn [mailto:gwz@cisco.com] >> Sent: Thursday, September 11, 2003 11:57 AM >> To: 'Avi Lior' >> Cc: 'Randy Bush'; 'radius list' >> Subject: RE: minneapolis >> >> >> Avi Lior writes: >> >> ... >> >>> Regarding prepaid, I have received several email with comments and >>> am working on the next version of the draft. I have certain issues >>> to resolve all of which pertain to incoming suggestions and how to >>> keep this document aligned with what 3GPP2 has done. I just need >>> some advice. >>> >>> - Someone wants a description of how do to simple pre-paid which >>> will work with the lowest common denominator RADIUS deployments >>> (ie., no CHIBA, no new attributes etc). Is that a separate >>> document or do I add that as an Appendix? >> >> >> ... >> >> Hope this helps, >> >> ~gwz >> >> "They that can give up essential liberty to obtain a little >> temporary safety deserve neither..." >> -- Benjamin Franklin, 1759 >> >> "It is forbidden to kill; therefore all murderers are >> punished unless they kill in large numbers and to the sound of >> trumpets." >> -- Voltaire Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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, 11 Sep 2003 18:00:00 +0000 Date: Thu, 11 Sep 2003 10:27:09 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'gwz@cisco.com'" , "'Randy Bush'" , "'radius list'" Subject: RE: minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > You can assign Session-Timeout a portion of X but then the NAS would boot > the user off. Terminate-Action is not usable since it is sent after the NAS > kicks the user off. > > If the Value is set to RADIUS-Request, upon termination of the > specified service the NAS MAY send a new Access-Request to the > RADIUS server, including the State attribute if any." > > > In WLAN its different. How is it different? The above paragraph in RFC 2865 refers to re-authentication. > In other words, it appears that in WLAN there is a reauthentication > mechanism that we can use to get another quota. This is just the mechanism described in RFC 2865. > If what is meant by simple prepaid solution is a solution that works with > existing deployements then this is not a simple prepaid solution that works > without changes. Actually, it sounds like you've just shown that a prepaid solution can be implemented based on RFC 2865 with no changes at all -- and no revenue leakage, without even requiring a dependency on RFC 3576. > Hope this clears things up. Actually, this makes things even more unclear. Not only does the prepaid draft invent a new RADIUS attribute format for "sub-attributes" but now it appears that it is also reinventing functionality already supported in RFC 2865. -- 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, 11 Sep 2003 17:42:06 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: "'gwz@cisco.com'" , 'Randy Bush' , 'radius list' Subject: RE: minneapolis Date: Thu, 11 Sep 2003 13:40:39 -0400 MIME-Version: 1.0 Content-Type: text/plain Assuming you use the Session-Timeout and Accounting Stops and Interims. Then the simplest example that demonstrates revenue leakage is: Subscriber's account starts with X. Subscriber logs in and gets Session-Timeout <- X. X is reserved. Interim messages are sent with reporting usage Y1,Y2 etc.. These are subtracted from X as the session continues. Then the user logs off and the client would have sent n Interim records and a Stop record. If the user re-connects immediately it is possible that only k of the Interim records and the Stop record has not yet been received. Therefore, since we favour the customer (we need to let him in). We will set the Serssion-Timeout to X - k*Y. Thus there would be a possibility of a revenue leakage of the time reported in(n-k)+Stop. Typically interim period would be set to 5 minutes so its likely that we would leak 5 minutes. Not that this leakage would only be realized if the subscriber utilized all of the time alloted in the second session. This is because eventhough the stop record arrives late, we will debit the subscriber account. The case where there are multiple service instances is prone to leakage (as above) but presents other issues. When you have multiple services going against a single account we usually do this by allocating a portion of the account to each service instance (we call that a quota). There is no mechanism in general RADIUS (prior to CHIBA) to replenish the quota. You can assign Session-Timeout a portion of X but then the NAS would boot the user off. Terminate-Action is not usable since it is sent after the NAS kicks the user off. If the Value is set to RADIUS-Request, upon termination of the specified service the NAS MAY send a new Access-Request to the RADIUS server, including the State attribute if any." In WLAN its different. Farid and I are discussing this issue right now. As Farid points out: >From RFC 3580: " When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re- authentication. In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X." In other words, it appears that in WLAN there is a reauthentication mechanism that we can use to get another quota. If what is meant by simple prepaid solution is a solution that works with existing deployements then this is not a simple prepaid solution that works without changes. It requires compliancy to 3580. The prepaid solution we are writing requires compliancy to TBD. Hope this clears things up. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, September 11, 2003 12:03 PM > To: Avi Lior > Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list' > Subject: RE: minneapolis > > > > It is possible to do pre-paid w/o new attributes but there > is no way > > to do it without revenue leakage. It maybe possible to > minimize the > > leakage in certain circumstances (for example WLAN). > > Can you explain this further? If the user has a credit of X > minutes, then returning a RADIUS Access-Accept with > Session-Timeout of X minutes should not result in revenue > leakage. Or are we assuming that the user could be doing > other things at the same time (e.g. multiple simultaneous > connections) so that their credit could expire before then? > -- 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, 11 Sep 2003 16:35:56 +0000 Date: Thu, 11 Sep 2003 09:03:18 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'gwz@cisco.com'" , "'Randy Bush'" , "'radius list'" Subject: RE: minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It is possible to do pre-paid w/o new attributes but there is no way to do > it without revenue leakage. It maybe possible to minimize the leakage in > certain circumstances (for example WLAN). Can you explain this further? If the user has a credit of X minutes, then returning a RADIUS Access-Accept with Session-Timeout of X minutes should not result in revenue leakage. Or are we assuming that the user could be doing other things at the same time (e.g. multiple simultaneous connections) so that their credit could expire before then? -- 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, 11 Sep 2003 16:32:32 +0000 Date: Thu, 11 Sep 2003 08:59:37 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: "'Avi Lior'" , "'Randy Bush'" , "'radius list'" Subject: RE: minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Question: if it is possible to do pre-paid w/o new attributes & w/o > rewriting RADIUS, what's the point of the rest when Diameter is > certainly capable of supporting more complex pre-paid implementations. > IOW, if the desire is to document the 3GPP2 approach, this doesn't seem > to require a WG. There appears to be a need for pre-paid in applications such as WLAN in which RFC 3576 may not be implemented. So being able to do it without new attributes or requiring extensions makes sense, particularly if the new attributes can be implemented within existing RADIUS dictionaries. However if the "documented" approach is not backwards compatible with RFC 2865, then I'm not comfortable with having that work done outside the IETF. RADIUS is fragmented enough as it is without defining new dialects. -- 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, 11 Sep 2003 16:16:03 +0000 Message-ID: From: Avi Lior To: "'gwz@cisco.com'" , Avi Lior Cc: 'Randy Bush' , 'radius list' Subject: RE: minneapolis Date: Thu, 11 Sep 2003 12:15:03 -0400 MIME-Version: 1.0 Content-Type: text/plain > Hope this helps, Not really. > Question: if it is possible to do pre-paid w/o new attributes > & w/o rewriting RADIUS, what's the point of the rest when > IOW, if the desire is to document > the 3GPP2 approach, this doesn't seem to require a WG. It is possible to do pre-paid w/o new attributes but there is no way to do it without revenue leakage. It maybe possible to minimize the leakage in certain circumstances (for example WLAN). > Diameter is certainly capable of supporting more complex > pre-paid implementations. Aside, there is nothing in Diameter that makes it more capable then RADIUS when it comes to prepaid. What makes it more capable? Other people want to do prepaid and they don't want Diameter. I think there are many good reasons for having a WG. The least of which is a place where people can review the documents. Putting it in the same light as your comment. If 3GPP is the only SDO who want Diameter why do we have to have an IETF AAA-WG for it? Let them do the work there. > -----Original Message----- > From: Glen Zorn [mailto:gwz@cisco.com] > Sent: Thursday, September 11, 2003 11:57 AM > To: 'Avi Lior' > Cc: 'Randy Bush'; 'radius list' > Subject: RE: minneapolis > > > Avi Lior writes: > > ... > > > Regarding prepaid, I have received several email with > comments and am > > working on the next version of the draft. I have certain issues to > > resolve all of which pertain to incoming suggestions and > how to keep > > this document aligned with what 3GPP2 has done. I just need some > > advice. > > > > - Someone wants a description of how do to simple pre-paid > which will > > work with the lowest common denominator RADIUS deployments (ie., no > > CHIBA, no new attributes etc). Is that a separate document or do I > > add that as an Appendix? > > > ... > > Hope this helps, > > ~gwz > > "They that can give up essential liberty to obtain a little > temporary safety deserve neither..." > -- Benjamin Franklin, 1759 > > "It is forbidden to kill; therefore all murderers are > punished unless they kill in large numbers and to the sound > of trumpets." > -- Voltaire > > -- 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, 11 Sep 2003 15:57:24 +0000 Reply-To: From: "Glen Zorn" To: "'Avi Lior'" Cc: "'Randy Bush'" , "'radius list'" Subject: RE: minneapolis Date: Thu, 11 Sep 2003 08:56:35 -0700 Organization: Cisco Systems Message-ID: <007b01c3787d$5b7b05a0$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Avi Lior writes: ... > Regarding prepaid, I have received several email with comments and am > working on the next version of the draft. I have certain issues to > resolve all of which pertain to incoming suggestions and how to keep > this document aligned with what 3GPP2 has done. I just need some > advice. > > - Someone wants a description of how do to simple pre-paid which will > work with the lowest common denominator RADIUS deployments (ie., no > CHIBA, no new attributes etc). Is that a separate document or do I > add that as an Appendix? Question: if it is possible to do pre-paid w/o new attributes & w/o rewriting RADIUS, what's the point of the rest when Diameter is certainly capable of supporting more complex pre-paid implementations. IOW, if the desire is to document the 3GPP2 approach, this doesn't seem to require a WG. ... Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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, 11 Sep 2003 15:49:14 +0000 Reply-To: From: "Glen Zorn" To: "'Wijnen, Bert \(Bert\)'" , Cc: Subject: RE: Potential MIB work? Date: Thu, 11 Sep 2003 08:48:01 -0700 Organization: Cisco Systems Message-ID: <007a01c3787c$26ca8430$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit owner-radiusext@ops.ietf.org writes: >> From draft-ietf-v6ops-ipv4survey-ops-02.txt: > > 7.3.20 RADIUS MIB (RFC 2618) > > The problems have not been addressed and a new MIB should be > defined. > > > 7.3.21 RADIUS Authentication Server MIB (RFC 2619) > > The problems have not been addressed and a new MIB should be > defined. > > There is more detail in the survey document itself. > > So if a RADIUSEXT WG is formed, do we want to at least evaluate these? Seems reasonable, although I think that the technical changes needed are pretty minimal, with the busywork factor high ;-( > > Thanks, > Bert ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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, 10 Sep 2003 15:11:08 +0000 Message-ID: From: Avi Lior To: 'Randy Bush' , 'radius list' Subject: RE: minneapolis Date: Wed, 10 Sep 2003 11:10:21 -0400 MIME-Version: 1.0 Content-Type: text/plain Randy, I agree we should get together in MN. I am very aware and committed to the schedule Bernard put out for these items. I have received comments mainly directly (not posted here). Here are some details: Regarding prepaid, I have received several email with comments and am working on the next version of the draft. I have certain issues to resolve all of which pertain to incoming suggestions and how to keep this document aligned with what 3GPP2 has done. I just need some advice. - Someone wants a description of how do to simple pre-paid which will work with the lowest common denominator RADIUS deployments (ie., no CHIBA, no new attributes etc). Is that a separate document or do I add that as an Appendix? - Someone wants to align this document with Diameter Credit Control -- which is great. I have received extensive comments from these individuals. We (the authors) have to decide whether this is a proper route for us to take. Regarding RADIUS reliablility etc... I have received comments from Glen (on this list) and others and will incorporate these comments so we can move this forward. Regarding RADIUS attribute extension. This was discussed in this group. I still think its needed and I will submit the draft to the RFC editor. If we pick it up then so be it. At least it will be out there... > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Tuesday, September 09, 2003 6:47 PM > To: radius list > Subject: minneapolis > > > > > i have not seen a lot of work on the documents. as early > reviews have show, the three we have need *serious* work, if > not radical surgery. > > i suggest that this gang meet in an open bof in msp, as > we did not have one in wie. if there is serious work on > the documents, and serious review of that work, then we > can discuss a path forward, charter, ... > > but, if there are no real workers, there is no sense > talking about what path, charter, ... no one should take. > > randy > > > -- > 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, 09 Sep 2003 22:48:26 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 9 Sep 2003 15:47:27 -0700 To: radius list Subject: minneapolis Message-Id: i have not seen a lot of work on the documents. as early reviews have show, the three we have need *serious* work, if not radical surgery. i suggest that this gang meet in an open bof in msp, as we did not have one in wie. if there is serious work on the documents, and serious review of that work, then we can discuss a path forward, charter, ... but, if there are no real workers, there is no sense talking about what path, charter, ... no one should take. randy -- 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 Sep 2003 13:54:34 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502582091@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'radiusext@ops.ietf.org'" Cc: v6ops@ops.ietf.org Subject: Potential MIB work? Date: Mon, 1 Sep 2003 15:53:04 +0200 MIME-Version: 1.0 Content-Type: text/plain >From draft-ietf-v6ops-ipv4survey-ops-02.txt: 7.3.20 RADIUS MIB (RFC 2618) The problems have not been addressed and a new MIB should be defined. 7.3.21 RADIUS Authentication Server MIB (RFC 2619) The problems have not been addressed and a new MIB should be defined. There is more detail in the survey document itself. So if a RADIUSEXT WG is formed, do we want to at least evaluate these? Thanks, Bert -- 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: