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

[Brian E Carpenter <brian@hursley.ibm.com>]

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