doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc2867.txt b/doc/rfc/rfc2867.txt
new file mode 100644
index 0000000..62e5d6d
--- /dev/null
+++ b/doc/rfc/rfc2867.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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.,
+         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)
+
+
+
+
+
+
+
+
+
+
+Zorn, et al.                 Informational                      [Page 6]
+
+RFC 2867            RADIUS Tunnel Accounting Support           June 2000
+
+
+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
+
+      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.
+
+
+
+
+Zorn, et al.                 Informational                      [Page 7]
+
+RFC 2867            RADIUS Tunnel Accounting Support           June 2000
+
+
+      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.
+
+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
+
+
+
+
+
+
+
+
+
+
+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 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 2866, June 2000.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
+        I.  Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
+        2868, June 2000.
+
+   [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.
+
+8.  Acknowledgments
+
+   Thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall
+   for salient input and review.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn, et al.                 Informational                      [Page 9]
+
+RFC 2867            RADIUS Tunnel Accounting Support           June 2000
+
+
+9.  Authors' Addresses
+
+   Questions about this memo can be directed to:
+
+   Glen Zorn
+   Cisco Systems, Inc.
+   500 108th Avenue N.E., Suite 500
+   Bellevue, Washington 98004
+   USA
+
+   Phone: +1 425 438 8218
+   FAX:   +1 425 438 1848
+   EMail: gwz@cisco.com
+
+
+   Dave Mitton
+   Nortel Networks
+   880 Technology Park Drive
+   Billerica, MA 01821
+
+   Phone: +1 978 288 4570
+   Fax:   +1 978 288 3030
+   EMail: dmitton@nortelnetworks.com
+
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, Washington 98052
+
+   Phone: +1 425 936 6605
+   Fax:   +1 425 936 7329
+   EMail: aboba@internaut.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn, et al.                 Informational                     [Page 10]
+
+RFC 2867            RADIUS Tunnel Accounting Support           June 2000
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn, et al.                 Informational                     [Page 11]
+