[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 6to4 deployement issues - was 6to4 security questions



Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] wrote:

<SNIP>
> Either you leave the relay model or you remove it.
> If you leave it as it is, you open serious security issues
> If you remove relays from the architecture, you create
> a partition of the Internet. Sure, today there is no content
> reachable though native IPv6, but one day, there will.
> That day, you do not want to prevent those gazilliions
> 6to4 users from reaching it.

6to4 is a good transition method that works, but as you say below
it needs some reworking so the abuse possibilities are limited
as far as possible.

> The only wat forward is either to deprecate 6to4 alltogether
> (and use another conncetivity for the masses approach until
> IPv6 ISPs are generally available)
> or to fix the security problem.
> 
> My take is go back to the white board and try to fix it.

Some of my thoughts about this:

* Limit 6to4 to 1 ISP.

This way an ISP could setup a 6to4 service for their clients
and provide it to the parts of their networks which are not
capable of native IPv6 at that moment.

I would implement that 'limit' by using carefull source address
filtering.
A ISP should know from which ranges clients could come which are not
capable of native IPv6.

For example the following network structure:

 IX-a --- brd -          6to4 relay       --- customer access
               \             |           /
 IX-b --- brd --- ISP core backbone --- * --- customer access
               /                         \
 IX-c --- brd -                           --- customer access
 { ISP }

Thus the 6to4 relay is just another router in the network of the ISP
Source address verification should be enabled on all incoming
connections
anyways if they are sane people and want to protect themselves against
DoS's.
Because of that the ISP can know that any traffic coming out of that
prefix
and which is on their network is from a client and that it is a valid
prefix.
Ofcourse a client could spoof inside the ranges on which the borders get
filtered.
But that is a local problem which can be found out.
As the 6to4 relay is inside the ISP's network it will only be reachable
for their
own clients.

This has the following advantages:
 - Spoofing is kept to the ISP level.
 - 

And ofcourse the disadvantages:
 - Every ISP needs to setup a 6to4 router or ask another ISP access to
theirs.

This setup could easily make use of the anycast address.
One should then restrict the announcement of this anycast address to the
ISP
or to the ISP's one trust to filter correctly on incoming connections.

Having no route to the 6to4 relay from the outside will makes this work
quite easily too :)

One will have to announce all the 2002:<IP>:<v4>:: prefixes one has and
is serving too
into the IPv6 routing cloud to make this work and make the paths
shorter.

Greets,
 Jeroen