Subject: (radius) comment on draft-ietf-radius-tunnel-acct-02.txt

From: Stuart A Barkley <[email-masked]>
Date: Fri, 15 Jan 1999 19:05:31 -0500 (EST)

Some comments on the tunneling drafts inspired by todays other
comments to the list.  I haven't given these drafts as much attention
as they deserve or as I would like.

draft-ietf-radius-tunnel-acct-02.txt says in part:

> Network Working Group                                            G. Zorn
> Internet-Draft                                     Microsoft Corporation
> Updates: RFC 2139                                              D. Mitton
> Category: Informational                                     Bay Networks
> <draft-ietf-radius-tunnel-acct-02.txt>                    September 1998

Note that draft-ietf-radius-tunnel-acct-02.txt is a draft for an
informational RFC.  The other related related draft RFCs are stated to
be Standards Track and it could be incorrectly inferred that
implementing the other RFCs requires also implementing this one. 
Radius Accounting was published as an information RFC nominally
documenting existing practise.  However, this status has been widely
misunderstood with people thinking that there is a radius accounting
standard. 

> 3.  Motivation
> 
> Many applications of tunneling protocols such as PPTP and  L2TP  involve
> dial-up network access.  Some, such as the provision of secure access to
> corporate intranets via the Internet,  are  characterized  by  voluntary
> tunneling:  the  tunnel is created at the request of the user for a spe-
> cific purpose.  Other applications  involve  compulsory  tunneling:  the
> tunnel  is created without any action from the user and without allowing
> the user any choice in the matter.  Examples of applications that  might
> be  implemented  using  compulsory tunnels are Internet software upgrade
> servers, software registration servers and banking services.

This same text also appears in -auth-06 and imp-04.  The text in
imp-04 is a little more readable there since it is broken into smaller
paragraphs. 

> These  are
> all services which, without compulsory tunneling, would probably be pro-
> vided using dedicated networks or  at  least  dedicated  network  access
> servers  (NAS),  since  they are characterized by the need to limit user
> access to specific hosts.

I question this last statement.  Compulsory tunneling is not required
for these functions and should not be implied as required for these
functions.

> Given the existence of widespread support for
> compulsory tunneling, however, these types of services could be accessed
> via any Internet service provider (ISP).  Typically,  ISPs  providing  a
> service  want  to collect data regarding that service, for billing, net-
> work planning, etc.

> The most popular way to collect usage data in dial-
> up  networks today is by means of RADIUS  Accounting.  The use of RADIUS
> Accounting allows dial-up usage data to be collected at a central  loca-
> tion,  rather  than  stored  on  each NAS.  It makes sense to use RADIUS
> Accounting to collect  usage  data  regarding  tunneling,  since  RADIUS
> Accounting  has  been  widely implemented and was designed to carry this
> type of information.

I have major problems with this section. 

As noted above this is only an "Informational" RFC and so has no true
authoritative status.  People can chose to implement what they want. 
However, I don't like having such strong words encouraging support for
radius accounting.  It certainly is not used by at least one major
ISP.  The only reason it is popular is that we continue to allow
confusing words like those above to be said about radius accounting.

Its true radius accounting was designed to carry this information,
however it is also true that as a transport mechanism it doesn't work
in large scale networks and that the data transported according to the
RFC is incomplete. 

> In order to provide this functionality, new RADIUS
> attributes are needed to aid in the collation of tunnel usage data; this
> document defines these attributes.  In addition, several new values  for
> the  Acct-Status-Type  attribute are proposed.  Specific recommendations
> for, and examples of, the application of this attribute for the L2TP and
> PPTP protocols can be found in draft-ietf-radius-tunnel-imp-XX.txt.
> [...]
> 5.  New Acct-Status-Type Values

This section then goes on to describe several new Acct-Status-Type
values which can be sent inside the radius transport.  I already have
concerns with the existing radius accounting data model and these new
Acct-Status-Type values continue a bad trend in system design.  The
accounting data transported inside the protocol needs to be complete
in each accounting request and should be consistent between accounting
requests.  In order for these tunneling requests to be useful you need
good assurance that all of the data gets to the accounting system.  If
accounting requests get lost somewhere you are left with a fairly
incomplete mess. 

These requests need to have interim accounting support and both the
interim and final requests should contain all required information. 

Timestamps are required inside the data separate from any transport
protocol.  Tunnel-Stop and Tunnel-Link-Stop should have distinct
timestamps for all interesting times (at least the Start and End
times).  As a practical requirement outside the radius protocol family
the NAS should have a well controlled clock from which to obtain
timestamp information if either accurate logs or actual revenue
invoicing are going to be derived from this data stream.
-- 
Stuart A Barkley                        email: [email-masked]

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

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Jan 1999 17:39:23 -0800

>as they deserve or as I would like.

At least you didn't wait unitl _after_ last call...

>implementing the other RFCs requires also implementing this one.

Only by people that don't understand the term "Informational"; the lack of
dependency is precisely why there is more than one document.

>misunderstood with people thinking that there is a radius accounting

Presumably, the same people who would make the 'incorrect inference'
mentioned above.  I don't know what more could be done about this. Every
Informational RFC contains as its first paragraph the folowing:

    Status of this Memo

       This memo provides information for the Internet community.  It does
       not specify an Internet standard of any kind.  Distribution of this
       memo is unlimited.

How much clearer can it get?  There is a reason, I think, for this behavior,
however.  People are desperate for an accounting standard; since RADIUS is
the only semi-reasonable approach we have provided, they grasp at the straw.
Note that I said "semi-reasonable"; I agree that RADIUS accounting is
seriously flawed.  However, the RADIUS WG was barred from even attempting to
fix it.

>for these functions and should not be implied as required for these

I can't see any implication of "requirement" there.  The sentence is merely
an observation of how most of these applications have been implemented in
the real-world, according to the authors.  It is certainly possible to
restrict network access through filters.  In a network that contains more
than one type (or even version of the same type) or NAS, filtering doesn't
scale, however.  Allow me to note that the first two example applications
probably do not require that tunneled traffic be encrypted to be useful.

>> Accounting  has  been  widely implemented and was designed to carry this

Note that the quoted section is from <draft-ietf-radius-tunnel-acct-02.txt>.

>ISP.

UUNET?

>The only reason it is popular is that we continue to allow

So all the netops who use RADIUS accounting are innocent victims of IETF
brainwashing who've been led down the primrose path?   Considering the many
ISPs that still support PAP years after it was officially renounced by the
IETF (just for one example), I find it difficult to beleive that they are
quite that easy to sway.  In fact, if I were an ISP, I think that I would be
extremely insulted by the patronizing tone of this steatement.  In any case,
the _real_ reason RADIUS accounting is popular is that there is _no_
alternative (other than turning your NASs into SNMP processors instead of
access servers).

>in large scale networks and that the data transported according to the

This incompleteness, of course, is a good reason to kill efforts to complete
it...

>accounting requests get lost somewhere you are left with a fairly

So is it the new attributes you don't like or the fact that they are carried
over RADIUS?  I'm confused...

>invoicing are going to be derived from this data stream.

We are not talking about things that should happen outside RADIUS - this is
the RADIUS WG.  If you require an accurate, wall-clock-time clock in the
NASs you buy, that's fine, but (as has been pointed out many times on this
list) the provision of such clocks is not universal in NASs and we cannot
assume their presence.

---

From: "Russell J. LeBar" <[email-masked]>
Date: Mon, 18 Jan 1999 09:56:19 -0600

This reminds me of a phrase:

"In theory there is no difference between theory and practice. In practice
there is"

In theory, rfc2139 is not a standard. In practice it is.

-