Pekka Nikander wrote:
I would find it very nice if we could change the IP layer, install
infrastructure, and change the applications in one shot. I just don't
believe that we any more can do it -- we almost failed with IPv6, and
IMHO would have failed without the _severe_ address scarcity outside of
NA and EU.
Pekka,
I hope you didn't interpret my comments that we need to replace
everything at once. For instance, I don't think we should change the
applications and the APIs at all - the applications should continue to
function using getaddrinfo() + connect()/sendto() using 128 bit names
for their peers. [We might want to introduce an optional
connect_by_name() call to make it easier/faster to handle the
multiplicity of locators.)
Thus I see a need to evolve the stack (towards shim6 and hip like
capabilities) as well as a way to handle ID->locator lookup when/if we
have identifiers that are not also usable as locators.
But I don't see a need to change anything else.
If there is new functionality in the stack and new piece of
infrastructure, it *may* be possible to provide sufficient incentives
for upgrading the applications. I would imagine that security might
be such a feature in the long run.
But security of what? See below.
But I do agree with you that we are missing some thinking here, i.e.,
we are missing a convincing set of incentives. Maybe we should go and
try to create them artificially, by reducing the KHI hash size so that
they will become insecure sooner that with the current design, and by
not allowing the experiment to be continued, say, beyond 2015 even with
IETF consensus. _Sort_ of similar to what we did with 6bone, making it
very clear from the beginning that people have to eventually move forward.
But for the 6bone there was a place to move to which had the same
characteristics hence the cost to move is relatively low; the needed
forcing function doesn't have to be that strong.
If the goal is to cause all the applications on the planet to be
rewritten there is no forcing function strong enough; you'd need
significant benefits to even get a small fraction of the applications to
be ported to something new.
If the currently secure hash size is about 96 bits, 120 bits can be
expected to become insecure in about 24 years.... Maybe that is too
much; OTOH, given the recent advances in breaking SHA-1, we should have
*some* marginal....
My assumption is that anybody that cares about security of the content
being communicated applies some security to that content; IPsec, TLS,
whatever. And if folks care about www.example.com really mapping to an
IP address and the routes pointing in that direction, we need DNSsec and
some routing security.
AFAICT we need this even if HIP is used (even though HIP helps to get
IPsec end-to-end).
I think this implies that the length of the hash is only there to
protect against redirection attacks for off-path attackers; on path
attackers e.g. somebody that can cut the wire or control the
software/firmware in a router or switch can always redirect packets.
Thus in terms of the mobility and multihoming control protocol, the
attacks for the important traffic would be limited to redirecting the
encrypted payload to somewhere else. If the e2e encryption is good
enough, this would be the same as redirecting it to a black hole i.e.,
a, possibly selective, DoS attack on some traffic.
How much effort would an attacker like to spend on such an attack?
And what are the different ways the attack could be performed?
The attacker could look for input that hashes to the same identifier,
which will be feasible in the future, but will require significant
compute cycles.
The attacker could also gain physical access to the path (break in,
bribe somebody with access, etc). Comparing the cost/effort of a
protocol attack vs. a physical attack is like comparing apples and
oranges. But I still think we need to consider this so that we don't
overengineer the protection against redirection attacks.
An attacker can use bribes to get physical access - take $10,000 to
$100,000 as numbers out of a hat.
An attacker can attack the hash function for a single host - how many
CPU hours are required to do this today? With what hash length would
this be less than 10,000 to 100,000 CPU hours today?
I realize that HIP is a bit harder to analyze in this was than shim6,
because HIP also uses the HIT/HI to secure the payload with ESP. But the
above arguments would apply to shim6 and "ESP-less HIP".
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
