Subject: RE: RADIUS BOF agenda
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Date: Tue, 30 Sep 2003 13:44:57 -0700

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, September 30, 2003 12:36 AM
To: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 30 Sep 2003 20:20:32 +0000
From: "Liess, Laura" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: AW: RADIUS BOF agenda 
Date: Tue, 30 Sep 2003 22:19:43 +0200

>> 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 [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 30 Sep 2003 16:45:55 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS BOF agenda 
Date: Tue, 30 Sep 2003 12:45:26 -0400
Message-Id: <[email-masked]>

Randy Bush <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 30 Sep 2003 16:18:49 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS BOF agenda 
Date: Tue, 30 Sep 2003 12:16:55 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 30 Sep 2003 16:10:07 +0000
From: Randy Bush <[email-masked]>
Date: Tue, 30 Sep 2003 09:09:07 -0700
To: "Alan DeKok" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS BOF agenda 

>> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 30 Sep 2003 16:03:18 +0000
Date: Tue, 30 Sep 2003 08:28:11 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: RADIUS BOF agenda 

>   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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 30 Sep 2003 15:59:05 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS BOF agenda 
Date: Tue, 30 Sep 2003 11:58:46 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 30 Sep 2003 15:09:38 +0000
Date: Tue, 30 Sep 2003 07:33:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Call for Agenda items

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 30 Sep 2003 08:11:13 +0000
Date: Tue, 30 Sep 2003 00:36:01 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
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-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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 26 Sep 2003 15:18:48 +0000
From: Avi Lior <[email-masked]>
To: 'Randy Bush' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Approval for RADIUS extension working group
Date: Fri, 26 Sep 2003 11:18:11 -0400

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:[email-masked]] 
> Sent: Friday, September 26, 2003 10:46 AM
> To: Avi Lior
> Cc: [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 26 Sep 2003 14:46:11 +0000
From: Randy Bush <[email-masked]>
Date: Fri, 26 Sep 2003 07:46:04 -0700
To: Avi Lior <[email-masked]>
Cc: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 26 Sep 2003 14:41:44 +0000
From: Avi Lior <[email-masked]>
To: 'Randy Bush' <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Approval for RADIUS extension working group
Date: Fri, 26 Sep 2003 10:40:44 -0400

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:[email-masked]] 
> Sent: Wednesday, September 24, 2003 5:06 PM
> To: Bernard Aboba
> Cc: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Sep 2003 23:55:46 +0000
From: Randy Bush <[email-masked]>
Date: Wed, 24 Sep 2003 14:05:33 -0700
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Sep 2003 16:36:51 +0000
Date: Wed, 24 Sep 2003 09:02:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Approval for RADIUS extension working group

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Sep 2003 16:22:18 +0000
Content-Class: urn:content-classes:message
Subject: RE: Approval for RADIUS extension working group
Date: Wed, 24 Sep 2003 09:19:57 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

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

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Monday, September 22, 2003 3:58 PM
To: [email-masked]'
Subject: Approval for RADIUS extension working group

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

 

------_=_NextPart_001_01C382B7.B24F9B2F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>Message</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I haven&#8217;t seen any responses to this
mail. &nbsp;I am hoping that we hear something from Bernard, Randy, or David N
on this.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>BR,</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Farid</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> [email-masked]
[mailto:[email-masked]] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Avi Lior<br>
<b><span style='font-weight:bold'>Sent:</span></b> Monday, September 22, 2003
3:58 PM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]'<br>
<b><span style='font-weight:bold'>Subject:</span></b> Approval for RADIUS
extension working group</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Arial><span
style='font-size:10.0pt;font-family:Arial'>What are the hurdles that keep us
from having a RADIUS Extension WG?</span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C382B7.B24F9B2F--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Sep 2003 22:58:40 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Approval for RADIUS extension working group
Date: Mon, 22 Sep 2003 18:57:30 -0400

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class8565222-22092003>What are the hurdles 
that keep us from having a RADIUS Extension WG?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class8565222-22092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class8565222-22092003></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3815C.E6CFAC90--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Sep 2003 20:44:09 +0000
Date: Fri, 12 Sep 2003 13:42:36 -0700
To: Avi Lior <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, Avi Lior <[email-masked]>
From: Richard Perlman <[email-masked]>
Subject: RE: minneapolis
Cc: "[email-masked]'" <[email-masked]>, "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>

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:[email-masked]]
> > Sent: Thursday, September 11, 2003 5:50 PM
> > To: Avi Lior
> > Cc: [email-masked]'; '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Þfault.  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 [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Sep 2003 20:22:52 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, 'Randy Bush' <[email-masked]>,  'radius list' <[email-masked]>
Subject: RE: minneapolis
Date: Fri, 12 Sep 2003 16:21:56 -0400

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:[email-masked]] 
> Sent: Thursday, September 11, 2003 5:50 PM
> To: Avi Lior
> Cc: [email-masked]'; '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Þfault.  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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Sep 2003 18:53:34 +0000
Date: Fri, 12 Sep 2003 11:50:51 -0700
To: <[email-masked]>, "'Avi Lior'" <[email-masked]>
From: Richard Perlman <[email-masked]>
Subject: RE: minneapolis
Cc: "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Sep 2003 17:18:34 +0000
Date: Fri, 12 Sep 2003 09:45:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Lortz, Victor" <[email-masked]>
cc: radius list <[email-masked]>, =?iso-8859-1?Q?Raquel_Rodríguez?= <[email-masked]>
Subject: RE: minneapolis

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Sep 2003 16:20:11 +0000
Content-Class: urn:content-classes:message
Subject: RE: minneapolis
Date: Fri, 12 Sep 2003 09:19:19 -0700
From: "Lortz, Victor" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "radius list" <[email-masked]>
Cc: =?iso-8859-1?Q?Raquel_Rodríguez?= <[email-masked]>

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:[email-masked]] 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Sep 2003 14:58:48 +0000
Date: Fri, 12 Sep 2003 07:24:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
cc: "'radius list'" <[email-masked]>
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 22:22:31 +0000
Date: Thu, 11 Sep 2003 14:49:50 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>
Subject: RE: minneapolis

> 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Þfault.  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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 21:57:41 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, 'Randy Bush' <[email-masked]>,  'radius list' <[email-masked]>
Subject: RE: minneapolis
Date: Thu, 11 Sep 2003 17:56:39 -0400

See inline.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, September 11, 2003 1:27 PM
> To: Avi Lior
> Cc: [email-masked]'; '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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 18:45:06 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>
Subject: RE: minneapolis
Date: Thu, 11 Sep 2003 11:44:00 -0700
Organization: Cisco Systems

Avi Lior <mailto:[email-masked]> 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:[email-masked]]
>> Sent: Thursday, September 11, 2003 11:57 AM
>> To: 'Avi Lior'
>> Cc: 'Randy Bush'; 'radius list'
>> Subject: RE: minneapolis
>> 
>> 
>> Avi Lior <mailto:[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 18:00:00 +0000
Date: Thu, 11 Sep 2003 10:27:09 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>
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.

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 17:42:06 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, 'Randy Bush' <[email-masked]>,  'radius list' <[email-masked]>
Subject: RE: minneapolis
Date: Thu, 11 Sep 2003 13:40:39 -0400

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:[email-masked]] 
> Sent: Thursday, September 11, 2003 12:03 PM
> To: Avi Lior
> Cc: [email-masked]'; '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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 16:35:56 +0000
Date: Thu, 11 Sep 2003 09:03:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 16:32:32 +0000
Date: Thu, 11 Sep 2003 08:59:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
cc: "'Avi Lior'" <[email-masked]>, "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>
Subject: RE: minneapolis

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 16:16:03 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: 'Randy Bush' <[email-masked]>, 'radius list' <[email-masked]>
Subject: RE: minneapolis
Date: Thu, 11 Sep 2003 12:15:03 -0400

> 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:[email-masked]] 
> Sent: Thursday, September 11, 2003 11:57 AM
> To: 'Avi Lior'
> Cc: 'Randy Bush'; 'radius list'
> Subject: RE: minneapolis
> 
> 
> Avi Lior <mailto:[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 15:57:24 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "'radius list'" <[email-masked]>
Subject: RE: minneapolis
Date: Thu, 11 Sep 2003 08:56:35 -0700
Organization: Cisco Systems

Avi Lior <mailto:[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 11 Sep 2003 15:49:14 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Potential MIB work?
Date: Thu, 11 Sep 2003 08:48:01 -0700
Organization: Cisco Systems

[email-masked] <mailto:[email-masked]>
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 10 Sep 2003 15:11:08 +0000
From: Avi Lior <[email-masked]>
To: 'Randy Bush' <[email-masked]>, 'radius list' <[email-masked]>
Subject: RE: minneapolis
Date: Wed, 10 Sep 2003 11:10:21 -0400

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:[email-masked]] 
> Sent: Tuesday, September 09, 2003 6:47 PM
> To: radius list
> Subject: minneapolis
> 
> 
> <ad-hat>
> 
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 09 Sep 2003 22:48:26 +0000
From: Randy Bush <[email-masked]>
Date: Tue, 9 Sep 2003 15:47:27 -0700
To: radius list <[email-masked]> 
Subject: minneapolis

<ad-hat>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Sep 2003 13:54:34 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: Potential MIB work?
Date: Mon, 1 Sep 2003 15:53:04 +0200 

>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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>