Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Standards Track October 23, 2006 Expires: April 26, 2007 Requirements for IP-in-IP Tunnel MTU Assurance draft-templin-mtuassurance-02.txt 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract IP-in-IP tunnels present a Maximum Transmission Unit (MTU) to layer 3 via static prearrangements and/or dynamic MTU determination based on layer 2 ICMP messages, but these methods have known operational limitations that can fail to enforce an assured MTU resulting in degraded performance and communications failures. A method for providing an assured MTU to layer 3 over IP-in-IP tunnels is needed. Templin Expires April 26, 2007 [Page 1] Internet-Draft Requirements for MTU Assurance October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems with Network-Based Fragmentation . . . . . . . . . . . 3 3. Problems with Path MTU Discovery . . . . . . . . . . . . . . . 3 4. Requirements for IP-in-IP Tunnel MTU Assurance . . . . . . . . 4 4.1. Tunnel Endpoint Negotiation . . . . . . . . . . . . . . . . 4 4.2. Compatible with IP Mechanisms . . . . . . . . . . . . . . . 4 4.3. Host-based Segmentation at the Encapsulator . . . . . . . . 4 4.4. Reassembly at the Decapsulator . . . . . . . . . . . . . . 4 4.5. Means for Detecting Packet Splicing Errors . . . . . . . . 5 4.6. Means for Accommodating Out-of-Order Delivery . . . . . . . 5 4.7. Path Probing by the Encapsulator . . . . . . . . . . . . . 5 4.8. Authenticated Probe Response from the Decapsulator . . . . 5 4.9. Proactive Path Probing . . . . . . . . . . . . . . . . . . 5 4.10. Decapsulator MRU Discovery . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Templin Expires April 26, 2007 [Page 2] Internet-Draft Requirements for MTU Assurance October 2006 1. Introduction IP-in-IP tunnels span multiple layer 2 network hops yet are seen by layer 3 as ordinary links that must support an assured MTU, e.g., 1280 bytes for the IPv6 minimum MTU. Common tunneling mechanisms (e.g., [RFC2529][RFC3056][RFC3931][RFC4213][RFC4214][RFC4380]) meet this requirement through conservative static prearrangements at the expense of degraded performance and/or communications failures over some paths due to excessive layer 2 network-based fragmentation. Optional dynamic MTU determination methods based on layer 2 ICMP "packet too big" messages are also available, but can result in communication failures due to the unreliable and untrustworthy nature of layer 2 ICMP messages generated by network middleboxes. This document discusses operational issues with the MTU determination schemes used by common tunneling mechanisms and outlines requirements for a new method that can present an assured MTU to layer 3. 2. Problems with Network-Based Fragmentation Common IP-in-IP tunneling mechanism encapsulators set a static layer 3 tunnel MTU (e.g., 1280 bytes or slightly larger for IPv6) and do not set the DF bit in the layer 2 IP headers of tunneled packets such that packets that are too large to traverse the path before reaching the decapsulator will be fragmented by the network. Unfortunately, network-based IP fragmentation has well-known issues [FRAG][RFC4459][I-D.heffner-frag-harmful] that can result in degraded performance and/or communications failures along some paths. In particular, a) firewalls and NAT boxes typically discard fragments other than the first fragment of fragmented IP datagrams, and b) self-sustaining cyclical reassembly mis-associations due to fragment loss can occur resulting in communications failures. 3. Problems with Path MTU Discovery IP-in-IP tunneling mechanisms can use Path MTU Discovery by setting the DF bit in the layer 2 IP headers of tunneled packets, but this method relies on layer 2 ICMP "packet too big" messages coming from untrusted network middleboxes along the path. A well-known issue is that ICMP messages are often dropped by firewalls and/or NATs resulting in MTU-related black holes along some paths [RFC2923]. Additionally, the untrusted middlebox paradigm opens the possibility for various spoofing attacks via fabricated ICMP messages inserted by on-path or off-path adversaries. [I-D.ietf-pmtud-method] and [I-D.gont-tcpm-icmp-attacks] discuss possible mitigations for dealing with fabricated ICMP messages, but no mitigations are possible when legitimate middleboxes fail to send/forward the ICMP's. Templin Expires April 26, 2007 [Page 3] Internet-Draft Requirements for MTU Assurance October 2006 4. Requirements for IP-in-IP Tunnel MTU Assurance Due to the operational issues with both layer 2 network-based IP fragmentation and ICMP-based Path MTU discovery, a new mechanism is needed to assure efficient and robust use of the available MTU over IP-in-IP tunnels. In particular, a mechanism is needed to present an assured MTU to layer 3 such that packets no larger than the MTU will be accepted by the tunnel or a suitable layer 3 "packet too big" message will be returned. The following subsections present requirements for IP-in-IP tunnel MTU assurance: 4.1. Tunnel Endpoint Negotiation The MTU assurance scheme must provide a means for the encapsulating and decapsulating tunnel endpoints to determine that the scheme is implemented at both ends. When only one (or neither) of the tunnel endpoints implements the scheme, behavior must revert back to that specified by the current tunneling mechanisms. 4.2. Compatible with IP Mechanisms The MTU assurance scheme must be compatible with both layer 2 network-based IP fragmentation/reassembly and layer 2 ICMP "packet too big" messages from Path MTU Discovery that may occur from within the tunnel. In particular, any packets prepared by the MTU assurance scheme must not be disrupted by any layer 2 network-based IP fragmentation that occurs along the path. An encapsulating node that implements the MTU assurance scheme must also be prepared to deal with any layer 2 ICMP "packet too big" messages it may receive in response to tunneled packets, e.g. as outlined in [I-D.ietf-pmtud-method][I-D.gont-tcpm-icmp-attacks]. 4.3. Host-based Segmentation at the Encapsulator The MTU assurance scheme must provide a means for the encapsulating tunnel endpoint to split layer 3 payloads into segments that are no larger than the tunnel path MTU. The segmentation must occur below layer 3 and prior to layer 2 IP encapsulation. 4.4. Reassembly at the Decapsulator The MTU assurance scheme must provide a means for the decapsulating tunnel endpoint to reassemble layer 3 payloads that were conveyed in multiple segments from the encapsulator. The reassembly must occur after layer 2 IP reassembly (and prior to layer 3 delivery), since it is possible that the segments may have also incurred fragmentation Templin Expires April 26, 2007 [Page 4] Internet-Draft Requirements for MTU Assurance October 2006 along the path. 4.5. Means for Detecting Packet Splicing Errors The MTU assurance scheme must provide a means for the decapsulating tunnel endpoint to detect packet splicing errors as it reassembles the segments of layer 3 payloads. 4.6. Means for Accommodating Out-of-Order Delivery The MTU assurance scheme must provide a means for the decapsulating tunnel endpoint to accommodate out-of-order delivery for the segments it receives while reassembling the segments of layer 3 payloads. 4.7. Path Probing by the Encapsulator The MTU assurance scheme must provide a means for the encapsulator to send "probe" segments used to determine whether segments of a certain size can traverse the tunnel. The scheme should allow for in-of-band path probing (i.e., when the probe segment is a segment of an actual tunneled packet) and must allow for out-of-band path probing. 4.8. Authenticated Probe Response from the Decapsulator The MTU assurance scheme must provide a means for the decapsulator to send an authenticated probe response message back to the encapsulator to acknowledge the receipt of a probe segment. 4.9. Proactive Path Probing The MTU assurance scheme should perform proactive path probing to quickly determine the most efficient segment size to use for a particular tunnel. The scheme should also periodically re-probe the path to determine whether path MTU reductions, e.g, due to route fluctuations, have occurred. 4.10. Decapsulator MRU Discovery The MTU assurance scheme must provide a means for an encapsulator to discover the maximum receive unit (MRU) for each decapsulator. 5. IANA Considerations This document does not introduce any IANA considerations. Templin Expires April 26, 2007 [Page 5] Internet-Draft Requirements for MTU Assurance October 2006 6. Security Considerations This document does not introduce any security considerations. 7. Acknowledgments This document represents the mindshare of many contributors. 8. Informative References [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful, In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology.", August 1987. [I-D.gont-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm-icmp-attacks-05 (work in progress), October 2005. [I-D.heffner-frag-harmful] Heffner, J., "Fragmentation Considered Very Harmful", draft-heffner-frag-harmful-02 (work in progress), June 2006. [I-D.ietf-pmtud-method] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", draft-ietf-pmtud-method-10 (work in progress), September 2006. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol Templin Expires April 26, 2007 [Page 6] Internet-Draft Requirements for MTU Assurance October 2006 (ISATAP)", RFC 4214, October 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006. Author's Address Fred L. Templin (editor) Boeing Phantom Works P.O. Box 3707 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Templin Expires April 26, 2007 [Page 7] Internet-Draft Requirements for MTU Assurance October 2006 Full 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Templin Expires April 26, 2007 [Page 8]