Subject: RE: 6to4 usage scenarios

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 22 Nov 2002 11:58:09 -0800

Pekka,

> 
> On Thu, 21 Nov 2002, Alain Durand wrote:
> > >But there are some ways to help here a bit:
> > > - it is desirable to have strong co-operation, but it's not 
> > >_necessary_,
> > >only if you want a higher level of security (the rest just 
> work as before)
> > > - ISP's providing 6to4 relay as a real service are more 
> likely to have a 
> > >stricter list of prefixes the ISP serves -- and 
> configuring static routes 
> > >is easier
> > >
> >
> > Remember: the threat that we are discussing is not 
> impacting _my_ 6to4 
> > site.
> 
> The threat I'm discussing has many implications.  One is that 
> it allows unidirectional, untraceable address spoofing 
> (consider e.g. an exploit for a security vulnerability in a 
> UDP service).  The other is that it allows sites to be used 
> as packet reflectors, as you said...
> 
> (this is really similar to HAO/RH spoofing but more difficult 
> to fix; see the expired 
> draft-savola-ipv6-rh-ha-security-02.txt for more text on that.  
> Thanks Francis.)
> 
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. 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.
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).

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Nov 2002 16:51:33 +0200 (EET)

On Fri, 22 Nov 2002, Mohan Parthasarathy wrote:
> in 6to4. 

Right.

> As a relay router SHOULD not be doing this, can

Yes, this can be caught easily (the way is shown in the draft), but
practise has shown most relays don't do this.

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 23 Nov 2002 17:05:36 -0800

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

> So it may be a bit confusing, perhaps I should try to reorganize them
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