On woensdag, sep 10, 2003, at 15:00 Europe/Amsterdam, Pekka Nikander wrote:
Ok, not sure what you mean by "byzantineously robust" exactly and maybe I've missed a few of those papers, but so far nobody has been able to explain to me how you can build a DHT system using untrustworthy nodes. The best you can do is replicate the data to such a degree that it becomes very unlikely that all the nodes that hold the data collude to deceive you. If you think the DNS is bad, consider having a system where you need to depend on random strangers to be reachable...
The basic assumption in byzantine robustness is that as long as the number of dishonest participants do not exceed a treshold ratio (e.g. one third of all participants), the system does not fail.
Ok, I'm going to read up on this stuff but in the mean time: it's pretty obvious that if you want to be sure that a certain node doesn't deceive you, you must check with a significant number of different nodes to see if they agree. This is going to cost you performance.
In the case of DHT servers, the more servers there are, the less likely it is that the treshold would be exceeded. Hence, even if you are relying on strangers, you are relying on them in a random manner, making any collusion highly unlikely, and impossible in practise.
I just don't see it happening. If we reach a million multihomers, 900,000 of which are SOHO/private persons at some point in the future, and every piece of information is replicated in 10 places, there is still a 35% chance that a fortune 500 company has to rely on "basement multihomers" exclusively for this incredibly sensitive stuff. And remember: no SLAs, nothing.
I think we need some experimentation first. Maybe set up a "shadow DNS" that uses DHT?
If you use reachable PA as identifiers you have the option of connecting first and adding multihomedness later.
Yes, provided that your PA address works, right now.
It does _most_ of the time. ...
If you restrict your thinking to multi-homing, then yes. But if you add mobility, the situation is not that simple any more.
Yes, mobility is complex. But don't you have the home agent as a fallback? So even in this case the regular PA home address should work most of the time.
Let me take a counterexample.
If you use PI addresses locally for administrative purposes (think SSH), you can use them even if your network is disconnected, going through renumbering, or otherwise failing to get any PA prefixes.
So you're saying: use PI first, PA as fallback?
I am saying that depending on application.
No, that's no way to build something reliable. Either you always first do PA and only use the potentially non-routable addresses as a fallback, or you need two faced DNS or complex IGP tricks.
I'm not worried about security as these are end-to-end mechanisms. If two hosts feel they don't have to protect their communication, who are we to say that they must?
We need to protect the infrastructure. As I wrote, the danger is not that mcuh to the communicating hosts but to the infrastructure.
I'm not sure what you mean. Routers? DNS servers?
As an example, an attacker may launch a denial-of-service attack on a given node A by contacting a large number of nodes, claiming to be A, and subsequently diverting the traffic at these other nodes so that A is harmed.
Not really big news. And yes, it would be extremely helpful if we could do something about this, as this kind of stuff is really getting out of hand these days, with all those worms, scanning and DoS. But it has nothing to do with multihoming, mobility or IPv6.
3.1.2 Stealing addresses of stationary nodes
[...]
Nodes with well-known addresses, such as servers and those using
stateful configuration, are most vulnerable. Nodes that are a part of
the network infrastructure, such as DNS servers, are particularly
interesting targets for attackers, and particularly easy to identify.
If we use the DNS for multihoming we have to accept a certain risk of DNS corruption. Fortunately, we don't have to argue about how bad the risk is and whether it's acceptable or not, because we already take it by using DNS names. So if we're vulnerable because we use the DNS once, (name -> address) there is no substantial additional harm in doing it a second time (identifier -> locators).
If you feel a mechanism is too insecure, either slap some additional IPsec or TLS on top of it, or don't use the mechanism.
Unfortunately neither IPsec nor TLS pixie dust helps here.
It does if you use it right. :-)
For instance: why bother making all kinds of complex systems to protect binding updates? If I'm communicating with node A and I get a packet from address B claiming to be node A, I simply install B as an additional locator address for A if the packet passes ESP authentication for an SA that's negotiated with A.
On the other hand, if your binding mechanisms can be corrupted by an attacker, running IPsec or TLS doesn't help because it doesn't magically get the wrongfully redirected packets back to where they should have been in the first place.
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
