[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt
On Wed, 4 Jul 2007 10:16:40 +1200, Nathan Ward <v6ops@daork.net> wrote:
> 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.
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/