RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

Hi,

> > Dear All,
> > 
> > An issue of general character has been brought up in 
> connection with the zero-conf work. 
> > The issue is the following:
> > 
> > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support 
> NUD-like mechanisms that enables
> > them to send ICMP destination unreachable messages back to origin ?
> > 
> > The initial feedback received in this respect is that - 
> "yes, they MUST".
> > 
> > As some RFCs previously has been silent about this, e.g. 
> 6to4 - RFC 3056,
> > and the working group currently is standardising a 
> mechanism which also seems
> > to be silent about this (Teredo) I would very much like to 
> hear if the above is the
> > general sentiment of the work group.
> 
> What happens, afaik, is the following:
> Remote Box (A) = 2001:db8::1
> tunnelendpoint @ Tunnel Server (Ts) = 2001:db8:1000::1
> tunnelendpoint @ Tunnel Client (Tc) = 2001:db8:1000::1
> R? = Routers in between.
> 
> Thus schematically:
> A -> Ra -> Rb -> Rc -> Ts -(6in4/proto41 tunnel)-> Tc
> 
> The packet will arrive at Ts, which will stick it into a 6in4 
> packet and
> actually forward it to Tc.
> 
> Following situations could arise:
>  a) IPv4 path works and Tc accepts the packet
>     -> no problems
>  b) IPv4 path works, Tc doesn't accept packet
>     -> it should return with a proto-41 unreach icmp
>  c) IPv4 route is broken between Ts and Tc
>     -> it should return a unreach host
> 
> In case of b and c when Ts gets a icmp route/port/host 
> unreach they can
> send a IPv6 unreach route/host back to the Remote Box A.
> This is, what I noticed, is what the current Linux, KAME and XP
> implementations do.
> 

Thanks,

So what you're saying is that the Tunnel Server can rely on the information from
the IPv4 layer and thus does not need glue native IPv6 NUD-like mechanism 
on top of the IPv4 layer - ?

> > I should be stressed that adding this to the goals of the zero-conf
> > requirements document isn't believed to severely limit the solution
> > space - but it requires implementation of a mechanism which 
> is know to
> > scale very badly and which in addition is susceptible to the DoS
> > attack described in Section 4.3.2 of RFC 3756.
> 
> The point where this can be DoS'd is by sending the Tc IPv4 
> unreachables
> for the Tc. Thus if you know the endpoints you can simply send a few
> icmp's and if the Ts remembers the state, which it hopefully does not
> do, then you can effectively disable the tunnel.
> 
> The real way to fix this is doing egress/ingress filtering on IPv4...
> But many ISP's do not do any filtering at all, so tough luck.
> For that matter, the not so many IPv6 ISP's that are out there don't
> filter on IPv6 either, at least most of them, so most are 
> repeating the
> same problem again, but all has to do with the router not 
> being able to
> do filtering or something on linerate...
> 

Neither of these are real problems in the particular scenario of
zeroconf, due to its severe assumptions on IPv4 source filtering and 
source spoof preventions.

A different issue however is that the server may be swamped with ICMP proto-41
unreachable from IPv4 nodes in the case where the server is used to reflect packets into
the network.

Thanks, Karen