Re: Draft multi6 minutes

[Erik Nordmark <erik.nordmark@sun.com>]

Tim Shepard wrote:

> I was trying to point out that the HBA scheme seems to allow you these
> three choices (if I understand it correctly):
>
> user work factor       attacker work factor
> ----------------       --------------------
>   1                             2^59
>  2^16                           2^75
>  2^32                           2^91
>
>
> and it's not clear that any of those are useful.  

Because?

Note that in any case (independent of the sec parameter) the peer's 
verification cost is constant. Thus what you call "user work factor" is 
the work factor for creating an HBA set of addresses.

> If security is not needed, then perhaps we don't even need to use the
> HBA scheme.  If security is needed, then perhaps this scheme isn't
> much better than using some public key cryptography.

We know that security is needed. full stop.

The question, given that we assume that when the payload requires 
security there will be some e2e payload security (ipsec, tls, ssh), is 
how hard we need to make it for
1) off path attackers to redirect the traffic (which for the e2e secure 
payload would have the effect of a DoS; packets will not be delivered to 
the peer)
2) on path attackets to redirect the traffic (which for the e2e secure 
payload would have the effect of a DoS)

With HBA we can get the work factor for an on-path attacker to be 2^59 
higher than the work factor to construct the HBA set of addresses.
Given that an on-path attacker might be able to cause packets not to be
delivered using other means (after all it is on the path so it might be 
able to perform ARP/ND spoofing, overload the local link, cut the cable, 
or might be sitting inside a router or switch).

For off-path attackers we can make things arbitrarely more hard to guess 
by just using large random nonces (in addition to the HBA/CBA addresses).

So I'm not concerned about dropping the number of hash bits further to 
be able to support longer than /64 subnet prefixes in the future; 
cutting 16 bits seems to be ok.

   Erik