| TOC |
|
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 (C) The Internet Society (2001). All Rights Reserved.
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 RFC1191 method and its security problems). 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 efficient attacks(WORK: ref).
| TOC |
| TOC |
This document is really a draft. read it at your own risk
| TOC |
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].
| TOC |
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).
| TOC |
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.
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 Cookie generation), 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 source address (ala TCPsyn flood) because the attacker is now forced to be on the path.
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.
| TOC |
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.
| TOC |
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.
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 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.
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:
The unused IPv4 fields are:
| TOC |
| TOC |
| Jerome Etienne | |
| EMail: | jme@off.net |
| URI: | http://www.off.net/~jme |
| TOC |
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).
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.
| TOC |
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
| TOC |
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.
Funding for the RFC Editor function is currently provided by the Internet Society.