Subject: (radius) documents wedge over track confusion

From: Randy Bush <[email-masked]>
Date: Thu, 16 Dec 1999 11:45:34 -0800

some documents have wedged at the iesg.  essentially we became confused
which track they were or should be on.

the confusion seems to be that some of the documents seem to specify
protocol, use words like MUST etc., but have been called as informational.
bernard tells me that this is because they rely on rfc2139 which is
informational, and was so classified because the specified transport was
feared not to be sufficiently reliable.

an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended
to replace 2139, and if it solves 2139's problems sufficiently to be
standards track and therefore clear the logjam.

i will append my notes as of last eve.

randy

  o RADIUS Extensions [Informational]
	<draft-ietf-radius-ext-05.txt> 

relies on 2139 which is infomational.

but this one might be experimental because

This memo suggests several additional Attributes that can be added to
RADIUS to perform various useful functions.  These Attributes do not
have extensive field experience yet and should therefore be
considered experimental.

but wg chair asked for info.

  o Implementation of L2TP Compulsory Tunneling via RADIUS
    [Informational]
	<draft-ietf-radius-tunnel-imp-05.txt>

should be proposed standard, because it specifies protocol, uses MUST, etc.,
but was requested as informational.  it says:

This document discusses implementation issues arising in the
provisioning of compulsory tunneling in dial-up networks using the L2TP
protocol.  This provisioning can be accomplished via the integration of
RADIUS and tunneling protocols. Implementation issues encountered with
other tunneling protocols are left to separate documents.

  o RADIUS Accounting Modifications for Tunnel Protocol
    Support [Informational]
	<draft-ietf-radius-tunnel-acct-05.txt>

relies on 2139 which is infomational, and i was told to ask as info and it
sez info on the draft.  but it looks like it specifies protocol.

  o RADIUS Accounting [Informational]
	<draft-ietf-radius-accounting-v2-02.txt>
    Note: Requires draft-ietf-radius-tunnel-auth

relies on 2139 so should be informational.  but it looks like a proposed
standard, though the wg chair asked for informational.  it says:

This document describes a protocol for carrying accounting information
between a Network Access Server and a shared Accounting Server.

-30-
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 16 Dec 1999 15:36:41 -0800

I think they should all be standards track. Both Radius and Radius 
accounting should be draft standard and the others should be proposed standard.

I recall that the reason Radius accounting was made Informational was that 
previous AD's were very much concerned with the risks associated with 
billing systems relying on this RFC. But time has shown that a great many 
ISP's serving tens of millions of users are happily using RFC 2139 today. 
It has achieved widespread interoperability as well.

I expect some will disagree and point at wording problems and/or threat 
theories, but reality should be our guide here. Both protocols are 
essentially at the same state as some other Full Standard protocols in 
terms of implementation and utilizations.

Let's not quibble over political or publishing issues. Radius is what it is 
and nothing we do or the IESG does can change how it is used today. The 
alternative is that we have a delta between what the IETF publishes and 
what happens on the real Internet. That is not a good thing.

-

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 16 Dec 1999 15:50:31 -0800

Oops I missed the Radius extensions draft. I agree that should be Experimental.

At 03:36 PM 12/16/99 -0800, Matt Holdrege wrote:
>Let's not quibble over political or publishing issues. Radius is what it 
>is and nothing we do or the IESG does can change how it is used today. The 

-

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Dec 1999 15:56:09 -0800

it would sure be nice to have users, as opposed to vendors, telling us how
happy the users are.

and a statement such as

> I expect some will disagree and point at ... threat theories, but reality
> should be our guide here.

is a very convincing argument.  but i suspect you might not like that for
which it convinces me and at least some other folk responsible for large
networks.  the network has *very* serious security problems, and they are
not on the wane.

we are trying to manage some drafts through the process.  this should be
done with prudence and as much technical excellence as we can muster.

randy
-

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 16 Dec 1999 17:07:06 -0800

>networks.  the network has *very* serious security problems, and they are

Sorry my statements were strong, but it's based on years of discussion on 
this topic. I guess I meant "happy with Radius" in that it works reasonably 
well. Especially in comparison with a lot of other things an ISP has to 
deal with.

RADIUS is not perfect, but we WERE NOT ALLOWED to continue working on it or 
any successor to help make things better. So we are stuck with what we 
have. That's why I said RADIUS is what it is and we should document it so.

As for securing messages, we all have access to IPsec now, right? IPsec may 
not be integrated into today's products as much as we would prefer, but it 
can be done.

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 16 Dec 1999 21:48:24 -0800

draft-ietf-radius-accounting-v2-02.txt is indeed intended to
replace RFC 2139. However, I do not believe that it addresses
the issues which caused RFC 2139 to be classified as
informational. Mike O'Dell is probably best qualified to
articulate the reasoning behind the original classification.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Randy Bush
Sent: Thursday, December 16, 1999 11:46 AM
To: [email-masked]
Subject: (radius) documents wedge over track confusion

randy

-30-
-

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 16 Dec 1999 23:46:08 -0800

>billing systems relying on this RFC.

Not sure what is meant by "risks" here. There are security risks (which
were also present with other accounting methods of the time, such as
SNMP v2c) and there are financial risks (e.g. due to packet loss).
I went back through the RADIUS mailing list archives, and could not
find any messages that articulate the reasons for the IESG decision.

>But time has shown that a great many ISP's serving tens of millions
>of users are happily using RFC 2139 today.

Time has shown that RFC 2139 is adequate for capacity planning
as well as accounting in non-usage sensitive billing situations which
comprise the bulk of today's dialup business. This does not necessarily
mean that RFC 2139 is applicable to usage-sensitive billing scenarios where
packet loss = revenue loss and a high degree of reliability is required.

>The alternative is that we have a delta between what the IETF publishes and

There are widely deployed, interoperable protocols that are not IETF
standards. I'm not sure that is bad per se, as long as there is good
technical justification for the distinction.

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Mon, 20 Dec 1999 07:49:35 -0500 (EST)

> it would sure be nice to have users, as opposed to vendors, telling us how

OK, I'm a user.  (Large New England regional ISP).

We use radius accounting for our billing usage feed.  We bill based on
time online for each user.  We have very little packet loss, and find that
it works consistently and reliably with every vendor hardware we have
used.

We have some disappointments with its limitaions [1], but overall I really
think it ought to be a standard, and not just informational.

Note: [1] The most serious limitations from our perspective are that
deployed radius accounting implementations we use do not implement interim
updates and Acct-Giga*.  We have to build vendor-specific workarounds
for the former and just not have traffic-sensitive billing for the latter.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net: Local Ties... World Class Connections

Like a bird that strays from its nest is a man who strays from his home.

-