Subject: (ngtrans) Review of draft-ietf-ngtrans-shipworm-03.txt

From: Randy Bush <[email-masked]>
Date: Mon, 21 Jan 2002 17:10:50 +0100

apologies for the long time it took to get this out.  aside from ad
overload, as you will see from some comments, the document is not
easy to read, and does not make the protocol amazingly clear.  and we
were also waiting for the publication of the architecture draft from
the iab, draft-iab-unsaf-considerations-00.txt, which we believe to
be very relevant to this work.

i will append the comments of four reviewers

randy

---

Shipworm makes use of IPv4 anycast. How it uses it is very scary, by
orders of magnitude compared to what has been deployed/talked about
today.

Shipworm relays source the packets they tunnel back to clients using
the shipworm IPv4 anycast address. They also advertise the shipworm
IPv6 prefix into the v6 world. If a random IPv6 node sends to a
shipworm IPv6 address, it will get routed to the closest egress point
(on the v6 cloud). The shipworm relay that receives it then figures
out the true IPv4 destination, and tunnels the shipworm packet to it,
using the ipv4 anycast address as a source address.  The IPv4
destination address will be random (with regardst to IPv4 topology --
it won't be "close" to the shipworm relay).

Imagine a world with thousands of these relays, all sending IPv4
packets sourced with an IPv4 anycast address. Ingress filtering may
make this fun. Debugging will be fun. ...

BTW, the  use of the anycast source address is integral to a bunch of
the error checks that nodes make when processing the packets. So it
may not be trivial to fix.

---

I had understood that the relay discovered by the shipworm client
would advertise the route to that client, making that relay the
closest egress?  Which also means maintaining state appropriately
between the client and the relay, and requires that the relay be
an effective IPv6 routing implementation.  

But, doesn't this also make a routing nightmare, with shipworm-prefixed
IPv6 address routes scattered individually across the globe?.

---

General problem being addressed: allowing any IPv4-networked machine
to interact with any machine in IPv6-networks, with no special code
in the client processes running on the client (IPv4-networked)
machine.  The special interpretation is implemented once in the IP
stack of the client machine.  There are 4 pieces to the proposal:

	1. a relay mechanism to bridge transmission of the data from
	   IPv4-networked machine to the IPv6-routable world (a
	   proxy)

	2. a server to reflect the "global" IPv4 address of the
	   client machine -- based on the assumption that the client
	   is behind a NAT (and, possibly, firewall)

	3. discovery -- of the shipworm server, and of the shipworm  
	   relay

	4. an IPv4 short-circuit practice to reduce load on relays,
	   by allowing the client to communicate directly to an IPv4
	   address when it detects that the destination IPv6 address
	   is in fact a shipworm address.

Comments/questions on #1 (relay):

This is the smallest scoping of the problem to be solved.  It has the
same issues as any proxy -- single point of failure, traffic
redirection, etc.  Because the work is done as wrappers (IPv4 around
an IPv6 packet, which is forwarded unmolested) this does not get in
the way of IPsec mechanisms (?).

The overall shipworm effectiveness is only as good as the shipworm
relays are at implementing IPv6 routing.

The document makes no comment about expected deployment & coverage of
these relays.

Comments/question on #2 (firewall/NAT tunnelling) :

#2 is effectively the same problem as is to be solved in "pre-midcom"

perhaps this could (should?) be broken out of this proposal, and
only one "solution" to finding and maintain the reflected IPv4 global
address should be discussed.

A basic assumption (to be tested by operational reality) is that the
client IPv4 machine will have a fairly stable external address (IPv4
address & port) relative to the shipworm server.

There are 2 basic security concerns:

	. that using UDP and poking through a firewall/NAT
	  to reach the shipworm server/relay allows the client
	  machine to circumvent intended traffic policies implemented
	  in the firewall (e.g., if the network policy is to prevent
	  IRC connections)

	. that the client machine becomes a fully-accessible
	  machine on the IPv6 network -- once the shipworm IPv6
	  address of the client box is advertised, _any_ packets can
	  be addressed to it, including ones that would normally be
	  stopped by the firewall (port-scanning policies, etc).  Any
	  firewall or other security mechanisms must be implemented
	  on the client (IPv4) machine directly.  This may not be
	  much of an issue if there is only one specific process
	  running on the machine trying to talk to a specific IPv6
	  remote host, but it is an issue in generalization: you
	  could (and therefore, people will) run a general purpose
	  server over shipworm, including HTTP, mail, other services.

Also, this document seems to assume that most or all shipworm clients
will be located behind NATs/firewalls, and seems to unnecessarily
skew its focus.  By separating out the "self address discovery"
portion of the proposal, this document could start from the premise
that a globally accessible IPv4 address for the client machine is
known.

Comments/questions on #3 (discovery):

The purpose of the discovery portion of the proposal is to allow
minimal configuration of the shipworm client.

How does a shipworm client determine "legitimate" shipworm servers?
I.e., it doesn't seem that it would be difficult to spoof the service
(e.g., in a bridged loop of home network users, how hard would it be
for someone to set up a "shipworm server" that declared itself and
got traffic from other machines, to whatever end?).

A more serious discussion of the pros/cons of discovery vs.
configuration is needed.

Comments/questions on #4 (IPv4 fallback):

The purpose of the fallback to IPv4 seems to be to reduce the load on
the shipworm relay when it's not necessary.  However, much of the
brittleness of the proposal is introduced by maintaining lists of
known "peers" and attempting to create an overlay.  This doesn't
directly address the basic problem of letting IPv4 nodes communicate
with IPv6-speaking servers, and the complexity suggests it should be
dropped.

Also, if the IPv4 address in the shipworm mapped address is in fact
an external address to a NATed machine, it's not at all clear that
the address+port combination that the shipworm server detected would
be the one that a shipworm client could address (the NAT heuristics
for address/port assignment are not known, and may vary with target).

It's not clear how the shipworm client, addressing a remote service
at the IPv4 address detected in the shipworm address, should declare
itself -- the remote service might reject the packets as being from
an "unknown" (not previously contacted) service.

The complexity of getting this part right, without amassed kludges,
is significant.

General comments/questions:

What is the transition plan -- state clearly that a client machine
MUST use IPv6 if it is available locally.

What happens if I do a "traceroute" (or other standard networking
tools) from the shipworm client machine to an IPv6 target?  Does this
help with the potential problem of shipworm server spoofing?

---

General comments:

Underspecified -

It badly needs diagrams before page 18 and a packet flow example
showing what the addresses are in each of the headers are for each
phase.  Reading the spec is quite difficult without these, and also,
I think an implementor would have to look at the MS implementation's
wire traffic to be sure what was supposed to be in the headers,
because the prose is not precise.

Key protocol behaviors, such as the "interval determination
procedure," are discussed in pieces, and unclearly.  This kind of
underspecification is not to be remedied by just inspecting wire
traffic, and it could foster doubt whether MS is serious about others
being able to implement the protocol.

Security -

Important security and trust points are hand-waved, such as the
authentication of relayed traffic (3.2) and the authorization of
advertisement of the shipworm anycast (section 7, paragraph 3).  More
remarks on this in the specific comments.

Transition/compatibility with other techniques -

There is a paragraph very late in the document (5.9) that says MUST
prefer v6-infrastructure, 6to4, and 6over4, if they are available.
There is no consideration of how to determine if they are, given that
the premise of shipworm is an unsophisticated end-user for whom
complete autoconfiguration is needed.  What is the automation of
transitioning to the preferred configurations?

Specific comments:

2.7

What is the usefulness of having 255 shipworm anycast addresses,
rather than doling out one?  It might make an UNSAF sunset harder if
there are 255 in use in parallel (relevant to this is the hand-wave
in the 3rd paragraph of Section 7, that somehow only ISPs will be
"authorized" to use shipworm anycast addresses).

3.0  Model, requirements

In keeping with the name of the section, the shipworm model is
assumed and requirements only discussed against it; this section
should have requirements, alternatives, then solution.

A tunnel broker-like model is dismissed too quickly as a
configuration problem, but one could imagine cases where a tunnel
broker is seen by the user as like home dialup server (only with
addresses).

Isolated v6 clients could get NAT-traversing UDP tunnels to a 6to4
router from a service providing that for production use.  A tunnel
service is in Future work (section 6), but it is discussed only as a
side-by-side later technique, with an unclear compatibility to
shipworm.  Possibly a tunneled approach would meet requirements of
clients needing shipworm (unless truly self-organizing and
unproduction are their strong requirements).  And the UNSAF issues
might be less or avoided.

ISP Tunnel: nodifying the one diagram the reader gets (page 18!),
this ISP-managed alternative would look like:

                                   .-----------------------
                                   |  Private network
         .--.   src=9.0.0.1:4096 .-----.     .----------.
        (IPv4)  src=9.0.0.1:4097;| NAT |     | Isolated
      (Internet)<--------------  | BOX | <-- | V6Client |
        (    )   (UDPv4 tunneled |     |     '----------'
         '--'         IPv6)      '-----'      10.0.0.2:1234
          |                9.0.0.1 |          Global v6
          |                        |          address
          |                        |          provided by
          V                        |          v6 ISP (not
   .--------------.                |          equal v4 ISP)
   | ISP tunnel to|                '-----------------------
   | 6to4Server   |
   '--------------'
     [6to4 router]

But rather than make a review into a spec, suffice to say that the
shipworm requirements are not all on the table, and that despite the
hand-waves about authentication and security, self-organization of
the IPv6 overlay seems to be a major unspoken requirement.  This goal
brings with it all the UNSAF considerations.

3.2	Protection against denial of service attacks

  Shipworm servers will act as a relay for IPv6 packets. Improperly
  designed packet relays can be used by denial of service attackers
  to hide their address, making the attack untraceable. The shipworm
  service must include adequate protection against such misuse.

What is the trust relationship that a valid user has?  How is there
any authentication?  It's hard to see how this could be provided (the
address checks later cited as the solution look spoofable).

3.3	Non-requirement of permanent addresses

Why not* require global IPv6 address allocation through a provider of
service for the isolated clients?  The alternative model above would
do so and this would be useful for long-term evolution.

4.2

 - List of recent Shipworm peers.

I echo the other reviews that the cache of direct tunnels to recent
Shipworm peers is a problem for control, security, and scalability.
It is not clear from the piecemeal (under)specification of how the
timers work, but it seems that this cache could be far from
soft-state.

The other side of the coin if the cache does get garbage- collected
aggressively, is lossiness and changes in delay in the tunnels over
the life of one connection.  For this, TCP will work, but users will
perceive lousy performance compared to their NAT without trying to
use IPv6.

4.2.1

The description of the Prefix Information is another example of
underspecification.  What are the Lifetimes?  Have you demonstrated
that DAD is not needed?  In what way are the shipworm servers not
stateful since the random link address of the solicitor is a nonce?
It may be fair to say that they fail safely because they drop the
packets if the nonce doesn't match, but what if routing flaps make
this happen often?

4.3.1	Processing of Shipworm IPv6 packets

  1) If the IPv4 source address does not belong to a range of IPv4
  addresses for which the Shipworm server is providing service, the
  server MAY silently discard the packet.

How is the binding of a range of valid addresses set up?

What is the operational idea here?  Very hard to follow.

Why MAY?

4.4.1	Difference between Shipworm Relays and Shipworm Servers

  The additional requirement for a Shipworm server to become a
  Shipworm relay is: advertise the Shipworm IPv6 service prefix in
  the IPv6 routing fabric. This may or may not be easy to achieve; it
  could be hard in some cases, e.g. if the Shipworm server's
  connectivity is by means of the 6to4 service. In any case, if a
  Shipworm server receives IPv6 packets bound to a Shipworm
  destination, it MUST process them according to the Shipworm relay
  specification.

This paragraph captures the difficulty of detecting and transitioning
to the preferred 6to4 service (5.9) and it gives incoherent guidance
for implementation and operation.

6	Further work: tunnel service

Very complex to say that this would be compatible with a shipworm
deployed base.  Also about the security statement:

  It is probably possible to use the Authentication Header for this
  purpose, but the whole procedure needs to be properly analyzed.

Not likely (see MIPv6 experience) - this is hand-waving away the need
for a trust structure of some kind.

7	Security Considerations

  Implementers should be aware that, in addition to possible attacks
  against IPv6, security attacks against IPv4 must also be
  considered.  Use of IP security at both IPv4 and IPv6 levels should
  nevertheless be avoided, for efficiency reasons.  For example, if
  IPv6 is running encrypted, encryption of IPv4 would be redundant
  except if traffic analysis is felt to be a threat.  If IPv6 is
  running authenticated, then authentication of IPv4 will add little.
  Conversely, IPv4 security will not protect IPv6 traffic once it
  leaves the Shipworm service. Therefore, implementing IPv6 security
  is required even if IPv4 security is available.

Paragraph is not coherent. The user is both told to run IPv6 security
even if IPv4 is there, and not run them both at the same time.

The referent of "security" is unclear: end2end security for the user
of the shipworm service?  IPsec or something higher?

BTW, I agree with another of the reviews about the comparison to the
many gotchas involved in NAT-traversal by IPsec.  The interaction of
shipworm and IPsec is not straightforward.

Finally about this paragraph, if it does happen to refer to security
associations of the client with the shipworm server and/or relay,
forming such isn't compatible with the statelessness and discovery
model.

  In contrast with the 6to4 default, Shipworm traffic will not be 
  accepted and decapsulated from any source from which regular IPv4 
  traffic is accepted: the service is designed to prevent malevolent 
  agent from using Shipworm servers for "laundering" a denial of 
  service attack. Shipworm packets are always sent from either the 
  Shipworm IPv4 anycast address, or from an IPv4 address and UDP port 
  that is strictly consistent with the encapsulated IPv6 source 
  address; this MUST be checked by servers and clients, as specified 
  in sections 4.2.2 and 4.3.1. We expect that only routers controlled 
  by Internet Service Providers will be authorized to use the anycast 
  address as a source address for UDP packets.

The checks described in 4.2.2 and 4.3.1 are spoofable for a packet
launderer.  The last sentence is just wishful.

---

Mohit Talwar had comments which i am not aware have been answered

The document is poorly organized.  It would greatly benefit from an
abbreviated walk-through up front.

In general, this is a way to deploy V6 application software to run in
a V4 universe.  But it does so through horrible tunneling through UDP
all over the net.

The stateful "list of recent peers" is an architectural horror.  it
is effectively building circuits and requiring the client stack to
maintain the cache.

If the site has a NAT, and the NAT does not gate 6to4, then why are
we building methods to subvert the site's security policy?  Note that
midcom transits NATs with their cooperation, i.e. is within site's
policy.

Further, I suspect that this could allow use of a host inside the
site to provide the service of transit routing between external
sites.

It presumes stable routing so that one's 'discovered' address is
constant in the multi-NAT environment.

In Sec 2, and in uses of these terms, it would be easier on the readier
if terms which are v6 or v4 specific had v6 or v4 in their name.  e.g.
Shipworm UDP port, Shipworm service port, ...

As 3.2 says, the service is not authenticated, anybody may use it.  And
anybody may use it to launch dos attacks.

-30-

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 21 Jan 2002 10:04:37 -0800

Randy,

While I agree the document is challenging to read, I think some of the
> a V4 universe.  But it does so through horrible tunneling through UDP

The point of Shipworm is to solve the case where all else has failed and
UDP is the only option. If this were stated through an ammendment to the
sending rules, I believe the question about transition would be answered
as well.

> In what way are the shipworm servers not

The server is not required to do anything more than echo the nonce. It
is simply a mechansim for clients to detect valid/spoofed RAs.

> is effectively building circuits and requiring the client stack to

While the document spends time describing the state maintenance, this is
supposed to be an optimization, not a requirement. Also, it is being
done in the only appropriate place for scaling, the origin node. Yes it
is full state, but no worse than TCP.

> midcom transits NATs with their cooperation, i.e. is within site's

Since when does NAT == Security ???

While I agree that this could be used to subvert a firewall, so could
IPsec over UDP, and IPsec ensures the network manager can't tell what is
happening. What might be useful is a comment in the security section
about how a site firewall could detect this protocol and block it if
policy dictates. The point is not to subvert actively managed networks,
rather it is to allow simple use of IPv6 through unmanaged networks with
inept NATs in the path. In any case NAT is not a security tool.

Tony

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Randy Bush
> Sent: Monday, January 21, 2002 8:11 AM
> To: NGtrans List
> Subject: (ngtrans) Review of draft-ietf-ngtrans-shipworm-03.txt
>
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jan 2002 21:11:12 +0200 (EET)

> inept NATs in the path. In any case NAT is not a security tool.

AFAICS, only some can be caught: Shipworm servers and relays source the 
packets from IPv4 UDP port 'Shipworm UDP Port'.  Also AFAICS, 
"route-optimized" Shipworm packets cannot be detected in this way. 

I'll comment on a few more points below.  Mostly people have brought up
issues like "authentication of the relay" that is already an issue with
6to4 (+ anycast).  I believe the most people commenting on these have not
looked into them in detail; do we need stricter requirements for Shipworm?

> > orders of magnitude compared to what has been deployed/talked about

RFC3068.

> > make this fun. Debugging will be fun. ...

See above.

> > IPv6 address routes scattered individually across the globe?.

RFC3056.

> > address & port) relative to the shipworm server.

This is my worry as well.

> > 	  in the firewall (e.g., if the network policy is to prevent

Too bad, you can do that already with a lot of different tunneling 
mechanisms.  (even e.g. tunneling via ICMP packets, for which software 
exists).

> > 	  server over shipworm, including HTTP, mail, other services.

Users can always shoot themselves in the foot, see above.

If enabling Shipworm is too easy (e.g. shipped by-default enabled in the 
next version of Windows), this punching holes in NAT's might get a bit too 
common.

> > that a globally accessible IPv4 address for the client machine is

As Tony pointed out, this is the only reason Shipworm should be used.

> > A more serious discussion of the pros/cons of discovery vs.

RFC 3068.

> > with IPv6-speaking servers, and the complexity suggests it should be

This is a route optimization, IMO not primarily there to reduce load.  The 
optimization can be extremely significant especially if there are only few 
Servers.

> > remarks on this in the specific comments.

RFC 3056 and RFC 3068.

> > "authorized" to use shipworm anycast addresses).

To get a /24 prefix; /32's would be filtered in IPv4 DFZ.

> > broker is seen by the user as like home dialup server (only with

Sure, tunneling is fine as long as there's someone to set up the tunnel 
endpoint which has access to both NAT'ed realm and has a global address: 
usually this means the network administrator.  But then, often, the same 
administrator could set up proper IPv6 too -- this assumes *zero* help 
from the network administrators.

> > address checks later cited as the solution look spoofable).

How is there, ever, any authentication (think RFC3068)?

> > do so and this would be useful for long-term evolution.

One could always get a global IPv6 address and use Shipworm address as a 
care-of address with Mobile IPv6.

> > for a trust structure of some kind.

This is very different from MIPv6; with MIPv6, the problem is that *third 
parties* could be jeopardized with BU's.  There, the harm can only be done 
against the Shipworm Client -- and using Shipworm is already the last 
possible solution.
> > launderer.  The last sentence is just wishful.

That's true, but cannot really be protected against (similar to RFC3056).  
Some fine-tuning is possible, of course.

> > Shipworm UDP port, Shipworm service port, ...

I agree, it's a bit confusing at times.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 21 Jan 2002 13:24:48 -0800

> "route-optimized" Shipworm packets cannot be detected in this way.

They all have to be destined to a well known Shipworm UDP port, or there
is no way for systems to find the remote service. If a firewall can't
detect a specific destination UDP port it isn't much of a firewall.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jan 2002 23:40:44 +0200 (EET)

> detect a specific destination UDP port it isn't much of a firewall.

Consider route-optimized traffic's IPv4 payload:

IPv4 source = <IPv4 of the NAT box>
IPv4 source port = <set by the NAT box>
IPv4 destination = <IPv4 of the destination site's NAT box>
IPv4 destination port = <the port that will be forwarded to destination 
Shipworm client>

IPv6 payload will contain the Shipworm UDP port.

Where in here is Shipworm UDP port an IPv4 firewall could detect?

Have I missed something?

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 21 Jan 2002 14:17:00 -0800

Pekka Savola wrote:
>...

The destination port on the outside of the NAT will have to be a well
known one for the new connection origin to find it. Else if it were an
ephemeral response port, the internal origin node would have been
sending to the well known port to establish the mapping. Basically as
far as I can tell the firewall would have to be seeing a well known port
from one side or the other, and if policy didn't want that protocol
going through it could block it. The only way I can see around it would
be for an internal node to know that some server/relay/end-node were
listening on a specific different port. Unless that port was one allowed
for other reasons (ie: 80), it would automatically be blocked by
firewalls that implement a block-all/open-by-request policy.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2002 00:56:34 +0200 (EET)

> firewalls that implement a block-all/open-by-request policy.

I think I get what you mean.

In this case, I think the optimization needs to be more clearly specified; 
I thought it worked like 6to4, but apparently not..

Of the optimization, the draft basically only says:

The list of peers is used to "optimize" the transmission of IPv6  
packets by using a "direct path" for the recently active peers. The
list of peers could grow over time. Clients should implement a list
management strategy, such as for example deleting the least recently
used entries. Clients should make sure that the list has a
sufficient size, so that most traffic goes over the "direct path."  

.. which seems to be in conflict with what's discussed here.  Where 
exactly this "direct path" could be used?  

It does never seem to work with two arbitrary shipworm clients in the
Internet (like 6to4), because outgoing packets to another shipworm client
going to a.b.c.d port 1234 from NAT's point of view look like a new
connection, not the same using shipworm server -- and this would allocate
a new mapping in NAT.  On the other hand, then destination's shipworm
client would fail security checks (4.2.2) because IPv6 address and IPv4
address/port (assigned 0.1 seconds ago by NAT) don't match.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 21 Jan 2002 15:53:24 -0800

> I thought it worked like 6to4, but apparently not..

It can't, simply because there is a higher layer protocol involved. If a
network wants to enforce policies, it can do so at the IPv4/UDP layer.

> a new mapping in NAT.

It depends on the NAT implementation. If the NAT maintains a strict
public-node/port mapping for the internal node, then it would appear to
be a new connection. Most NATs though simply map the public port to the
internal address, so any src could send to the IPv4/UDP and get it
through.

> On the other hand, then destination's shipworm

The NAT doesn't get involved here. The security checks have to be based
on a match between the inner & outer addresses for the shortcut path, or
based on the known IPv4 source of the server/relay. Any specific stream
shouldn't care if the outer header switches between those two choices,
but the src needs to be one of them.

This doesn't prevent spoofed packets using the IPv4 of the relay. That
would have to be done as a boundary filter by the ISP providing the
relay.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2002 02:13:12 +0200 (EET)

> but the src needs to be one of them.

NAT would seem to get involved here.  Assume Client A from
2003:0102:0405:7890 wants to get a shortcut for Client B in
2003:0908:0706:5432.

Client A has sent out packets to IPv4 anycast address before, establishing 
the said prefix A.

When Client A sends packet, via the shortcut (if I didn't misunderstand
what shortcut is here for -- if I did, please explain it!) to
2003:0908:0706:5432, it would create an IPv4 packet with:

IPv4 source = <internal address>
IPv4 sport = <whatever>
IPv4 destination = 9.8.7.8
Ipv4 dport = (dec)0x5432

IPv6 source = 2003:0102:0405:7890::1
[...]

However, NAT allocates a new port for the new destination 9.8.7.6 (because
the destination is not the anycast address), and the packet B would be
like (when out in the Internet):

Ipv4 source = 1.2.3.4
IPv4 sport = XYZW           <-- note, something random
IPv4 destination = 9.8.7.6
IPv4 dport = (dec)0x5432

Client B receives the packet (assuming it is NAT type 1, else it may get
dropped in NAT but that's a separate issue), and when performing security
processing as defined in 4.2.2 realizes:

2003:0102:0405:7890::1 does not correspond to 1.2.3.4 (dex)0xXYZW.

(expected port (dec)0x7890)

Am I missing something here?

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 21 Jan 2002 16:33:48 -0800

> 2003:0102:0405:7890 wants to get a shortcut for Client B in

You have the steps correct, it depends on the NAT. If the NAT maintains
a consistent external port number for the internal src/port in use, then
port XYZW would not be generated. If the NAT creates separate ports
based on dst address then your description fits, and the only possible
check would be that the IPv4 addr of the outer header matches the IPv4
part of the Shipworm src. I don't know how the various NAT products deal
with this, but there is no fundemental reason to create a new port on
the public side if the private src/port are the same. The UDP handler in
the private side node is already capable of dealing with multiplexing.

Tony

---

From: "Eng Soo Guan" <[email-masked]>
Date: Tue, 22 Jan 2002 10:11:19 +0800

Hi!

We have used Shipworm as a solution to tunnel packets through a GPRS
network. (We statically assign an IPv4 and IPv6 addr instead of using IPv4 &
IPv6 Anycast addr.) We have to do so because GGSN on the GPRS network is
running IPv4 NAT. Shipworm works well for us: we can use Mobile IPv6 and
Shipworm to do simple interface selection over Wireless LAN and GPRS.

About "If the site has a NAT, ...., then why are we building methods to
subvert the site's security policy?", in our case, if we don't use Shipworm,
I don't see how IPv6 packets can still reach our LAN via the GPRS interface.
No security policies from the GPRS ISP are 'broken'.

On "Have you demonstrated that DAD is not needed?", (correct me if I am
wrong) if the NAT has a global unique IPv4 addr and the NAT controls the
ports, the first 64 bits of the IPv6 addr will be unique. So DAD is not
required. Did I miss something?

SG
Soo Guan, Eng
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jan 2002 16:23:30 +0100

Randy Bush wrote:
...
...
> transitioning to the preferred configurations?

This is the most important comment. Essentially the others can either
be resolved, or they refer to the price worth paying to accelerate
IPv6 adoption. We can tolerate a level of kludge for that (as we do
for 6to4 and NAT-PT to name but two).

Preference for other solutions over shipworm is really an implementation
issue, so I don't see how it can be specified further in a protocol spec.
Maybe a host requirements document could cover it, but not this document.
(If by accident a system ever acquired both a shipworm address and a
non-shipworm address simultaneously, address selection policy can take care
of it, but again that doesn't belong in this document.)

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2002 15:25:02 -0500

>>>>> "Tony" == Tony Hain <[email-masked]> writes:
    Tony> check would be that the IPv4 addr of the outer header matches the IPv4
    Tony> part of the Shipworm src. I don't know how the various NAT products deal
    Tony> with this, but there is no fundemental reason to create a new port on
    Tony> the public side if the private src/port are the same. The UDP handler in
    Tony> the private side node is already capable of dealing with multiplexing.

  NATs which are security gateways as well tend to create a new port per 5-tuple. 
  Garden variety NATs (including Linux Masquerade, and some revisions of BSD
IPF's IPnat) do not do this. So this means most of the things one would find
in a hotel room.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: David Terrell <[email-masked]>
Date: Fri, 25 Jan 2002 16:50:12 -0800

> of it, but again that doesn't belong in this document.)

Perhaps a description of shipworm as being strictly intended for
IPv6 connectivity where the nat/edge administrator is not interested
in providing IPv6 support, and 6to4 should be preferred for
site-wide access.

6to4 should be preferred over shipworm.  Shipworm is more complex
and fragile.  To not mention shipworm is only a tertiary solution
behind native connectivity and 6to4/6over4 would be a mistake.

-- 
David Terrell           |  "Please note that calling an attacker
[email-masked]            |  'lame' is not an approved security method."
http://wwn.nebcorp.com/ |    - Benjy Feen

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Jan 2002 13:04:27 -0800

> in providing IPv6 support

how can we differentiate between the site admin is not interested and
they are actively anti-interested, i.e. connection of 'inside' hosts
to the v6 network is against policy, as unenghtened as that may be?

randy

---

From: David Terrell <[email-masked]>
Date: Sat, 26 Jan 2002 13:27:43 -0800

> to the v6 network is against policy, as unenghtened as that may be?

They'll probably block protocol 41 at their border, and then traffic
to the shipworm registration/relay services and to the default
shipworm server port, and then tell their users to stop doing it.

-- 
David Terrell            | "When we said that you needed to cut the
[email-masked]             | wires for ultimate security, we didn't
Nebcorp Prime Minister   | mean that you should go wireless instead."
http://wwn.nebcorp.com/  |   - Casper Dik

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Jan 2002 17:40:07 -0800

> shipworm server port, and then tell their users to stop doing it.

and we railed against napster etc?

randy

---

From: Pekka Savola <[email-masked]>
Date: Sun, 27 Jan 2002 19:40:09 +0200 (EET)

> the private side node is already capable of dealing with multiplexing.

To evaluate the robustness of these techniques, I'd very much like to get 
some perspective how different NAT's handle:

1) assigning new ports for outbound connections
2) allowing traffic in for existing NAT ports

This would have to be in format 'NAT software/router+version, behaviour',
rather than just a rather vague statement in the draft.  In addition, a
testing methodology description for this would be great, so we could
gather information for most NAT's.

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Jan 2002 13:15:25 -0800

what is the plan for a rewrite of shipworm?  the ball is in the wg's court.
and it is not a small ball.

randy