Subject: 6to4 usage scenarios

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 04:13:46 +0200 (EET)

Hello,

It seems like the 6to4 security discussion degenerated into argument on 
how it was meant to be used.

There are two basic models of connecting 6to4 routers to relays:

1) simple static route to your relay
2) BGP sessions to your relay and all the other relays where you want to 
receive native IPv6 packets from

I know of _no_ deployments of 2) even though Brian insists on that being
the only "real" 6to4 usage scenario.  Does anyone know this being used?

If not, I think we must acknowledge that 2) is not really
right-tool-for-the-job (think of 6over4 **), and that 1) is the primary
(only?) applicability target of 6to4.

The alternative is that we have gaping holes in Home/SOHO and partially 
maybe enterprise transition scenarios, and nothing to fill them at the 
moment.

**) 6over4 is a nice technique, and we could even use it -- but we don't 
want stuff like that.  The same IMO applies to 6to4+BGP.  There is no use 
specifying mechanisms for the audience who does not want them.

P.S. I only came to the wg after 6to4 had just gone RFC, this internal
bickering really took me off surprise and made me both frustrated and
angry about refusing to accept the reality.

-- 
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: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 18:31:56 -0800

You're basically right.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2002 03:36:53 +0100

Pekka,

I'm not blind- I am quite aware that the BGP4+ scenario is
not deployed. I simply wanted to make it clear that when we
designed 6to4, we did think about the need to establish some sort
of relationship between relays and their "customer" routers.
It doesn't surprise me that we've now discovered that such
a relationship is needed to reduce the spoofing risk.

Any suggestions on how to create such a relationship?

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 04:54:32 +0200 (EET)

> a relationship is needed to reduce the spoofing risk.

Ok -- such stressing seemed like denying the problem, "this should not
have happened if you did XXX like we were supposed to ".  It seems
apparent that static routes were probably added as a patch at a later
stage, and peopled failed to see a change in the big picture.  But this is 
irrelevant.
 
> Any suggestions on how to create such a relationship?

I think section 6.3.2 of my draft discusses (very roughly) one approach at
the problem.  Of course, it still needs a lot of work if it's seen as an
approach worth investigating more.  This is something I'd like feedback 
on.

Some others have been proposed too. (IMO, I believe a solution like 
neighbor affiliation is not really scalable in the global case.)

---

From: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 19:39:20 -0800

Pekka Savola wrote

>the problem.   
   This could be done by forming eBGP
   [BGP] multi-hop peerings between Relays, and advertising more
   specific routes (e.g. the same superblocks of IPv4 addresses one
   expects to service) to all the other Routers.

This is where I doubt it works. As you pointed out in your draft,
it requires (strong)cooperation among all the relays, but worse,
it requires complete coverage of the IPv4 space.

And again, how will the 6to4 router knows the valid IPv4 address
of the relay it is associated with (if the router has used the well 
known anycast addr
to discover the relay)?

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 05:53:49 +0200 (EET)

> it requires complete coverage of the IPv4 space.

Yeah, this is a problem.  But you can approach this many ways, my view is:

 1) identify the current status, document the threats
 2) make up a way to lessen these threats (they cannot completely go away)
 3) if people are worried about the spoofing problem, _expect them to 
contact their home relay, and make it to advertise their prefix_.  If the 
person doesn't care.. can't help anyway.

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
 - some more specifics can even be automatically generated e.g. from 
RADB/RIPE route databases
 - we could develop a very simple protocol/process (could be just a 
triggering packet or whatnot) to make the home relay start automatically 
advertise a prefix

> of the relay it is associated with (if the router has used the well 

1) the relay may use 192.88.99.1 as the souce address (our relay does 
that)
2) if not, a simple ping to that address or manual equivalent should 
reveal this

As you note, there are quite a few problems to be ironed out, but it just 
_might_ work.

---

From: Alain Durand <[email-masked]>
Date: Thu, 21 Nov 2002 20:04:12 -0800

>stricter list of prefixes the ISP serves -- and configuring static routes 
Remember: the threat that we are discussing is not impacting _my_ 6to4 site.
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.

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Nov 2002 15:59:57 +0200 (EET)

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

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