Subject: [L2tpext] draft-ietf-l2tpext-fresh-cookies

From: Neil McGill <[email-masked]>
Date: Tue, 28 Feb 2006 11:35:49 -0500 (EST)

Comments on this proposal welcome

Thanks,

Neil.

Network Working Group                                        Neil McGill
Internet Draft                                             cisco Systems
                                                        Carlos Pignataro
                                                           cisco Systems

                                                                 Feb2006

                           L2TP Fresh Cookies

Status of this Memo

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

   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-fresh-cookies" and expires .  Please send comments to
   the L2TP mailing list ([email-masked]).

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

Abstract

   This document defines extensions for the Layer 2 Transfer Protocol
   (L2TP) to allow L2TP peers to update the Assigned Cookie and other
   L2TP settings without tearing down any associated control channel or
   sessions.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 1]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 2]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

Contents

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

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

Status of this Memo ..........................................   2

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

Abstract .....................................................   1    3

Status of this Memo ..........................................   2    3

1. Introduction ..............................................   4    3

2. L2TP update protocol exchange .............................   5    3

3. New AVPs ..................................................   8    3

4. AVP considerations ........................................  11    3

5. L2TP update examples ......................................  14    3

6. Security Considerations ...................................  16    3

7.  IANA Considerations ......................................  16    3

8. Authors' Addresses ........................................  16    3

9. Normative References ......................................  16    3

10. Informative References ...................................  16    3

1. Introduction ..............................................   4
   1.1 Specification of Requirements .........................   4

2. L2TP update protocol exchange .............................   5

3. New AVPs ..................................................   8
   3.1 L2TP update request/response/confirm AVPs .............   8
   3.2 L2TP update accept/reject AVPs ........................   9

4. AVP considerations ........................................  11

5. L2TP update examples ......................................  14

6. Security Considerations ...................................  16

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 3]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

7.  IANA Considerations ......................................  16

8. Authors' Addresses ........................................  16

9. Normative References ......................................  16

10. Informative References ...................................  16

Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 4]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

1. Introduction

   L2TP exchanges the Assigned Cookie AVP (Attribute Value Pair) during
   session establishment. Unfortunately, this value never changes for
   the duration of a session, which may be long. The lack of any change
   in settings makes it easier for the connection to be compromised
   through brute force techniques and left potentially open to packet
   injection/denial of service attacks.

   This document specifies extensions which allow control channels and
   sessions to update certain AVPs without tearing down any connection.

   This document is aimed at the session-related Assigned Cookie AVP,
   however, the approach suggested can be used for a more general
   parameter update between L2TP peers.

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

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 5]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

2. L2TP update protocol exchange

   The updating of L2TP AVPs is performed via a three way handshake.
   This is done to prevent spoofing/injection of AVP updates and
   requires that each L2TP peer fully acknowledges a configuration
   change. The protocol message exchange is as follows:

   The initiating LCCE (L2TP control connection endpoint), LCCE A,
   provides AVPs that it wishes to negotiate or update to LCCE B. These
   AVPs are carried either in an SLI or UPDATE message.

   The receiving LCCE, LCCE B, will then either explicitly accept or
   reject all the received AVPs in its response (or propose a new
   value).  Certain AVPs are explicitly excluded from the update
   mechanism, and those are listed later.

   The initiating LCCE, LCCE A, confirms acceptance of the negotiated or
   updated AVPs.

   LCCE A and LCCE B for a time MAY accept both the old and new AVP
   values.  Once the implementation deems that both peers have migrated
   to the new AVP values, the old value MAY be flushed. This time period
   is defined by the implementation, but should consider packets that
   may be queued and still using the old AVP values.

   The SLI message type MAY be used to relay these AVPs between peers.
   This is suitable for updates performed on sessions. The SLI means of
   updating MUST also be implemented via the three way handshake. This
   avoids the peer needing to assume any pre-arranged capability with
   the peer, which would be needed if only a single SLI was used to
   convey updates. The handshake also provides a scope for the receiving
   peer to reject particular updates which would not be possible with a
   single message.

   Alternatively, the following new message types MAY be used for a more
   explicit request/response/confirm handshake. This has the advantage
   of being more visible in message logging against a background of SLI
   status updates.

   The new message types are:

      MSG-TBD1  (CC-UPDATE-REQ)     Control Channel Update Request
      MSG-TBD2  (CC-UPDATE-RSP)     Control Channel Update Response
      MSG-TBD3  (CC-UPDATE-CNF)     Control Channel Update Confirm
      MSG-TBD4  (SN-UPDATE-REQ)     Session Update Request
      MSG-TBD5  (SN-UPDATE-RSP)     Session Update Response
      MSG-TBD6  (SN-UPDATE-CNF)     Session Update Confirm

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 6]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

   The exchange of each set of message types is identical for control
   channels vs sessions. The three way handshake is done as follows:

      LCCE A                    LCCE B
      ------                    ------
      *-UPDATE-REQ ->
      (with list of proposed AVPs)

                                <- *-UPDATE-RSP
                                (indicates accepted/rejected AVPs)
      *-UPDATE-CNF ->
      (confirms changes or rejects alternatives)

   When using SLI for a session oriented update, an additional AVP is
   included to convey the request/response/confirm status.

      LCCE A                    LCCE B
      ------                    ------
      SLI {request} ->
      (with list of proposed AVPs)

                                <- SLI {response}
                                (indicates accepted/rejected AVPs)
      SLI {confirm} ->
      (confirms changes or rejects alternatives)

   NOTES

   - The new Message-Type AVPs MUST be sent with the M-bit set to 0 to
   cater for peers that may not support these optional messages.

   - The full three way handshake MUST be supported for either SLI or
   UPDATE messages. This protects against IP spoofing from a party
   injecting request or response packets between the LCCEs.

   - If a peer receives an unexpected response or confirm SLI or UPDATE
   it MAY tear down the session/control channel (whichever is
   appropriate) and log this event. This might be an indication of
   packet injection.

   - The three way handshake MAY restart, once completed, in the event
   of peers failing to agree on some settings. This would be a new three
   way handshake and MAY attempt to negotiate those AVPs that could not
   be agreed on in the earlier.

   - All AVPS listed in a request or response MUST either be accepted or
   rejected in the corresponding response and confirm messages. If not
   listed, the receiving peer MUST assume the value was rejected and

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 7]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

   continue using the original value.

   - Unrecognized AVPS MUST be rejected and included in the rejected
   list returned to the peer.

   - Message digest MAY be used for all message exchanges. This ensures
   that the messages have not been tampered with.

   - Where the AVPs being exchanged are security/verification oriented
   (Assigned Cookie), the response and confirm messages SHOULD only list
   these AVPs using the acceptance/rejection AVPs, defined later.  This
   practice discourages re-sending of the full AVP contents multiple
   times.

   - Where negotiation of an AVP is being performed and the AVP is not
   security sensitive, the full AVP MAY be passed back and forth. If
   agreement on a value is not reached by the end of the handshake, a
   new handshake MAY be started.

   - Where full AVP values are received in a response message they are
   to be taken as alternatives offered by the peer. If this value is not
   acceptable, the initiator MUST reject the change.

   - All AVPs valid for the SLI message are valid for the SN-UPDATE
   messages.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 8]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

3. New AVPs

3.1 L2TP update request/response/confirm AVPs

   When SLI is being used as the means of transport for updated AVPs,
   the following AVP (type AVP-TBD1) MUST be included to indicate the
   state of the message

       0               1
       0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H|0|0|Rsv|      Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Vendor Id [IETF]       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Value MUST be one of:

      0 - Request message

      1 - Response message

      2 - Confirm message

   - Each AVP is encoded as the IETF Vendor ID 0,

   - These AVPs are not stackable and do not pass-through a multi-hop
   node.

   - The update/negotiation mechanism is local to a LCCE pair.

   - The M-bit for these new AVPs MUST be set to 0.

   - The H-bit MAY be set based on the current L2TP node's policy.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies            [Page 9]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

3.2 L2TP update accept/reject AVPs

   The following additional AVP types are proposed to allow the
   acceptance and/or rejection of earlier proposed AVP values without
   the need to reply with the full AVP contents.

   These AVPs MAY be used where the AVP being updated is security
   sensitive, e.g. Assigned Cookie. However, it MAY be used for any AVP.

   The following format is common to both AVPs:

       0               1
       0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H|0|0|Rsv|      Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Vendor Id [IETF]       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Vendor Id [IETF] #1    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute Type  #1    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Vendor Id [IETF] #n    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute Type  #n    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   These AVPs, length 0-253, allow multiple embedded AVP vendor/type
   values to be encoded indicating either acceptance or rejection of a
   previous value.

   NOTES:

   - The following new attribute types (value AVP-TBD2, AVP-TBD3)
   defined are:

   Update-Accepted

      Indicates that all embedded AVPs listed in the AVP value portion
      have been accepted by the peer.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 10]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

   Update-Rejected

      Indicates that all embedded AVPs listed in the AVP value portion
      have been rejected by the peer.

   - Each AVP is encoded as the IETF Vendor ID 0,

   - These AVPs are not stackable and do not pass-through a multi-hop
   node.

   - The update/negotiation mechanism is local to a LCCE pair.

   - The M-bit for these new AVPs MUST be set to 0.

   - The H-bit MAY be set based on the current L2TP node's policy.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 11]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

4. AVP considerations

   Not all AVPs are suitable for updating between peers. The following
   is a list, not exhaustive, of AVPs which are deemed unsuitable for
   negotiation and updating. Such AVPs MUST not be considered as part of
   AVP updating and should be ignored as part of this process and
   processed normally.

          Result Code                              (IETF AVP 1)
          Protocol Version                         (IETF AVP 2)
          Tie Breaker                              (IETF AVP 5)
          Hostname                                 (IETF AVP 7)
          Assigned Tunnel ID                       (IETF AVP 9)
          Challenge                                (IETF AVP 11)
          Challenge Resp                           (IETF AVP 13)
          Q931 Cause Code                          (IETF AVP 12)
          Assigned Call ID                         (IETF AVP 14)
          Bearer Type                              (IETF AVP 18)
          Framing Type                             (IETF AVP 19)
          Called Number                            (IETF AVP 21)
          Calling Number                           (IETF AVP 22)
          Sub-Address                              (IETF AVP 23)
          Initial LCPREQ                           (IETF AVP 26)
          Last Sent LCPREQ                         (IETF AVP 27)
          Last Rx LCPREQ                           (IETF AVP 28)
          Proxy Auth Type                          (IETF AVP 29)
          Proxy Auth Name                          (IETF AVP 30)
          Proxy Auth Chal                          (IETF AVP 31)
          Proxy Auth ID                            (IETF AVP 32)
          Proxy Auth Resp                          (IETF AVP 33)
          ACCM                                     (IETF AVP 35)
          Sub-Address Ext                          (IETF AVP 44)
          VPI/VCI Identifier                       (IETF AVP 45)
          PPP Disconnect Cause Code (IETF)         (IETF AVP 46)
          LCP Want Options                         (IETF AVP 49)
          LCP Allow Options                        (IETF AVP 50)
          LNS Last Sent LCP Confreq                (IETF AVP 51)
          LNS Last Received LCP Confreq            (IETF AVP 52)
          Modem On-Hold Status                     (IETF AVP 54)
          PPPoE Relay                              (IETF AVP 55)
          Call Error                               (IETF AVP 34)
          Random Vector                            (IETF AVP 36)
          Seq Required                             (IETF AVP 39)
          Extended Vendor ID                       (IETF AVP 58)
          Message Digest                           (IETF AVP 59)
          Peer Router ID                           (IETF AVP 60)
          Assigned Control Connection ID           (IETF AVP 61)
          Local Session ID                         (IETF AVP 63)

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 12]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

          Remote Session ID                        (IETF AVP 64)
          End Identifier                           (IETF AVP 66)
          Pseudo Wire Type                         (IETF AVP 68)
          L2 Specific Sublayer                     (IETF AVP 69)
          Data Sequencing                          (IETF AVP 70)
          Circuit Status                           (IETF AVP 71)
          CC Auth Nonce                            (IETF AVP 73)
          Failover Capability                      (IETF AVP 76)
          Tunnel Recovery                          (IETF AVP 77)
          Control Sequence                         (IETF AVP 78)
          Failover Session State                   (IETF AVP 79)

   The following AVPs are deemed suitable for negotiation/updating
   between peers. Again, this list is not exhaustive and intended as a
   guideline:

          Framing Cap                              (IETF AVP 3)
          Bearer Cap                               (IETF AVP 4)
          Firmware Ver                             (IETF AVP 6)
          Vendor Name                              (IETF AVP 8)
          Rx Window Size                           (IETF AVP 10)
          Serial Number                            (IETF AVP 15)
          Private Group ID                         (IETF AVP 37)
          Service Category                         (IETF AVP 42)
          Service Name                             (IETF AVP 43)
          CCDS                                     (IETF AVP 47)
          SDS                                      (IETF AVP 48)
          Modem On-Hold Capable                    (IETF AVP 53)
          Pseudo Wire Capabilities List            (IETF AVP 62)
          Assigned Cookie                          (IETF AVP 65)
          Application Code                         (IETF AVP 67)
          Preferred Language                       (IETF AVP 72)
          Connect Speed                            (IETF AVP 24)
          Phy Channel ID                           (IETF AVP 25)
          Rx Speed                                 (IETF AVP 38)
          Rx Min BPS                               (IETF AVP 40)
          Rx Max BPS                               (IETF AVP 41)
          Min BPS                                  (IETF AVP 16)
          Max BPS                                  (IETF AVP 17)
          Tx Connect Speed                         (IETF AVP 74)
          Rx Connect Speed                         (IETF AVP 75)

   The following AVPs are considered security oriented. As such, these
   SHOULD not be relayed back and forth with their full AVP contents.

          Assigned Cookie                          (IETF AVP 65)

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 13]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

   NOTES

   When a value is updated, a peer MAY allow acceptance of the old value
   for a period of time. How long, is implementation specific, and may
   be until the next update occurs.  However, be aware that the
   temporary presence of 2 Assigned Cookies presents an additional
   security risk.  Hence, there is a tradeoff between potentially
   dropping some packets that are using the old cookie and switching to
   the new cookie as soon as possible.

   However, for security related AVPS, it MAY be prudent to flush the
   old AVP value as soon as possible.

   If the Pseudo Wire Capabilities is changed such that a previously
   available type is now no longer lister, then the sessions MUST be
   torn down.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 14]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

5. L2TP update examples

5.1. Cookie update with session update messages

   In the following example, the session cookie is updated. This action
   may be done periodically and is implemention specific as to the
   policy driving this change.

      LCCE A                    LCCE B
      ------                    ------
      SN-UPDATE-REQ ->
      +local/remote session IDs
      +Cookie AVP with new hidden value

                                <- SN-UPDATE-RSP
                                +local/remote session IDs
                                +Update-Accepted {Cookie AVP}
      SN-UPDATE-CNF ->
      +local/remote session IDs
      +Update-Accepted {Cookie AVP}

5.2. Cookie update with SLI messages

   As with the UPDATE In the following example, the session cookie is
   updated; this time via SLI.

      LCCE A                    LCCE B
      ------                    ------
      SLI {request} ->
      +local/remote session IDs
      +Cookie AVP with new hidden value

                                <- SLI {response}
                                +local/remote session IDs
                                +Update-Accepted {Cookie AVP}
      SLI {confirm} ->
      +local/remote session IDs
      +Update-Accepted {Cookie AVP}

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 15]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

5.3. Update of multiple AVPs

   In the following example, The peers are negotiating a new pseudo-wire
   capability. The firmware revision is also sent as an update which is
   accepted by the peer.

   Message flow.

      LCCE A                    LCCE B
      ------                    ------
      CC-UPDATE-REQ ->
      +Pseudo Wire Capabilities = AAL5 | PPP
      +Firmware rev AVP = 2

                                <- CC-UPDATE-RSP
                                +Update-Accepted {Firmware rec AVP}
                                +Update-Rejected {Rx window size AVP}
                                +Pseudo Wire Capabilities = AAL5

      CC-UPDATE-CNF ->
      +Update-Accepted {Firmware rev AVP},
                       {Pseudo Wire Capabilities}

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 16]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

6. Security Considerations

   This document describes mechanisms where AVPs may be updated with a
   peer without tearing down a connection. Users of these AVPs should
   have the understanding that any information sent could be used for
   malicious purposes. As such, a full three way handshake and message
   digest checking MAY be performed.

7.  IANA Considerations

This document creates no new requirements on IANA namespaces [RFC2434].

8. Authors' Addresses

   Neil McGill
   7025-4 Kit Creek Rd,
   PO Box 14987,
   Research Triangle Park
   NC 27709

   Email: [email-masked]

9. Normative References

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

10. Informative References

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 17]

INTERNET DRAFT             L2TP fresh cookies                    Feb2006

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
   [email-masked].

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 (2006).

   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.

McGill, et al.      draft-ietf-l2tpext-fresh-cookies           [Page 18]

--

Neil McGill <mailto:[email-masked]>                        .       .
Software Developer: L2VPN                                  ~~""~""~"~"|~"~
MailStop RTP4E/3/1, Cube E3A0605                             |||     |||
Phone 919 392 3439, Fax 919 392 7200, Cell 919 623 7413   .:|||||:.:|||||:.
Home  919 325 9401

7025-4 Kit Creek Rd, PO Box 14987, Research Triangle Park
NC 27709

   I used to think I knew what made a hero; now I do.

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext