[L2tpext] draft-ietf-l2tpext-fresh-cookies
Neil McGill <nmcgill@cisco.com> Tue, 28 February 2006 16:26 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE7gW-0004r3-Rx; Tue, 28 Feb 2006 11:26:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE7gV-0004qm-QD for l2tpext@ietf.org; Tue, 28 Feb 2006 11:26:47 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE7gU-0000uH-J1 for l2tpext@ietf.org; Tue, 28 Feb 2006 11:26:47 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Feb 2006 17:26:46 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1SGQjpE004677 for <l2tpext@ietf.org>; Tue, 28 Feb 2006 17:26:45 +0100 (MET)
Received: from dhcp-64-102-48-243.cisco.com (dhcp-64-102-48-243.cisco.com [64.102.48.243]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA06572 for <l2tpext@ietf.org>; Tue, 28 Feb 2006 16:26:44 GMT
Date: Tue, 28 Feb 2006 11:35:49 -0500
From: Neil McGill <nmcgill@cisco.com>
X-X-Sender: nmcgill@liberator
To: l2tpext@ietf.org
Message-ID: <Pine.LNX.4.58.0602281132270.2258@liberator>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 2.0 (++)
X-Scan-Signature: d6b0e0d49fdeccc4f4975ee60f85ef51
Subject: [L2tpext] draft-ietf-l2tpext-fresh-cookies
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l2tpext>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
Errors-To: l2tpext-bounces@ietf.org
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 (l2tp@l2tp.net).
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: nmcgill@cisco.com
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
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 (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:nmcgill@cisco.com> . .
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
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext
- [L2tpext] draft-ietf-l2tpext-fresh-cookies Neil McGill