Subject: RE: (ngtrans) Shipworm Questions

From: "Christian Huitema" <[email-masked]>
Date: Wed, 10 Oct 2001 08:27:09 -0700

> Consider a Shipworm Client uses the random link local address
> FE80::1:NODE_ID (where NODE_ID is a 64 bit node identifier).

Actually, that would be FE80::NODE_ID; don't know why you insert the
":1:".

> From Section 5.8, "the use of a randomized link-local address in the
> router
> solicitation messages provides some protection against this attack: a
> router
> advertisement whose destination address does not match the expected
> value
> will be silently discarded".
> 
> My first doubt is if the destination of a RA must be FE80::1:NODE_ID
> (from
> Section 5.8), then the source of the corresponding RS must be
> FE80::1:NODE_ID right? If yes, then a malevolent third party with a
> Shipworm
> IPv6 Anycast will still be able to send perform denial of service
> attach. If
> no, then how will a Server knows the random link-local address?

The Router Solicit is sent over IPv4 to the Shipworm IPv4 anycast
address and to the Shipworm UDP port; it is not multicast; it will be
received by the nearest Shipworm server. The NODE_ID will thus only be
visible by this server, and by the routers on the path to this server.
It is true that these routers, and the Shipworm server, can mount a
denial of service attack and essentially deprive the client from the
benefit of the Shipworm service. But then, this is an intrinsic property
of routers: they can at any time filter a fraction of the traffic and
black-hole it; there are in fact many examples of routers/firewalls that
do exactly that.

The anycast routing mechanism should ensure that the RS packet is
delivered to the nearest Shipworm server. This can be attacked in two
ways: first, if a router on the message path is corrupted, it can
capture the packet and send a fake response; second, if a corrupted
server manages to convince one of the router on the path that it is a
legitimate Shipworm server, it can obtain the Shipworm packets. Both
attacks have much more drastic consequences than affecting the RS/RA
exchange: in fact, they can lead to the capture of the entire Shipworm
traffic of a node. However, this capability to capture traffic is,
again, an intrinsic property of routers: corrupted routers can misroute
packets. We could insert drastic security protections in the RS/RA
exchanges, but none of these protections could prevent corrupted routers
from misrouting traffic. According to this analysis, we see that the
integrity of the Shipworm service relies on the integrity of the IPv4
routing between the client and the local Shipworm server; there is not
much we can do about it, and we should thus just pick the simplest
design for the RS/RA exchange.

> For RS, instead of Shipworm Anycast Address, let the Client uses the
> local
> scope all node multicast address FF02::1 in RFC2641. From Section
> 4.3.2, the
> Server will send a RA back to the Client with a destination FF02::1.

Using a multicast address as a source address is illegal.

> I am also unsure about using IPv4 Anycast Address. I hope I am not
> wrong in
> saying that Shipworm will be an excellent solution if it requires
> minimum
> modifications to existing IPv4 Internet.  The use of IPv4 Anycast
> address
> will requires some modifications/additions to existing routing
> protocols.
> Will this not affect the 'usefuleness' of Shipworm?

The use of IPv4 anycast does not require a modification to existing IPv4
routing. It does require a configuration of the router to which the
Shipworm server is attached, so that the router will to the server the
anycast packets bound to the anycast address, and so that the router
will either advertise a "host route" (/32) to the server, or simply
advertise a route to the /24 prefix. Performing such configuration on a
router is quite common. (Indeed, a natural place to implement the
Shipworm service is within a router, in which case the configuration
becomes quite simple.)

-- Christian Huitema

---

From: "Eng Soo Guan" <[email-masked]>
Date: Thu, 11 Oct 2001 13:58:51 +0800

Dear Christain,

Thanx for the prompt reply.

> Actually, that would be FE80::NODE_ID; don't know why you insert the

Yes, you are right. This is my mistake. The random link local address should
be FE80::NODE_ID.

> design for the RS/RA exchange.

When I read the first Shipworm draft, there is no random link-local address
(FE80::NODE_ID). I believe it is added for anti denail-of service (dos)
attack (Section 5.8). From your explaination, I think using FE80::NODE_ID
will not help in dos attack in IPv4.

> Shipworm service is within a router, in which case the configuration

SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
Tel (65) 8709330
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Eng Soo Guan" <[email-masked]>
Date: Thu, 11 Oct 2001 16:52:03 +0800

Dear Christian,

I got another 3 questions.

1)Why is the combination of Shipworm Relay and Server not mandatory?
Consider a Client sending a IPv6 packet to a non-Shipworm host.  The IPv4
destination address is Shipworm IPv4 Anycast. There are 2 possibilities. The
packet will be routed to either a Shipworm Server or Relay. From the Server
and Relay Specifications, only the Server is capable of using regular IPv6
to send the packet to the receiver. What will happen if the 'nearest' node
with Shipworm IPv4 Anycast is a Relay? Similarly, if a IPv6 host sends a
packet to a Client's Shipworm IPv6 address, and the packet gets routed to a
Shipworm Server, will the packet still reach the Client?

2)There is an interesting example I read from another mailing list that is
worthed considering here. Using the example in Section 5.1, let's say there
is a Client2 in the private network, using 10.0.0.3/1235 and the mapped port
at NAT is 4097. How can Client2 sends a packet to Client1(10.0.0.2)? If
Client1 is using Mobile IPv6, Client2 will send the packet to Client1's Home
IPv6 address (destination=Client1's Home IPv6 address, source=Client2's
Shipworm IPv6). Client1 will receive the packet from Client2 and try to
reply with Client2's Shipworm IPv6 address. But the reply reaching the NAT
has destination IPv4 address 9.0.0.1 and UDP port 4096. Will the NAT be able
to deliever this packet to Client2?

3) If there is a firewall between the NAT and Shipworm Server, and the
firewall did not enable Shipworm Port, will Shipworm still works?

SG
Soo Guan, Eng