rfc2867.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

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


      RADIUS Accounting Modifications for Tunnel Protocol Support

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.

Copyright Notice

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

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.

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.



Zorn, et al.                 Informational                      [Page 1]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000


   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
   RFC 2809.

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.

   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



Zorn, et al.                 Informational                      [Page 2]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000


      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

      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-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-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)

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.






Zorn, et al.                 Informational                      [Page 4]

RFC 2867            RADIUS Tunnel Accounting Support           June 2000


         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 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)



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-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 link can be carried in a given tunnel (e.g.,