Subject: RE: Teredo vs Silkroad

From: "Christian Huitema" <[email-masked]>
Date: Sun, 23 May 2004 22:59:25 -0700

> Why do you think Silkroad need more relays and servers than Teredo?

The SAR's relay packets, while Teredo servers don't. It implies that you
will need more SAR servers than Teredo servers.

The number of relays is different. Depending how you count, there are
currently maybe 1 or 2 Teredo relays, or 2 millions. This is because
every host that is aware of Teredo can act as a "host specific relay". I
suspect that the number of relays required for silkroad is similar to
the number required for 6to4. 

-- Christian Huitema

---

From: "Liu Min" <[email-masked]>
Date: Mon, 24 May 2004 14:09:32 +0800

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, May 24, 2004 1:59 PM
> To: Liu Min; Eiffel Wu; [email-masked]
> Cc: [email-masked]
> Subject: RE: Teredo vs Silkroad
> 

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.

---

From: Fred Templin <[email-masked]>
Date: Mon, 24 May 2004 06:29:28 -0700 (PDT)

Liu Min <[email-masked]> wrote:
No. Although Teredo servers don't relay packets, Teredo need separate
relays.

I don't think "separate relay" is is an accurate way to characterize
a relay that occurs on the end host?
 
Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 24 May 2004 11:29:55 -0700

Liu Min wrote:
> ...

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

---

From: "Liu Min" <[email-masked]>
Date: Wed, 26 May 2004 01:26:16 +0800

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.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tony Hain
> Sent: Tuesday, May 25, 2004 2:30 AM
> To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; [email-masked]
> Cc: [email-masked]
 
> 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?

> 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"?

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

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

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

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

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

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 May 2004 12:53:05 -0700

> SARs are expected to make access control.

It would be useful to see some text before commenting about how that could
possibly work.

> provide IPv4 information?

The text says that the SN can indicate the SA to the SC via an IPv6 RA.
Since the RA is an IPv6 mechanism, it doesn't have any capability to provide
an IPv4 address of the SA to the SC. 

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

Yes.

> address need. If a SC already has its default SAR, it will not connect to

So when the SAR is dead, there is no way to choose an alternative...

Since there is no detail about the client authentication process, there is
no way to comment about mechanisms for allocating prefixes. The one thing
that is clear from the ISPs I have talked to is that they want to control
that prefix length through their business process, so having a dynamic
protocol for requesting an arbitrary length is pointless. Figure out how to
use DHCP-PD to accomplish this task.

> all NAT transversal mechanism. But it will not influence silkroad's

Yes the mechanism will find the least common capabilities, but what was the
point? The result is limited to a very specific address (and possibly port)
over a short period of time. Every transfer will required a different
decision, so the SC is very likely to spend more time trying to figure out
the optimization than actually transferring data. The whole mechanism will
be simpler if you just assume that the SA will be in the path, because it
will be more often than not.

> R1 and R2 may be the same SARs.

That was not the point of my comment. The figure is showing architectural
components, but there is no 'SAR' in the picture (they are designated R1 &
R2 rather than SAR1 & SAR2). Yes SC's may attach to the same SAR, but they
are just as likely to be attached to different ones. The mechanism has to
work for the more complex case, leaving the simple one as just an
optimization.

> have the route information and need not connect to SN. SARs should

So every time a SAR restarts it will beat on the SN until it rebuilds its
cache... Clearly you are assuming that a collection of IPv6 prefixes will be
routed through a single IPv4 address for an extended period of time. What
mechanism allows that IPv4 address to change? When a SAR has a stale mapping
it will just forward packets into oblivion, or worse end up DOSing the new
device that was unfortunate enough to have been assigned an old SAR address.

> on location, performance, cost or other consideration.

Clearly this is not intended for real deployment. As a simple example, if a
node can only have one SAR, but it wants to optimize itself for different
gaming environments it would need the ability to attach to different ones
depending on the application. Yes there is SAR-SAR tunneling, but for the
serious gamer that hop is unacceptable. 

In any case you missed the point. It doesn't matter who provides the SAR,
there is no way the operator of that device will allow the clients to direct
its routing decisions. The document appears to be hacking in a QoS mechanism
by increasing the overhead in every packet. If that is the goal, it would be
better to simply require mapping the QoS from the IPv6 header to the IPv4
tunnel header.

> > Why would this happen? The only reason would be that a routing prefix
> for
> A

...Some serious hand waving going on here... R1 (really SAR1) is not
connected to B by a native IPv6 path, so your forwarding comment makes no
sense. In any case, it is not better to remove R2 (really SAR2) because you
have to make the complex case work, and this spec doesn't even come close.
The only reason B would send a packet to SAR2 is if it believed SAR2 was the
path to A. For that to happen, SAR2 would have to announce SAR1's prefix
into the IPv6 routing system that B is attached to. Since the scenario
described in the document claims that SAR2 has no information about SAR1,
there is no reason for it to make that announcement. 

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

The point was that 'static' is not practical in the global production
Internet. It doesn't matter if that is tunnels or routes.

> related contents will appear in the next version.

Shared secret between all clients is also know as WEP. While the
architecture works between a small trusted set, it fails miserably in the
real world. Whatever the process is, it needs to provide a scalable way to
distribute & change the auth token (hint: shared key across 1M clients will
never work).

> SN is not necessary for client authentication.

It really doesn't matter where the auth is done until there is an
unambiguous way to identify the client. Even when there is a way to identify
the client, the SC will need a way to verify the authenticity of the list
the SN is providing. Also it is wrong to claim there is no need for a SN
when SAR's are expected to use it to find each other, and for that each SAR
will need a way to verify that the list from the SN is valid. 

> to IPv6 Internet, SN could be omitted.

Since the SARs require the SN to find each other having only one (or even a
handful) in the world is a guarantee that this proposal will go nowhere.
Simply connecting some of the SARs to the native IPv6 network does not
obviate the need for the SN so they can all find the ones that are isolated.

> natural to make a comparison between them.

They are not solving the same problem. Silkroad is a tunnel broker,
requiring explicit manual intervention at setup, while Teredo requires no
manual action at the client. Silkroad is an enhancement to the tunnel broker
concept in that it attempts to optimize routing away from the prefix
allocation point. The only similarity with Teredo is due to this routing
optimization, and the need to punch arbitrary holes in NATs. Since the
fundamental point of any tunneling mechanism is providing basic connectivity
to isolated IPv6 nodes, the primary comparison has to be on that point. The
secondary issue about optimizations may be helpful in terms of sharing best
practices, but optimizations are not the place to make primary comparisons. 

If Silkroad incorporates a trust model that is simple enough to deploy and
operate at Internet scale, there might be reason to continue working on it.
Once there is a trust model, the whole demand based query to the SN will
need to be replaced by a dynamic protocol between the distributed SN's, with
some form of dynamic update out to the SARs. Without those capabilities,
there is no value over any of the existing Tunnel Broker schemes. 

Tony