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

[Randy Bush <[e-mail]>]

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-