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

[Brian E Carpenter <brian@hursley.ibm.com>]

Jeroen,

The RFC 3056 model is to limit the visibility of a relay by BGP
policy - that allows it to be wider (or narrower) than one ISP;
As I said to Pekka Savola, you do that by scoping the
advertisement of 2002::/16 using normal BGP policy mechanisms.

But that isn't the spoofing solution; for that you need a peer
relationship of some kind between the 6to4 "customer" router
and the set of trustworthy relays.

   Brian

Jeroen Massar wrote:
> 
> 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