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

["Jeroen Massar" <jeroen@unfix.org>]

Pekka Savola wrote:
> Sent: Thursday, 21 November, 2002 21:05
> To: Jeroen Massar
> Cc: Alain.Durand@Sun.COM; v6ops@ops.ietf.org
> Subject: RE: 6to4 deployement issues - was 6to4 security questions
> 
> 
> please think that to the end, it will not want without 
> re-specification _globally_. 
> We don't want to restrict 6to4 to ISPs' walled gardens.

One ISP can have a trust relation with another ISP and announce
the anycast prefix only to that other ISP so it can make use of it too.
Source address verification should then ofcourse be extended by the
other ISP's. This could be seen as a 'transit' type service, but then
between the v4 and v6 world ;)

> On Thu, 21 Nov 2002, 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
> > 
> > 
> 
> -- 
> 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
> 
> 
> 
>