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

Versions: 00 01

Network Working Group                                       T. Mistretta
Internet Draft                                          Juniper Networks
Category: Standards Track
draft-mistretta-l2tp-infomsg-01.txt                            I. Goyret
                                                     Lucent Technologies

                                                               N. McGill
                                                             M. Townsley
                                                           cisco Systems

                                                           November 2002

                     L2TP Call Information Messages


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 10 of RFC 2026 [BCP9].

   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/1id-abstracts.html

   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-
   mistretta-l2tp-infomsg-01.txt" and expires April 30, 2003.  Please
   send comments to the L2TP mailing list (l2tp@l2tp.net).

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

Abstract

   This document defines additional L2TP AVPs to communicate
   informational ASCII text messages between the tunnel endpoints during
   call establishment. The message contents are not interpreted by the
   receiving endpoint in any way but can be used for logging or



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 1]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


   debugging purposes.


Contents

   Status of this Memo ..........................................   1

   Abstract .....................................................   1

   1. Introduction ..............................................   2
      1.1 Specification of Requirements .........................   3

   2. L2TP AVPs .................................................   3
      2.1 Common AVP Properties .................................   3
      2.2 Call-Information AVP ..................................   4
      2.3 Platform-Information AVP ..............................   4
      2.4 Software Information AVP ..............................   4
      2.5 Vendor-Information AVP ................................   5

   3. RADIUS attributes .........................................   5
      3.1 Call-Information RADIUS attribute .....................   5
      3.2 Platform-Information RADIUS attribute .................   6
      3.3 Software-Information RADIUS attribute .................   7
      3.4 Vendor-Information RADIUS attribute ...................   8

   4. Security Considerations ...................................   9

   5. References ................................................   9

   6. IANA Considerations .......................................  10

   7. Authors' Addresses ........................................  10

   8. Full Copyright Statement ..................................  11

   9. Expiration Date ...........................................  12


1. Introduction

   It is often desirable to send adjunct information from the LAC to the
   LNS during call setup.  Some such information can be circuit
   oriented, describing the attributes of the circuit interface.  Other
   information could describe the peer itself.  In either case, the
   information is typically used for for logging or debugging.  L2TP
   [RFC2661] already has a Physical Channel ID AVP that provides a
   limited logging capability during call setup.  It is limited in that
   its length is only 4 octets.  This draft defines extensions whereby



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 2]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


   human-readable ASCII strings are sent during call setup.  The strings
   are typed, but uninterpreted by L2TP.  Their sole purposes are to
   enhance logging and debugging capabilities in L2TP.

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 AVPs

2.1 Common AVP Properties

   All of the AVPs share the following traits:

      The AVPs are not mandatory (the M bit MUST be set to 0).  The AVP
      SHOULD NOT be hidden (the H-bit SHOULD be set to 0).

      The information strings themselves MUST be human readable, they
      SHOULD contain UTF-8 encoded 10646 [RFC2279] characters using the
      Default Language [BCP18].

      The strings are not null-terminated.  Valid lengths are between 1
      and 253 octets, so it can fit on a RADIUS attribute.

      The format of the information strings are purposely not defined.
      The contents of the string MUST NOT be parsed nor interpreted by
      the receiving L2TP endpoint.

      As mentioned previously, possible uses of the strings are output
      to a console or logging to a server.  If the strings were to be
      used in RADIUS accounting or authentication requests, it SHOULD be
      mapped into corresponding RADIUS attributes defined in section 3.

      The treatment of these AVPs through a L2TP tunnel switch follows
      the "stacking" model introduced in the draft RFC [SESINFO].  This
      model allows propagation of information from earlier L2TP nodes
      while at the same time providing a capability to append new
      information at each hop.  A "list" format is defined for the AVPs,
      where the last entry corresponds to the most recent sending node,
      and all preceding values are for previous nodes.  In the event
      that an AVP is received where there is no local value to append,
      an "empty" entry (one whose string length is zero) MUST be
      appended. Interim L2TP tunnel switches can only append to existing
      AVPs that are being passed through.  They MUST NOT initiate a new
      AVP if one does not already exist.  This is done so that



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 3]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


      information across the AVPs can be correlated and reflected
      accurately at the final location.

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

      All AVPs has the following format, the only difference being that
      the attribute type is particular to the specific AVP being used.

          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 [TBD]       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Length 0      |  Information String 0 (1-253 octets) ...      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Length 1      |  Information String 1 (1-253 octets) ...      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                 ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Length N      |  Information String N (1-253 octets) ...      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.2 Call-Information AVP

   The Call Information AVP, Attribute type TBD, allows a UTF-8 string
   to be sent with a human readable description of the call.  Examples
   could include "Atlanta POP", or "Neptune-304x using frame2 module".

2.3 Platform-Information AVP

   The Platform Information AVP, Attribute type TBD, allows a UTF-8
   string to be sent with a human readable description of the platform.
   Examples could be "Model 457", or "TPX-1700".

2.4 Software Information AVP

   The Software Information AVP, Attribute type TBD, allows a UTF-8
   string to be sent with a human readable description of the software
   running on the platform.  Examples could be "Version 4-0.12(c)-2" or
   "Rev 10.4.2-beta".





Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 4]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


2.5 Vendor-Information AVP

   The Vendor Information AVP, Attribute type TBD, 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".




3. RADIUS attributes

3.1 Call-Information RADIUS attribute

   Description
      This Attribute indicates text which MAY be supplied to the RADIUS
      [RFC2865] server during authentication (Access-Request),
      accounting (Accounting-Request) or tunnel-link accounting
      [RFC2867] for the purposes of logging only.  The message MUST NOT
      be parsed and as such termination action MUST NOT be based on the
      contents of this attribute.

      In contrast to RADIUS Connect-Info [RFC2869], Call-Information
      indicates where a call terminated, not what it terminated as. For
      example, Call-Information MAY be used to report NAS module, slot,
      port in a vendor specific format. Connect-Info MAY be used to
      specify negotiated compression, connection protocol etc...

      Multiple Call-Information's MAY be included and if any are
      displayed, they MUST be displayed in the same order as they appear
      in the packet.

      A summary of the Call-Information 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
         |     Type      |    Length     |  Text ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      TBD for Call-Information.

   Length

      >= 3



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 5]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


   Text

      The Text field is one or more octets, and its contents are
      implementation dependent.  It is intended to be human readable,
      and MUST NOT affect operation of the protocol.  It is recommended
      that the message contain UTF-8 encoded 10646 [RFC2279] characters
      using the Default Language [BCP18].  The string is not null-
      terminated.

   For L2TP calls, this attribute SHOULD be used to log information
   obtained via Call-Information AVPs. See section 2.

3.2 Platform-Information RADIUS attribute

   Description
      This Attribute indicates text which MAY be supplied to the RADIUS
      [RFC2865] server during authentication (Access-Request),
      accounting (Accounting-Request) or tunnel accounting [RFC2867] for
      the purposes of logging only.  The message MUST NOT be parsed and
      as such termination action MUST NOT be based on the contents of
      this attribute.

      Multiple Platform-Information's MAY be included and if any are
      displayed, they MUST be displayed in the same order as they appear
      in the packet.

      A summary of the Platform-Information 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
         |     Type      |    Length     |  Text ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      TBD for Platform-Information.

   Length

      >= 2

   Text

      The Text field is one or more octets, and its contents are
      implementation dependent.  It is intended to be human readable,
      and MUST NOT affect operation of the protocol.  It is recommended



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 6]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


      that the message contain UTF-8 encoded 10646 [RFC2279] characters
      using the Default Language [BCP18].  The string is not null-
      terminated.

   For L2TP tunnels, this attribute MUST be used to log information
   obtained via Platform-Information AVPs. See section 2. To cater for
   L2TP multihop environments, if no Platform-Information is available,
   then this attribute MUST be used with Length set to 2. Such
   attributes indicate that no Platform-Information was available for a
   particular node within the L2TP tunnel path. The sequence of RADIUS
   Platform-Information attributes MUST follow that of any L2TP
   Platform-Information AVPS received.

3.3 Software-Information RADIUS attribute

   Description
      This Attribute indicates text which MAY be supplied to the RADIUS
      [RFC2865] server during authentication (Access-Request),
      accounting (Accounting-Request) or tunnel accounting [RFC2867] for
      the purposes of logging only.  The message MUST NOT be parsed and
      as such termination action MUST NOT be based on the contents of
      this attribute.

      Multiple Software-Information's MAY be included and if any are
      displayed, they MUST be displayed in the same order as they appear
      in the packet.

      A summary of the Software-Information 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
         |     Type      |    Length     |  Text ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      TBD for Software-Information.

   Length

      >= 2

   Text

      The Text field is one or more octets, and its contents are
      implementation dependent.  It is intended to be human readable,



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 7]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


      and MUST NOT affect operation of the protocol.  It is recommended
      that the message contain UTF-8 encoded 10646 [RFC2279] characters
      using the Default Language [BCP18].  The string is not null-
      terminated.

   For L2TP tunnels, this attribute MUST be used to log information
   obtained via Software-Information AVPs. See section 2. To cater for
   L2TP multihop environments, if no Software-Information is available,
   then this attribute MUST be used with Length set to 2. Such
   attributes indicate that no Software-Information was available for a
   particular node within the L2TP tunnel path. The sequence of RADIUS
   Software-Information attributes MUST follow that of any L2TP
   Software-Information AVPS received.

3.4 Vendor-Information RADIUS attribute

   Description
      This Attribute indicates text which MAY be supplied to the RADIUS
      [RFC2865] server during authentication (Access-Request),
      accounting (Accounting-Request) or tunnel accounting [RFC2867] for
      the purposes of logging only.  The message MUST NOT be parsed and
      as such termination action MUST NOT be based on the contents of
      this attribute.

      Multiple Vendor-Information's MAY be included and if any are
      displayed, they MUST be displayed in the same order as they appear
      in the packet.

      A summary of the Vendor-Information 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
         |     Type      |    Length     |  Text ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      TBD for Vendor-Information.

   Length

      >= 2

   Text

      The Text field is one or more octets, and its contents are



Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 8]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


      implementation dependent.  It is intended to be human readable,
      and MUST NOT affect operation of the protocol.  It is recommended
      that the message contain UTF-8 encoded 10646 [RFC2279] characters
      using the Default Language [BCP18].  The string is not null-
      terminated.

   For L2TP tunnels, this attribute MUST be used to log information
   obtained via Vendor-Information AVPs. See section 2. To cater for
   L2TP multihop environments, if no Vendor-Information is available,
   then this attribute MUST be used with Length set to 2. Such
   attributes indicate that no Vendor-Information was available for a
   particular node within the L2TP tunnel path. The sequence of RADIUS
   Vendor-Information attributes MUST follow that of any L2TP Vendor-
   Information AVPS received.


4. Security Considerations

   This document describes mechanisms where arbitrary, human-readable
   information can be sent between L2TP peers.  User of these AVPs
   should have the understanding that any information sent is completely
   insecure.  If the information sent could be used for malicious
   purposes, the use of the features described in this document
   increases the possibility of that information being compromised.  In
   particular, since the text message AVP SHOULD NOT be hidden, even
   that security feature cannot be employed.


5. References

[RFC2661] Townsley W., et al., "Layer Two Tunneling Protocol (L2TP)",
          RFC 2661, August 1999.

[RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

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

[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
          2279, January 1998.

[BCP9]    Bradner, S., "The Internet Standards Process -- Revision 3",
          BCP 9, RFC 2026, October 1996.

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




Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt          [Page 9]


INTERNET DRAFT       L2TP Call Information Messages        November 2002


[BCP18]   H. Alvestrand, "IETF Policy on Character Sets and Languages",
          BCP 18, RFC 2277, January 1998.

[BCP26]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998.

[STD51]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
          1661, July 1994.

[SESINFO] Palter, William et al, "L2TP Session Information", draft-ietf-
          l2tpext-sesinfo-04.txt, February 2002.






6. 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.


7. Authors' Addresses

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

   Email: tmistretta@juniper.net


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

   Email: igoyret@lucent.com









Mistretta, et al.  draft-mistretta-l2tp-infomsg-01.txt         [Page 10]


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