Subject: RE: (ngtrans) I-D ACTION:draft-huitema-shipworm-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Wed, 18 Jul 2001 10:28:38 -0700

> I have hard time understanding how on earth could this protocol could
be
> stateless from server's point of view; assuming the ipv6 shipworm
address
> is like:
> 
> 2003:aabb:ccdd:1234:<eui64>
> 
> Now, aabb:ccdd is a global IPv4 address of the Shipworm server,
> and 1234 is the hexadecimal representation of the port.

No. aabb:ccdd:1234 is the mapping allocated to the UDP port by the last
NAT on the path between the client and the server. The mapping state is
kept by this NAT.

> Joe IPv6 User (e.g. with 3ffe::/16) knows where to send a packet with
> dst=2003:aabb:ccdd:1234; (tunnel it himself or) via shipworm relay to
IPv4
> address aabb:ccdd port TBD.  But how does the shipworm server just
after
> receiving the packet know where to put it?  0x1234 is insufficient
space
> for enconding NATted IPv4 address unless there's some state in the
server,
> and if the aabb:ccdd wasn't shipworm server's address, how could it
have
> ended up there?

See above.

> Or have I gravely misunderstook something?

Yes. Which indeed means that the draft should be better written. Hey, it
is -00...

> Some other comments...
> 
> It says, in Chapter 3:
> 
> ---
> The Shipworm routers must be connected to the IPv6 Internet and must
> participate in IPv6 routing; they must be able to announce
> reachability over IPv6 of the "Shipworm service IPv6 prefix." They
> must then be able to relay packets over IPv4 UDP towards Shipworm
> clients. It is very sensible to combine the functions of Shipworm
> server and Shipworm relay in a single box.
> ---
> 
> There is no tecnical reason why Shipworm routers would have to be
> dual-homed.  "Virtually dual-homed", perhaps.  All you need is add a
box
> with one interface in private LAN, and configure the NAT box to pass
the
> traffic through to its global address untouched.

They must be dual homed in the sense of responding to two IPv4
addresses, the IPv4 one and the specific ones. The servers don't have to
have any direct access to the private LAN; in fact, they should not be,
because they must make sure that receive packets through the existing
NATs.
> Why is this?  Even though anycast address is used, I don't see this to
be
> fundamentally different from e.g. NUD.  The mappings only become
important
> when you send packets, at which time you could perform this if you
have a
> reason to believe Shipworm server has failed.

You must ceck that you are constantly able to receive, which is
different from being able to send. Checking receive capability cannot be
triggered by the need to send a packet.

> This kind of "keepalive" would be important if there were e.g.
stateful
> UDP firewalls between clients and server, but that's not often the
case I
> suspect.  If this is one goal, it should be noted in the draft.

In fact, all UDP NAT are stateful.

> Being able to specify the dst port for UDP tunneling opens up some
> interesting DoS/portscan scenarios; for example, you can make shipworm
> relay router probe all the possible IPv4 UDP ports of everybody in the
> Internet....

You can already do that with any IP connection.

-- Christian Huitema

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jul 2001 21:07:07 +0300 (EEST)

> Yes. Which indeed means that the draft should be better written. Hey, it

An example transaction with different addresses might have cleared it up a
bit, I suppose.

> In fact, all UDP NAT are stateful.

Yes, but especially enterprise firewalls might not always be.

If the firewall does stateful inspection, it only lets UDP packets back
from Shipworm server if there have been outgoing packets to there lately.
The NAT timers might differ from firewall timers.  Keepalives might help
with this too.

Else, if firewall does not do stateful inspection, basically all incoming
UDP packets with dst port >1024 must be passed through.  Then it becomes
NAT-only issue.

> You can already do that with any IP connection.

Well, some (ipv4) methods:

1) plain old probing without any spoofing
2) probing with src spoofing (can be prevented by ip filters at source)
3) methods like smurfing, ie. spoofing source and sending to a broadcast

These are of course possible with IPv6 too, with the exception of 3).

With Shipworm, though, you're able do cause "proxied" hassle through
combined relay/server boxes; the recipient whose ports are being knocked
is just seeing incoming packets coming from ipv4 shipworm anycast address.
(sure, the original ipv6 address is inside too).

Combined with (e.g. automatic) tunneling between the prober and shipworm
relay, you could probably perform some pretty anonymous nastiness.

-- 
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: Pekka Savola <[email-masked]>
Date: Thu, 19 Jul 2001 00:19:50 +0300 (EEST)

> NAT on the path between the client and the server. The mapping state is

Ah; the location of Server wrt. NAT was not clear.

Here's a simplified diagram I made; hope this helps others as much as
myself while figuring this out...

                                                .-----------------------
                                                |  Private network
                      ____                   .-----.     .----------.
                     (    ) src=9.0.0.1:4096 | NAT |     | Shipworm |
                    ( 'Net )<--------------  | BOX | <-- |  Client  |
                     (    ) (UDPv4 tunneled  |     |     '----------'
                      '--'        IPv6)      '-----'       10.0.0.2
        src=            |               9.0.0.1 | 10.0.0.1
PRFX:900:1:1000:[eui64] |                       |
   (native IPv6) <==.   |                       |
                    \\  V                       |
                .--------------.                '-----------------------
                |   Shipworm   |
                | Server/Relay |
                '--------------'
                 [IPv4-anycast]