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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 2 Oct 2001 09:58:03 -0700

Nathan,

Your questions seem more in the line of whether we should do it, rather
than whether this is the right way. 

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

We could say the same thing about any transition strategy, and indeed
the argument was made about 6to4 as well: by making it easy to deploy
IPv6 over the existing infrastructure, we ease the pressure to change
that infrastructure. However, we have a converse problem: if it is hard
to run IPv6 over the existing infrastructure, then there is little
incentive to deploy IPv6 capable applications, and so there is little
use of IPv6; if there is little use of IPv6, then there is no incentive
to upgrade the infrastructure to support it. The goal of Shipworm is to
make sure that every Internet user can use IPv6, so that we start a
virtuous circle: more IPv6 capable applications, more IPv6 traffic,
hence more pressure to upgrade routers and NATs.

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

This is addressed in section 5.10. A firewall administrator who wants to
block the Shipworm service can do so by blocking the shipworm UDP port.
You are hinting however at a more generic problem than Shipworm:
administrators who rely on an IPv4 firewall for security will have to
deploy an IPv6 capable firewall if they want to secure their IPv6
traffic.

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

I don't quite see the point of your comments. We are not in the business
of second guessing the business motives of ISPs or their customers. Are
you suggesting that we change the specification so that customers can
hide from their ISP?

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

As you say, not much we can do about this; but then, there is not much
we can do about anything. In fact, we could probably get IPv4 address
discovery through a lot of strange ways; abusing SMTP comes to mind.
Note that there is parallel work going on to provide an IPv6 independent
IPv4 address discovery service
(http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt); this
should be more appropriate for IPv4 applications. In addition, I should
note that the approach is not new; see
http://www.alumni.caltech.edu/~dank/peer-nat.html for a reference to
previous art.

By the way, it seems that peer-to-peer applications such as Bearshare
would really benefit from better connectivity. Rather than messing
around with the shipworm servers, they are much more likely to just use
IPv6.

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

Again, Shipworm is specifically not designed to work through firewalls. 

> 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

We definitely intend to implement it, but I would get in deep trouble if
I committed to any release date.

-- Christian Huitema

---

From: Nathan Lutchansky <[email-masked]>
Date: Tue, 2 Oct 2001 16:42:23 -0400

> than whether this is the right way.

I'm sorry, I should have been more clear about what I was arguing for.  

I'm very much in support of Shipworm, as it seems to be a great approach
to making IPv6 available everywhere.  Although tunneling IP through UDP
has been around for a while, Shipworm is well-planned, well-researched and
well-supported, giving it a good chance of putting IPv6 in the hands of
all users.

My only suggestion is for the draft to clearly state that Shipworm
functionality should NOT be enabled by default, as it creates too much of
a security problem for my comfort.  With this caveat, I fully support
advancing the draft to PS.

More comments below...

> > no longer have any incentive to implement IPv6 until it is needed
> > on the WAN link.
> 
> that infrastructure.

Yes, 6to4 eases pressure on the infrastructure, but I don't think that's a
huge concern.  If the users/customers demand IPv6, the infrastructure will
support it; the existence of a strong IPv6 backbone has no effect on
customer demand.  Look at multicast if you want a good example of that.  
Almost all backbones support native multicast, most supply it to customers
for free, but nobody wants it.

My concern was that NAT vendors, who make the hardware that most needs
IPv6 support, will no longer have a reason to support IPv6.  But I bet
there's enough competition in the NAT market that the IPv6 support will be
available before the users even really care.  I certainly think the
benefits of Shipworm outweigh this concern, I simply felt obligated to
point out that this was my biggest reservation about supporting Shipworm
at all.

> However, we have a converse problem: if it is hard to run IPv6 over
> the existing infrastructure, then there is little incentive to deploy
> IPv6 capable applications, and so there is little use of IPv6; [...]

Yes, I agree that simply making IPv6 available to all users is more 
important than concern about whether the transition technologies hinder 
vendor and provider adoption.

> > 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.
> 
> This is addressed in section 5.10. A firewall administrator who wants
> to block the Shipworm service can do so by blocking the shipworm UDP 
> port.

Yes, but how many administrators read all RFCs as soon as they come out,
just to make sure their firewalls are up-to-date?  I know they *should*,
but in practice that doesn't happen.  It will take many months after
Shipworm becomes available for admins to figure out that it even exists.  
Thus, you can't assume that simply because an administrator hasn't blocked
the Shipworm UDP port, they don't mind the use of Shipworm on their
network.  They may have figured that any protocol that uses UDP is
probably safe, which is true in general.

My point here is that you are taking UDP, which is generally assumed to be
fairly benign, and you're tunneling an entire network protocol through it.  
Not only that, but you have included a workaround (bubbles) to defeat an
extra security feature of many firewalls!  So I'm trying to ensure that a
security nightmare doesn't happen inadvertently due to the OS vendor
enabling Shipworm by default, possibly without the user even knowing it.  

If the user has to enable Shipworm explicitly, then at least they get the
blame for security breaches.  Can you imagine the web-zine headlines if
Shipworm was on by default?  "IPv6 labeled 'major security risk' by
experts" or even "Gaping security hole in XP renders firewalls useless"
(replace XP with your favorite Shipworm-supporting OS).

Maybe it sounds like I'm blowing the security aspect out of proportion,
but I know if a user had started running a protocol like Shipworm back
when I was a network administrator, I would have had them shot for
compromising the network.

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

No, users don't need the help of the WG to hide from their ISP.  There are
already a number of software packages that tunnel traffic like Shipworm,
but with extra features like encryption.  (I use vtun.)

The point about hiding NATs was just another illustration of why Shipworm
should be disabled by default.  If a user doesn't need or want IPv6
connectivity, his/her workstation should not be attempting to achieve it
by default.

> around with the shipworm servers, they are much more likely to just use

One would hope.  I'm sure they'll be the first widely-used IPv6 apps.  
Eventually they'll all use IPv6, of course, but in the mean time they
probably won't be too hot on it since nobody will be using it until XP
gets a bit better penetration and Shipworm becomes available.

I wouldn't be too surprised if what really gets everybody IPv6-enabled is
if a popular P2P app enables the IPv6 stack as part of the install
procedure.

> > will be made available as an add-on to XP, or maybe as part of a 
> > service pack?
> 

Well, my question was really whether we can expect Shipworm as some sort 
of free XP add-on in the not-too-distant future, or if we'll have to wait 
for Windows XXP or XP 2.0 or whatever the next version will be called.  It 
will be nice if it's integrated into a service pack so users won't have to 
download it themselves.  -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      |
+------------------------------------------------------------------+