[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About DHTs, byzantine robustness, and security (was Re: A roadmapfor end-point identifiers? ...)


Iljitsch van Beijnum wrote:
> So you're afraid that when to people communicate without proper security 
> mechanisms in place, others might suffer? 

Exactly.  That I have been trying to say all the way along.

> I agree that we shouldn't add to existing attack vectors,


> but I doubt that we can solve this general case here and now.

I don't know what you mean with the general case.  My point has
been that if we do introduce the id/loc separation then we have to
take care of security, in order to not to add new vulnerabilities.
Perhaps I have not been able to say this clearly enough.

If you don't care about security when you do the separation, the
consequences can be severe.  We do need crypto to fix the
potential problems.  We do not necessarily need cryptographic
identifiers, but cryptographic identifiers help, and potentially
make the system much more secure.

Once more:  There is no intrinsic need to protect the actual data
traffic (even though I think it would be good in most cases),
but we do have to protect the signalling traffic that verifies
and updates the id->locs mappings in the end-hosts.  Since we have
to place the appopriate protection mechanisms there, I do not
think that we can easily allow zillions of different protocols
there, as you were suggesting.  Two or three maybe (LIN6, HIP,
MAST, counting.... :-), but more than that may have difficulties in
getting through the IESG due to the security requirements.

> Hm, I think Smurf attacks were pretty successful in singlehomed fixed 
> location IPv4 networks.

There is a huge difference between someone getting nodes to
reflect single spoofed packets and someone legitimately
redirecting complete data streams, and only *then* starting
to spoof acoknowledgements to keep those data streams running.

I know, the MIPv6 RO security background draft is long.
But I don't have time to try to distill a shorter version
of it right now.

--Pekka Nikander

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6