Internet DRAFT - draft-ietf-radius-tunnel-acct

draft-ietf-radius-tunnel-acct



Network Working Group                                            G. Zorn
Internet-Draft                                     Microsoft Corporation
Updates: RFC 2139                                              D. Mitton
Category: Informational                                  Nortel Networks
<draft-ietf-radius-tunnel-acct-04.txt>                          B. Aboba
                                                   Microsoft Corporation
                                                             August 1999

      RADIUS Accounting Modifications for Tunnel Protocol Support

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

The distribution of this memo is unlimited.  It is filed as <draft-ietf-
radius-tunnel-acct-04.txt>, and expires February 23, 2000.  Please send
comments to the RADIUS Working Group mailing list (ietf-
radius@livingston.com) or to the authors (gwz@acm.org,
dmitton@baynetworks.com and aboba@internaut.com).

Abstract

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

Zorn, Mitton & Aboba                                            [Page 1]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

Specification of Requirements

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

1.  Introduction

Many applications of tunneling protocols such as PPTP [5] and L2TP [4]
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 specific 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, as a service of the
Internet service provider (ISP).  Typically, ISPs providing a service
want to collect data regarding that service for billing, network
planning, etc.  One way to collect usage data in dial-up networks is by
means of RADIUS  Accounting [1].  The use of RADIUS Accounting allows
dial-up usage data to be collected at a central location, rather than
stored on each NAS.

In order to collect usage data regarding tunneling, new RADIUS
attributes are needed; 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 protocol can be found in
draft-ietf-radius-tunnel-imp-XX.txt.

2.  Implementation Notes

Compulsory tunneling may be part of a package of services provided by
one entity to another.  For example, a corporation might contract with
an ISP to provide remote intranet access to its employees via compulsory
tunneling.  In this case, the integration of RADIUS and tunnel protocols
allows the ISP and the corporation to synchronize their accounting
activities so that each side receives a record of the user's resource
consumption.  This provides the corporation with 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 to
uniquely identify the call, allowing the Accounting-Request sent by the
NAS to be reconciled with the corresponding Accounting-Request sent by
the tunnel server.

Zorn, Mitton & Aboba                                            [Page 2]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

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

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

3.  New Acct-Status-Type Values

3.1.  Tunnel-Start

   Value

      9

   Description

      This value MAY be used to mark the establishment of a tunnel with
      another node.  If this value is used, the following attributes
      SHOULD also be included in the Accounting-Request 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-Stop

   Value

      10

Zorn, Mitton & Aboba                                            [Page 3]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

   Description

      This value MAY be used to mark the destruction of a tunnel to or
      from another node.  If this value is used, the following
      attributes SHOULD also be 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)

3.3.  Tunnel-Reject

   Value

      11

   Description

      This value MAY be used to mark the rejection of the establishment
      of a tunnel with another node.  If this value is used, the
      following attributes SHOULD also be 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, Mitton & Aboba                                            [Page 4]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

3.4.  Tunnel-Link-Start

   Value

      12

   Description

      This value MAY be used to mark the creation of a tunnel link.
      Only some tunnel types (e.g., L2TP) support multiple links per
      tunnel.  This Attribute is intended to mark the creation of a 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 each marking the
      initiation and destruction of the tunnel itself and one each for
      the initiation and destruction of each link within the 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 included in
      accounting packets, since the presence of the Tunnel-Start
      Attribute will imply the initiation of the (only possible) link.

      If this value is used, the following attributes SHOULD also be
      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-Stop

   Value

      13

   Description

      This value MAY be used to mark the destruction of a tunnel link.
      Only some tunnel types (e.g., L2TP) support multiple links per

Zorn, Mitton & Aboba                                            [Page 5]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

      tunnel.  This Attribute is intended to mark the destruction of a
      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 each marking the
      initiation and destruction of the tunnel itself and one each for
      the initiation and destruction of each link within the 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 included in
      accounting packets, since the presence of the Tunnel-Stop
      Attribute will imply the termination of the (only possible) link.

      If this value is used, the following attributes SHOULD also be
      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)
      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-Reject

   Value

      14

   Description

      This value MAY be used to mark the rejection of the establishment
      of a new link in an existing tunnel.  Only some tunnel types
      (e.g., L2TP) support multiple links per tunnel.  If only a single

Zorn, Mitton & Aboba                                            [Page 6]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

      link can be carried in a given tunnel (e.g., IPsec in the tunnel
      mode), this Attribute need not be included in accounting packets,
      since in this case the Tunnel-Reject Attribute has the same
      meaning.

      If this value is used, the following attributes SHOULD also be
      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)

4.  Attributes

4.1.  Acct-Tunnel-Connection

   Description

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

   A summary of the Acct-Tunnel-Connection Attribute format is shown
   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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      68 for Acct-Tunnel-Connection

Zorn, Mitton & Aboba                                            [Page 7]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

   Length

      >= 3

   String

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

4.2.  Acct-Tunnel-Packets-Lost

   Description

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

   A summary of the Acct-Tunnel-Packets-Lost Attribute format is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Lost (cont)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      86 for Acct-Tunnel-Packets-Lost

   Length

      6

   Lost

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

Zorn, Mitton & Aboba                                            [Page 8]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

5.  Table of Attributes

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

   Request        #       Attribute
     0-1          64      Tunnel-Type
     0-1          65      Tunnel-Medium-Type
     0-1          66      Tunnel-Client-Endpoint
     0-1          67      Tunnel-Server-Endpoint
     0-1          68      Acct-Tunnel-Connection
     0            69      Tunnel-Password
     0-1          81      Tunnel-Private-Group-ID
     0-1          82      Tunnel-Assignment-ID
     0            83      Tunnel-Preference
     0-1          86      Acct-Tunnel-Packets-Lost

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 in packet.
   0-1   Zero or one instance of this attribute MAY be present in packet.

6.  Security Considerations

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

7.  References

[1]  Rigney, C., "RADIUS Accounting", RFC 2139, April 1997

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

[3]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I.
     Goyret, "RADIUS Attributes for Tunnel Protocol Support", draft-
     ietf-radius-tunnel-auth-09.txt (work in progress), August 1999

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

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

Zorn, Mitton & Aboba                                            [Page 9]

INTERNET-DRAFT      RADIUS Tunnel Accounting Support         August 1999

8.  Acknowledgments

Thanks to Aydin Edguer, Matt Holdrege and Gurdeep Singh Pall for salient
input and review.

9.  Authors' Addresses

Questions about this memo can also be directed to:

   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone:  +1 425 703 1559
   FAX:    +1 425 936 7329
   E-Mail: gwz@acm.org

   Dave Mitton
   Nortel Networks
   8 Federal Street, BL8-05
   Bilerica, MA 01821

   Phone:  +1 978 916 4570
   FAX:    +1 978 916 4789
   E-Mail: dmitton@nortelnetworks.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone:  +1 425 936 6605
   FAX:    +1 425 936 7329
   E-Mail: aboba@internaut.com

10.  Expiration Date

This memo is filed as draft-ietf-radius-tunnel-acct-04.txt and expires
on February 23, 2000.

Zorn, Mitton & Aboba                                           [Page 10]