Educated Guesswork

« RFID passport rollout | Main | Nasal spray addiction »

March 12, 2006

Review of draft-bryan-sipping-p2p-02.txt

OVERVIEW
This draft describes a protocol and architecture for doing
"P2P SIP". What this means in practice is that registration
information is stored in a Distributed Hash Table, thus
in principle removing the need for centralized servers.


GENERAL COMMENTS

Use of SIP for DHT Functions
----------------------------
The protocol used in this draft uses SIP both for the usual
signalling functions and for DHT maintenance. This strikes
me as a poor design decision.

1. It means that while you will be able to use generic 
   DHT algorithms you won't be able to use a generic
   DHT service. There's nothing particularly special
   that this application requires from a DHT, so it seems
   like a classic architectural mistake to tie yourself
   to something specific.

2. It obscures what should be a clean architectural separation
   between lookup services (what the DHT is being used for)
   and signalling services (what SIP is used for now). This
   made some sense in the previous draft which actually 
   punned on the SIP messages (using INVITE to find the
   UA for the desired contact) but now that you're using
   REGISTER in order to explicitly separate these functions,
   there's really no value added here.

3. It's really confusing.



Security
--------
There are a number of known security issues with DHTs. In
the specific design described here:

1. There is no authentication for names. The authors write:

   "The lack of central authority to resolve name disputes in the
   namespace means that at some level this problem is unsolved.  The
   approach has tended to be to allow everyone to call themselves Wally
   then let the certificates sort them out.  Users with names that are
   often "stolen" by others will learn that theirs is a poor choice of
   name because it is too valuable, and they will select a less valuable
   name.  Equilibrium will prevail, or chaos."

I don't really understand how this works. If the attacker can 
insert itself at a single replica, it can create a systematic
inconsistency about the appropriate holder of a name. This
makes it very easy to mount an attack on a specific target. 
This draft seems to assume that it's specific names that are
valuable, but in many cases it's not the name itself but rather
the identity of the name holder that's valuable, so changing
your name won't help, at last not for long.

2. You need some mechanism for resolving which replica is 
correct. Otherwise, any inconsistency leads to what...?

3. The protection against Sybil attacks depends entirely on the
attacker not having access to a large block of routable
addresses. This is questionable at best with Pv4 and silly with
v6. Designing a protocol which is only secure on v4 seems unwise.
The discussion of this in 10.11 is clearly inadequate and I
don't really see how it can work unless you assume specific
address boundaries. 

It's not clear to me what constraints lead to this design. 
The use cases documents talk a lot about not necessarily
having access to a global nameservice, but the kind of
non-real-time access required for secure naming (e.g.,
to get DNSSEC "certificates") is very different from requiring
a full-time service. Having any kind of distributed naming
service obviates many of the security problems listed above.


These aren't security problems that can be solved by gluing on 
some crypto at the end of the day. Security for DHTs is a
major unsolved research problem, so this is rather worrisome.


DETAILED COMMENTS
S 7.2.1:

   ipport         =  IPV4address ":" port

And v6?


S 10.4:

   A P2P environment can do little to protect against an individual node
   compromising the registrations it is responsible for.  Accordingly, a
   UA cannot trust a response from a single node, whether it indicates a
   successful search or an error.  In the absence of other methods of
   verifying the response (such as having a certificate of the user
   being searched for and a signed registration that can be verified
   with the certificate) a UA should search for the primary registration
   and at least one replica.  Because the locations the replicas are
   stored are unrelated to the location of the primary registration, a
   single attacker is unlikely to be able to compromise both entries.
   As the overlay gains more nodes and more replicas are searched for,
   the odds of a compromise are reduced.

It's not clear to me why you think your replica model has superior
security properties to the "next N successors" model that chord uses.
In both cases, the attacker needs to compromise (or compromise
routing to) N nodes. And since the preimages of the next N node IDs
are randomly distributed in IP space, I don't see an advantage
here. Please explain.

S 10.7:

   computer.  Cao et al, [9] describe an approach that separates the
   storage of resource location information from the actual storage of
   the offline research.

Is "research" really the word you want here?

Posted by ekr at March 12, 2006 9:33 PM | Filed under:

Comments

Posted by: Bram at March 13, 2006 7:56 AM

Posted by: Lisa Dusseault at March 20, 2006 4:44 PM

Posted by: pics gyno medical fetishes at March 20, 2006 6:44 PM