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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 22 Nov 2002, Brian E Carpenter wrote:
> RFC 3056 forbids announcing prefixes longer than 2002::/16, 
> and instructs ISPs to filter them, to avoid polluting the 
> IPv6 DFZ with IPv4 specifics.

Yes.

.. which is why I proposed a model where 6to4 relays are interconnected
using eBGP multihop peerings, and IPv6 DFZ would be safe, and everyone
would be happy :-).

> Jeroen Massar wrote:
> > 
> > Pekka Savola [mailto:pekkas@netcore.fi] wrote:
> > 
> > > On Fri, 22 Nov 2002, Brian E Carpenter wrote:
> > > > > On Thu, 21 Nov 2002, Jeroen Massar wrote:
> > > > > > > please think that to the end, it will not work 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 ;)
> > > > >
> > > > > How will you send traffic from 2001:dead:beef::1 to
> > > 2002:0103:0405::1, if
> > > > > 2001:dead:beef::/48 is not within the trust boundary?
> > > >
> > > > Wrong question. The question is, does *any* 2002::/16 announcement
> > > > reach dead:beef's ISP? If yes, whichever relay is the origin of
> > > > that announcement will relay the traffic. The 2nd question
> > > is whether
> > > > that particular relay is trusted by 0103:0405's 6to4 router.
> > >
> > > Exactly.  In Jeroen's model, I believe, the particular relay would
> > > particully never be trusted.
> > 
> > That is exactly what I mean.
> > 
> > >
> > > Any such model model is broken.
> > 
> > Eek :)
> > 
> > > 6to4 routers do not have any ways of knowing where traffic
> > > will be coming
> > > from, so discarding packets because they didn't come from your two
> > > favourite relays is *wrong*.
> > 
> > Thats indeed true, fortunatly in the setup depicted below one
> > knows where packets should be coming from.
> > 
> > > Propagating more specific routes etc. avoids this problem as
> > > you have only one "home" relay.
> > 
> > Which where my thoughts exactly.
> > Indeed the origin 6to4 relay's ISP will announce the prefixes it
> > is willing to relay for, so the others can now where this relay
> > is located and send all the return traffic directly there.
> > That 6to4 relay can then send the traffic directly to the 6to4 node.
> > 
> > One thing is that "local" traffic will go over that same relay too
> > even if it's in the same subnet. Maybe a check for "local subnet"
> > could be devised to overcome this problem.
> > 
> > Eg, box-A = 10.1.2.3/24, box-B = 10.1.2.4/24, these are directly
> > connected
> > and should send the 6to4 packets directly too each other.
> > But when box-C has 192.168.1.2 this should go over the relay.
> > Basically it comes down to:
> > 
> > 10.100.2.5/24
> > [6to4 node A] <---+
> >                   |        10.100.1.1
> >                   +-----> [6to4 relay] <------> [IPv6 Internet]
> > 10.100.2.6/24     |
> > [6to4 node B] <---+
> > 
> > The relay announces 2002:0A64::/32 (10.100.0.0/16)
> > - Any node on the internet knows how to reach it.
> > - It only serves 10.100.0.0/16.
> > - "6to4 Transit" goes over native (or configured tunnels) IPv6.
> > - "Spoofing" is limited to the ISP, or the prefixes the 6to4 relay
> > trusts.
> > - 6to4 Anycast route is only available inside the ISP, or the ISPs it
> > trusts.
> > - Local traffic (6to4 node A <-> 6to4 node B) travels locally only.
> >   This should save some traffic on the relay though it is not 100%
> > required.
> > 
> > Ofcourse 10.x.x.x addresses can be replaced by real IP's, these are
> > examples.
> > 
> > One could also see this approach as aggregating 6to4 traffic.
> > Eg I imagine a 6to4 relay one hop more to the right of the above picture
> > which carries for instance 10.0.0.0/8 which it announces to the
> > internet.
> > 
> > Hope this clears it up a bit :)
> > 
> > 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