RE: 6to4 usage scenarios

[Pekka Savola <pekkas@netcore.fi>]

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.

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

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