[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 6to4 usage scenarios
Pekka,
>
> On Thu, 21 Nov 2002, Alain Durand wrote:
> > >But there are some ways to help here a bit:
> > > - it is desirable to have strong co-operation, but it's not
> > >_necessary_,
> > >only if you want a higher level of security (the rest just
> work as before)
> > > - ISP's providing 6to4 relay as a real service are more
> likely to have a
> > >stricter list of prefixes the ISP serves -- and
> configuring static routes
> > >is easier
> > >
> >
> > Remember: the threat that we are discussing is not
> impacting _my_ 6to4
> > site.
>
> The threat I'm discussing has many implications. One is that
> it allows unidirectional, untraceable address spoofing
> (consider e.g. an exploit for a security vulnerability in a
> UDP service). The other is that it allows sites to be used
> as packet reflectors, as you said...
>
> (this is really similar to HAO/RH spoofing but more difficult
> to fix; see the expired
> draft-savola-ipv6-rh-ha-security-02.txt for more text on that.
> Thanks Francis.)
>
I looked at your examples in section A.3, which talks about
reflection attack against IPv4 nodes and IPv6 nodes using
relay routers :
src = X
dst = Y
src_v4 = 8.0.0.1
dst_v4 = 9.0.0.2
If Y is 2002:0500:0001::1, you mention that target 5.0.0.1
would be bombed with reflected packets from 6to4 relay router.
This happens because the relay router decapsulated the packet
(removing src_v4 and dst_v4) and then *again* encapsulated
in 6to4. As a relay router SHOULD not be doing this, can
we not catch this case ? I agree that sending to a native
V6 address with a forged source V6 address is a problem.
But it is essentially the same problem as not being able
to trace back as mentioned in A.1. I am just trying to understand
which threats we are trying to address here.
The only thing that seems seruous to me is the IPv6 spoofing
and access control avoidance threat in your draft. (It might
be better if you can move all the attacks to the main section
and list the possible solution together with it).
-mohan
> > It enables an attacker to abuse my and many other 6to4
> hosts elsewhere
> > in the Internet to arm a victim in the native v6 Internet.
>
> .. but that's not really nothing new -- pretty much what you
> can do today with regular spoofing, and we'll probably never
> be able to eliminate all of that. The difference is that it
> is more difficult to trace and it can be initiated by the
> hosts who are v4 or v6 ingress filtered.
>
> I don't think all the threats in _any_ automatic tunneling
> mechanism can be neutralized except by heavy packet exchange
> which usually makes the mechanism unusable. We'll just have
> to analyse what those are and decide the acceptable level
> security (or consider the whole mechanism a no-go).
>
> --
> 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
>
>
>