Network Working Group J. Etienne Internet-Draft Nov 2001 Expires: May 2, 2002 Secure Path MTU discovery: framework draft-etienne-ietf-secure-pmtud-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/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 May 2, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document presents a framework for a secure path MTU discovery which intend to improve the security compared to the current method. The rfc1191 [5] method relies on unauthenticated packets sent by routers on the path. The lack of authentication allows an attacker to send fake packets and forces the host to instensively fragment all packets (see Appendix A). It is an effective DoS because it significantly increases the packet loss, dramatically reduces the effective bandwidth and can be done from anywhere in the internet. The secure path mtu discovery requires a cookie exchange between the router and the host before accepting the suggested MTU. Thus, it limits the scope of this attack to the adversaries on the path. We think it is acceptable as attacker on the path can perform more Etienne Expires May 2, 2002 [Page 1] Internet-Draft Secure Path MTU discovery: framework Nov 2001 efficient attacks(WORK: ref). Table of Contents 1. Notes: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Secure pmtu discovery overview . . . . . . . . . . . . . . . . 3 4.1 Cookie definition . . . . . . . . . . . . . . . . . . . . . . 3 4.2 In a nutshell . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Cookie generation . . . . . . . . . . . . . . . . . . . . . . 4 6. mark's location . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Relation with ICMP error packets . . . . . . . . . . . . . . . 5 6.2 UDP header . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3 IPv4 header . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 A. RFC1191 method and its security problems . . . . . . . . . . . 8 A.1 Attack overview . . . . . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 B. note about a 1RTT pmtu . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Etienne Expires May 2, 2002 [Page 2] Internet-Draft Secure Path MTU discovery: framework Nov 2001 1. Notes: This document is really a draft. read it at your own risk 2. Terminology 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 [8]. o path: The sequence of routers and (sub-)networks that a packet traverses from a particular source to a particular destination host. Note that a path is uni-directional; it is not unusual to have different paths in the two directions between a given host pair. This definition is inspired from rfc1812.B [6]. 3. Threat model The secure path MTU discovery assumes the attacker isn't on the path. An attacker on the path can perform at least as efficient attacks than the pmtu ones (WORK: include ip in appendix). It doesn't seem usefull to design a method able to resist to this kind of attacker as it will very likely be significantly more complex and won't increase the effective security. The attacker is assumed to know any informations which haven't been explicitly designed to be unpredictable by attackers out of the path (e.g IP address, TCP/UDP ports, IPsec SPI, TCP sequence number when RFC1948 [7] isn't applied). 4. Secure pmtu discovery overview The secure pmtu discovery is an application of the cookie (invented by Phil Karn and William Allen Simpson RFC2522.3.3 [12]) to the pmtud. very briefly, the suggested MTU is accepted only if the ICMP 'DF set and fragmentation needed' contains a valid cookie. 4.1 Cookie definition A cookie is an unpredictable value sent in clear by a server to a claimed client. The client replies it to prove it received the cookie. This process ensures the communication between the server and the client is bidirectionnal. As the cookie generation is stateless and fast (see Section 5), the server doesn't consume significant resources during the cookie exchange. An attacker not on the path can't know the cookie value, it can't consume server's rescources as a DoS. It dramatically reduce the DoS based on forged Etienne Expires May 2, 2002 [Page 3] Internet-Draft Secure Path MTU discovery: framework Nov 2001 source address (ala TCPsyn flood) because the attacker is now forced to be on the path. 4.2 In a nutshell When a host receives an ICMP 'DF set and fragmentation needed', it checks if it contains a valid cookie (WORK:ref). If so, the suggested MTU is accepted. If not, the host sends a probe (WORK: ref) which is larger than the suggested MTU and which contains a cookie. This probe is supposed to trigger an ICMP which would contain the cookie. When the host receives it, the suggested MTU is finally accepted. It requires an additionnaly round time trip between the router and the host compared to the RFC1191 [5] method but the frequency of pmtu changes is quite low (WORK: give numbers) and we believe the additionnal security overweights the additionnal delay. Cookies are generated and checked by the same host, any others simply ignoring their presence. So the local secret, the cookie's location and computation are purely a local matter and can be changed without notification. 5. Cookie generation The cookie is the output of a MAC with a local secret (e.g. HMAC- SHA1). The fields covers by the MAC depends on local configuration. o To check the cookie, the informations must be the same in the original IP header and in the ICMP error. They must be immutable in transit (RFC2402.3.3.3.1.1.1 [9]). o The fields used for the computation can't be used to store the cookie. This constraint may be removed by using a local secret directly instead of a MAC (WORK: ref ). o The mac SHOULD be statically unique for a given path, or attacker on one path could send fake ICMP to interrupt other paths with the same cookie. It isn't allowed by the threat model (Section 3). o To rely solely on IP addresses isn't sufficient as modern routing may use upper layer information. The connection information contained in the IPv4 header (RFC0791.3.1 [2]) are the source and destination addresses, the Type of Service (TOS), and the ip protocol. For UDP (RFC0768.p1 [1]) and TCP (RFC0793.3.1 [4]), the source and destination port are appended to the IP's connection information. Etienne Expires May 2, 2002 [Page 4] Internet-Draft Secure Path MTU discovery: framework Nov 2001 6. mark's location A probe is a packet dedicated to probe the path MTU. It is sent rather unfrequently, it doesnt need to be accepted by the other peer, or even to reach it. Its real destination is the router on the path which sent a ICMP triggered by a non-probe packet. o In this section, the mark means an value unpredictable by attackers not on the path. If may be a cookie (see Section 5) or an ephemeral random value (see WORK ref ). o In order to be verifiable, the mark MUST be included in fields immutable in transit (RFC2402.3.3.3.1.1.1 [9]). If the mark stored in the originated IP packet is modified in transit (from the originator to the router triggering the ICMP or from the router back to the originator), the spmtu discovery will fail and the connectivity will be lost. o spmtud uses a dedicated probe because it leaves more freedom in include the mark. o Note about the probe and the cookie localtion: it MUST be able to reach the end destination, it MAY be unacceptable by the end destination, it MUST NOT cause damage to the end destination, it SHOULD be legal, It SHOULD be 'usual' not to trigger bugs in the intermediary routers (WORK: can be estimated by experimentation with other ICMP errors such as TTL expired, aka traceroute) o Note about using UDP/TCP fields: UDP (RFC0768 [1]) and TCP (RFC0793 [4]) are theorically end to end protocols so only the source and the final destination should read them. Nevetheless firewall, proxy or other end2end brokers may read it and discard the packets if they considere them invalid. 6.1 Relation with ICMP error packets The sender of the ICMP is a router on the path. We assume it isn't under our control and we can't modify its behaviour. Concequently the ICMP authentication must rely on the part of the original datagram included with the ICMP packet. In the IPv4 case, ICMPv4 includes the IPv4 header + 64bits of the payload (RFC0792.p5 [3]). RFC1812.4.3.2.3 [6] specifies an ICMP error SHOULD include as much of the original datagram as possible up to 576 byte. Unfortunatly an informal statistic shows that XX % of the routers don't follow this requirement so we can't rely on it without loosing connectivity. (WORK: todo. tcpdump -e icmp and Etienne Expires May 2, 2002 [Page 5] Internet-Draft Secure Path MTU discovery: framework Nov 2001 traceroute all around the world find a list of host- top 50 site from phil) In the IPv6 case, ICMPv6 (RFC2463.2.4.c [11]) includes as much of the triggering packet and up to 1280 byte, the minimum IPv6 MTU (RFC2460.5 [10]). WORK: more likely to be actually done as IPv6 doesnt have the history of IPv4 but need to be checked. In any case, as the packet is never completly included, it is required to authenticate only part of the packets. It isn't considered as an issue as ICMP error are made to be associated to a given connection, so they contains the necessary informations. 6.2 UDP header As UDP is an end-to-end protocol and as the probe doesn't have to be acceptable by the destination, all header's fields may theorically be usable. Nevertheless, in practice, the packet may reach the destination and cause trouble to unauthenticated connections (e.g. by changing the ports) or end2end brokers may discard packet they considere invalid. The unused UDP fields (RFC0768.p1 [1]) are: o The udp length (16bit): to set it to a random value will create a invalid UDP packet. o The udp checksum (16bit): The packet is still valid as the probe payload may be adapated to make the checksum valid (see xref="UDP checksum to a random value"/>). WORK: what about the udp checksum inside the ICMP when it comes back to the NAT box, is it updated ? o The udp ports (32bits): The packet may reach the destination and cause trouble to unauthenticated connections. WORK: list trouble with end2end brokers. 6.3 IPv4 header The unused IPv4 fields are: o TOS (8bit) may be used for routing and "some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field" (RFC2402.3.3.3.1.1.1 [9]). o ID (16bit) is used only for reassemble the packet and in pmtud's Etienne Expires May 2, 2002 [Page 6] Internet-Draft Secure Path MTU discovery: framework Nov 2001 case the packet has DF set, so this field is considered unused. o the fragment offset (13bit), some routers (e.g. linux) don't generate ICMP error for fragments. o options: References [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 28 August 1980. [2] Postel, J., "Internet Protocol", STD 5, RFC 791, Sep 1981. [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, Sep 1981. [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, Sep 1981. [5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, Nov 1990. [6] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [7] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [11] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [12] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. Etienne Expires May 2, 2002 [Page 7] Internet-Draft Secure Path MTU discovery: framework Nov 2001 Author's Address Jerome Etienne EMail: jme@off.net URI: http://www.off.net/~jme Appendix A. RFC1191 method and its security problems On internet, the IPv4 pmtu discovery is based on RFC1191 [5]. In short, the algorithm is when a router receives a packet too large to be forwarded, it checks the 'Dont fragment' bit (DF RFC0791.p25 [2]). If it isn't set, the packet is fragmented and forwarded, else the router replies to the source an ICMP 'Fragmentation needed but DF set' (RFC0791.p5 [2]). The ICMP packet includes the largest acceptable size (RFC1191.4 [5]). The source uses this information to reduce its estimation of the path MTU. This process is applied as long as the packet doesn't reach its final destination (see RFC1191.2 [5] for a longer overview). A.1 Attack overview As the ICMP packets aren't authenticated, an attacker, anywhere on the internet, can send fake ones (RFC1191.8 [5]). The receiver sets the path MTU to the one suggested in the ICMP (RFC1191.2 [5]), in our case, chosen by the attacker. As the minimal IPv4 MTU is 68 byte (RFC0791.p25 [2]), the attacker can reduce the MTU to 68 byte and so produce a lot of fragmentation (WORK: ref on fragmentation considered harmfull). It is an effective DoS because it significantly increases the packet loss and dramatically reduce the effective bandwidth. Appendix B. note about a 1RTT pmtu This section explains an alternative to increase the security of the RFC1191 [5] method without increase the delay. Nevertheless it has significant disadvantages which motivated the 2RTT proposition. WORK: to write Etienne Expires May 2, 2002 [Page 8] Internet-Draft Secure Path MTU discovery: framework Nov 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Etienne Expires May 2, 2002 [Page 9]