RE: Teredo vs Silkroad

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

Liu Min wrote:
> 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.

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

> What's your meaning by saying that it fails by using an IPv6 function to
> 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. 

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

Yes.

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

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.

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

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.

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

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.

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

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.


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

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.

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

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

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

The point was that 'static' is not practical in the global production
Internet. It doesn't matter if that is tunnels or 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.

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

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

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. 

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

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.


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

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