[p2p-sip] P2PSIP, Kademlia and caching

[bk9001 at gmail.com (Brijesh Kumar)]

----- Original Message ----- 
From: "Heiko Niedermayer" <niedermayer at informatik.uni-tuebingen.de>

> commenting on all the mails on DHts. Well, I assume that the choice of
> DHT is of minor importance and that any DHT will at least do after
> adapting it to P2PSIP. But, why not build a specialized p2p network for
> P2PSIP. SIP is not a pure hash table service, so why transform a SIP
> network to a hash table?

Good question that is very hard to answer except to say that this is the 
easiest
thing  to do, and code. Well, hopefully someone will comeout with more
cogent answer.

> However, the big problem I see is that there is no convincing solution
> to provide security. Say, if I want to communicate with Nokia I might
> end up at Ericsson, that is fatal. And moreover, I do not want my
> personal data and behaviour be manged and tracked by peers I can and do
> not trust.

As you know, p2p application security without a confederated security
framework is not possible. You need to trust someone to be able to get in - 
the
question is who will issue credentials, for a large network, who is willing 
to
accept those credentials.

> So, the general question is if there is a way to secure P2PSIP and to
> provide privacy. In an open environment this is probably not possible. A
> closed P2PSIP network is no real value-add from my point-of-view. With
> respect to credentials, I assume that credentials are fine if the
> network is a closed infrastructure network and clients are not part of
> the network.

Very valid observation ..

cheers,

--bk

> Stefan Sayer wrote:
>> Hello,
>> Bruce Lowekamp wrote:
>>
>>> I don't think caching adds any complexities for authentication---if
>>> you're working in an open P2P system you're probably assuming you have
>>> an untrusted network to begin with and will be trying to validate any
>>> registration, regardless of whether it's cached or not.
>>>
>> 'validate' means for me in this context that the one who wants to
>> register really is the one that has on sign-up reserved that name.
>>
>> What I don't understand: If every node is admitted to publish or
>> update a record (which is true for a system that does caching), for
>> example my location record, how can identity theft be prevented?
>>
>> * if every node is admitted to change a value associated to a key then
>> anyone can steal the identity very easily
>>
>> * if every node is admitted to republish a <key,value> pair (be it at
>> cache places or some original root of the key), regardless of whether
>> it is the original publisher of the pair, then an attacker could still
>> litter the overlay with corrupted values
>>
>> So I would see the requirement as follows:
>>    The overlay MUST support binding a credential to a key, in order to
>>    authenticate the original publisher of a <key,value> pair in update
>>    and remove operations.
>>
>> On the API level, for example starting from the definition in
>> draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials
>> directly as parameter to the functions add, update, and remove:
>> get(in overlay_id, in key, out records, out error)
>> add(in overlay_id, in key, in record, in lifetime, in option,
>>      in credential, out error)
>> update(in overlay_id, in key, in record, in lifetime, in option,
>>         in credential, out error)
>> remove(in overlay_id, in key, in credential, out error)
>>
>> As much as I like Kademlia, as I understand it at the moment without
>> modifications it does not support this. But I might very well have
>> overlooked something.
>>
>> Regards
>> Stefan
>>
>>
>>> Bruce
>>>
>>
>> _______________________________________________
>> p2p-sip mailing list
>> p2p-sip at cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip