IPv6 Operations Working Group N. Ward
Internet-Draft Braintrust Ltd.
Intended status: Standards Track June 30, 2007
Expires: January 1, 2008
Teredo Server Selection
draft-nward-v6ops-teredo-server-selection-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes performance, reliability and privacy problems
inherent when using a remotely situated vendor-provided Teredo
server, which is a common default in current implementations, and
then discussed why configuring servers manually is bad and difficult.
It recommends two partial solutions, and gives a final recommendation
combining both solutions using anycast IPv4 and a well known DNS
hostname.
Ward Expires January 1, 2008 [Page 1]
Internet-Draft Teredo Server Selection June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation for Local Teredo Servers . . . . . . . . . . . . . 3
2.1. Performance and Reliability . . . . . . . . . . . . . . . 4
2.2. Blocking Peers . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Hijacking Peers . . . . . . . . . . . . . . . . . . . . . 4
3. Static Configuration of Teredo Server Names in Clients . . . . 5
3.1. Hosts Moving Networks . . . . . . . . . . . . . . . . . . 5
3.2. Reconfiguration Logistics . . . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overloading A Well Known DNS Name . . . . . . . . . . . . 6
4.1.1. Problems . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Anycast IPv4 . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Problems . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Combined IPv4 Anycast and DNS Overloading . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Incomplete Work . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Ward Expires January 1, 2008 [Page 2]
Internet-Draft Teredo Server Selection June 2007
1. Introduction
Current Teredo RFC 4380 [RFC4380] implementations do not select the
best Teredo servers for the client's current network location,
instead relying on a single server name.
This document explores why an access network provider would wish to
provide its own Teredo servers, for reasons of reliability,
performance, and data security and privacy.
While the server name is configurable in all existing Teredo
implementations, a network wishing to advise its users to use its own
Teredo services would currently be required to contact all those
uesrs and guide them through the re-configuration process. This
document describes several reason why this is in-feasible.
Alternatively, a network may force customers to use its Teredo
servers by `spoofing' DNS names or IPv4 addresses. Spoofing of this
nature is generally considered a bad practice by the Internet
community, and as such the author advises against doing so.
As a solution to these problems, this document recommends two things;
a default configuration setting for Teredo implementations, and an
IPv4 anycast network for public and internal Teredo server
distribution. This default configuration setting can be utilised by
a network to direct end users to either their own Teredo servers, or
to publicly available Teredo servers.
The section entitled "Incomplete Work" at the end of this document
outlines work required before this document is complete.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Motivation for Local Teredo Servers
This section describes several reasons why a network may wish to
provide its own Teredo servers, as opposed to requiring or allowing
end hosts to rely on those of a third party.
The Teredo specification documents a relay discovery procedure by
which a client must find an appropriate Teredo relay for the IPv6
peer it wishes to exchange IPv6 traffic with. At a high level, this
is done by transmitting ICMPv6 Echo-Request messages to the peer via
Ward Expires January 1, 2008 [Page 3]
Internet-Draft Teredo Server Selection June 2007
the Teredo server and examining responses. The path that these
responses take depends on the NAPT type detected during the Teredo
Qualification Procedure.
A Teredo client wishing to access another Teredo client may need to
use a Teredo server to help establish NAPT translation rules. This
is susceptible to the problems below, however two Teredo clients that
are able to initiate direct communication without assistance from a
Teredo server are not impacted - i.e. two clients behind two
different 'cone' NAPTs, or on the same local broadcast network.
2.1. Performance and Reliability
Teredo servers and their clients are likely to be located in vastly
different geographical locations, and as such the Qualification
Procedure and relay detection mechanisms may not perform optimally.
While these are small performance hits, hosts at the end of high
delay networks are likely to be severely impacted.
2.2. Blocking Peers
A maliciously configured Teredo server or attached IPv6 network could
prevent ICMPv6 Echo-Request messages from reaching certain peer nodes
by simply dropping the packet as part of a firewall filter. Teredo
client hosts attempting to reach these nodes will wait for a timeout,
and optionally fall back to attempting to reach the peer directly via
IPv4, if available.
+-------------+ +-------------+ +---------+
|Teredo Client|--------->|Teredo Server|D.........>|IPv6 Peer|
+-------------+ +-------------+ +---------+
D = Dropped packet
. = Intended relay discovery path
- = Actual relay discovery path
2.3. Hijacking Peers
A maliciously configured Teredo server or attached IPv6 network could
redirect relay discovery messages intended for certain peer nodes to
a malicious server. The malicious server can respond to the Echo-
Request message via its relay, causing the client's Teredo software
to select this relay as the best relay for this IPv6 peer. Now the
client believes itself to be exchanging traffic with the correct IPv6
peer, but it is in-fact communicating with an impostor.
Using this method, a malicious party could either provide services to
the client, or proxy requests while performing logging or translation
Ward Expires January 1, 2008 [Page 4]
Internet-Draft Teredo Server Selection June 2007
of content. This attack is undetectable to applications, as the
peer's IPv6 address is unchanged, and the Teredo stack internals does
not interact with applications. This attack is undetectable to the
intended peers, as no traffic will reach it from this client.
In addition, if this malicious party is or otherwise has access to a
root certificate authority that is trusted by the client's
application, a transparent attack on SSL-secured applications - such
as HTTPS secured banking applications - could easily be performed.
+-------------+ +---------+
|Actual | |Actual |
++=========>|Teredo Relay |<=====>|IPv6 Host|
|| +-------------+ +---------+
|| ^
\/ | +---------+
+-------------+ +-------------+ | |Intended |
|Teredo Client|---------->|Teredo Server|-->R.......>|IPv6 Host|
+-------------+ +-------------+ +---------+
^ .
. .
. +------------+ .
. |Intended | .
...................|Teredo Relay|<.................
+------------+
R = Redirected packet
. = Intended relay discovery path
- = Actual relay discovery path
= = Actual data path
3. Static Configuration of Teredo Server Names in Clients
A network wishing to provide local Teredo servers is currently only
able to do so by re-configuring all its client hosts' Teredo
implementations. This is difficult and problematic for the reasons
discussed below.
3.1. Hosts Moving Networks
If a host with a statically configured Teredo server specific to one
network wishes to move to another network, it may cause performance
problems (see section 2.1), or reachability problems if the
configured Teredo server is configured to only provide access to
hosts connected to a particular network, or the Teredo server's
hostname is not available for querying outside a particular network.
These can be mitigated through changes in client configuration during
Ward Expires January 1, 2008 [Page 5]
Internet-Draft Teredo Server Selection June 2007
network moves, however this is unlikely to be something most end
users will wish to do.
3.2. Reconfiguration Logistics
A service provider with many customers is unlikely to want to spend
its call centre's resources on contacting these customers, convincing
them that reconfiguration is important, and guiding them through the
process for each of their end hosts.
It has been suggested that a service provider may wish to simply wait
until a customer has problems and calls the call centre, however this
has potential to be seen as a problem with the service by the
customer, and a problem with the IPv6 protocol by the server
provider's management.
4. Recommendations
4.1. Overloading A Well Known DNS Name
One possible solution is to create a well known DNS name which is
configured in Teredo clients as the default Teredo server.
Networks wishing to implement Teredo servers for local use do so by
creating A records for the well known hostname in their recursive
resolvers, pointing at one or more Teredo servers that are available
to their users.
In programming terms, this is similar to overloading so this
technique is referred to as DNS overloading for the purposes of this
document. This does not reflect any particular network performance
or loading.
4.1.1. Problems
This solution does not provide a good mechanism for a 'fallback' to a
public or vendor provided set of Teredo servers in the event of a
failure of the network provided servers, or if a network does not
provide servers at all. A possible solution to this would be to have
the DNS name hosted by the root servers (or some other independent
party), and have A records pointing to Teredo servers hosted by
organisations who wish to volunteer their servers for public use.
However this would require additional administrative overhead to
maintain a list of working public Teredo servers, in addition either
all servers would have to have roughly the same load requirements, or
some weighting would have to occur by duplicating records in the DNS.
Ward Expires January 1, 2008 [Page 6]
Internet-Draft Teredo Server Selection June 2007
4.2. Anycast IPv4
Another solution is to allocate a new 24-bit IPv4 prefix for
anycasting Teredo servers. Teredo client software vendors who
provide Teredo servers for public use should change the A records of
their current default Teredo server hostnames to point to the first
IPv4 host address in this prefix.
Networks wishing to implement Teredo servers for local use do so by
directing the prefix to one or more local Teredo servers.
This differs slightly from the IPv4 anycast prefix assigned to 6to4
servers in RFC 3068 [RFC3068] in that the traffic to this prefix is
only relay discovery and qualification traffic. As such, it is
anticipated that some providers and vendors may make their Teredo
servers available for use by the public Internet as is done today.
This can be done by advertising the Teredo anycast IPv4 prefix to
their peers.
4.2.1. Problems
This does not provide a way to distribute load across several servers
other than to distribute them throughout a network and anycast them
at each location. This problem is also apparent in hosts wishing to
provide public Teredo servers for the use of the general Internet.
In addition, third party hostnames are still required, and could
still be changed to point to malicious Teredo servers.
4.3. Combined IPv4 Anycast and DNS Overloading
A third approach is to combine the two above solutions, where both a
well known DNS name is used, and an IPv4 anycast prefix is allocated.
The root servers (or some other independent party) would host the DNS
name, with an A record for the first host address in the anycast
prefix. This removes the reliance on any vendor provided hostnames,
and gives the ability for a network to use DNS to distribute load
across local Teredo servers.
A network wishing for its users to use Teredo services has several
non-exclusive deployment options, depending on its requirements:
1. The simplest implementation is to direct the anycast prefix to
one or more local Teredo servers. The DNS name does not need to
be overloaded, as the publicly returned A records are accurate
for the local network.
Ward Expires January 1, 2008 [Page 7]
Internet-Draft Teredo Server Selection June 2007
2. A network wishing to provide Teredo servers on its own IPv4 space
can do so by overloading the DNS name. This is useful in larger
networks to distribute load across several Teredo servers, for
example. Note that these servers will only be used by hosts
configured to use the DNS servers that this name is overloaded
on.
3. A network overloading the DNS name may also wish to provide local
Teredo services for users using third party DNS servers. Many of
these hosts can be captured by directing the anycast IPv4 prefix
at one or more local Teredo servers.
4. A network may make its Teredo servers, which are using the IPv4
anycast addresses, available for the use of the public Internet
by advertising the IPv4 anycast prefix to its peers, as in
section 4.2.
5. A network not wishing to deploy any Teredo services can do so by
simply not overloading the well known hostname, and not
originating the IPv4 anycast prefix - typically, this will mean
taking no action, so networks with no Teredo knowledge will
likely function like this already, and their end users will use
third party Teredo servers selected by the network to be the
closest IPv4 path.
6. Hosts often use statically configured DNS servers, and sometimes
move to remote networks. It is not unreasonable to expect
services like Teredo to continue to function optimally in this
case. A network overloading the DNS name may wish to use DNS
'views' to provide A record(s) pointing to local Teredo server
addresses when requested by local hosts, and to the public
anycast Teredo server address when requested by non-local hosts.
Locally overloaded instances of the DNS name MUST NOT return records
pointing to any addresses in the public anycast prefix other than the
first host address. To do so would cause a problem when hosts that
either cache results, or remotely query local DNS servers due to
static configuration, prefer a different anycasted Teredo server
instance.
5. Acknowledgements
The problems described in this document were arrived at during
conversations with Shane Connolly and Robin Hartley.
Ward Expires January 1, 2008 [Page 8]
Internet-Draft Teredo Server Selection June 2007
6. IANA Considerations
This memo includes no request to IANA at this time.
7. Security Considerations
This document highlights several security concerns with current
Teredo implementations.
Fake advertisements of the anycast IPv4 prefix, or fake responses to
the well known DNS name are not new attack vectors for hijacking
servers that are introduced by this document - these vectors are
available in an existing Teredo implementation using vendor provided
server names and server IPv4 addresses.
This document assumes that the end user's ISP is a trusted party for
the purposes of providing a Teredo server. A Teredo server gives an
ISP no more control over users' traffic than it has already when
providing native IPv4 or IPv6 connectivity.
8. Incomplete Work
This document is incomplete. It does not investigate alternative
service discovery mechanisms, such as SRV records RFC 2782 [RFC2782].
It does not recommend which of the three solutions to use. It
probably needs a bit of re-organisation to make things clearer.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
Ward Expires January 1, 2008 [Page 9]
Internet-Draft Teredo Server Selection June 2007
9.2. Informative References
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
Author's Address
Nathan Ward
Braintrust Ltd.
Wellington,
NZ
Phone: +64 21 431 675
Email: nward@braintrust.co.nz
Ward Expires January 1, 2008 [Page 10]
Internet-Draft Teredo Server Selection June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ward Expires January 1, 2008 [Page 11]