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

[Pekka Savola <pekkas@netcore.fi>]

Hello,

Thanks for comments.

On Wed, 11 Dec 2002, Brian E Carpenter wrote:
> 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.

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

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

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

More or less agree.
 
> 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.

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

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

As this seems to be becoming a concensus, I'll look at this.
 
> > 7.3.2. Limited Distribution of More Specific Routes
> 
> 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.

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

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