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]