7.3.2. Denial of Service by Server Spoofing
In Section 7.2, we discussed the use of spoofed router advertisements
to insert an attacker in the middle of a Teredo conversation. The
spoofed router advertisements can also be used to provision a client
with an incorrect address, pointing to either a non-existing IPv4
address or the IPv4 address of a third party.
The Teredo client will detect the attack when it fails to receive
traffic through the newly acquired IPv6 address. The attack can be
mitigated by using the authentication encapsulation.
7.3.3. Denial of Service by Exceeding the Number of Peers
A Teredo client manages a cache of recently used peers, which makes
it stateful. It is possible to mount an attack against the client by
provoking it to respond to packets that appear to come from a large
number of Teredo peers, thus trashing the cache and effectively
denying the use of direct communication between peers. The effect
will last only as long as the attack is sustained.
7.3.4. Attacks against the Local Discovery Procedure
There is a possible denial of service attack against the local peer
discovery procedure, if attackers can manage to send spoofed local
discovery bubbles to a Teredo client. The checks described in
Section 5.2.8 mitigate this attack. Clients who are more interested
in security than in performance could decide to disable the local
discovery procedure; however, if local discovery is disabled, traffic
between local nodes will end up being relayed through a server
external to the local network, which has questionable security
implications.
7.3.5. Attacking the Teredo Servers and Relays
It is possible to mount a brute force denial of service attack
against the Teredo servers by sending them a very large number of
packets. This attack will have to be brute force, since the servers
are stateless, and can be designed to process all the packets that
are sent on their access line.
The brute force attack against the Teredo servers is mitigated if
clients are ready to "failover" to another server. Bringing down the
servers will, however, force the clients that change servers to
renumber their Teredo address.
It is also possible to mount a brute force attack against a Teredo
relay. This attack is mitigated if the relay under attack stops
announcing the reachability of the Teredo service prefix to the IPv6
network: the traffic will be picked up by the next relay.
An attack similar to that described in Section 7.3.2 can be mounted
against a relay. An IPv6 host can send IPv6 packets to a large
number of Teredo destinations, forcing the relay to establish state
for each of these destinations. Teredo relays can obtain some
protection by limiting the range of IPv6 clients that they serve, and
by limiting the amount of state used for "new" peers.
7.4. Denial of Service against Non-Teredo Nodes
There is a widely expressed concern that transition mechanisms such
as Teredo can be used to mount denial of service attacks, by
injecting traffic at locations where it is not expected. These
attacks fall in three categories: using the Teredo servers as a
reflector in a denial of service attack, using the Teredo server to
carry a denial of service attack against IPv6 nodes, and using the
Teredo relays to carry a denial of service attack against IPv4 nodes.
The analysis of these attacks follows. A common mitigating factor in
all cases is the "regularity" of the Teredo traffic, which contains
highly specific patterns such as the Teredo UDP port, or the Teredo
IPv6 prefix. In case of attacks, these patterns can be used to
quickly install filters and remove the offending traffic.
We should also note that none of the listed possibilities offer any
noticeable amplification.
7.4.1. Laundering DoS attacks from IPv4 to IPv4
An attacker can use the Teredo servers as reflectors in a denial of
service attack aimed at an IPv4 target. The attacker can do this in
one of two ways. The first way is to construct a Router Solicitation
message and post it to a Teredo server, using as IPv4 source address
the spoofed address of the target; the Teredo server will then send a
Router advertisement message to the target. The second way is to
construct a Teredo IPv6 address using the Teredo prefix, the address
of a selected server, the IPv4 of the target, and an arbitrary UDP
port, and to then send packets bound to that address to the selected
Teredo server.
Reflector attacks are discussed in [REFLECT], which outlines various
mitigating techniques against such attacks. One of these mitigations
is to observe that "the traffic generated by the reflectors [has]
sufficient regularity and semantics that it can be filtered out near
the victim without the filtering itself constituting a denial-of-
service to the victim (’collateral damage’)". The traffic reflected
by the Teredo servers meets this condition: it is clearly
recognizable, since it originates from the Teredo UDP port; it can be
filtered out safely if the target itself is not a Teredo user. In
addition, the packets relayed by servers will carry an Origin
indication encapsulation, which will help determine the source of the
attack.
7.4.2. DoS Attacks from IPv4 to IPv6
An attacker may use the Teredo servers to launch a denial of service
attack against an arbitrary IPv6 destination. The attacker will
build an IPv6 packet bound for the target and will send that packet
to the IPv4 address and UDP port of a Teredo server, to be relayed
from there to the target over IPv6.
The address checks specified in Section 5.3.1 provide some protection
against this attack, as they ensure that the IPv6 source address will
be consistent with the IPv4 source address and UDP source port used
by the attacker: if the attacker cannot spoof the IPv4 source
address, the target will be able to determine the origin of the
attack.
The address checks ensure that the IPv6 source address of packets
forwarded by servers will start with the IPv6 Teredo prefix. This is
a mitigating factor, as sites under attack could use this to filter
out all packets sourced from that prefix during an attack. This will
result in a partial loss of service, as the target will not be able
to communicate with legitimate Teredo hosts that use the same prefix.
However, the communication with other IPv6 hosts will remain
unaffected, and the communication with Teredo hosts will be able to
resume when the attack has ceased.
7.4.3. DoS Attacks from IPv6 to IPv4
An attacker with IPv6 connectivity may use the Teredo relays to
launch a denial of service attack against an arbitrary IPv4
destination. The attacker will compose a Teredo IPv6 address using
the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the
target, and an arbitrary UDP port.
In the simplest variation of this attack, the attacker sends IPv6
packets to the Teredo destination using regular IPv6 routing. The
packets are picked by the nearest relay, which will forward them to
the IPv4 address of the target. In a more elaborate variant, the
attacker tricks a Teredo into sending packets to the target, either
by sending a first packet with a spoofed IPv6 address and letting the
Teredo host reply or by publishing a spoofed IPv6 address in a name
service.
There are three types of IPv4 addresses that an attacker may embed in
the spoofed Teredo address. It may embed a multicast or broadcast
address, an local unicast address, or a global unicast address.
With multicast or broadcast addresses, the attacker can use the
multiplying effect of multicast routing. By sending a single packet,
it can affect a large number of hosts, in a way reminiscent of the
"smurf" attack.
By using local addresses, the attacker can reach hosts that are not
normally reachable from the Internet, for example, hosts connected to
the a Teredo relay by a private subnet. This creates an exposure
for, at a minimum, a denial of service attack against these otherwise
protected hosts. This is similar to attack variants using source
routing to breach a perimeter.
The address checks specified in Section 5.2.4, 5.3.1, and 5.4.1
verify that packets are relayed only to a global IPv4 address. They
are designed to eliminate the possibility of using broadcast,
multicast or local addresses in denial of service or other attacks.
In what follows, we will only consider attacks targeting globally
reachable unicast addresses.
The attacks can be targeted at arbitrary UDP ports, such as, for
example, the DNS port of a server. The UDP payload must be a well-
formed IPv6 packet, and is thus unlikely to be accepted by any well-
written UDP service; in most case, the only effect of the attack will
be to overload the target with random traffic.
A special case occurs if the attack is directed to an echo service.
The service will echo the packets. Since the echo service sees the
request coming from the IPv4 address of the relay, the echo replies
will be sent back to the same relay. According to the rules
specified in Section 5.4, these packets will be discarded by the
Teredo relay. This is not a very efficient attack against the Teredo
relays -- establishing a legitimate session with an actual Teredo
host would create more traffic.
The IPv6 packets sent to the target contain the IPv6 address used by
the attacker. If ingress filtering is used in the IPv6 network, this
address will be hard to spoof. If ingress filtering is not used, the
attacker can be traced if the IPv6 routers use a mechanism similar to
ICMP Traceback. The ICMP messages will normally be collected by the
same relays that forward the traffic from the attacker; the relays
can use these messages to identify the source of an ongoing attack.
The details of this solution will have to be developed in further
research.
8. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing"
(UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism [RFC3424].
Teredo is an example of a protocol that performs this type of
function. The IAB has mandated that any protocols developed for this
purpose document a specific set of considerations. This section
meets those requirements.
8.1. Problem Definition
From [RFC3424], any UNSAF proposal must provide a precise definition
of a specific, limited-scope problem that is to be solved with the
UNSAF proposal. A short-term fix should not be generalized to solve
other problems; this is why "short term fixes usually aren’t".
The specific problem being solved by Teredo is the provision of IPv6
connectivity for hosts that cannot obtain IPv6 connectivity natively
and cannot make use of 6to4 because of the presence of a NAT between
them and the 6to4 relays.
8.2. Exit Strategy
From [RFC3424], any UNSAF proposal must provide the description of an
exit strategy/transition plan. The better short term fixes are the
ones that will naturally see less and less use as the appropriate
technology is deployed.
Teredo comes with its own built-in exit strategy: as soon as a client
obtains IPv6 connectivity by other means, either 6to4 or native IPv6,
it can cease using the Teredo service. In particular, we expect that
the next generation of home routers will provide an IPv6 service in
complement to the current IPv4 NAT service, e.g., by relaying
connectivity obtained from the ISP, or by using a configured or
automatic tunnel service.
As long as Teredo is used, there will be a need to support Teredo
relays so that the remaining Teredo hosts can communicate with native
IPv6 hosts. As Teredo usage declines, the traffic load on the relays
will decline. Over time, managers will observe a reduced traffic
load on their relays and will turn them off, effectively increasing
the pressure on the remaining Teredo hosts to upgrade to another form
of connectivity.
The exit strategy is facilitated by the nature of Teredo, which
provides an IP-level solution. IPv6-aware applications do not have
to be updated to use or not use Teredo. The absence of impact on the
applications makes it easier to migrate out of Teredo: network
connectivity suffices.
There would appear to be reasons why a Teredo implementation might
decide to continue usage of the Teredo service even if it already has
obtained connectivity by some other means, for example:
1. When a client is dual homed, and it wishes to improve the service
when communicating with other Teredo hosts that are "nearby" on the
IPv4 network. If the client only used its native IPv6 service, the
Teredo hosts would be reached only through the relay. By maintaining
Teredo, the Teredo hosts can be reached by direct transmission over
IPv4.
2. If, for some reason, the Teredo link is providing the client with
better service than the native IPv6 link, in terms of bandwidth,
packet loss, etc.
The design of Teredo mitigates the dual-homing reason. A host that
wishes to communicate with Teredo peers can implement a "host-based
relay", which is effectively an unnumbered Teredo interface. As
such, the dual-homed host will obtain Teredo connectivity with those
hosts that must use Teredo, but will not inadvertently encourage
other dual-homed hosts to keep using the Teredo service.
The bubbles and the UDP encapsulation used by Teredo introduce a
significant overhead. It would take exceptional circumstances for
native technologies to provide a lesser service than Teredo. These
exceptional circumstances, or other unforeseen reasons, may induce
hosts to keep using the Teredo service despite the availability of
native IPv6 connectivity. However, these circumstances are likely to
be rare and transient. Moreover, if the primary reason to use Teredo
fades away, one can expect that Teredo relays will be progressively
turned off and that the quality of the Teredo service will
progressively degrade, reducing the motivation to use the Teredo
service.
8.3. Brittleness Introduced by Teredo
From [RFC3424], any UNSAF proposal must provide a discussion of
specific issues that may render systems more "brittle". For example,
approaches that involve using data at multiple network layers create
more dependencies, increase debugging challenges, and make it harder
to transition.
Teredo introduces brittleness into the system in several ways: the
discovery process assumes a certain classification of devices based
on their treatment of UDP; the mappings need to be continuously
refreshed; and addressing structure may cause some hosts located
behind a common NAT to be unreachable from each other.
There are many similarities between these points and those introduced
by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489];
however, Teredo is probably somewhat less brittle than STUN. The
reason is that all Teredo packets are sent from the local IPv4 Teredo
service port, including discovery, bubbles, and actual encapsulated
packets. This is different from STUN, where NAT type detection and
binding allocation use different local ports (ephemeral, in both
cases).
Teredo assumes a certain classification of devices based on their
treatment of UDP (e.g., cone, protected cone and symmetric). There
could be devices that would not fit into one of these molds, and
hence would be improperly classified by Teredo.
The bindings allocated from the NAT need to be continuously
refreshed. Since the timeouts for these bindings are very
implementation specific, the refresh interval cannot easily be
determined. When the binding is not being actively used to receive
traffic, but to wait for an incoming message, the binding refresh
will needlessly consume network bandwidth.
The use of the Teredo server as an additional network element
introduces another point of potential security attack. These attacks
are largely prevented by the security measures provided by Teredo,
but not entirely.
The use of the Teredo server as an additional network element
introduces another point of failure. If the client cannot locate a
Teredo server, or if the server should be unavailable due to failure,
the Teredo client will not be able to obtain IPv6 connectivity.
The communication with non-Teredo hosts relies on the availability of
Teredo relays. The Teredo design assumes that there are multiple
Teredo relays; the Teredo service will discover the relay closest to
the non-Teredo peer. If that relay becomes unavailable, or is
misbehaving, communication between the Teredo hosts and the peers
close to that relay will fail. This reliability issue is somewhat
mitigated by the possibility to deploy many relays, arbitrarily close
from the native IPv6 hosts that require connectivity with Teredo
peers.
Teredo imposes some restrictions on the network topologies for proper
operation. In particular, if the same NAT is on the path between two
clients and the Teredo server, these clients will only be able to
interoperate if they are connected to the same link, or if the common
NAT is capable of "hairpinning", i.e., "looping" packets sent by one
client to another.
There are also additional points of brittleness that are worth
mentioning:
- Teredo service will not work through NATs of the symmetric variety.
- Teredo service depends on the Teredo server running on a network
that is a common ancestor to all Teredo clients; typically, this is
the public Internet. If the Teredo server is itself behind a NAT,
Teredo service will not work to certain peers.
- Teredo introduces jitter into the IPv6 service it provides, due to
the queuing of packets while bubble exchanges take place. This
jitter can negatively impact applications, particularly latency
sensitive ones, such as Voice over IP (VoIP).
8.4. Requirements for a Long-Term Solution
From [RFC3424], any UNSAF proposal must identify requirements for
longer-term, sound technical solutions -- contribute to the process
of finding the right longer-term solution.
Our experience with Teredo has led to the following requirements for
a long-term solution to the NAT problem: the devices that implement
the IPv4 NAT services should in the future also become IPv6 routers.
9. IANA Considerations
This memo documents a request to IANA to allocate a 32-bit Teredo
IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
multicast address, as specified in Section 2.17.
10. Acknowledgements
Many of the ideas in this memo are the result of discussions between
the author and Microsoft colleagues, notably Brian Zill, John Miller,
Mohit Talwar, Joseph Davies, and Rick Rashid. Several encapsulation
details are inspired from earlier work by Keith Moore. The example
in Section 5.1 and a number of security precautions were suggested by
Pekka Savola. The local discovery procedure was suggested by Richard
Draves and Dave Thaler. The document was reviewed by members of the
NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi
Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng
Soo Guan, and Eiffel Wu. Eric Klein, Karen Nielsen, Francis Dupont,
Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg
provided detailed reviews during the IETF last call.
11. References
11.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory,
National Institute of Standards and Technology, U.S.
Department Of Commerce, May 1993.
11.2. Informative References
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy.
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[REFLECT] V. Paxson, "An analysis of using reflectors for
distributed denial of service attacks", Computer
Communication Review, ACM SIGCOMM, Volume 31, Number 3,
July 2001, pp 38-47.
Author’s Address
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
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