On Thu, 2004-09-09 at 14:40, Karen E. Nielsen (AH/TED) wrote:
> 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.
> 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...
Greets,
Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part