Re: 6to4 usage scenarios

["Mohan Parthasarathy" <mohanp@tahoenetworks.com>]

> On Fri, 22 Nov 2002, Mohan Parthasarathy wrote:
> > I looked at your examples in section A.3, which talks about
> > reflection attack against IPv4 nodes and IPv6 nodes using
> > relay routers :
> >
> > src = X
> > dst = Y
> > src_v4 = 8.0.0.1
> > dst_v4 = 9.0.0.2
> >
> > If Y is 2002:0500:0001::1, you mention that target 5.0.0.1
> > would be bombed with reflected packets from 6to4 relay router.
> > This happens because the relay router decapsulated the packet
> > (removing src_v4 and dst_v4) and then *again* encapsulated
> > in 6to4.
>
> Right.
>
> > As a relay router SHOULD not be doing this, can
> > we not catch this case ? I agree that sending to a native
> > V6 address with a forged source V6 address is a problem.
>
> Yes, this can be caught easily (the way is shown in the draft), but
> practise has shown most relays don't do this.
>
Do we really care about those relays ? All we can do at the ietf is to
provide those hints which will help do a robust implementation. If
there are implementations that don't do this, they  will get fixed sooner
or later.

> > But it is essentially the same problem as not being able
> > to trace back as mentioned in A.1. I am just trying to understand
> > which threats we are trying to address here.
> >
> > The only thing that seems seruous to me is the IPv6 spoofing
> > and access control avoidance threat in your draft. (It might
> > be better if you can move all the attacks to the main section
> > and list the possible solution together with it).
>
> Right, I'm not that worried about some of those DoS attacks myself either.
>
> A problem with the draft is that it tries to address:
>
>  1) problems which happen when no proper check haven't been implemented
>  2) problems which happen when all proper checks have been implemented
>  3) some solutions to 6to4 relay problem
>
> So it may be a bit confusing, perhaps I should try to reorganize them
> somehow...
>
Yes, please. Then, it will be clear as to what problems we need to solve.
IMO, i don't think we should really care about implementations that don't
do all the checks mentioned in the draft.

-mohan
> > > > 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
> > >
> > >
> > >
> >
>
> --
> 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
>
>