Subject: Fwd: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt

From: Nathan Ward <[email-masked]>
Date: Wed, 4 Jul 2007 10:16:40 +1200

Morning (or whatever's appropriate),

This document is incomplete, and there are some notes at the end  
about what needs doing/thinking about, based on some initial comments  
from Christian Huitema and Jim Hoagland.

Comments welcome (and encouraged!).

If folks decide that one of these approaches (or some other approach  
that we come up with) is good, I intend to clean up/re-arrange the  
document to describe the solution, the alternatives, and why we  
didn't choose them. Right now it's intended to generate discussion,  
and describe some ideas.

Begin forwarded message:

> From: [email-masked]
> Date: 4 July 2007 6:15:01 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Teredo Server Selection
> 	Author(s)	: N. Ward
> 	Filename	: draft-nward-v6ops-teredo-server-selection-00.txt
> 	Pages		: 11
> 	Date		: 2007-7-3
> 	
>    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.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nward-v6ops-teredo-server- 
> selection-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-nward-v6ops-teredo-server-selection-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-nward-v6ops-teredo-server- 
> selection-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> !DSPAM:22,468a9390262211949113524!
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
> !DSPAM:22,468a9390262211949113524!

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 4 Jul 2007 09:48:27 +0200

> and describe some ideas.

Section 2.3 says:

   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.

Now, if this is possible, it's something terribly wrong with the root CA,

not with Teredo. I think that paragraph goes out of scope.

I would personnaly support the anycast solution. I'll be more than happy

to update my zone A RRs points to an anycast address if it gets to work.

I know that Microsoft is using DNS-based round-robin to balance the load,

but I am not sure if this is really needed... Since Teredo servers are

fully stateless, there should be no problem doing round-robin or any

other kind of load-balancing at the IP routing level.

The real problem is, how would anycast interact with hole punching? It

*might* just work out of the box, but I am not 100% sure...

-- 

Rémi Denis-Courmont

http://www.remlab.net/

---

From: Nathan Ward <[email-masked]>
Date: Wed, 4 Jul 2007 20:12:31 +1200

> not with Teredo. I think that paragraph goes out of scope.

Fair enough, it was intended as an example of how bad it could be.

> *might* just work out of the box, but I am not 100% sure...

Anycast is good, but I think it's important that the clients are  
default configured with a vendor agnostic DNS name that points to the  
anycast address as well. That means that the control is entirely with  
the SP, and there is no reliance on third party DNS names etc. Also,  
if providers don't have the ability to anycast, or need the ability  
to point clients at multiple servers and can't do it with IP-level  
load balancing for some reason, they can.

--
Nathan Ward

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 4 Jul 2007 19:29:39 +0300

Le mercredi 4 juillet 2007, vous avez écrit :
> anycast address as well.

I have not seen any precedent of vendor-agnostic DNS name (apart from 
example.TLD that is). Not only that, but who would maintain the DNS 
zone that clients would run into when the ISP does not "hijack" the 
name?

There are probably millions of Windows boxes using 
teredo.ipv6.microsoft.com already. It is technically possible to change 
this zone to point to an anycast prefix (should Microsoft be willing to 
use it...), as has seemingly been done with 6to4.ipv6.microsoft.com.

> That means that the control is entirely with 
> the SP, and there is no reliance on third party DNS names etc.

With anycast, the access provider has control, always. With DNS, it 
assumes that the user is using the ISP recursive DNS servers (most 
common, but not systematic).

> Also, if providers don't have the ability to anycast,

If they have no control over routing, I doubt they would or even should 
have control over DNS still.

By the way, you may as well drop the SRV records idea. Some people would 
complain that it allows Teredo to run not-on-port 3544, and becomes a 
mess to block at the firewall. Not *me* though.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Nathan Ward <[email-masked]>
Date: Fri, 6 Jul 2007 00:30:28 +1200

> zone that clients would run into when the ISP does not "hijack" the

I've not seen precedent of vendor-default DNS names for network  
functions, either (or at least, that I can recall on short  
notice :-). I'm not sure that lack of precedent is a good reason to  
not do something.

That's a good question as to who would host and maintain the zone. In  
the document I say: "The root servers (or some other independent  
party) would host the DNS name". I'm not sure who that third party  
could be, but the root servers (or perhaps a subset of the root  
servers) seem well placed in terms of reliability, and trust-ability.

> use it...), as has seemingly been done with 6to4.ipv6.microsoft.com.

My recommendation would be for MS to change the default to a new  
name, and also change the A record of the existing default to point  
to the anycast address.

> common, but not systematic).

With /only/ DNS, yes.
My recommendation (which isn't clear from ready the document, sorry  
about that!) is to use both DNS and anycast, and by default the DNS  
entry points to the anycast address. ISPs should use anycast where  
possible, but use DNS if it's not available.

> have control over DNS still.

Perhaps, however there are 'virtual' ISPs who run DNS, SMTP, etc.  
services for their customers, but who do not route their IP traffic  
to other parts of the Internet.
However, my comment was more in regards to it being unsuitable for  
their network for some reason (perhaps in an enterprise network, for  
example), or because they want to be able to load balance things  
differently to how they could with anycast.

> mess to block at the firewall. Not *me* though.

If end users can connect out through your firewall on any address,  
being able to block a Teredo port doesn't gain you any security. If  
you want to prevent users from automatically establishing tunnelling  
without them realising, either a) disable Teredo on all machines, or  
b) put in a DNS entry pointing to an invalid server, or c) null route  
the anycast address. I'm sure you're aware of this, but I'll describe  
why it's not a problem when I document the SRV as a sub-option of the  
well known DNS name bit so that others get it too :-).

The only reason I can see not to do well known DNS in parallel to  
IPv4 anycast is the issue of who would host the name, and I suspect  
we could resolve that fairly easily. It seems to me that the  
flexibility and security that is gained is worth it.

Perhaps an alternative to having a fallback in DNS is to have the  
anycast address configured as the Teredo server address to use when  
the DNS name is un-resolvable - that would require some extra logic  
in the clients though, but it would be pretty trivial I'd imagine:

address = dns_lookup(well.known.dns.name)
if (address = failed) then address = a.b.c.d

--
Nathan Ward

---

From: John Curran <[email-masked]>
Date: Thu, 5 Jul 2007 09:29:16 -0400

At 12:30 AM +1200 7/6/07, Nathan Ward wrote:
>That's a good question as to who would host and maintain the zone. In the document I say: "The root servers (or some other independent party) would host the DNS name". I'm not sure who that third party could be, but the root servers (or perhaps a subset of the root servers) seem well placed in terms of reliability, and trust-ability.

Any entity that takes on such a role will quite likely ask the question:
"Under what conditions is a request to change said DNS RR valid?"
This should be considered carefully if one wishes to anchor to DNS
name.

/John

---

From: Perry Lorier <[email-masked]>
Date: Fri, 06 Jul 2007 09:57:50 +1200

Nathan Ward wrote:
> functions, either (or at least, that I can recall on short notice :-).
> I'm not sure that lack of precedent is a good reason to not do something.

Web browsers have "Web Proxy Automatic Discovery".  They look up the
name "wpad" which gets searched for in the usual dns search path.  Thus
if you're 192-0-2-1.dsl.example.com it will look up
"wpad.dsl.example.com" then "wpad.example.com".  If either of these
exist then it will use them.

To be honest this system is fragile and unreliable, but it is precedent
for a "name" to find a service based on a hard coded dns name.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 6 Jul 2007 09:09:25 +0200

> for a "name" to find a service based on a hard coded dns name.

Yeah, and to take a more v6ops-ish thing, "some" ISATAP client

implementations try to resolve "isatap" to autoconfigure their ISATAP

gateway.

But unless you insert a "wpad."/"isatap." entry into the root DNS zone,

it does not work in this particular case. In fact, even then, if would

not work as many DNS caches are "clever" not to recurse queries for

non-FQDN (and will take any "single-piece" name to be non-FQDN).

Of course, it could go that you try to resolve "teredo" and if that does

not work, you use the anycast address.

-- 

Rémi Denis-Courmont

http://www.remlab.net/

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Jul 2007 14:37:00 -0400

On 5-Jul-2007, at 08:30, Nathan Ward wrote:

> That's a good question as to who would host and maintain the zone.  
> In the document I say: "The root servers (or some other independent  

Procedurally, probably the way to side-step this issue would be to  
document actions that you'd like the IANA to take (assign address/ 
prefix, host zone, etc). That approach is not without its headaches,  
but allows at least more operational flexibility than hard-coding  
such details in a static document. "teredo.iana.org"?

> if (address = failed) then address = a.b.c.d

I'm not convinced that a name is required, actually. If RFC 3068  
could assign an IP address for use as an anycast 6to4 relay, I don't  
see why a new document couldn't do a corresponding assignment for  
Teredo.

Codifying an address and a corresponding covering prefix for use in  
an anycast advertisement also has better characteristics with respect  
to a migration from the status quo, since old implementations could  
be supported seamlessly by simply changing the A record for  
teredo.ipv6.microsoft.com to match whatever is assigned.

Joe