Subject: Re: (ngtrans) W.G. Last Call on "Shipworm: Tunneling IPv6 over UDP through NATs"

From: Nathan Lutchansky <[email-masked]>
Date: Tue, 2 Oct 2001 11:24:27 -0400

On Fri, Sep 28, 2001 at 06:38:11AM -0700, Bob Fink wrote:
> This is an NGtrans working group last call for comments on advancing the
> following document as a Proposed Standard:
> 
> 	Title		: Shipworm: Tunneling IPv6 over UDP through NATs
> 	Author(s)	: C. Huitema
> 	Filename	: draft-ietf-ngtrans-shipworm-02.txt
> 	Pages		: 25
> 	Date		: 27-Sep-01

I do have a few observations about the Shipworm draft, although I haven't
spent as much time thinking about it as I'd like.

My biggest concern about deploying Shipworm is that NAT vendors will no
longer have any incentive to implement IPv6 until it is needed on the WAN
link.  Currently, for a NAT box to correctly and transparently support
IPv6, it must have a full IPv6 stack and correctly forward packets over
either a configured tunnel or via a 6to4 relay.  If Shipworm is available
in most operating systems, vendors will have no reason to support IPv6 any
further than to make sure Shipworm works with their particular NAT
implementation.  There are advantages to having a real IPv6 router instead
of running everything on Shipworm, such as (more) stable addresses, not
needing to send local traffic thorough a relay, etc, that we'd miss with a
Shipworm-only network.

I can see Shipworm causing security issues as well.  Obviously, it can
create holes in firewalls as well as NATs, which will upset administrators
once they discover that all of their IPv6-enabled workstations are fully
exposed to the Internet.  6to4 fails safely in this situation, since most
firewalls won't allow arbitrary IP packet types through.

Thus, I think Shipworm implementors should be careful to leave Shipworm
disabled by default, and require user action to turn it on.  I can think
of several additional situations in which users would be upset that their
computer was "broadcasting" its presence from behind the NAT.  ISPs would
love to have an easy way to detect NAT use by their customers, and access
of the Shipworm UDP port seems like a big red flag.  "ISP cancel your
account for running a NAT?  Shouldn't have installed that IPv6 thing,
that's how they found you!"

One thing that public Shipworm server operators should keep in mind is
that they're providing a public, anonymous method for nodes to obtain the
global IPv4 address of the NAT that they are behind, using unprivileged
userland network access.  If any popular peer-to-peer type applications,
such as BearShare, decide to (mis)use the Shipworm protocol to discover
their NAT address, public servers may see more non-IPv6 traffic than real
traffic.  There's not much that can be done about this, though.

My final observation is mostly a curiousity.  Since Shipworm provides IPv6
connectivity over a nonprivileged protocol, it will be feasible to
implement a full IPv6 stack entirely in userland.  If I had a lot of free
time, it might be fun to write such a stack and release it for free.  
Maybe some P2P apps would pick it up as a quick way to work around NATs
and firewalls, or a SOCKS v4v6 translator could be built around it to
provide "on-the-go" IPv6 access from any computer, such as in a public lab
on a university campus.

Oh, and a question for the MSR guys.  How likely is it that Shipworm will 
be made available as an add-on to XP, or maybe as part of a service pack?  
I was impressed that ISATAP made it into the XP release, so maybe Shipworm 
will follow once it's standardized?  -Nathan

-- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 4 Oct 2001 18:20:50 -0700

Bob,

I had a side discussion with Keith in order to resolve his comment on
the last call. We agree that it is possible to extend Shipworm so that
the clients could also speak to a "stateful tunnel server". The main
problem with the extension is defining a way for the client to securely
claim allocation of a specific address. This requires more work. In
order to not slow the process, I propose to add a "further work" section
to the shipworm draft that describe this work; the actual "stateful
tunnel" extension will be described in a separate draft, that should
normally evolve in an RFC that extends the Shipworm specification. The
text of the proposed further work section is appended.

-- Christian Huitema

6	Further work: tunnel service

It may be desirable in some cases to deploy stateful tunnel servers
instead of the stateless Shipworm servers. Tunnels servers generally
require more resources, but an advantage is that they can potentially
provide the users with "permanent" IPv6 addresses. It is possible to
design a tunnel server protocol that is compatible with Shipworm, in the
sense that the same client could be used either in the Shipworm service
or with a tunnel service. The main requirements of such a solution would
be:

1) Allow clients to be configured to send traffic to either the shipworm
anycast address or the address of a specific tunnel server;

2) Modify the qualification procedure so that clients would detect
whether they are connected to the Shipworm service or to a tunnel
server, e.g. by checking whether the advertised prefix is a Shipworm
prefix;

3) Ensure that clients, when they are connected in tunnel mode, do not
send shipworm bubbles;

4) Ensure that clients, when they are connected in tunnel mode, send
their packets to the tunnel server.

A tunnel server will manage a pool of /64 IPv6 prefixes, for which it
will advertise IPv6 reachability. When it receives a router solicitation
from a new client, the tunnel server will allocate one of the available
prefixes to the client, and will keep track of the mapped IP address and
mapped IP port of that client. When the tunnel server receives an IPv6
packet, it will check the table of prefixes and forward the packet over
UDP to the corresponding mapped IP address and mapped UDP port of the
client; the maintenance procedure performed by the client guarantees
that these packets can be received through the NAT.

In order to fully specify the behavior of a tunnel server, we must study
how the client could be authenticated and authorized, so that the same
client would receive over time the same address, even if the mapping
provided by the local NAT changes. It is probably possible to use the
Authentication Header for this purpose, but the whole procedure needs to
be properly analyzed.
<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Bob Fink <[email-masked]>
Date: Thu, 04 Oct 2001 19:35:09 -0700

Christian,

Your proposed process seems ok to me. Let's assume it will work until 
informed otherwise by the IESG.

Thanks,

Bob

===

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Oct 2001 11:24:16 -0700

Christian,

It sounds to me that what you are describing is a form of Tunnel Broker
where the actual tunnel set up is done with IPv6/UDP/IPv4 instead of
IPv6/IPv4.
May be I could expand the MINE type description to include this case.

         - Alain.

         - Alain.