[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/