Subject: Re: Automatic tunnels

From: [email-masked]
Date: Fri, 25 Jul 2003 10:12:46 +0200

Hi Christian,

you wrote:
> (...) [configured tunnels] don't follow the natural
> Internet topology and thus often result in rather poor
> transmission times

and a bit further:

> Automatic tunnels like 6to4 (...) have the advantage of being
> potentially "very short": the transmission between two transition
> hosts follows the IPv4 topology,

What do you mean by "following or not the IPv4 topology" ?

From the IPv4 forwarding point of view, I can't figure out such
a difference between configured or 6to4 tunnels.

I guess I must be missing you point here ?

Thanks,
Robert

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 25 Jul 2003 08:58:27 -0700

> a difference between configured or 6to4 tunnels.

Traffic between two 6to4 routers will follow exactly the same path as
IPv4 traffic between these two routers. If the network topology changes,
the path will automatically follow the new routing state. This is a big
difference to traffic over overlay networks like the 6Bone, in which
packets hop from tunnel to tunnel; the tunnel layout is typically meant
to reflect the nominal network topology, but it will not change if
events affect the routing. A practical consequence is that a ping
between two 6to4 addresses often shows a much shorter delay than a ping
between two tunneled hosts.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 31 Jul 2003 17:59:12 -0700

> >Which type of abuse are you concerned with? We can deploy
native-to-6to4
> >relays in several modes:
> >
> > - host specific=20
> >	(host is multi-homed to 6to4, local routing entry to 2002::/16)
> > - AS specific=20
> >	(some routers act as relay, export a route to 2002::/16 in IGP)
> > - Across multiple AS
> >	(export a route to 2002::/16 in BGP)
> >
> >The first two modes don't seem particularly prone to abuse. Host
> >specific relays certainly are not an issue, and the abuse to AS
specific
> >relay fall in the general category of "abusing peering agreements",
> >which is by no means specific to 6to4. I agree that exporting a route
> >through BGP is hard to control, as the route can be re-exported by
> >peering ASes. But, again, this fall in the category of "peering
abuses",
> >which can be contained by proper peering contracts.
> 
> 	we are afraid of our native-to-6to4 device being used as open
relay
> 	of packet (bullet 3 in the above, of course).  the IPv4 source
> address
> 	will be ours, so we will get compliants from random people,
because
> of
> 	malicious traffic from somewhere to 2002::/16.  running 6to4
relay
> 	router is like running open relay smtp server.

The comparison with an open relay smtp server is a bit excessive. In the
native to 6to4 direction, the 6to4 relay will send over IPv4 a 6to4
packet (protocol type 41), in which the payload will the original IPv6
packet. The main attack through such gateway is to send packets to IPv4
nodes, which can be either 6to4 or legacy. 

The attacks to 6to4 nodes are basically the same as attacks over IPv6 to
native nodes. From that point of view, running the relay is pretty much
equivalent to providing BGP peering to a third party network, and does
not seem to create a particular type of concern.

The attacks to legacy nodes can only be DoS attacks -- the legacy nodes
don't understand 6to4, and will not understand the packets. However, if
the attack is serious, someone will analyze the content and find out the
source IPv6 address. If the source address cannot be spoofed, then the
attacker will be caught. If the source address can be spoofed, then the
"open relay" issue is caused by the lack of filtering at the origin, not
by 6to4.

-- Christian Huitema