RE: Teredo vs Silkroad

["Liu Min" <liumin@ict.ac.cn>]

Thank you for your comments. You have mentioned some problems which are
common to NAT transversal mechanism, such as the security and multiple NATs
in a path. I will try to answer the questions in-line. Any suggestions will
be appreciated.

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On 
> Behalf Of Tony Hain
> Sent: Tuesday, May 25, 2004 2:30 AM
> To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi
> Cc: v6ops@ops.ietf.org
> Subject: RE: Teredo vs Silkroad
> 
 
> This whole discussion has completely ignored the broken concept of the 
> Silkroad Navigator. That device is essentially a route reflector, 
> without any mechanism to secure the updates to it, or a distribution 
> protocol for consistency (assuming there is intended to be more than 
> one in the world). Also there is an unstated assumption that the 
> Silkroad clients just know how to find the navigator (if IPv4 anycast 
> is assumed, that should be explicitly stated). Any fair comparison 
> should be to tunnel broker schemes, but if one insists on relating 
> this to Teredo, the navigator is functionally the same as the Teredo 
> server, while the access router is functionally the same as the Teredo 
> relay. The primary difference is that Silkroad provides the address 
> stability of a tunnel broker at the expense of client automation.
> 
> As for security, the idea that an RA could come from an arbitrary 
> navigator pointing to some random Silkroad access router is a security 
> hole big enough to drive an army through (never mind that it fails by 
> using an IPv6 function to provide IPv4 information).

SARs are expected to make access control.
What's your meaning by saying that it fails by using an IPv6 function to
provide IPv4 information?

>    Of course, a SC can determine the address or domain name of a SAR
>    through other means. For example, the SC could get the address of
>    SAR by sending Router Solicitation message over UDP to the SN. The SN
>    replies with a Router Advertisement over UDP containing the address
>    of available SAR.
> 
> 
> The whole lifetime discussion is confused. All prefixes will have a 
> lifetime, it may be very long, but it will be there. Any discussion 
> about 'permanent' only invites people to believe the prefix will move 
> with them when they leave Slikroad behind, but that can't happen if 
> the prefix is part of the SAR aggregate.

Do you think it will be better to change "permanent" to "stable"?

> 
> 
>       Moreover, if the SC is an IPv6 router willing to provide IPv6
>    connectivity to several hosts, it should provide some information
>    about how many IPv6 addresses are required.  This allows the SAR to
>    allocate the SC an IPv6 prefix that fits its address needs.
> 
> That is a nice concept, but unnecessary complexity. Given that there 
> is an authentication step at the navigator to find the SAR to begin 
> with, the appropriate prefix length for this subscriber is already 
> available and doesn't need to be included in the protocol between the 
> client and SAR.
 
SN only helps SC who doesn't have a default SAR to choose its SAR, and what
SN provide to SC is the SAR's IPv4 address. The SC should ask for IPv6
address space from SAR and SAR will allocate IPv6 prefix that fits SC's
address need. If a SC already has its default SAR, it will not connect to SN
again.

> 4.2.3 is useless clutter since the base assumption is that there may 
> be multiple nats in the path. Why is there an assumption that they 
> will all be the same type, or that any optimization for the first hop 
> nat will actually be useful along a path full of nats? The whole 
> discussion misses the point that many transfers will be over before an 
> optimization determination could be made.
There is no assumption that the NATs will be the same type.When there are
multiple NATs in the path, silkroad will still work, although the
performance may be influenced. For example, if there are two NATs, one is
cone NAT and the other is symmetric, the NAT type determining process will
judge the NAT type as symmetric. In other words, the NAT type will be the
one with more route optimization constraints. This is a problem common to
all NAT transversal mechanism. But it will not influence silkroad's
functions.


> 
> Figure 2 is very ambiguous (and actually supports Christian's note 
> about the number of SARs). It appears that R1 & R2 should really be 
> SAR1 & SAR2, with a collection of routers (IPv4 Rn) not shown.

R1 and R2 may be the same SARs.


> 
> 
>    If R1 has never forwarded an packet towards this
>    IPv6 destination address and has no route information in its local
>    route table, it will connect to SN to search the list of SARs that
>    can forward IPv6 packets to the specific IPv6 network and get the
>    IPv4 addresses of these SARs.
> 
> No, any router without a route will drop the packet. Anything else 
> will kill the router. Clearly there is need for a periodic routing 
> update here, but the overall specification assumes a small lab 
> environment style network where scale and time delays don't matter.

In this process, the role of SN is just like a DNS. When the SAR has no
route information in its local cache, it will connect SN to 'resolve' the
destination address. This process will leave a record in its cache. So when
the SAR forward packets to the same destination address next time, it will
have the route information and need not connect to SN. SARs should announce
its address space to SN.

> For example:
>    the SC can specify the transmission method in Control Option domain
> 
> No ISP would allow their customers to define the transmission path 
> choice between its routers.
>
SARs may not be provided by ISPs. For example, it could be an enabler for a
game that requires direct IPv6 communication between client hosts. SARs
could be provided by the third party. SC could choose appropriate SAR based
on location, performance, cost or other consideration.
 
> It would appear that the authors don't really have a grasp on 
> operational
> realities:
>    When B wants to transmit an IPv6 packet to A, B simply follows IPv6
>    rules. The packet will be forwarded to one SAR close to B in the IPv6
>    Internet topology, R2, over IPv6.
> Why would this happen? The only reason would be that a routing prefix for
A
> is announced by B into the IPv6 routing domain. But this unreasonable
> assumption is followed with:
>    If R2 has no route information in its local route table, it
>    will connect to SN to search the IPv4 address of the SAR that can
>    forward IPv6 packets to the specific IPv6 address.
> If R2 has no route information, why would it be telling the IPv6 domain
that
> it does? Teredo can do this because it uses a unique prefix for all Teredo
> reachable destinations and assumes the IPv4 network is contiguous.
Silkroad
> can't do this unless all SARs have full routing tables for all clients.

It may be clearer to remove the R2. When a regular IPv6 node B wants to
transmit an IPv6 packet to a SC A, B simply follows IPv6 rules. And because
A's address is belonging to R1' address space, the packet will be forwarded
to R1.


> Another example:
>    All SARs could configure static routes between each other Static 
> configuration is a lab class concept; not useful in the real world.

Sorry, it should be static tunnels, not static routes.

> 
> 
>    In the simplest case, when the Silkroad clients are very few, one SAR
>    may be enough, only if the SAR has connected to IPv6 Internet.

> One thing I haven't seen on the list are all the traditional 
> complaints about open relays and spoofing. There is nothing magic 
> about a SAR that would prevent spoofing. If someone really intends to 
> deploy this, a robust mechanism for limiting access and verifying 
> correct IPv4 / IPv6 mappings will be needed. Since the single SN in 
> the world is the only one that the correct mappings, it will clearly 
> need to be consulted for mapping coherence on each cache miss.

Security consideration is necessary to all NAT transversal mechanisms. In
the first version of silkroad, both the SC's request and the SAR's response
will be   protected by an authentication token, carried in the UDP message.
We call them Shared Secret Request and Shared Secret Response. But it's not
clear whether a shared-secret cryptography is useful in a mechanism like
this, and second, we didn't make it clearer whether the SAR has only one
shared secret or one for each SC. So the shared secret mechanism is removed
in this version. We are working on detailed security mechanisms now. And
related contents will appear in the next version. 


>    In the simplest case, when the Silkroad clients and Silkroad access
>    routers are very few, there is no need to configure Silkroad
>    navigator.
> 
> Wait, I thought the SN was necessary for client authentication up 
> front. How can the system get by without one? It really doesn't matter 
> because the assumption that the world can do with ONE is a clear 
> indication that the spec is a lab effort that is never intended to be 
> deployed.
> 
SN only helps SC who doesn't have a default SAR to choose its SAR. What SN
provides to SC is the IPv4 address of available SAR. SC should ask
appropriate SAR for service. SARs are expected to perform access control. So
SN is not necessary for client authentication. 

As mentioned in the draft, in the initial deployment of the Silkroad
service, there may be only one globally accessible Silkroad navigator.
However, along with the increase in the size of the route database in SN and
frequency of updates, it may demand a distributed manner with local caching
to improve performance. But at this time, it is recommended to offer native
IPv6 instead of deploying many SNs. In fact, when all SARs have easy access
to IPv6 Internet, SN could be omitted.
> 
> 
> In short Silkroad is nothing more than trying to provide a scaling 
> front end for the forwarding function of the tunnel broker model. 
> While that function is an admirable goal, this spec will need major 
> rework before it even comes close to something that is operationally 
> deployable. A reasonable trust model and fully dynamic routing update 
> system are the first steps. In any case Silkroad should not be 
> compared to Teredo because it is fundamentally a tunnel broker (albeit 
> a broken one in the current spec) so section 7.4 should simply be 
> removed.

Silkroad and Teredo are two solutions to the same problem. It is very
natural to make a comparison between them.


> 
> Tony
> 
> 
> 
>