Subject: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt

From: [email-masked]
Date: Mon, 09 Dec 2002 08:01:09 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Security Considerations for 6to4
	Author(s)	: P. Savola
	Filename	: draft-savola-v6ops-6to4-security-01.txt
	Pages		: 27
	Date		: 2002-12-6
	
The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4
tunneling to interconnect IPv6 networks.  The architecture includes
Relay Routers and Routers, which accept and decapsulate IPv4 traffic
from anywhere.  There aren't many constraints on the embedded IPv6
packets, or where IPv4 traffic will be automatically tunneled to.
These could enable one to go around access controls, and more likely,
being able to perform proxy Denial of Service attacks using 6to4
relays or routers as reflectors.  Anyone is also capable of spoofing
traffic from non-6to4 addresses, as if it was coming from a relay, to
a 6to4 node.  This document discusses these issues in more detail and
tries to suggest enhancements to alleviate the problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-savola-v6ops-6to4-security-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-savola-v6ops-6to4-security-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Dec 2002 11:35:07 +0100

Hi Pekka,

Just a few comments.

Generally I wonder if there is a way to reorganize the text to make the
relay spoofing problem the most visible (first?) part. It is the unsolved
problem, after all.

On section 5.2.2 and the other discussions of this problem:

I think you could consider making a recommendation that
6to4 decapsulators SHOULD keep an LRU cache of recent relayed
headers for trace purposes. If you cache a few hundred
{src,dst,src_v4} triplets you could use this to trace spoofs.

As you observe in more than one place, this only helps if ISPs run
v4 ingress filtering - but so many of the Internet's vulnerabilities
need ingress filtering that we can't penalize 6to4 for that.

You also say somewhere that this would only allow you to trace
zombies in a DDOS attack - but it is necessary to trace zombies
in any case, even if you can't find the attacker that way.

Another use of a cache is that you might be able to build
a relay blacklist mechanism of some kind, or a rate limiting
mechanism - this is really outside the scope of an IETF draft
but the cache would be an enabling mechanism.

We haven't talked about possible crypto based solutions. At least in
theory, one could use something like AH to authenticate relayed packets, 
assuming that each relay knows one of a small number of private keys
(imagine each major ISP having a 6to4 private key for its relays)
and that each decapsulator knows all the corresponding public keys.

> 6.3. All Relays Must Be Anycast

It's pretty obvious from the description that this doesn't
work, and you should probably say so more clearly. Also,
this section and 7.3.1 really should be combined.

> 7.3.2. Limited Distribution of More Specific Routes

Again, your description makes this fairly obviously hopeless.
I do note however that relays, being routers, can look "sideways"
at the IPv4 routing table. If they had some magic way of deriving
the "last relay" address from this, there would be a solution
without effectively creating a spare copy of the IPv4 table.

   Brian

---

From: Alain Durand <[email-masked]>
Date: Wed, 11 Dec 2002 09:48:57 -0800

Pekka,

There are some aspects you somehow overlooked in your draft.

1. This attack by spoofing relay can be distributed to
    a huge number of reflectors (just have to find their address
    in the DNS). This changes  quiet a lot of things, and
    makes tracing the attack and stopping it very difficult.
    For example, it is not clear how statistical analysis
    done on packet sampling will work.

2. If outgoing 6to4 relays get widely deployed and the attack
    uses a very large number of reflectors with just one zombie,
    it is not clear that the relays will act as a contention point...

3. ...but if they do, the attack is transformed from a DDOS attack
    on the fake IPv6 src to a DDOS attack on the relays!

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Dec 2002 23:30:15 +0200 (EET)

Hello,

Thanks for comments.

> relay spoofing problem the most visible (first?) part. It is the unsolved

I'm not sure if it is really the only unsolved problem: that depends on
whether one is satisfied with the "solutions" for other problems.

But I agree: it should be made clearer what are the (more?) real problems 
and what are not.

I also agree with Christian's three-tier evaluation criteria -- that's one 
way to consider them.  I'm not sure how usable it really is (ie. the 
criteria to meet those three levels vary quite a bit), but at least it's 
something.

So I think I'll add more beef to the summary section (e.g. in a form of a
table) or the issues and their perceived issues.
 
> {src,dst,src_v4} triplets you could use this to trace spoofs.

Problem here is what you're going to _do_ with these traces.

Most systems where 6to4 is implementated are already able to do this, 
after a fashion -- with firewall logging rules.

But unless there's some way to easily use that information, it is not all 
that usable when run e.g. in 6to4 sites.
 
> need ingress filtering that we can't penalize 6to4 for that.

v4 ingress filtering is a problem -- yes.  6to4 is slightly different in
the respect that it expects 6to4 routers to form weakish trust
relationships with any IP address in the Internet.  This would be less the
case if such relationships would only be required with e.g. some of your
own ISP's addresses.
 
> in any case, even if you can't find the attacker that way.

More or less agree.
 
> but the cache would be an enabling mechanism.

Currently, a cache would work -- to an extent.  But I fear if we assume no 
IPv4 ingress filtering, we get to the situation where the attackers could 
just spoof the 6to4 relays they know of..
 
> and that each decapsulator knows all the corresponding public keys.

Agree; if we'd want "real", stronger security in 6to4, there are not many
other possibilities other than a crypto-based approach.

Crypto would be usable in the limited distribution of more specifics
concept, I believe -- if you need the public keys of all the relays, I
believe we might end up in an unsolvable key management nightmare..
 
> this section and 7.3.1 really should be combined.

As this seems to be becoming a concensus, I'll look at this.
 
> Again, your description makes this fairly obviously hopeless.

I don't want to give too much hope even though there may be some light at
the end of the tunnel :-) -- but I believe this model _could_ work.  And
conceptually it would be pretty close to the current Internet routing
security model -- so it would be a relatively good solution.

I'm interested on working this more, fleshing it out, but I'd first like 
some thoughts whether folks feel this could be doable.

> without effectively creating a spare copy of the IPv4 table.

I'm not sure what you mean by the "last relay" (or magic deriving) ..?

-- 
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: Tue, 17 Dec 2002 23:43:40 +0200 (EET)

>     done on packet sampling will work.

I meant to write about these a bit, but seemingly forgot.  (I don't see 
this as a huge issue, as it seems to me that to succeed, this would 
require at least hundreds of relay routers.)

If 6to4 router/node acts as a reflector, distributing the attacks to a
number of reflectors naturally makes the statistical analysis in them a
bit more difficult.

However, if 6to4 relay routers are still a bit more sparsely distributed, 
most of the reflected traffic gets aggregated to smaller number of relays, 
and then statistical analysis there might be doable.
 
>     it is not clear that the relays will act as a contention point...

This is a less dangerous attack (relays << routers).

>     on the fake IPv6 src to a DDOS attack on the relays!

I believe there are two issues that should perhaps be separated: attacks
against 6to4 infrastructure and general Internet (one could say that if an
attack can just harm the 6to4 mechanism itself, it's a bit more harmless).

---

From: Alain Durand <[email-masked]>
Date: Tue, 17 Dec 2002 14:19:12 -0800

>require at least hundreds of relay routers.)
Maybe I was not very clear, I meant a single zombie
pretending to be a relay and sending a single packet
to a very large number of 6to4 hosts with IPv6 src
set to the victim machine.

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Dec 2002 23:58:26 +0200 (EET)

> set to the victim machine.

Right, I misunderstood a part of your cases.

However, I believe this becomes a real pain in the case that there are
enough relays (in the degree of hundreds or thousands) so rate-limiting or
statistical analysis on _relays_ is not really possible; obviously 6to4
nodes/routers can't do much there -- but that's little different to
someone today sending a TCP SYN to Joe Random with forged source address.

The difference is mainly in that the attack is doable even if you're ipv4
ingress filtered as trace about real IPv4 address used in the attack is
lost at 6to4 routers.

---

From: Alain Durand <[email-masked]>
Date: Wed, 18 Dec 2002 14:42:10 -0800

>ingress filtered as trace about real IPv4 address used in the attack is
This is exactly the point I've been trying to make.
In this scenario, the 6to4 technology enables one
to set up an attack that was supposed to be prevented
by ingress filtering. And again, there is no way to prevent
it from hapening.

    - Alain.