Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3931

Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Pages: 94
Proposed Standard
Errata
Updated by:  5641
Part 5 of 5 – Pages 78 to 94
First   Prev   None

Top   ToC   RFC3931 - Page 78   prevText

8. Security Considerations

This section addresses some of the security issues that L2TP encounters in its operation.

8.1. Control Connection Endpoint and Message Security

If a shared secret (password) exists between two LCCEs, it may be used to perform a mutual authentication between the two LCCEs, and construct an authentication and integrity check of arriving L2TP control messages. The mechanism provided by L2TPv3 is described in Section 4.3 and in the definition of the Message Digest and Control Message Authentication Nonce AVPs in Section 5.4.1. This control message security mechanism provides for (1) mutual endpoint authentication, and (2) individual control message integrity and authenticity checking. Mutual endpoint authentication ensures that an L2TPv3 control connection is only established between two endpoints that are configured with the proper password. The individual control message and integrity check guards against accidental or intentional packet corruption (i.e., those caused by a control message spoofing or man-in-the-middle attack). The shared secret that is used for all control connection, control message, and AVP security features defined in this document never needs to be sent in the clear between L2TP tunnel endpoints.

8.2. Data Packet Spoofing

Packet spoofing for any type of Virtual Private Network (VPN) protocol is of particular concern as insertion of carefully constructed rogue packets into the VPN transit network could result in a violation of VPN traffic separation, leaking data into a customer VPN. This is complicated by the fact that it may be particularly difficult for the operator of the VPN to even be aware that it has become a point of transit into or between customer VPNs. L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit.
Top   ToC   RFC3931 - Page 79
   In the presence of a blind packet spoofing attack, the Cookie may
   also provide security against inadvertent leaking of frames into a
   customer VPN.  To illustrate the type of security that it is provided
   in this case, consider comparing the validation of a 64-bit Cookie in
   the L2TPv3 header to the admission of packets that match a given
   source and destination IP address pair.  Both the source and
   destination IP address pair validation and Cookie validation consist
   of a fast check on cleartext header information on all arriving
   packets.  However, since L2TPv3 uses its own value, it removes the
   requirement for one to maintain a list of (potentially several)
   permitted or denied IP addresses, and moreover, to guard knowledge of
   the permitted IP addresses from hackers who may obtain and spoof
   them.  Further, it is far easier to change a compromised L2TPv3
   Cookie than a compromised IP address," and a cryptographically random
   [RFC1750] value is far less likely to be discovered by brute-force
   attacks compared to an IP address.

   For protection against brute-force, blind, insertion attacks, a 64-
   bit Cookie MUST be used with all sessions.  A 32-bit Cookie is
   vulnerable to brute-force guessing at high packet rates, and as such,
   should not be considered an effective barrier to blind insertion
   attacks (though it is still useful as an additional verification of a
   successful Session ID lookup).  The Cookie provides no protection
   against a sophisticated man-in-the-middle attacker who can sniff and
   correlate captured data between nodes for use in a coordinated
   attack.

   The Assigned Cookie AVP is used to signal the value and size of the
   Cookie that must be present in all data packets for a given session.
   Each Assigned Cookie MUST be selected in a cryptographically random
   manner [RFC1750] such that a series of Assigned Cookies does not
   provide any indication of what a future Cookie will be.

   The L2TPv3 Cookie must not be regarded as a substitute for security
   such as that provided by IPsec when operating over an open or
   untrusted network where packets may be sniffed, decoded, and
   correlated for use in a coordinated attack.  See Section 4.1.3 for
   more information on running L2TP over IPsec.

9. Internationalization Considerations

The Host Name and Vendor Name AVPs are not internationalized. The Vendor Name AVP, although intended to be human-readable, would seem to fit in the category of "globally visible names" [RFC2277] and so is represented in US-ASCII. If (1) an LCCE does not signify a language preference by the inclusion of a Preferred Language AVP (see Section 5.4.3) in the
Top   ToC   RFC3931 - Page 80
   SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or
   (3) the requested language is not supported by the peer LCCE, the
   default language [RFC2277] MUST be used for all internationalized
   strings sent by the peer.

10. IANA Considerations

This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document. Sections 10.1 through 10.3 are requests for new values already managed by IANA according to [RFC3438]. The remaining sections are for new registries that have been added to the existing L2TP registry and are maintained by IANA accordingly.

10.1. Control Message Attribute Value Pairs (AVPs)

This number space is managed by IANA as per [RFC3438]. A summary of the new AVPs follows: Control Message Attribute Value Pairs Attribute Type Description --------- ------------------ 58 Extended Vendor ID AVP 59 Message Digest 60 Router ID 61 Assigned Control Connection ID 62 Pseudowire Capabilities List 63 Local Session ID 64 Remote Session ID 65 Assigned Cookie 66 Remote End ID 68 Pseudowire Type 69 L2-Specific Sublayer 70 Data Sequencing 71 Circuit Status 72 Preferred Language 73 Control Message Authentication Nonce 74 Tx Connect Speed 75 Rx Connect Speed
Top   ToC   RFC3931 - Page 81

10.2. Message Type AVP Values

This number space is managed by IANA as per [RFC3438]. There is one new message type, defined in Section 3.1, that was allocated for this specification: Message Type AVP (Attribute Type 0) Values ------------------------------------------ Control Connection Management 20 (ACK) Explicit Acknowledgement

10.3. Result Code AVP Values

This number space is managed by IANA as per [RFC3438]. New Result Code values for the CDN message are defined in Section 5.4. The following is a summary: Result Code AVP (Attribute Type 1) Values ----------------------------------------- General Error Codes 13 - Session not established due to losing tie breaker (L2TPv3). 14 - Session not established due to unsupported PW type (L2TPv3). 15 - Session not established, sequencing required without valid L2-Specific Sublayer (L2TPv3). 16 - Finite state machine error or timeout.
Top   ToC   RFC3931 - Page 82

10.4. AVP Header Bits

This is a new registry for IANA to maintain. Leading Bits of the L2TP AVP Header ----------------------------------- There six bits at the beginning of the L2TP AVP header. New bits are assigned via Standards Action [RFC2434]. Bit 0 - Mandatory (M bit) Bit 1 - Hidden (H bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved

10.5. L2TP Control Message Header Bits

This is a new registry for IANA to maintain. Leading Bits of the L2TP Control Message Header ----------------------------------------------- There are 12 bits at the beginning of the L2TP Control Message Header. Reserved bits should only be defined by Standard Action [RFC2434]. Bit 0 - Message Type (T bit) Bit 1 - Length Field is Present (L bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Sequence Numbers Present (S bit) Bit 5 - Reserved Bit 6 - Offset Field is Present [RFC2661] Bit 7 - Priority Bit (P bit) [RFC2661] Bit 8 - Reserved Bit 9 - Reserved Bit 10 - Reserved Bit 11 - Reserved
Top   ToC   RFC3931 - Page 83

10.6. Pseudowire Types

This is a new registry for IANA to maintain, there are no values assigned within this document to maintain. L2TPv3 Pseudowire Types ----------------------- The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review [RFC2434], while 32768 to 65535 are assigned by a First Come First Served policy [RFC2434]. There are no specific pseudowire types assigned within this document. Each pseudowire-specific document must allocate its own PW types from IANA as necessary.

10.7. Circuit Status Bits

This is a new registry for IANA to maintain. Circuit Status Bits ------------------- The Circuit Status field is a 16-bit mask, with the two low order bits assigned. Additional bits may be assigned by IETF Consensus [RFC2434]. Bit 14 - New (N bit) Bit 15 - Active (A bit)
Top   ToC   RFC3931 - Page 84

10.8. Default L2-Specific Sublayer bits

This is a new registry for IANA to maintain. Default L2-Specific Sublayer Bits --------------------------------- The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. Reserved bits may be assigned by IETF Consensus [RFC2434]. Bit 0 - Reserved Bit 1 - Sequence (S bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved Bit 6 - Reserved Bit 7 - Reserved

10.9. L2-Specific Sublayer Type

This is a new registry for IANA to maintain. L2-Specific Sublayer Type ------------------------- The L2-Specific Sublayer Type is a 2-octet unsigned integer. Additional values may be assigned by Expert Review [RFC2434]. 0 - No L2-Specific Sublayer 1 - Default L2-Specific Sublayer present

10.10. Data Sequencing Level

This is a new registry for IANA to maintain. Data Sequencing Level --------------------- The Data Sequencing Level is a 2-octet unsigned integer Additional values may be assigned by Expert Review [RFC2434]. 0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
Top   ToC   RFC3931 - Page 85

11. References

11.1. Normative References

[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, October 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

11.2. Informative References

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
Top   ToC   RFC3931 - Page 86
   [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
             51, RFC 1661, July 1994.

   [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC
             1700, October 1994.

   [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness
             Recommendations for Security", RFC 1750, December 1994.

   [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
             Internet", RFC 1958, June 1996.

   [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery
             for IP version 6", RFC 1981, August 1996.

   [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
             January 1997.

   [RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC:  Keyed-
             Hashing for Message Authentication", RFC 2104, February
             1997.

   [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer
             Two Forwarding (Protocol) L2F", RFC 2341, May 1998.

   [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
             Control", RFC 2581, April 1999.

   [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
             and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
             RFC 2637, July 1999.

   [RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for
             Literal IPv6 Addresses in URL's", RFC 2732, December 1999.

   [RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory
             Tunneling via RADIUS", RFC 2809, April 2000.

   [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two
             Tunneling Protocol (L2TP) over Frame Relay", RFC 3070,
             February 2001.
Top   ToC   RFC3931 - Page 87
   [RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two
             Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5
             (AAL5)", RFC 3355, August 2002.

   [KPS]     Kaufman, C., Perlman, R., and Speciner, M., "Network
             Security:  Private Communications in a Public World",
             Prentice Hall, March 1995, ISBN 0-13-061466-1.

   [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The
             Protocols", Addison-Wesley Publishing Company, Inc., March
             1996, ISBN 0-201-63346-9.

12. Acknowledgments

Many of the protocol constructs were originally defined in, and the text of this document began with, RFC 2661, "L2TPv2". RFC 2661 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and B. Palter. The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. Danny Mcpherson and Suhail Nanji published the first "L2TP Service Type" version, which defined the use of L2TP for tunneling of various L2 payload types (initially, Ethernet and Frame Relay). The team for splitting RFC 2661 into this base document and the companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided very helpful review and comment. Some constructs of L2TPv3 were based in part on UTI (Universal Transport Interface), which was originally conceived by Peter Lothberg and Tony Bates. Stewart Bryant and Simon Barber provided valuable input for the L2TPv3 over IP header. Juha Heinanen provided helpful review in the early stages of this effort. Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth and Maria Dos Santos contributed to the Control Message Authentication Mechanism as well as general discussions of security.
Top   ToC   RFC3931 - Page 88
   James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted
   Hardie, and Pekka Savola provided very helpful review of the final
   versions of text.

   Russ Housley provided valuable review and comment on security,
   particularly with respect to the Control Message Authentication
   mechanism.

   Pekka Savola contributed to proper alignment with IPv6 and inspired
   much of Section 4.1.4 on fragmentation.

   Aside of his original influence and co-authorship of RFC 2661, Glen
   Zorn helped get all of the language and character references straight
   in this document.

   A number of people provided valuable input and effort for RFC 2661,
   on which this document was based:

   John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
   Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
   review at the 43rd IETF in Orlando, FL, which led to improvement of
   the overall readability and clarity of RFC 2661.

   Thomas Narten provided a great deal of critical review and
   formatting.  He wrote the first version of the IANA Considerations
   section.

   Dory Leifer made valuable refinements to the protocol definition of
   L2TP and contributed to the editing of early versions leading to RFC
   2661.

   Steve Cobb and Evan Caves redesigned the state machine tables.
   Barney Wolff provided a great deal of design input on the original
   endpoint authentication mechanism.
Top   ToC   RFC3931 - Page 89

Appendix A: Control Slow Start and Congestion Avoidance

Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS] (this algorithm is also described in [RFC2581]). Slow start and congestion avoidance make use of several variables. The congestion window (CWND) defines the number of packets a sender may send before waiting for an acknowledgment. The size of CWND expands and contracts as described below. Note, however, that CWND is never allowed to exceed the size of the advertised window obtained from the Receive Window AVP. (In the text below, it is assumed any increase will be limited by the Receive Window Size.) The variable SSTHRESH determines when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH. A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgment (either explicit or piggybacked). When the acknowledgment is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ACK message or piggybacked) is received. Increasing CWND by one on each ACK has the effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins. During congestion avoidance, CWND expands more slowly. Specifically, it increases by 1/CWND for every new ACK received. That is, CWND is increased by one packet after CWND new ACKs have been received. Window expansion during the congestion avoidance phase is effectively linear, with CWND increasing by one packet each round trip. When congestion occurs (indicated by the triggering of a retransmission) one-half of the CWND is saved in SSTHRESH, and CWND is set to one. The sender then reenters the slow start phase.
Top   ToC   RFC3931 - Page 90

Appendix B: Control Message Examples

B.1: Lock-Step Control Connection Establishment

In this example, an LCCE establishes a control connection, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within an ACK message. An alternative would be to piggyback the acknowledgment within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the control connection. LCCE A LCCE B ------ ------ SCCRQ -> Nr: 0, Ns: 0 <- SCCRP Nr: 1, Ns: 0 SCCCN -> Nr: 1, Ns: 1 <- ACK Nr: 2, Ns: 1

B.2: Lost Packet with Retransmission

An existing control connection has a new session requested by LCCE A. The ICRP is lost and must be retransmitted by LCCE B. Note that loss of the ICRP has two effects: It not only keeps the upper level state machine from progressing, but also keeps LCCE A from seeing a timely lower level acknowledgment of its ICRQ. LCCE A LCCE B ------ ------ ICRQ -> Nr: 1, Ns: 2 (packet lost) <- ICRP Nr: 3, Ns: 1 (pause; LCCE A's timer started first, so fires first) ICRQ -> Nr: 1, Ns: 2 (Realizing that it has already seen this packet, LCCE B discards the packet and sends an ACK message) <- ACK Nr: 3, Ns: 2
Top   ToC   RFC3931 - Page 91
      (LCCE B's retransmit timer fires)

                                         <-      ICRP
                                         Nr: 3, Ns: 1
       ICCN      ->
       Nr: 2, Ns: 3

                                         <-       ACK
                                         Nr: 4, Ns: 2

Appendix C: Processing Sequence Numbers

The Default L2-Specific Sublayer, defined in Section 4.6, provides a 24-bit field for sequencing of data packets within an L2TP session. L2TP data packets are never retransmitted, so this sequence is used only to detect packet order, duplicate packets, or lost packets. The 24-bit Sequence Number field of the Default L2-Specific Sublayer contains a packet sequence number for the associated session. Each sequenced data packet that is sent must contain the sequence number, incremented by one, of the previous sequenced packet sent on a given L2TP session. Upon receipt, any packet with a sequence number equal to or greater than the current expected packet (the last received in-order packet plus one) should be considered "new" and accepted. All other packets are considered "old" or "duplicate" and discarded. Note that the 24-bit sequence number space includes zero as a valid sequence number (as such, it may be implemented with a masked 32-bit counter if desired). All new sessions MUST begin sending sequence numbers at zero. Larger or smaller sequence number fields are possible with L2TP if an alternative format to the Default L2-Specific Sublayer defined in this document is used. While 24 bits may be adequate in a number of circumstances, a larger sequence number space will be less susceptible to sequence number wrapping problems for very high session data rates across long dropout periods. The sequence number processing recommendations below should hold for any size sequence number field. When detecting whether a packet sequence number is "greater" or "less" than a given sequence number value, wrapping of the sequence number must be considered. This is typically accomplished by keeping a window of sequence numbers beyond the current expected sequence number for determination of whether a packet is "new" or not. The window may be sized based on the link speed and sequence number space and SHOULD be configurable with a default equal to one half the size of the available number space (e.g., 2^(n-1), where n is the number of bits available in the sequence number).
Top   ToC   RFC3931 - Page 92
   Upon receipt, packets that exactly match the expected sequence number
   are processed immediately and the next expected sequence number
   incremented.  Packets that fall within the window for new packets may
   either be processed immediately and the next expected sequence number
   updated to one plus that received in the new packet, or held for a
   very short period of time in hopes of receiving the missing
   packet(s).  This "very short period" should be configurable, with a
   default corresponding to a time lapse that is at least an order of
   magnitude less than the retransmission timeout periods of higher
   layer protocols such as TCP.

   For typical transient packet mis-orderings, dropping out-of-order
   packets alone should suffice and generally requires far less
   resources than actively reordering packets within L2TP.  An exception
   is a case in which a pair of packet fragments are persistently
   retransmitted and sent out-of-order.  For example, if an IP packet
   has been fragmented into a very small packet followed by a very large
   packet before being tunneled by L2TP, it is possible (though
   admittedly wrong) that the two resulting L2TP packets may be
   consistently mis-ordered by the PSN in transit between L2TP nodes.
   If sequence numbers were being enforced at the receiving node without
   any buffering of out-of-order packets, then the fragmented IP packet
   may never reach its destination.  It may be worth noting here that
   this condition is true for any tunneling mechanism of IP packets that
   includes sequence number checking on receipt (i.e., GRE [RFC2890]).

   Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only
   non-IP data packets require sequencing) allows IP data packets being
   tunneled by L2TP to not utilize sequence numbers, while utilizing
   sequence numbers and enforcing packet order for any remaining non-IP
   data packets.  Depending on the requirements of the link layer being
   tunneled and the network data traversing the data link, this is
   sufficient in many cases to enforce packet order on frames that
   require it (such as end-to-end data link control messages), while not
   on IP packets that are known to be resilient to packet reordering.

   If a large number of packets (i.e., more than one new packet window)
   are dropped due to an extended outage or loss of sequence number
   state on one side of the connection (perhaps as part of a forwarding
   plane reset or failover to a standby node), it is possible that a
   large number of packets will be sent in-order, but be wrongly
   detected by the peer as out-of-order.  This can be generally
   characterized for a window size, w, sequence number space, s, and
   number of packets lost in transit between L2TP endpoints, p, as
   follows:
Top   ToC   RFC3931 - Page 93
   If s > p > w, then an additional (s - p) packets that were otherwise
   received in-order, will be incorrectly classified as out-of-order and
   dropped.  Thus, for a sequence number space, s = 128, window size, w
   = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional
   packets would be dropped after the outage until the sequence number
   wrapped back to the current expected next sequence number.

   To mitigate this additional packet loss, one MUST inspect the
   sequence numbers of packets dropped due to being classified as "old"
   and reset the expected sequence number accordingly.  This may be
   accomplished by counting the number of "old" packets dropped that
   were in sequence among themselves and, upon reaching a threshold,
   resetting the next expected sequence number to that seen in the
   arriving data packets.  Packet timestamps may also be used as an
   indicator to reset the expected sequence number by detecting a period
   of time over which "old" packets have been received in-sequence.  The
   ideal thresholds will vary depending on link speed, sequence number
   space, and link tolerance to out-of-order packets, and MUST be
   configurable.

Editors' Addresses

Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134 EMail: jedlau@cisco.com W. Mark Townsley cisco Systems EMail: mark@townsley.net Ignacio Goyret Lucent Technologies EMail: igoyret@lucent.com
Top   ToC   RFC3931 - Page 94
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.

   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.

Intellectual Property

   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.

Acknowledgement

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