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

From: Stuart A Barkley <[email-masked]>
Date: Thu, 21 Jan 1999 19:31:16 -0500 (EST)

I have still not been able to give these drafts complete attention,
but I have a few comments on draft-ietf-radius-tunnel-acct-02.txt.
There are a few minor comments of the other drafts, but unless
otherwise mentioned these apply to -acct-02.

Section 3 "Motivation" of -acct-02 and -auth-06 consists of one large
paragraph.  Section 6 "Introduction" of -imp-04 breaks similar text up
into three paragraphs which are more easily digestible. 

Section 5 of -acct-02 defines several new Acct-Status-Type values for
the Accounting-Request packet.  These packets are sent upon various
events of the system.  Because it is possible for the accounting
request to be lost or significantly delayed we should have provision
for interim accounting packets.  These interim packets should contain
enough information in a single packet so that usage can be as fully
reported as possible (lost Stop packets would cause information to
only be accurate up to the last interim packet). 

My preference would be that the start packets have a start timestamp,
interim packets have the start and current timestamp and the stop
packets have a start and stop timestamp.  By using timestamps instead
of just having something like Acct-Session-Time you leave open the
possibility of adding additional timestamps for other points of
interest in the session (e.q. when was the Tunnel requested vs when
did the Tunnel actually come up for data transfer or both timestamps
when dual authentication is performed).  We use this type of data both
for invoicing users and for network operational statistics.  By having
a series of timestamps for significant points in the state diagram for
the process we are able to compute what ever delta time metric we need
instead of relying upon only a single elapsed time value.

Whether the timestamp has any external meaning is a separate issues
which has been discussed before, but these should be in well defined
units.  Once a timestamp is determined for a particular attribute it
should be constant for every accounting packet for a particular
Tunnel.

Also by putting timestamps in the packets we can eliminate the need to
Acct-Delay-Time (although that can be very helpful when attempting to
normalize the NAS timestamps to real world time). 

Section 5 of -acct-02 defines several new Acct-Status-Type values for
the Accounting-Request packet and section 6 defines several new
attributes including Acct-Tunnel-Connection.  What is the relationship
to Acct-Session-Id already defined for radius accounting?  Can this
tunnel be contained inside a PPP session which has been already
reported by radius accounting?  Can multiple Tunnels and Tunnel-Links
exist inside a single PPP session sequentially or simultaneously? 

Should these tunnel accounting requests always contain the
Acct-Session-Id of the containing PPP session?

My concern here is that when accounting for "port connect time" you
really need to relate all of the contained sessions together so that
you don't double charge for simultaneous sessions on the same port. 

Its possible this is just another instance of where the radius
accounting model doesn't meet our specific needs, but I think others
would also find it useful to be able to relate these various tunnels
together.

Section 10 "UserID issues" or -imp-04 got me just thinking about the
routing of accounting packets from the NAS back to the home radius
server.  I don't see User-Name in and of the -acct-02 accounting
request packets.  How is a radius proxy server supposed to route these
packets?  I certainly have not studied this for more than 5 minutes
and perhaps it is covered somewhere I haven't noticed.

Spelling: My spell checker found a few things.  Are people generally
interested in these or does the RFC editor take care of these sorts of
things?  I doubt I found everything either, I rely heavily on spell
checkers (hopefully I won't accidently correct the following before
sending this message out). 

-acct-02: Acknowledgements should be Acknowledgments.
-auth-06: Acknowledgements should be Acknowledgments.
-imp-04: Advantanges should be Advantages.
-imp-04: accomodated should be accommodated.
-imp-04: Start-Control-Conection-Reply should be Start-Control-Connection-Reply.
-imp-04: implmentation should be implementation.
-imp-04: Acknowledgements should be Acknowledgments.

Stuart
-- 
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: Thu, 21 Jan 1999 17:13:40 -0800

> into three paragraphs which are more easily digestible.

OK

> only be accurate up to the last interim packet).

Interim accounting is discussed (slightly) in
http://www.ietf.org/internet-drafts/draft-ietf-radius-acct-interim-01.txt

> normalize the NAS timestamps to real world time).

There is an attribute called Event-Timestamp described in
draft-ietf-radius-ext-02 (expired and apparently removed from the IETF
site).  I like the idea of start, stop and interim timestamps; OTOH, I'm
tired of fighting for (new and) sensible RADIUS enhancements like that.  If
you are talking about timestamps incorporated in individual attributes,
that's going to be a _really_ tough row to hoe.  Good luck!

> reported by radius accounting?

Actually, the PPP session is contained inside the tunnel, but yes, I think
that you can account seperately for PPP and tunnel usage.  For example, in
the case where a user authenticates to a NAS which then starts a tunnel, the
usage of the NAS port is different than the tunnel usage.

>Can multiple Tunnels and Tunnel-Links

Multiple links can exist inside a tunnel simultaneously in L2TP, PPTP and
L2F.

> Acct-Session-Id of the containing PPP session?

The tunnel (or tunnel link) encapsulates PPP, not vice-versa, but yes,
Acct-Session-Id is required in every accounting request packet (RFC 2139).

> things?

Yes, I'm _very_ interested in spelling errors and other typos.  The RFC
Editor sometimes catches some them, but that's not really their job: it's
supposed to be a finished document when it reaches them.

>I doubt I found everything either, I rely heavily on spell

Thanks!

-

---

From: Stuart A Barkley <[email-masked]>
Date: Thu, 21 Jan 1999 21:30:42 -0500 (EST)

> http://www.ietf.org/internet-drafts/draft-ietf-radius-acct-interim-01.txt

Yes, but this defines a new Acct-Status-Type value.  What
Acct-Status-Type value does an interim Tunnel-Stop-ish accounting
request contain? 

> site).

Hmm, I only had draft-ietf-radius-ext-00.  I just found the latest in
ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ext-02.txt. 

> I like the idea of start, stop and interim timestamps; OTOH, I'm

Yes, my preference is several attributes so that the various
interesting metrics are available and so that interim and stop packets
will have complete information. 

And Yes, I expect that this won't fly but since we are doing a new
draft for this it is a possibility. 

I would like to see a good complete data model independent from the
transport so we have a basis for building other transports or even
file formats.  e.g. draft-ietf-roamops-actng-05.txt attempts to encode
radius attributes, but without supplementing the radius data with
external information (like receive time at the radius server) it isn't
complete enough information for our use.  Even if Event-Timestamp is
included there are complicated issues regarding computing constant
start times for sessions if you are feeding split records to other
downstream systems.

This is starting to drift from the real L2TP RADIUS drafts.

> Multiple links can exist inside a tunnel simultaneously in L2TP, PPTP and

So each of these tunnels should have a unique Acct-Session-Id?  That
sounds good and is probably implied when taken with RFC-2139. 

Would a tunnel with a single contained link and the PPP session use
the same Acct-Session-Id?

If there are multiple links in a tunnel are there multiple
Acct-Session-Ids assigned and can these be related to the containing
tunnel Acct-Session-Id?  I guess the links could all use the tunnel
Acct-Session-Id since the Tunnel- and Tunnel-Link- messages have other
attributes which uniquely identify them.  What would the multiple PPP
sessions use? 

> Acct-Session-Id is required in every accounting request packet (RFC 2139).

Should the table in section 7 of -acct-02 include this information? 
OTOH, RFC-2139 does say all accounting packets should have both
Acct-Status-Type and Acct-Session-Id so maybe this is okay. 

Thanks for the clarification,
Stuart
-- 
Stuart A Barkley                        email: [email-masked]

-

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 22 Jan 1999 12:11:24 -0800

> Acct-Status-Type value does an interim Tunnel-Stop-ish accounting

Tunnel-Stop (? guess I don't understand the question).  The intent is that
an accounting request be sent every time a "significant" tunnel-related
event occurs, but there is no reason why the tunnel attributes can't be sent
in interim accounting requests, too.

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ext-02.txt.

I had only looked at the Web site, from which it is missing (or I just can't
see it).

<text excised>

-