[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-l2tpext-radius-ext-nas-port

Network Working Group                                       T. Mistretta
Internet-Draft                                          Juniper Networks
Expires: January 17, 2005                                      I. Goyret
                                                     Lucent Technologies
                                                               N. McGill
                                                             M. Townsley
                                                                G. Weber
                                                           cisco Systems
                                                           July 19, 2004



                  RADIUS & L2TP Extended NAS-Port AVPs
             draft-nmcgill-l2tp-radius-ext-nas-port-02.txt


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   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.


   This Internet-Draft will expire on January 17, 2005.


Copyright Notice


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


Abstract


   This document defines additional Layer 2 Transfer Protocol (L2TP) and
   Remote Authentication Dial In User Service (RADIUS) Attribute-Value
   Pairs (AVPs) to communicate Network Access Server (NAS) informational
   ASCII text and port usage information between L2TP peers during call




Mistretta, et al.       Expires January 17, 2005                [Page 1]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



   establishment to facilitate authorization, accounting and logging.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Specification of Requirements  . . . . . . . . . . . . . .  4
   2.  L2TP Extended NAS-Port AVPs  . . . . . . . . . . . . . . . . .  4
   3.  RADIUS Extended NAS-Port AVP . . . . . . . . . . . . . . . . .  7
     3.1   Table of Attributes  . . . . . . . . . . . . . . . . . . . 10
     3.2   Interactions with other RADIUS attributes  . . . . . . . . 10
     3.3   Diameter Compatibility . . . . . . . . . . . . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   6.2   Informative References . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 14


































Mistretta, et al.       Expires January 17, 2005                [Page 2]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



1.  Introduction


   It is often desirable to send adjunct and port usage information from
   the L2TP Access Concentrator (LAC) to the L2TP Network Server (LNS)
   during call setup.  Such information may be used for:



      Logging
         to describe system and port related information in a
         human-readable, vendor-specific form.
      Authorization
         to restrict users to particular given access types or
         interfaces.
      Accounting
         to determine port usage on a per-user basis, for example, via
         RADIUS accounting [RFC2866].
      Auditing
         to ensure that the LNS vendor is being allocated the proper
         contractual resources by the LAC vendor.


   L2TP [RFC2661] already has a Physical Channel ID AVP that may be used
   to provide port usage information.  However, its usefulness is
   limited in multi-vendor LAC/LNS environments where the vendor-
   specific bit encoding used for this AVP will often not be understood
   by L2TP peers from differing vendors.


   This makes the task of de-constructing the Physical Channel ID AVP
   contents at the LNS for (RADIUS) authorization/accounting server
   extremely difficult.


   Additionally, it is length limited to 4 octets of information which
   is inadequate in access servers supporting multiple access types and
   large numbers of ports.


   This document defines extensions whereby such port usage information
   may be transferred in a vendor-independent fashion between
   mixed-vendor LAC and LNSs, thus facilitating detailed and matching
   logging and accounting at each end of the tunnel.














Mistretta, et al.       Expires January 17, 2005                [Page 3]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



   The following diagram depicts a typical dialin scenario for L2TP with
   RADIUS accounting servers at the LNS:



                  Authen/Accounting
                    RADIUS server
                        |
                        |
                        |
                        |
      intranet - - - - LNS - - - - - internet - - - -LAC - - - -client
                        <----------------------------->
                                   L2TP tunnel




1.1  Specification of Requirements


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  L2TP Extended NAS-Port AVPs


   The following collection of Extended NAS-Port AVPs, attribute types
   TBD, allow detailed logging and port usage information to be
   transmitted between L2TP peers.  This format is common to all
   Extended NAS-Port AVPs; only the Attribute Type is different for
   each:


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|H| rsvd  |      Length       |        Vendor ID [IETF]       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Attribute Type        |        Attribute Value...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        [until Length is reached]...                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   NOTES:


   o  Each Extended NAS-Port AVP is encoded as the IETF Vendor ID 0


   o  Each AVP has defined behaviour associated with it, namely:







Mistretta, et al.       Expires January 17, 2005                [Page 4]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



      Passthrough AVPs: If this AVP is received by a node participating
         in a multi-hop scenario, then the AVP MUST be copied as-is to
         the next hop.  A locally generated AVP MAY be generated if
         required and appended in the outbound message to the next hop.


      Stackable AVPs: If this AVP is received by a node participating in
         a multi-hop scenario, then the AVP MUST be copied as-is to the
         next hop.  A locally generated AVP MUST be generated and
         appended in the outbound message to the next hop.  If no value
         is appropriate then an AVP of Length 0 MUST be appended.


   o  The value of all bits MUST be preserved in any AVPs copied.



   The following are valid values for the Attribute Type field:


      TBD - Platform Information


         This AVP, length 0-253, allows a UTF-8 string to be sent with a
         human-readable description of the platform.


         Examples: "Model 457", or "TPX-1700".


         This information MUST NOT be parsed and as such termination
         action MUST NOT be based on the contents of this attribute.


         The M-bit MUST be set to 0.  The H-bit MAY be set based on the
         current L2TP node's policy.  This AVP is a stackable AVP.


      TBD - System Identification Information


         This AVP, length 0-253, allows a UTF-8 string to be sent with a
         human-readable description of the router's identification
         within the provider's network.


         Examples: "CommCo LAC", or "SuperProvider AS".


         This information MUST NOT be parsed and as such termination
         action MUST NOT be based on the contents of this attribute.


         The M-bit MUST be set to 0.  The H-bit MAY be set based on the
         current L2TP node's policy.  This AVP is a stackable AVP.


      TBD - Call Information


         This AVP, length 0-253, allows a UTF-8 string to be sent with a
         human-readable description of the call.





Mistretta, et al.       Expires January 17, 2005                [Page 5]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



         Examples could include "Atlanta POP", or "Neptune-304x using
         frame2 module".


         This information MUST NOT be parsed and as such termination
         action MUST NOT be based on the contents of this attribute.


         The M-bit MUST be set to 0.  The H-bit MAY be set based on the
         current L2TP node's policy.  This AVP is a stackable AVP.


      TBD - Software Information


         This AVP, length 0-253, allows a UTF-8 string to be sent with a
         human-readable description of the software running on the
         platform.


         Examples: "Version 4-0.12(c)-2", or "Rev 10.4.2-beta".


         This information MUST NOT be parsed and as such termination
         action MUST NOT be based on the contents of this attribute.


         The M-bit MUST be set to 0.  The H-bit MAY be set based on the
         current L2TP node's policy.  This AVP is a stackable AVP.


      TBD - Vendor-Information AVP


         This AVP, length 0-253, allows a UTF-8 string to be sent with a
         human-readable description of the vendor of the platform.


         Examples: "Hudson Computer Systems", or "Lightning Networks".


         This information MUST NOT be parsed and as such termination
         action MUST NOT be based on the contents of this attribute.


         The M-bit MUST be set to 0.  The H-bit MAY be set based on the
         current L2TP node's policy.  This AVP is a stackable AVP.


      TBD - Shelf
      TBD - Slot
      TBD - Module
      TBD - Adapter
      TBD - Interface
      TBD - Line
      TBD - Port
      TBD - Channel
      TBD - Physical Interface
      TBD - Physical Sub-interface
      TBD - Virtual Path





Mistretta, et al.       Expires January 17, 2005                [Page 6]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



      TBD - Virtual Circuit
      TBD - Virtual Lan
      TBD - Virtual Interface
      TBD - Virtual Sub-interface


         This AVP, length 0 or 4, is an octet integer value,
         representing a specific Extended NAS-Port AVP value at this
         L2TP node.


         The M-bit MUST be set to 0.  The H-bit MAY be set based on the
         current L2TP node's policy.  These AVPs are passthrough AVPs.


      All Extended NAS-Port AVPs SHOULD be used in conjunction with the
      Port Type List AVP [I-D.ietf-l2tpext-sesinfo] to allow correlation
      between port type and usage.


      For incoming calls, these AVPs are valid either on ICRQ or ICCN.
      If sent on both, the ICCN AVP MUST override the ICRQ value.  For
      outgoing calls, the AVPs are valid on OCRP and OCCN, with similar
      override behavior.


3.  RADIUS Extended NAS-Port AVP


   The RADIUS Extended NAS-Port AVP closely resembles its L2TP counter-
   part and allows detailed port-usage/accounting information to be
   provided in multi-vendor environments.


   The key distinction is that for RADIUS we have a single new attribute
   with multiple Extensions, encoded as string attribute-value pairs of
   the form "<extension>=<value>".  These Extensions exist in a one-to-
   one mapping with the previously defined L2TP AVPs.


   The following format is common to all Extended NAS-Port AVPs; only
   the Extension string name is different for each:


     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 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    |Extnd. NAS-Port|    Length     |  "extension=value"...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type


      TBD for Extended NAS-Port


   Length






Mistretta, et al.       Expires January 17, 2005                [Page 7]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



      >= 3


   Value


      This attribute is of string format, with the following definition:


      "<extension>=<value>"


      Where "<extension>" is one of the following case-sensitive
      strings:


         "platform" - Platform Information


            This AVP, length 3-255, allows a UTF-8 string to be sent
            with a human-readable description of the platform.


            Examples: "platform=Model 457", or "platform=TPX-1700".


            This information MUST NOT be parsed and as such termination
            action MUST NOT be based on the contents of this attribute.


         "system-id" - System Identification Information


            This AVP, length 3-255, allows a UTF-8 string to be sent
            with a human-readable description of the routers
            identification within the provider's network.


            Examples: "system-id=CommCo LAC", or
            "system-id=SuperProvider AS".


            This information MUST NOT be parsed and as such termination
            action MUST NOT be based on the contents of this attribute.


         "call" - Call Information


            This AVP, length 3-255, allows a UTF-8 string to be sent
            with a human-readable description of the call.


            Examples could include "call=Atlanta POP", or "call=Neptune-
            304x using frame2 module".


            This information MUST NOT be parsed and as such termination
            action MUST NOT be based on the contents of this attribute.


         "software" - Software Information


            This AVP, length 3-255, allows a UTF-8 string to be sent
            with a human-readable description of the software running on




Mistretta, et al.       Expires January 17, 2005                [Page 8]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



            the platform.


            Examples: "software=Version 4-0.12(c)-2", or "software=Rev
            10.4.2-beta".


            This information MUST NOT be parsed and as such termination
            action MUST NOT be based on the contents of this attribute.


         "vendor" - Vendor-Information AVP


            This AVP, length 3-255, allows a UTF-8 string to be sent
            with a human-readable description of the vendor of the
            platform.


            Examples: "vendor=Hudson Computer Systems", or
            "vendor=Lightning Networks".


            This information MUST NOT be parsed and as such termination
            action MUST NOT be based on the contents of this attribute.


         "shelf" - Shelf
         "slot" - Slot
         "module" - Module
         "adapter" - Adapter
         "intf" - Interface
         "line" - Line
         "port" - Port
         "channel" - Channel
         "phys-intf" - Physical Interface
         "phys-subintf" - Physical Sub-interface
         "vpi" - Virtual Path
         "vci" - Virtual Circuit
         "vlan" - Virtual Lan
         "vintf" - Virtual Interface
         "vsubintf" - Virtual Sub-interface


            These AVPs, length 3-255, allow a UTF-8 string to be sent
            with the integer value of the relevant Extended NAS-Port
            AVP.


            Examples: "vpi=3", "vci=0", "vlan=12345"


   For L2TP tunnels, these attributes MUST be used, if available, to log
   information obtained via the corresponding L2TP Extended NAS-Port
   AVPs.  See section 2.


   To cater for L2TP multi-hop environments, if an L2TP Extended NAS-
   Port AVP is available, but without a corresponding value, then the




Mistretta, et al.       Expires January 17, 2005                [Page 9]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



   associated RADIUS AVP MUST be encoded as "<extension>"


   The sequence of RADIUS Extended NAS-Port AVPs MUST follow that of any
   L2TP Extended NAS-Port AVPs received.


   For scenarios without L2TP, these attributes MAY also be used in
   preference over the RADIUS NAS-Port attribute to provide finer
   granularity during accounting.


   Where an attribute was not received from L2TP it is considered
   optional to send.


   For non L2TP environments, all Extensions are optional.


   All strings are NOT null terminated.


   Any numbers encoded as the value part of the Extension MUST be as
   strings with a minimum value of "0".  Only unsigned values MUST be
   sent.


   The use of the character '"' in this document is included purely as a
   visual aid in identifying the beginning and end of strings.  It MUST
   NOT be included as part of the end format, unless specifically
   encoded as data within the AVP Value section.


3.1  Table of Attributes


   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.


   For Authentication:


         Request  Accept  Reject  Challenge   Attribute
         0+       0       0       0           Extended NAS-Port


   For Accounting:


         Request  Response                    Attribute
         0+       0                           Extended NAS-Port



3.2  Interactions with other RADIUS attributes


   Extended NAS-Port overlaps in functionality with NAS-Port.  However,
   whereas the encoding of NAS-Port is limited to 32 bits and often
   vendor specific, Extended NAS-Port is not.  NAS-Port may still
   continue to be used but preference SHOULD be given to information
   received in Extended NAS-Port.




Mistretta, et al.       Expires January 17, 2005               [Page 10]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



   If a RADIUS vendor detects conflicting values between NAS-Port and
   Extended NAS-Port, Extended NAS-Port SHOULD be taken as the more
   accurate value.


3.3  Diameter Compatibility


   The RADIUS Extended NAS-Port attribute defined in this section may be
   translated for transmission via Diameter [RFC3588] by AAA Translation
   Agents as described by Section 9 of [I-D.ietf-aaa-diameter-nasreq].


   Such a translation might represent the extended NAS-Port information
   as a single Diameter attribute of type Grouped.  Each RADIUS
   <extension> valued defined in section 3 would map to a new Diameter
   attribute, all of which would be encapsulated in a single Grouped
   Extended-NAS-Port attribute.  The ABNF for such an attribute might
   look like:


        Extended-NAS-Port     ::= < AVP Header: TBD >
            [ NAS-Port-Platform ]
            [ NAS-Port-System-Id ]
            [ NAS-Port-Call ]
            [ NAS-Port-Software ]
            [ NAS-Port-Vendor ]
            [ NAS-Port-Shelf ]
            [ NAS-Port-Slot ]
            ...



4.  Security Considerations


   This document describes mechanisms where port termination information
   can be sent between L2TP peers.  Users of these AVPs should have the
   understanding that any information sent could be used for malicious
   purposes.  If this is a concern, any of the L2TP Extended NAS-Port
   List AVPs MAY be hidden.


5.  IANA Considerations


   The "Call Information", "Platform Information", "Software
   Information", and "Vendor Information" AVPs needs to be assigned an
   IETF "Attribute Type" from the "Control Message Attribute Value
   Pairs" maintained by IANA for L2TP.


6.  References


6.1  Normative References


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate




Mistretta, et al.       Expires January 17, 2005               [Page 11]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



              Requirement Levels", BCP 14, RFC 2119, March 1997.


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


   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.


6.2  Informative References


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


   [I-D.ietf-l2tpext-sesinfo]
              Palter, W., "L2TP Session Information (``SESINFO'')",
              draft-ietf-l2tpext-sesinfo-04 (work in progress), February
              2002.


   [I-D.ietf-aaa-diameter-nasreq]
              Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
              Network Access Server Application",
              draft-ietf-aaa-diameter-nasreq-16 (work in progress), June
              2004.



Authors' Addresses


   Tom Mistretta
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   US


   EMail: tmistretta@juniper.net



   Ignacio Goyret
   Lucent Technologies
   1701 Harbor Bay Parkway
   Alameda, CA  94502


   EMail: igoyret@lucent.com










Mistretta, et al.       Expires January 17, 2005               [Page 12]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



   Neil McGill
   cisco Systems
   3rd Floor
   96 Commercial Street
   Edinburgh, EH6 6LX
   UK


   EMail: nmcgill@cisco.com



   W. Mark Townsley
   cisco Systems


   EMail: mark@townsley.net



   Greg Weber
   cisco Systems
   10850 Murdock Road
   Knoxville, TN  37932
   US


   EMail: gdweber@cisco.com





























Mistretta, et al.       Expires January 17, 2005               [Page 13]


Internet-Draft    RADIUS & L2TP Extended NAS-Port AVPs         July 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


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




Mistretta, et al.       Expires January 17, 2005               [Page 14]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/