RE: Teredo vs Silkroad

["Tony Hain" <alh-ietf@tndh.net>]

Liu Min wrote:
> ...
> No. Although Teredo servers don't relay packets, Teredo need separate
> relays.
> SAR's role includes the role of Teredo server and Teredo relay. You
> should compare the number of SAR with the number of Teredo servers +
> Teredo relays.

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).
   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. 


      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. 

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. 

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.


   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.
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. 

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


   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.


   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.



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. 

Tony