Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item

[Rui Cruz <[e-mail]>]

Hi Arno, All

Please see inline...

*<[:{)
ho ho ho

Regards,

Rui Cruz
[e-mail]

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ppsp


On 21/11/2012, at 12:56, Arno Bakker <[e-mail]> wrote:

> Hi Rui et al,
> 
> please see inline.
> 
> On 14/11/2012 13:36, Rui Cruz wrote:
> 
>> The CONNECT message in the base protocol is restricted to certain
>> conditions.
> 
> IMHO, these restrictions on CONNECT could be lifted to allow it to be used for refreshing registrations, yielding a very simple 1 message protocol.
> 
Perhaps I oversimplified my explanation (in terms of protocol semantics).
 
The protocol, as a matter of fact, only uses one message, i.e., a POST request message, and the corresponding response (it is a request-response protocol).

Each POST carries (as message body)  "action" signals or "information (on status or statistics)" signals. 
For "actions" the Request method name to be used is CONNECT. 
For "information" the Request method name to be used is STAT_REPORT.
Responses to requests correspond to "Status-Codes" and may carry a Response body with the results of the corresponding requested "actions" or the acknowledge of reception of the "information". 

From that, it is not logic to send an "action" request just to provide "status/statistic" information.

> 
>>> But if it is currently not possible to implement a tracker service
>>> that offers this functionality and is secure in a malicious
>>> environment, the support for it should not be in the tracker protocol,
>>> IMHO.
>> I do not agree with your position stating that a (global) trust
>> functionality is "not possible" to be offered.
>> An implementation of a tracker service can perfectly offer a trust
>> functionality. It might not be "global" but can be offered.
>> In EU Project SARACEN we have an implementation of a trust/reputation
>> functionality.
> 
> Let me phrase it differently: Can you build a PPSP-based YouTube that securely uses this property-based peer selection? If not, the draft should make it clear that property-based selections can only be safely used under specific conditions.
You are mentioning a completely different type of approach in terms of access to contents. 
Youtube allows anyone to individually receive the stream (in some rare exceptions allowing to download the content). 
But to upload contents, users are required to be registered, and consequently authenticated, before being able to upload. And even so, contents may be banned if some specific conditions are met.

In a P2P environment with a Tracker service, if the tracker is able to filter peers from a swarm, based on location properties, the selection is not done under "specific conditions" but just on network topology properties, independently of the possible "malicious intentions" of some of the peers in the swarm. 

But if the properties of peers are related with activity or capabilities, then I agree with you that a selection based on those properties would only be considered "safe" if the requesting peers are trusted and well known.

We can add these concerns to the draft document.  
> 
> CU,
>    Arno
> 
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp