doc/rfc/rfc2867.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            G. Zorn
   8 Request for Comments: 2867                           Cisco Systems, Inc.
   9 Category: Informational                                         B. Aboba
  10 Updates: 2866                                      Microsoft Corporation
  11                                                                D. Mitton
  12                                                          Nortel Networks
  13                                                                June 2000
  14
  15
  16       RADIUS Accounting Modifications for Tunnel Protocol Support
  17
  18 Status of this Memo
  19
  20    This memo provides information for the Internet community.  It does
  21    not specify an Internet standard of any kind.  Distribution of this
  22    memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  27
  28 Abstract
  29
  30    This document defines new RADIUS accounting Attributes and new values
  31    for the existing Acct-Status-Type Attribute [1] designed to support
  32    the provision of compulsory tunneling in dial-up networks.
  33
  34 Specification of Requirements
  35
  36    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  37    "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
  38    described in [2].
  39
  40 1.  Introduction
  41
  42    Many applications of tunneling protocols such as PPTP [5] and L2TP
  43    [4] involve dial-up network access.  Some, such as the provision of
  44    secure access to corporate intranets via the Internet, are
  45    characterized by voluntary tunneling: the tunnel is created at the
  46    request of the user for a specific purpose.  Other applications
  47    involve compulsory tunneling: the tunnel is created without any
  48    action from the user and without allowing the user any choice in the
  49    matter, as a service of the Internet service provider (ISP).
  50    Typically, ISPs providing a service want to collect data regarding
  51    that service for billing, network planning, etc.  One way to collect
  52    usage data in dial-up networks is by means of RADIUS  Accounting [1].
  53    The use of RADIUS Accounting allows dial-up usage data to be
  54    collected at a central location, rather than stored on each NAS.
  55
  56
  57
  58 Zorn, et al.                 Informational                      [Page 1]
  59 \f
  60 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
  61
  62
  63    In order to collect usage data regarding tunneling, new RADIUS
  64    attributes are needed; this document defines these attributes.  In
  65    addition, several new values for the Acct-Status-Type attribute are
  66    proposed.  Specific recommendations for, and examples of, the
  67    application of this attribute for the L2TP protocol can be found in
  68    RFC 2809.
  69
  70 2.  Implementation Notes
  71
  72    Compulsory tunneling may be part of a package of services provided by
  73    one entity to another.  For example, a corporation might contract
  74    with an ISP to provide remote intranet access to its employees via
  75    compulsory tunneling.  In this case, the integration of RADIUS and
  76    tunnel protocols allows the ISP and the corporation to synchronize
  77    their accounting activities so that each side receives a record of
  78    the user's resource consumption.  This provides the corporation with
  79    the means to audit ISP bills.
  80
  81    In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-
  82    Endpoint and Tunnel-Server-Endpoint attributes are typically used to
  83    uniquely identify the call, allowing the Accounting-Request sent by
  84    the NAS to be reconciled with the corresponding Accounting-Request
  85    sent by the tunnel server.
  86
  87    When implementing RADIUS accounting for L2TP/PPTP tunneling, the
  88    Call-Serial-Number SHOULD be used in the Acct-Tunnel-Connection
  89    attribute.  In L2TP, the Call-Serial-Number is a 32-bit field and in
  90    PPTP it is a 16-bit field.  In PPTP the combination of IP Address and
  91    Call-Serial-Number SHOULD be unique, but this is not required.  In
  92    addition, no method for determining the Call-Serial-Number is
  93    specified, which leaves open the possibility of wrapping after a
  94    reboot.
  95
  96    Note that a 16-bit Call-Serial-Number is not sufficient to
  97    distinguish a given call from all other calls over an extended time
  98    period.  For example, if the Call-Serial-Number is assigned
  99    monotonically, the NAS in question has 96 ports which are continually
 100    busy and the average call is of 20 minutes duration, then a 16-bit
 101    Call-Serial-Number will wrap within 65536/(96 * 3 calls/hour * 24
 102    hours/day) = 9.48 days.
 103
 104 3.  New Acct-Status-Type Values
 105
 106 3.1.  Tunnel-Start
 107
 108       Value
 109
 110          9
 111
 112
 113
 114 Zorn, et al.                 Informational                      [Page 2]
 115 \f
 116 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 117
 118
 119       Description
 120
 121          This value MAY be used to mark the establishment of a tunnel
 122          with another node.  If this value is used, the following
 123          attributes SHOULD also be included in the Accounting-Request
 124          packet:
 125
 126             User-Name (1)
 127             NAS-IP-Address (4)
 128             Acct-Delay-Time (41)
 129             Event-Timestamp (55)
 130             Tunnel-Type (64)
 131             Tunnel-Medium-Type (65)
 132             Tunnel-Client-Endpoint (66)
 133             Tunnel-Server-Endpoint (67)
 134             Acct-Tunnel-Connection (68)
 135
 136 3.2.  Tunnel-Stop
 137
 138       Value
 139
 140          10
 141
 142       Description
 143
 144          This value MAY be used to mark the destruction of a tunnel to
 145          or from another node.  If this value is used, the following
 146          attributes SHOULD also be included in the Accounting-Request
 147          packet:
 148
 149             User-Name (1)
 150             NAS-IP-Address (4)
 151             Acct-Delay-Time (41)
 152             Acct-Input-Octets (42)
 153             Acct-Output-Octets (43)
 154             Acct-Session-Id (44)
 155             Acct-Session-Time (46)
 156             Acct-Input-Packets (47)
 157             Acct-Output-Packets (48)
 158             Acct-Terminate-Cause (49)
 159             Acct-Multi-Session-Id (51)
 160             Event-Timestamp (55)
 161             Tunnel-Type (64)
 162             Tunnel-Medium-Type (65)
 163             Tunnel-Client-Endpoint (66)
 164             Tunnel-Server-Endpoint (67)
 165             Acct-Tunnel-Connection (68)
 166             Acct-Tunnel-Packets-Lost (86)
 167
 168
 169
 170 Zorn, et al.                 Informational                      [Page 3]
 171 \f
 172 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 173
 174
 175 3.3.  Tunnel-Reject
 176
 177       Value
 178
 179          11
 180
 181       Description
 182
 183          This value MAY be used to mark the rejection of the
 184          establishment of a tunnel with another node.  If this value is
 185          used, the following attributes SHOULD also be included in the
 186          Accounting-Request packet:
 187
 188             User-Name (1)
 189             NAS-IP-Address (4)
 190             Acct-Delay-Time (41)
 191             Acct-Terminate-Cause (49)
 192             Event-Timestamp (55)
 193             Tunnel-Type (64)
 194             Tunnel-Medium-Type (65)
 195             Tunnel-Client-Endpoint (66)
 196             Tunnel-Server-Endpoint (67)
 197             Acct-Tunnel-Connection (68)
 198
 199 3.4.  Tunnel-Link-Start
 200
 201       Value
 202
 203          12
 204
 205       Description
 206
 207          This value MAY be used to mark the creation of a tunnel link.
 208          Only some tunnel types (e.g., L2TP) support multiple links per
 209          tunnel.  This Attribute is intended to mark the creation of a
 210          link within a tunnel that carries multiple links.  For example,
 211          if a mandatory tunnel were to carry M links over its lifetime,
 212          2(M+1) RADIUS Accounting messages might be sent: one each
 213          marking the initiation and destruction of the tunnel itself and
 214          one each for the initiation and destruction of each link within
 215          the tunnel.  If only a single link can be carried in a given
 216          tunnel (e.g., IPsec in the tunnel mode), this Attribute need
 217          not be included in accounting packets, since the presence of
 218          the Tunnel-Start Attribute will imply the initiation of the
 219          (only possible) link.
 220
 221
 222
 223
 224
 225
 226 Zorn, et al.                 Informational                      [Page 4]
 227 \f
 228 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 229
 230
 231          If this value is used, the following attributes SHOULD also be
 232          included in the Accounting-Request packet:
 233
 234             User-Name (1)
 235             NAS-IP-Address (4)
 236             NAS-Port (5)
 237             Acct-Delay-Time (41)
 238             Event-Timestamp (55)
 239             Tunnel-Type (64)
 240             Tunnel-Medium-Type (65)
 241             Tunnel-Client-Endpoint (66)
 242             Tunnel-Server-Endpoint (67)
 243             Acct-Tunnel-Connection (68)
 244
 245 3.5.  Tunnel-Link-Stop
 246
 247       Value
 248
 249          13
 250
 251       Description
 252
 253          This value MAY be used to mark the destruction of a tunnel
 254          link.  Only some tunnel types (e.g., L2TP) support multiple
 255          links per tunnel.  This Attribute is intended to mark the
 256          destruction of a link within a tunnel that carries multiple
 257          links.  For example, if a mandatory tunnel were to carry M
 258          links over its lifetime, 2(M+1) RADIUS Accounting messages
 259          might be sent: one each marking the initiation and destruction
 260          of the tunnel itself and one each for the initiation and
 261          destruction of each link within the tunnel.  If only a single
 262          link can be carried in a given tunnel (e.g., IPsec in the
 263          tunnel mode), this Attribute need not be included in accounting
 264          packets, since the presence of the Tunnel-Stop Attribute will
 265          imply the termination of the (only possible) link.
 266
 267          If this value is used, the following attributes SHOULD also be
 268          included in the Accounting-Request packet:
 269
 270             User-Name (1)
 271             NAS-IP-Address (4)
 272             NAS-Port (5)
 273             Acct-Delay-Time (41)
 274             Acct-Input-Octets (42)
 275             Acct-Output-Octets (43)
 276             Acct-Session-Id (44)
 277             Acct-Session-Time (46)
 278             Acct-Input-Packets (47)
 279
 280
 281
 282 Zorn, et al.                 Informational                      [Page 5]
 283 \f
 284 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 285
 286
 287             Acct-Output-Packets (48)
 288             Acct-Terminate-Cause (49)
 289             Acct-Multi-Session-Id (51)
 290             Event-Timestamp (55)
 291             NAS-Port-Type (61)
 292             Tunnel-Type (64)
 293             Tunnel-Medium-Type (65)
 294             Tunnel-Client-Endpoint (66)
 295             Tunnel-Server-Endpoint (67)
 296             Acct-Tunnel-Connection (68)
 297             Acct-Tunnel-Packets-Lost (86)
 298
 299 3.6.  Tunnel-Link-Reject
 300
 301       Value
 302
 303          14
 304
 305       Description
 306
 307          This value MAY be used to mark the rejection of the
 308          establishment of a new link in an existing tunnel.  Only some
 309          tunnel types (e.g., L2TP) support multiple links per tunnel.
 310          If only a single link can be carried in a given tunnel (e.g.,
 311          IPsec in the tunnel mode), this Attribute need not be included
 312          in accounting packets, since in this case the Tunnel-Reject
 313          Attribute has the same meaning.
 314
 315          If this value is used, the following attributes SHOULD also be
 316          included in the Accounting-Request packet:
 317
 318             User-Name (1)
 319             NAS-IP-Address (4)
 320             Acct-Delay-Time (41)
 321             Acct-Terminate-Cause (49)
 322             Event-Timestamp (55)
 323             Tunnel-Type (64)
 324             Tunnel-Medium-Type (65)
 325             Tunnel-Client-Endpoint (66)
 326             Tunnel-Server-Endpoint (67)
 327             Acct-Tunnel-Connection (68)
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Zorn, et al.                 Informational                      [Page 6]
 339 \f
 340 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 341
 342
 343 4.  Attributes
 344
 345 4.1.  Acct-Tunnel-Connection
 346
 347       Description
 348
 349          This Attribute indicates the identifier assigned to the tunnel
 350          session.  It SHOULD be included in Accounting-Request packets
 351          which contain an Acct-Status-Type attribute having the value
 352          Start, Stop or any of the values described above.  This
 353          attribute, along with the Tunnel-Client-Endpoint and Tunnel-
 354          Server-Endpoint attributes [3], may be used to provide a means
 355          to uniquely identify a tunnel session for auditing purposes.
 356
 357       A summary of the Acct-Tunnel-Connection Attribute format is shown
 358       below.  The fields are transmitted from left to right.
 359
 360        0                   1                   2
 361        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 362       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 363       |      Type     |    Length     |    String ...
 364       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 365
 366       Type
 367
 368          68 for Acct-Tunnel-Connection
 369
 370       Length
 371
 372          >= 3
 373
 374       String
 375
 376          The format of the identifier represented by the String field
 377          depends upon the value of the Tunnel-Type attribute [3].  For
 378          example, to fully identify an L2TP tunnel connection, the L2TP
 379          Tunnel ID and Call ID might be encoded in this field.  The
 380          exact encoding of this field is implementation dependent.
 381
 382 4.2.  Acct-Tunnel-Packets-Lost
 383
 384       Description
 385
 386          This Attribute indicates the number of packets lost on a given
 387          link.  It SHOULD be included in Accounting-Request packets
 388          which contain an Acct-Status-Type attribute having the value
 389          Tunnel-Link-Stop.
 390
 391
 392
 393
 394 Zorn, et al.                 Informational                      [Page 7]
 395 \f
 396 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 397
 398
 399       A summary of the Acct-Tunnel-Packets-Lost Attribute format is
 400       shown below.  The fields are transmitted from left to right.
 401
 402        0                   1                   2                   3
 403        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
 404       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 405       |      Type     |    Length     |               Lost
 406       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 407                  Lost (cont)          |
 408       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 409
 410       Type
 411
 412          86 for Acct-Tunnel-Packets-Lost
 413
 414       Length
 415
 416          6
 417
 418       Lost
 419
 420          The Lost field is 4 octets in length and represents the number
 421          of packets lost on the link.
 422
 423 5.  Table of Attributes
 424
 425    The following table provides a guide to which attributes may be found
 426    in Accounting-Request packets.  No tunnel attributes should be found
 427    in Accounting-Response packets.
 428
 429    Request        #       Attribute
 430      0-1          64      Tunnel-Type
 431      0-1          65      Tunnel-Medium-Type
 432      0-1          66      Tunnel-Client-Endpoint
 433      0-1          67      Tunnel-Server-Endpoint
 434      0-1          68      Acct-Tunnel-Connection
 435      0            69      Tunnel-Password
 436      0-1          81      Tunnel-Private-Group-ID
 437      0-1          82      Tunnel-Assignment-ID
 438      0            83      Tunnel-Preference
 439      0-1          86      Acct-Tunnel-Packets-Lost
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Zorn, et al.                 Informational                      [Page 8]
 451 \f
 452 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 453
 454
 455    The following table defines the meaning of the above table entries.
 456
 457    0     This attribute MUST NOT be present in packet.
 458    0+    Zero or more instances of this attribute MAY be present in
 459          packet.
 460    0-1   Zero or one instance of this attribute MAY be present in
 461          packet.
 462
 463 6.  Security Considerations
 464
 465    By "sniffing" RADIUS Accounting packets, it might be possible for an
 466    eavesdropper to perform a passive analysis of tunnel connections.
 467
 468 7.  References
 469
 470    [1]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 471
 472    [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 473         Levels", BCP 14, RFC 2119, March 1997.
 474
 475    [3]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
 476         I.  Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
 477         2868, June 2000.
 478
 479    [4]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
 480         B.  Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
 481         August 1999.
 482
 483    [5]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
 484         G.  Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
 485         July 1999.
 486
 487 8.  Acknowledgments
 488
 489    Thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall
 490    for salient input and review.
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Zorn, et al.                 Informational                      [Page 9]
 507 \f
 508 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 509
 510
 511 9.  Authors' Addresses
 512
 513    Questions about this memo can be directed to:
 514
 515    Glen Zorn
 516    Cisco Systems, Inc.
 517    500 108th Avenue N.E., Suite 500
 518    Bellevue, Washington 98004
 519    USA
 520
 521    Phone: +1 425 438 8218
 522    FAX:   +1 425 438 1848
 523    EMail: gwz@cisco.com
 524
 525
 526    Dave Mitton
 527    Nortel Networks
 528    880 Technology Park Drive
 529    Billerica, MA 01821
 530
 531    Phone: +1 978 288 4570
 532    Fax:   +1 978 288 3030
 533    EMail: dmitton@nortelnetworks.com
 534
 535
 536    Bernard Aboba
 537    Microsoft Corporation
 538    One Microsoft Way
 539    Redmond, Washington 98052
 540
 541    Phone: +1 425 936 6605
 542    Fax:   +1 425 936 7329
 543    EMail: aboba@internaut.com
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Zorn, et al.                 Informational                     [Page 10]
 563 \f
 564 RFC 2867            RADIUS Tunnel Accounting Support           June 2000
 565
 566
 567 10.  Full Copyright Statement
 568
 569    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 570
 571    This document and translations of it may be copied and furnished to
 572    others, and derivative works that comment on or otherwise explain it
 573    or assist in its implementation may be prepared, copied, published
 574    and distributed, in whole or in part, without restriction of any
 575    kind, provided that the above copyright notice and this paragraph are
 576    included on all such copies and derivative works.  However, this
 577    document itself may not be modified in any way, such as by removing
 578    the copyright notice or references to the Internet Society or other
 579    Internet organizations, except as needed for the purpose of
 580    developing Internet standards in which case the procedures for
 581    copyrights defined in the Internet Standards process must be
 582    followed, or as required to translate it into languages other than
 583    English.
 584
 585    The limited permissions granted above are perpetual and will not be
 586    revoked by the Internet Society or its successors or assigns.
 587
 588    This document and the information contained herein is provided on an
 589    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 590    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 591    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 592    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 593    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 594
 595 Acknowledgement
 596
 597    Funding for the RFC Editor function is currently provided by the
 598    Internet Society.
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Zorn, et al.                 Informational                     [Page 11]
 619 \f