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

Versions: 00 01 03 04

Network Working Group                                     William Palter
Internet-Draft                                             Pipal Systems
Category: Standards Track                               W. Mark Townsley
<draft-ietf-l2tpext-sesinfo-04.txt>                        cisco Systems
                                                          Ignacio Goyret
                                                     Lucent Technologies
                                                            Suhail Nanji
                                                        Redback Networks
                                                           February 2002


                   L2TP Session Information "sesinfo"

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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-
   ietf-l2tpext-sesinfo-04.txt> and expires August 2002.  Please send
   comments to the L2TP mailing list (l2tpext@ietf.org).

Copyright Notice

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

Abstract

   This document defines additional L2TP AVPs that may be used during
   session or control connection establishment to provide additional
   node and port information for accounting and debugging use.




Townsley, et al.            Standards Track                     [Page 1]


INTERNET DRAFT                  SESINFO                    February 2002


   Contents

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

   1. Introduction..............................................    2

   2. AVPs......................................................    2

   4. IANA Considerations.......................................    5

   5. Security Considerations...................................    6

   6. Contacts..................................................    6

   7. References................................................    7

1. Introduction

   By design, an L2TP LNS is insulated from many of the details of the
   interface on which the session arrives before being tunneled. This
   abstraction is further mitigated when an L2TP session is directed to
   an additional tunnel via an L2TP Tunnel Switching (a.k.a. "Multihop")
   node. While not necessary for the proper operation of the tunneled
   session itself, it may be desirable for L2TP node identity, LAC
   media, and port information to be provided in a descriptive format
   for accounting or debugging use.

   It should be noted that the Framing Type and Bearer Type AVPs defined
   in [RFC2661] are designed simply to allow the LNS to tailor the PPP
   options it uses for the media the session is running over. They are
   not intended to fully describe the originating port type or LAC.
   Further, at the time this document is being written, there there is
   no standardized mechanism for keeping this information intact as a
   session traverses L2TP tunnel switching nodes.  None of the AVPs
   described in this document should have any effect on either the
   functioning of the tunnel or the parameters used in negotiating PPP
   parameters. They should only be used for logging, session limiting,
   accounting, and/or debugging purposes.

2. AVPs

   Each of the following AVPs are defined in a list format which is
   designed to allow propogation of information forward by receiving and
   appending values to each AVP list when passing through an L2TP tunnel
   switching node or LAC. Values in each list AVP are correlated based
   upon their actual position in the list, thus care must be taken that
   entries remain balanced properly for all lists propogated. In the
   event that a value is unknown for a given list, a suitable "default"



Townsley, et al.            Standards Track                     [Page 2]


INTERNET DRAFT                  SESINFO                    February 2002


   or "unknown" value (defined within the context of each AVP) MUST be
   inserted in any list AVPs before propogating.

   Each list entry is appended such that the last entry corresponds to
   the most recent sending node, and all preceding values are for
   "downstream" L2TP nodes. It is possible that all L2TP nodes did not
   participate in the Session Information extensions, in which case the
   entire list of L2TP nodes may not be accurately reflected at the
   final location.

   It is permissible, though not recommended, to implement only a
   portion of the AVP Lists defined in this document. However, if any of
   the AVPs defined in this document are implemented, the Port Type List
   MUST be among them. The Port Type List is the basis for correlating
   values in all other lists defined in this document.

   For example, if the Port Type List AVP (section 2.1) contained a
   single entry, and no other AVPs defined in this document are sent,
   this would be valid for a typical LAC aiming to implement the minimum
   requirements of this document. A more sophisticated L2TP tunnel
   switching node may then use the information in the single Port Type
   List AVP and entry, together with information from other sources
   (such as other AVPs defined outside this document), to populate the
   remaining AVP lists defined here. More specific information on this
   is decribed in the individual AVP definitions throughout this
   document.


   2.1 Port Type List (icrq, iccn)

      The Port Type List AVP is encoded as IETF Vendor ID 0, attribute
      TBD. The Value is a list of Port Types, using the same values that
      are used in RADIUS [RFC2058][RFC2059].  Each time an L2TP node
      forwards a session, a new value MUST be appended to this list
      before it is propogated.

      Note that the last port type (or first if there is only one value
      in the list) always represents the port type of the sender of the
      control message containing this AVP.












Townsley, et al.            Standards Track                     [Page 3]


INTERNET DRAFT                  SESINFO                    February 2002


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Port Type 0                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Port Type 1                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Port Type n                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.2 Channel ID List (icrq, iccn)

      The Channel ID List AVP is encoded as the IETF Vendor ID 0,
      Attribute TBD. The Value is a list of four octet values,
      representing the Channel ID of each node that the session has
      passed through. Each time an L2TP node forwards a session, a new
      value MUST be appended to this list before it is propogated. If
      there is no appropriate value, the reserved value 0 MUST be
      appended as a place holder.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Channel ID 0                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 Channel ID n                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      This AVP is analogous to the Physical Channel ID AVP defined in
      [RFC2661], except that it is allowed to grow as a list. As with
      the Port Type List, the last item in the list always represents
      the Channel ID of the sender of this AVP. Thus, the last value in
      the list should be identical to the Physical Channel ID AVP at any
      given node.

      In the event a tunnel switching node has implemented the
      extensions defined in this document but does not receive a Channel
      ID List from its downstream node, it MUST first copy the value
      received in the Physical Channel ID AVP at Session establishment
      into the Channel ID List before adding its own Channel ID to the
      list.

   2.3 L2TP Node Name List (sccrq, icrq, iccn)




Townsley, et al.            Standards Track                     [Page 4]


INTERNET DRAFT                  SESINFO                    February 2002


      The LAC Name List AVP is encoded as Vendor ID 0, Attribute TBD.
      The Value is a list of counted strings, with the octet prior to
      each string indicating the length of the string that follows it.
      Each time an L2TP node forwards a session, a new value MUST be
      appended to this list before it is propogated.  If there is no
      appropriate value, then a length of 0 MUST be inserted for the
      L2TP Node Name Length as a place holder. The L2TP Node Name should
      be a human readable value, analogous or equivalent to the value
      sent the the L2TP Hostname AVP defined in [RFC2661]. Human
      readable text in all messages MUST be provided in the UTF-8
      charset using the Default Language [RFC2277].

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | length  0      | L2TP Node Name 0 (1-255 octets)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | length  1      | L2TP Node Name 1 (1-255 octets)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                   ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        length  n      | L2TP Node Name n (1-255 octets)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP is analogous to the Hostname AVP defined in [RFC2661],
      except that it is allowed to grow as a list, and may be present at
      session as well as control connection startup. The last item in
      the list always represents the name of the sender of the message
      containing this AVP. Thus, the last value MAY be identical to that
      in the Hostname AVP.

      In the event a tunnel switching node has implemented the
      extensions defined in this document but does not receive a LAC
      Node Name List from its downstream node, it MUST first copy the
      value received in the Hostname AVP at Control Connection
      establishment into the LAC Node Name List before adding its own
      LAC Node Name to the list.

4. IANA Considerations

   This document requires three new "AVP Attributes" to be assigned
   through IETF Consensus [RFC2434] as indicated in Section 10.1 of
   [RFC2661]. These are:

      Port Type List (section 2.1)

      Channel ID List (section 2.2)




Townsley, et al.            Standards Track                     [Page 5]


INTERNET DRAFT                  SESINFO                    February 2002


      L2TP Node Name List (section 2.3)

   This document defines no additional number spaces for IANA to manage.

5. Security Considerations

   This document describes a method for propogating additional
   information about interfaces and equipment information by which a PPP
   session arrives before and after tunneling via L2TP.  While it is not
   obvious how this information could be used for malicious purposes, if
   it somehow was used to comprimise security then implementation of the
   mechanisms described in this document increase the number of times
   this information is made available on the network. AVP hiding,
   described in [RFC2661] MAY be used to help mitigate this, though it
   is not widely regarded as cryptographically secure. [RFC3193]
   describes a more robust method for securing L2TP in general, and
   should be used to encrypt all L2TP messages if access to the
   information sent within the AVPs described in this document is of
   concern.

6. Contacts

      Ignacio Goyret
      Lucent Technologies
      1701 Harbor Bay Parkway
      Alameda, CA 94502
      igoyret@lucent.com

      William Palter
      Pipal Systems
      palter.ietf@zev.net

      W. Mark Townsley
      cisco Systems
      7025 Kit Creek Road
      PO Box 14987
      Research Triangle Park, NC 27709
      mark@townsley.net

      Suhail Nanji
      RedBack Networks
      1389 Moffett Park Drive
      Sunnyvale, CA 94089
      suhail@redback.com







Townsley, et al.            Standards Track                     [Page 6]


INTERNET DRAFT                  SESINFO                    February 2002


7. References


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

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

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

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

      [RFC2058] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
                Authentication Dial In User Service (RADIUS)," RFC 2058,
                January 1997

      [RFC2059] C. Rigney, RADIUS Accounting, RFC 2059, January 1997

      [RFC3193] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing
                L2TP Using IPsec," RFC 3193, November 2001




























Townsley, et al.            Standards Track                     [Page 7]


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