Re: 6to4 usage scenarios

[Pekka Savola <pekkas@netcore.fi>]

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.)

> 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