the packet MUST NOT be forwarded.
If the destination address is not a Teredo IPv6 address, the packet
should be relayed to the IPv6 Internet using regular IPv6 routing.
If the IPv6 destination address is a valid Teredo IPv6 address as
defined in Section 2.13, the Teredo Server MUST check that the IPv4
address derived from this IPv6 address is in the format of a global
unicast address; if this is not the case, the packet MUST be silently
discarded.
If the address is valid, the Teredo server encapsulates the IPv6
packet in a new UDP datagram, in which the following parameters are
set:
- The destination IPv4 address is derived from the IPv6 destination.
- The source IPv4 address is the Teredo server IPv4 address.
- The destination UDP port is derived from the IPv6 destination.
- The source UDP port is set to the Teredo UDP Port.
If the destination IPv6 address is a Teredo client whose address is
serviced by this specific server, the server should insert an origin
indication in the first bytes of the UDP payload, as specified in
Section 5.1.1. (To verify that the client is served by this server,
the server compares bits 32-63 of the client’s Teredo IPv6 address to
the server’s IPv4 address.)
5.3.2. Processing of Router Solicitations
When the Teredo server receives a Router Solicitation message (RS,
[RFC2461]), it retains the IPv4 address and UDP port from which the
solicitation was received; these become the Teredo mapped address and
Teredo mapped port of the client. The router uses these values to
compose the origin indication encapsulation that will be sent with
the response to the solicitation.
The Teredo server responds to the router solicitation by sending a
Router Advertisement message [RFC2461]. The router advertisement
MUST advertise the Teredo IPv6 prefix composed from the service
prefix and the server’s IPv4 address. The IPv6 source address should
be set to a Teredo link-local server address associated to the local
interface; this address is derived from the IPv4 address of the
server and from the Teredo port, as specified in Section 4; the cone
bit is set to 1. The IPv6 destination address is set to the IPv6
source address of the RS. The Router Advertisement message must be
sent over UDP to the Teredo mapped address and Teredo mapped port of
the client; the IPv4 source address and UDP source port should be set
to the server’s IPv4 address and Teredo Port. If the cone bit of the
client’s IPv6 address is set to 1, the RA must be sent from a
different IPv4 source address than the server address over which the
RS was received; if the cone bit is set to zero, the response must be
sent back from the same address.
Before sending the packet, the Teredo server MUST check that the IPv4
destination address is in the format of a global unicast address; if
this is not the case, the packet MUST be silently discarded (see
Section 5.2.4 for a definition of global unicast addresses).
If secure qualification is required, the server MUST insert a valid
authentication parameter in the UDP packet carrying the router
advertisement. The client identifier and the nonce value used in the
authentication parameter MUST be the same identifier and nonce as
received in the router solicitation. The confirmation byte MUST be
set to zero if the client identifier is still valid, and a non-null
value otherwise; the authentication value SHOULD be computed using
the secret that corresponds to the client identifier.
5.4. Teredo Relay Specification
Teredo relays are IPv6 routers that advertise reachability of the
Teredo service IPv6 prefix through the IPv6 routing protocols. (A
minimal Teredo relay may serve just a local host, and would not
advertise the prefix beyond this host.) Teredo relays will receive
IPv6 packets bound to Teredo clients. Teredo relays should be able
to receive packets sent over IPv4 and UDP by Teredo clients; they may
apply filtering rules, e.g., only accept packets from Teredo clients
if they have previously sent traffic to these Teredo clients.
The receiving and sending rules used by Teredo relays are very
similar to those of Teredo clients. Teredo relays must use a Teredo
service port to transmit packets to Teredo clients; they must
maintain a "list of peers", identical to the list of peers maintained
by Teredo clients.
5.4.1. Transmission by Relays to Teredo Clients
When a Teredo relay has to transmit a packet to a Teredo client, it
examines the destination IPv6 address. By definition, the Teredo
relays will only send over UDP IPv6 packets whose IPv6 destination
address is a valid Teredo IPv6 address.
Before processing these packets, the Teredo Relay MUST check that the
IPv4 destination address embedded in the Teredo IPv6 address is in
the format of a global unicast address; if this is not the case, the
packet MUST be silently discarded (see Section 5.2.4 for a definition
of global unicast addresses).
The relay then checks if there is an entry for this IPv6 address in
the list of recent Teredo peers, and if the entry is still valid.
The relay then performs the following:
1) If there is an entry for that IPv6 address in the list of peers,
and if the status of the entry is set to "trusted", the IPv6 packet
should be sent over UDP to the mapped IPv4 address and mapped UDP
port of the entry. The relay updates the date of last transmission
in the peer entry.
2) If there is no trusted entry in the list of peers, and if the
destination is a Teredo IPv6 address in which the cone bit is set to
1, the packet is sent over UDP to the mapped IPv4 address and mapped
UDP port extracted from that IPv6 address.
3) If there is no trusted entry in the list of peers, and if the
destination is a Teredo IPv6 address in which the cone bit is set to
0, the Teredo relay creates a bubble whose source address is set to a
local IPv6 address, and whose destination address is set to the
Teredo IPv6 address of the packet’s destination. The bubble is sent
to the server address corresponding to the Teredo destination. The
entry becomes trusted when a bubble or another packet is received
from this IPv6 address; if no such packet is received before a time-
out of 2 seconds, the Teredo relay may repeat the bubble, up to three
times. If the relay fails to receive a bubble after these
repetitions, the entry is removed from the list of peers. The relay
MAY queue packets bound to untrusted entries; the queued packets
SHOULD be de-queued and forwarded when the entry becomes trusted;
they SHOULD be deleted if the entry is deleted. To avoid denial of
service attacks, the relays SHOULD limit the number of packets in
such queues.
In cases 2 and 3, the Teredo relay should create a peer entry for the
IPv6 address; the entry status is marked as trusted in case 2 (cone
NAT) and not trusted in case 3. In case 3, if the Teredo relay
happens to be located behind a non-cone NAT, it should also send a
bubble directly to the mapped IPv4 address and mapped port number of
the Teredo destination. This will "open the path" for the return
bubble from the Teredo client.
For reliability reasons, relays MAY decide to ignore the value of the
cone bit in the flag, and always perform the "case 3", i.e., treat
all Teredo peers as if they were located behind a non-cone NAT. This
will result in some increase in traffic, but may avoid
reliability issues if the determination of the NAT status was for
some reason erroneous. For the same reason, relays MAY also decide
to always send a direct bubble to the mapped IPv4 address and mapped
port number of the Teredo destination, even if they do not believe
that they are located behind a non-cone NAT.
5.4.2. Reception from Teredo Clients
The Teredo relay may receive packets from Teredo clients; the packets
should normally only be sent by clients to which the relay previously
transmitted packets, i.e., clients whose IPv6 address is present in
the list of peers. Relays, like clients, use the packet reception
procedure to maintain the date and time of the last interaction with
the Teredo server and the "list of recent peers".
When a UDP packet is received over the Teredo service port, the
Teredo relay checks that it contains a valid IPv6 packet as specified
in [RFC2460]. If this is not the case, the packet is silently
discarded.
Then, the Teredo relay examines whether the IPv6 source address is a
valid Teredo address, and if the mapped IPv4 address and mapped port
match the IPv4 source address and port number from which the packet
is received. If this is not the case, the packet is silently
discarded.
The Teredo relay then examines whether there is an entry for the IPv6
source address in the list of recent peers. If this is not the case,
the packet may be silently discarded. If this is the case, the entry
status is set to "trusted"; the relay updates the "date and time of
the last interaction" to the current date and time.
Finally, the relay examines the destination IPv6 address. If the
destination belongs to a range of IPv6 addresses served by the relay,
the packet SHOULD be accepted and forwarded to the destination. In
the other cases, the packet SHOULD be silently discarded.
5.4.3. Difference between Teredo Relays and Teredo Servers
Because Teredo servers can relay Teredo packets over IPv6, all Teredo
servers must be capable of behaving as Teredo relays. There is,
however, no requirement that Teredo relays behave as Teredo servers.
The dual role of server and relays implies an additional complexity
for the programming of servers: the processing of incoming packets
should be a combination of the server processing rules defined in
Section 5.3.1, and the relay processing rules defined in Section
5.4.2. (Section 5.3 only specifies the rules implemented by a pure
server, not a combination relay+server.)
5.5. Implementation of Automatic Sunset
Teredo is designed as an interim transition mechanism, and it is
important that it should not be used any longer than necessary. The
"sunset" procedure will be implemented by Teredo clients, servers,
and relays, as specified in this section.
The Teredo-capable nodes MUST NOT behave as Teredo clients if they
already have IPv6 connectivity through any other means, such as
native IPv6 connectivity. In particular, nodes that have a global
IPv4 address SHOULD obtain connectivity through the 6to4 service
rather than through the Teredo service. The classic reason why a
node that does not need connectivity would still enable the Teredo
service is to guarantee good performance when interacting with Teredo
clients; however, a Teredo-capable node that has IPv4 connectivity
and that has obtained IPv6 connectivity outside the Teredo service
MAY decide to behave as a Teredo relay, and still obtain good
performance when interacting with Teredo clients.
The Teredo servers are expected to participate in the sunset
procedure by announcing a date at which they will stop providing the
service. This date depends on the availability of alternative
solutions to their clients, such as "dual-mode" gateways that behave
simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers
will not be expected to operate more than a few years. Teredo relays
are expected to have the same life span as Teredo servers.
6. Further Study, Use of Teredo to Implement a Tunnel Service
Teredo defines a NAT traversal solution that can be provided using
very little resource at the server. Ongoing IETF discussions have
outlined the need for both a solution like Teredo and a more
controlled NAT traversal solution, using configured tunnels to a
service provider [RFC3904]. This section provides a tentative
analysis of how Teredo could be extended to also support a configured
tunnel service.
It may be possible to design a tunnel server protocol that is
compatible with Teredo, in the sense that the same client could be
used either in the Teredo service or with a tunnel service. In fact,
this could be done by configuring the client with:
- The IPv4 address of a Teredo server that acts as a tunnel broker
- A client identifier
- A shared secret with that server
- An agreed-upon authentication algorithm.
The Teredo client would use the secure qualification procedure, as
specified in Section 5.2.2. Instead of returning a Teredo prefix in
the router advertisement, the server would return a globally routable
IPv6 prefix; this prefix could be permanently assigned to the client,
which would provide the client with a stable address. The server
would have to keep state, i.e., memorize the association between the
prefix assigned to the client and the mapped IPv4 address and mapped
UDP port of the client.
The Teredo server would advertise reachability of the client prefix
to the IPv6 Internet. Any packet bound to that prefix would be
transmitted to the mapped IPv4 address and mapped UDP port of the
client.
The Teredo client, when it receives the prefix, would notice that
this prefix is a global IPv6 prefix, not in the form of a Teredo
prefix. The client would at that point recognize that it should
operate in tunnel mode. A client that operates in tunnel mode would
execute a much simpler transmission procedure: it would forward any
packet sent to the Teredo interface to the IPv4 address and Teredo
UDP port of the server.
The Teredo client would have to perform the maintenance procedure
described in Section 5.2.5. The server would receive the router
solicitation, and could notice a possible change of mapped IPv4
address and mapped UDP port that could result from the
reconfiguration of the mappings inside the NAT. The server should
continue advertising the same IPv6 prefix to the client, and should
update the mapped IPv4 address and mapped UDP port associated to this
prefix, if necessary.
There is as yet no consensus that a tunnel-mode extension to Teredo
should be developed. This section is only intended to provide
suggestions to the future developers of such services. Many details
would probably have to be worked out before a tunnel-mode extension
would be agreed upon.
7. Security Considerations
The main objective of Teredo is to provide nodes located behind a NAT
with a globally routable IPv6 address. The Teredo nodes can use IP
security (IPsec) services such as Internet Key Exchange (IKE),
Authentication Header (AH), or Encapsulation Security Payload (ESP)
[RFC4306, RFC4302, RFC4303], without the configuration restrictions
still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947].
As such, we can argue that the service has a positive effect on
network security. However, the security analysis must also envisage
the negative effects of the Teredo services, which we can group in
four categories: security risks of directly connecting a node to the
IPv6 Internet, spoofing of Teredo servers to enable a man-in-the-
middle attack, potential attacks aimed at denying the Teredo service
to a Teredo client, and denial of service attacks against non-Teredo
participating nodes that would be enabled by the Teredo service.
In the following, we review in detail these four types of issues, and
we present mitigating strategies for each of them.
7.1. Opening a Hole in the NAT
The very purpose of the Teredo service is to make a machine reachable
through IPv6. By definition, the machine using the service will give
up whatever firewall service was available in the NAT box, however
limited this service may be [RFC2993]. The services that listen to
the Teredo IPv6 address will become the potential target of attacks
from the entire IPv6 Internet. This may sound scary, but there are
three mitigating factors.
The first mitigating factor is the possibility to restrict some
services to only accept traffic from local neighbors, e.g., using
link-local addresses. Teredo does not support communication using
link-local addresses. This implies that link-local services will not
be accessed through Teredo, and will be restricted to whatever other
IPv6 connectivity may be available, e.g., direct traffic with
neighbors on the local link, behind the NAT.
The second mitigating factor is the possible use of a "local
firewall" solution, i.e., a piece of software that performs locally
the kind of inspection and filtering that is otherwise performed in a
perimeter firewall. Using such software is recommended.
The third mitigating factor is the availability of IP security
(IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303].
Using these services in conjunction with Teredo is a good policy, as
it will protect the client from possible attacks in intermediate
servers such as the NAT, the Teredo server, or the Teredo relay.
(However, these services can be used only if the parties in the
communication can negotiate a key, which requires agreeing on some
credentials; this is known to be a hard problem.)
7.2. Using the Teredo Service for a Man-in-the-Middle Attack
The goal of the Teredo service is to provide hosts located behind a
NAT with a globally reachable IPv6 address. There is a possible
class of attacks against this service in which an attacker somehow
intercepts the router solicitation, responds with a spoofed router
advertisement, and provides a Teredo client with an incorrect
address. The attacker may have one of two objectives: it may try to
deny service to the Teredo client by providing it with an address
that is in fact unreachable, or it may try to insert itself as a
relay for all client communications, effectively enabling a variety
of "man-in-the-middle" attack.
7.2.1. Attacker Spoofing the Teredo Server
The simple nonce verification procedure described in Section 5.2.2
provides a first level of protection against attacks in which a third
party tries to spoof the server. In practice, the nonce procedure
can be defeated only if the attacker is "on path".
If client and server share a secret and agree on an authentication
algorithm, the secure qualification procedure described in Section
5.2.2 provides further protection. To defeat this protection, the
attacker could try to obtain a copy of the secret shared between
client and server. The most likely way to obtain the shared secret
is to listen to the traffic and mount an offline dictionary attack;
to protect against this attack, the secret shared between client and
server should contain sufficient entropy. (This probably requires
some automated procedure for provisioning the shared secret and the
algorithm.)
If the shared secret contains sufficient entropy, the attacker would
have to defeat the one-way function used to compute the
authentication value. This specification suggests a default
algorithm combining HMAC and MD5. If the protection afforded by MD5
was not deemed sufficient, clients and servers can agree to use a
different algorithm, e.g., SHA1.
Another way to defeat the protection afforded by the authentication
procedure is to mount a complex attack, as follows:
1) Client prepares router solicitation, including authentication
encapsulation.
2) Attacker intercepts the solicitation, and somehow manages to
prevent it from reaching the server, for example, by mounting a
short-duration DoS attack against the server.
3) Attacker replaces the source IPv4 address and source UDP port of
the request by one of its own addresses and port, and forwards the
modified request to the server.
4) Server dutifully notes the IPv4 address from which the packet is
received, verifies that the Authentication encapsulation is correct,
prepares a router advertisement, signs it, and sends it back to the
incoming address, i.e., the attacker.
5) Attacker receives the advertisement, takes note of the mapping,
replaces the IPv4 address and UDP port by the original values in the
intercepted message, and sends the response to the client.
6) Client receives the advertisement, notes that the authentication
header is present and is correct, and uses the proposed prefix and
the mapped addresses in the origin indication encapsulation.
The root cause of the problem is that the NAT is, in itself, a man-
in-the-middle attack. The Authentication encapsulation covers the
encapsulated IPv6 packet, but does not cover the encapsulating IPv4
header and UDP header. It is very hard to devise an effective
authentication scheme, since the attacker does not do anything else
than what the NAT legally does!
However, there are several mitigating factors that lead us to avoid
worrying too much about this attack. In practice, the gain from the
attack is either to deny service to the client or to obtain a "man-
in-the-middle" position. However, in order to mount the attack, the
attacker must be able to suppress traffic originating from the
client, i.e., have denial of service capability; the attacker must
also be able to observe the traffic exchanged between client and
inject its own traffic in the mix, i.e., have man-in-the-middle
capacity. In summary, the attack is very hard to mount, and the gain
for the attacker in terms of "elevation of privilege" is minimal.
A similar attack is described in detail in the security section of
[RFC3489].
7.2.2. Attacker Spoofing a Teredo Relay
An attacker may try to use Teredo either to pass itself for another
IPv6 host or to place itself as a man-in-the-middle between a Teredo
host and a native IPv6 host. The attacker will mount such attacks by
spoofing a Teredo relay, i.e., by convincing the Teredo host that
packets bound to the native IPv6 host should be relayed to the IPv4
address of the attacker.
The possibility of the attack derives from the lack of any
algorithmic relation between the IPv4 address of a relay and the
native IPv6 addresses served by these relay. A Teredo host cannot
decide just by looking at the encapsulating IPv4 and UDP header
whether or not a relay is legitimate. If a Teredo host decided to
simply trust the incoming traffic, it would easily fall prey to a
relay-spoofing attack.
The attack is mitigated by the "direct IPv6 connectivity test"
specified in Section 5.2.9. The test specifies a relay discovery
procedure secured by a nonce. The nonce is transmitted from the
Teredo host to the destination through Teredo server, which the
client normally trusts. The response arrives through the "natural"
relay, i.e., the relay closest to the IPv6 destination. Sending
traffic to this relay will place it out of reach of attackers that
are not on the direct path between the Teredo host and its IPv6 peer.
End-to-end security protections are required to defend against
spoofing attacks if the attacker is on the direct path between the
Teredo host and its peer.
7.2.3. End-to-End Security
The most effective line of defense of a Teredo client is probably not
to try to secure the Teredo service itself: even if the mapping can
be securely obtained, the attacker would still be able to listen to
the traffic and send spoofed packets. Rather, the Teredo client
should realize that, because it is located behind a NAT, it is in a
situation of vulnerability; it should systematically try to encrypt
its IPv6 traffic, using IPsec. Even if the IPv4 and UDP headers are
vulnerable, the use of IPsec will effectively prevent spoofing and
listening of the IPv6 packets by third parties. By providing each
client with a global IPv6 address, Teredo enables the use of IPsec
without the configuration restrictions still present in "Negotiation
of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the
security of these clients.
7.3. Denial of the Teredo service
Our analysis outlines five ways to attack the Teredo service. There
are countermeasures for each of these attacks.
7.3.1. Denial of Service by a Rogue Relay
An attack can be mounted on the IPv6 side of the service by setting
up a rogue relay and letting that relay advertise a route to the
Teredo IPv6 prefix. This is an attack against IPv6 routing, which
can also be mitigated by the same kind of procedures used to
eliminate spurious route advertisements. Dual-stack nodes that
implement "host local" Teredo relays are impervious to this attack.