Internet DRAFT - draft-etienne-ietf-secure-pmtud
draft-etienne-ietf-secure-pmtud
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]
