As per Relevance of the word included, we have this rfc below:











Network Working Group G.
Request for Comments: 2867 Cisco Systems, Inc
Category: Informational B.
Updates: 2866 Microsoft
D.
Nortel
June 2000


RADIUS Accounting Modifications for Tunnel Protocol

Status of this

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

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved



This document defines new RADIUS accounting Attributes and new
for the existing Acct-Status-Type Attribute [1] designed to
the provision of compulsory tunneling in dial-up networks

Specification of

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted
described in [2].

1.

Many applications of tunneling protocols such as PPTP [5] and L2
[4] involve dial-up network access. Some, such as the provision
secure access to corporate intranets via the Internet,
characterized by voluntary tunneling: the tunnel is created at
request of the user for a specific purpose. Other
involve compulsory tunneling: the tunnel is created without
action from the user and without allowing the user any choice in
matter, as a service of the Internet service provider (ISP).
Typically, ISPs providing a service want to collect data
that service for billing, network planning, etc. One way to
usage data in dial-up networks is by means of RADIUS Accounting [1].
The use of RADIUS Accounting allows dial-up usage data to
collected at a central location, rather than stored on each NAS



Zorn, et al. Informational [Page 1]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


In order to collect usage data regarding tunneling, new
attributes are needed; this document defines these attributes.
addition, several new values for the Acct-Status-Type attribute
proposed. Specific recommendations for, and examples of,
application of this attribute for the L2TP protocol can be found
RFC 2809.

2. Implementation

Compulsory tunneling may be part of a package of services provided
one entity to another. For example, a corporation might
with an ISP to provide remote intranet access to its employees
compulsory tunneling. In this case, the integration of RADIUS
tunnel protocols allows the ISP and the corporation to
their accounting activities so that each side receives a record
the user's resource consumption. This provides the corporation
the means to audit ISP bills

In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client
Endpoint and Tunnel-Server-Endpoint attributes are typically used
uniquely identify the call, allowing the Accounting-Request sent
the NAS to be reconciled with the corresponding Accounting-
sent by the tunnel server

When implementing RADIUS accounting for L2TP/PPTP tunneling,
Call-Serial-Number SHOULD be used in the Acct-Tunnel-
attribute. In L2TP, the Call-Serial-Number is a 32-bit field and
PPTP it is a 16-bit field. In PPTP the combination of IP Address
Call-Serial-Number SHOULD be unique, but this is not required.
addition, no method for determining the Call-Serial-Number
specified, which leaves open the possibility of wrapping after
reboot

Note that a 16-bit Call-Serial-Number is not sufficient
distinguish a given call from all other calls over an extended
period. For example, if the Call-Serial-Number is
monotonically, the NAS in question has 96 ports which are
busy and the average call is of 20 minutes duration, then a 16-
Call-Serial-Number will wrap within 65536/(96 * 3 calls/hour * 24
hours/day) = 9.48 days

3. New Acct-Status-Type

3.1. Tunnel-



9



Zorn, et al. Informational [Page 2]

RFC 2867 RADIUS Tunnel Accounting Support June 2000




This value MAY be used to mark the establishment of a
with another node. If this value is used, the
attributes SHOULD also be included in the Accounting-
packet

User-Name (1)
NAS-IP-Address (4)
Acct-Delay-Time (41)
Event-Timestamp (55)
Tunnel-Type (64)
Tunnel-Medium-Type (65)
Tunnel-Client-Endpoint (66)
Tunnel-Server-Endpoint (67)
Acct-Tunnel-Connection (68)

3.2. Tunnel-



10



This value MAY be used to mark the destruction of a tunnel
or from another node. If this value is used, the
attributes SHOULD also be included in the Accounting-
packet

User-Name (1)
NAS-IP-Address (4)
Acct-Delay-Time (41)
Acct-Input-Octets (42)
Acct-Output-Octets (43)
Acct-Session-Id (44)
Acct-Session-Time (46)
Acct-Input-Packets (47)
Acct-Output-Packets (48)
Acct-Terminate-Cause (49)
Acct-Multi-Session-Id (51)
Event-Timestamp (55)
Tunnel-Type (64)
Tunnel-Medium-Type (65)
Tunnel-Client-Endpoint (66)
Tunnel-Server-Endpoint (67)
Acct-Tunnel-Connection (68)
Acct-Tunnel-Packets-Lost (86)



Zorn, et al. Informational [Page 3]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


3.3. Tunnel-



11



This value MAY be used to mark the rejection of
establishment of a tunnel with another node. If this value
used, the following attributes SHOULD also be included in
Accounting-Request packet

User-Name (1)
NAS-IP-Address (4)
Acct-Delay-Time (41)
Acct-Terminate-Cause (49)
Event-Timestamp (55)
Tunnel-Type (64)
Tunnel-Medium-Type (65)
Tunnel-Client-Endpoint (66)
Tunnel-Server-Endpoint (67)
Acct-Tunnel-Connection (68)

3.4. Tunnel-Link-



12



This value MAY be used to mark the creation of a tunnel link
Only some tunnel types (e.g., L2TP) support multiple links
tunnel. This Attribute is intended to mark the creation of
link within a tunnel that carries multiple links. For example
if a mandatory tunnel were to carry M links over its lifetime
2(M+1) RADIUS Accounting messages might be sent: one
marking the initiation and destruction of the tunnel itself
one each for the initiation and destruction of each link
the tunnel. If only a single link can be carried in a
tunnel (e.g., IPsec in the tunnel mode), this Attribute
not be included in accounting packets, since the presence
the Tunnel-Start Attribute will imply the initiation of
(only possible) link






Zorn, et al. Informational [Page 4]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


If this value is used, the following attributes SHOULD also
included in the Accounting-Request packet

User-Name (1)
NAS-IP-Address (4)
NAS-Port (5)
Acct-Delay-Time (41)
Event-Timestamp (55)
Tunnel-Type (64)
Tunnel-Medium-Type (65)
Tunnel-Client-Endpoint (66)
Tunnel-Server-Endpoint (67)
Acct-Tunnel-Connection (68)

3.5. Tunnel-Link-



13



This value MAY be used to mark the destruction of a
link. Only some tunnel types (e.g., L2TP) support
links per tunnel. This Attribute is intended to mark
destruction of a link within a tunnel that carries
links. For example, if a mandatory tunnel were to carry
links over its lifetime, 2(M+1) RADIUS Accounting
might be sent: one each marking the initiation and
of the tunnel itself and one each for the initiation
destruction of each link within the tunnel. If only a
link can be carried in a given tunnel (e.g., IPsec in
tunnel mode), this Attribute need not be included in
packets, since the presence of the Tunnel-Stop Attribute
imply the termination of the (only possible) link

If this value is used, the following attributes SHOULD also
included in the Accounting-Request packet

User-Name (1)
NAS-IP-Address (4)
NAS-Port (5)
Acct-Delay-Time (41)
Acct-Input-Octets (42)
Acct-Output-Octets (43)
Acct-Session-Id (44)
Acct-Session-Time (46)
Acct-Input-Packets (47)



Zorn, et al. Informational [Page 5]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


Acct-Output-Packets (48)
Acct-Terminate-Cause (49)
Acct-Multi-Session-Id (51)
Event-Timestamp (55)
NAS-Port-Type (61)
Tunnel-Type (64)
Tunnel-Medium-Type (65)
Tunnel-Client-Endpoint (66)
Tunnel-Server-Endpoint (67)
Acct-Tunnel-Connection (68)
Acct-Tunnel-Packets-Lost (86)

3.6. Tunnel-Link-



14



This value MAY be used to mark the rejection of
establishment of a new link in an existing tunnel. Only
tunnel types (e.g., L2TP) support multiple links per tunnel
If only a single link can be carried in a given tunnel (e.g.,
IPsec in the tunnel mode), this Attribute need not be
in accounting packets, since in this case the Tunnel-
Attribute has the same meaning

If this value is used, the following attributes SHOULD also
included in the Accounting-Request packet

User-Name (1)
NAS-IP-Address (4)
Acct-Delay-Time (41)
Acct-Terminate-Cause (49)
Event-Timestamp (55)
Tunnel-Type (64)
Tunnel-Medium-Type (65)
Tunnel-Client-Endpoint (66)
Tunnel-Server-Endpoint (67)
Acct-Tunnel-Connection (68)










Zorn, et al. Informational [Page 6]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


4.

4.1. Acct-Tunnel-



This Attribute indicates the identifier assigned to the
session. It SHOULD be included in Accounting-Request
which contain an Acct-Status-Type attribute having the
Start, Stop or any of the values described above.
attribute, along with the Tunnel-Client-Endpoint and Tunnel
Server-Endpoint attributes [3], may be used to provide a
to uniquely identify a tunnel session for auditing purposes

A summary of the Acct-Tunnel-Connection Attribute format is
below. The fields are transmitted from left to right

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



68 for Acct-Tunnel-



>= 3



The format of the identifier represented by the String
depends upon the value of the Tunnel-Type attribute [3].
example, to fully identify an L2TP tunnel connection, the L2
Tunnel ID and Call ID might be encoded in this field.
exact encoding of this field is implementation dependent

4.2. Acct-Tunnel-Packets-



This Attribute indicates the number of packets lost on a
link. It SHOULD be included in Accounting-Request
which contain an Acct-Status-Type attribute having the
Tunnel-Link-Stop




Zorn, et al. Informational [Page 7]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


A summary of the Acct-Tunnel-Packets-Lost Attribute format
shown below. The fields are transmitted from left to right

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lost (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



86 for Acct-Tunnel-Packets-



6



The Lost field is 4 octets in length and represents the
of packets lost on the link

5. Table of

The following table provides a guide to which attributes may be
in Accounting-Request packets. No tunnel attributes should be
in Accounting-Response packets

Request #
0-1 64 Tunnel-
0-1 65 Tunnel-Medium-
0-1 66 Tunnel-Client-
0-1 67 Tunnel-Server-
0-1 68 Acct-Tunnel-
0 69 Tunnel-
0-1 81 Tunnel-Private-Group-
0-1 82 Tunnel-Assignment-
0 83 Tunnel-
0-1 86 Acct-Tunnel-Packets-










Zorn, et al. Informational [Page 8]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


The following table defines the meaning of the above table entries

0 This attribute MUST NOT be present in packet
0+ Zero or more instances of this attribute MAY be present
packet
0-1 Zero or one instance of this attribute MAY be present
packet

6. Security

By "sniffing" RADIUS Accounting packets, it might be possible for
eavesdropper to perform a passive analysis of tunnel connections

7.

[1] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[2] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.

[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
2868, June 2000.

[4] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.

[5] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
July 1999.

8.

Thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh
for salient input and review















Zorn, et al. Informational [Page 9]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


9. Authors'

Questions about this memo can be directed to

Glen
Cisco Systems, Inc
500 108th Avenue N.E., Suite 500
Bellevue, Washington 98004


Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.


Dave
Nortel
880 Technology Park
Billerica, MA 01821

Phone: +1 978 288 4570
Fax: +1 978 288 3030
EMail: dmitton@nortelnetworks.


Bernard
Microsoft
One Microsoft
Redmond, Washington 98052

Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: aboba@internaut.


















Zorn, et al. Informational [Page 10]

RFC 2867 RADIUS Tunnel Accounting Support June 2000


10. Full Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE



Funding for the RFC Editor function is currently provided by
Internet Society



















Zorn, et al. Informational [Page 11]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum