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

[Tony Hain <[e-mail]>]

Randy,

While I agree the document is challenging to read, I think some of the
comments are based on a misunderstanding of the goal. Specifically:
> 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 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
> stateful since the random link address of the solicitor is a nonce?

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.


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

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.


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

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: [e-mail]
> [mailto:[e-mail]]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
>
>
> 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-
>
>
>