Re: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00

Hey Henry,

Henry Sinnreich wrote:
>> [Haibin] As far as I know, Joost has just changed its basic P2P system
>> architecture and turned to client/server architecture. It’s better to
>> remove this reference.
> 
> There is still Bittorrent and several others.

Indeed, but as we mention in the text the sentence is there only to show
uses other than file sharing. We are not trying to provide an exhaustive
enumeration.

Cheers
Emil
> 
> Henry
> 
> 
> On 4/14/09 7:44 AM, "Enrico Marocco" <enrico.marocco@telecomitalia.it>
> wrote:
> 
>     Thanks for an accurate review, Haibin, we'll integrate your comments in
>     the next version of the draft. A few notes inline.
> 
>     Song Haibin wrote:
>     > 1. In Section 1, paragraph 1, "P2P networks are now also being used for
>     > applications such as Voice over IP (VoIP) [SKYPE] [Singh] and
>     television
>     > [JOOST] [COOLSTREAM]."
>     >
>     > [Haibin] As far as I know, Joost has just changed its basic P2P system
>     > architecture and turned to client/server architecture. It’s better to
>     > remove this reference.
> 
>     Yes, indeed, probably now PPLive is a better example of P2P systems for
>     realtime content delivery.
> 
>     > 2. Section 2.1 Incentive of attacker
>     >
>     > [Haibin]  I could give some additional common incentives of attackers.
>     > For example, some attacks are motivated by the business competition or
>     > for selling security products. E.g., I heard some firewall product
>     > companies usually attack some company’s network, and tell them their
>     > network is not safe, so that they could sell them firewalls.
>     Attacks due
>     > to competition are also common cases. These kinds of attacks may happen
>     > to p2p overlays.
> 
>     While it is arguably a real issue in C/S scenarios, I'm not sure who, in
>     a P2P system, could be the target customer of such security solutions.
>     Maybe you are thinking of sort of a hybrid model, but the case of some
>     company selling a security product for an application distributed by
>     another company doesn't seem much realistic. OTOH I agree that
>     competition could be a real incentive.
> 
>     > 5. In Section 5.1.2, Reactive identification, "In a file-sharing
>     > application for example, after downloading content from a node, if the
>     > peer observes that data does not match its original query it can
>     > identify the corresponding node as malicious."
>     >
>     > [Haibin] It is hard to determine which node is the malicious node in
>     > this context. But at least this content in this node can be marked with
>     > “malicious”, or this node can be marked with “suspicious”.
> 
>     Identification of malicious peers is actually a very complex topic,
>     subject itself of many possible attacks. The example in section 5.1.2,
>     surely over-simplistic, has the only intent to pass to the reader a
>     quick image of the reactive approach, but it is of course far from a
>     real solution.
> 
>     > 7. In section 7.1.2 When to upgrade
>     >
>     > [Haibin] It lists some information to determine the peer load, e.g.
>     > number of clients attached, bandwidth usage for DHT maintenance, memory
>     > usage for DHT routing table. I hope p2psip diagnostics
>     > (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect the
>     > listed corresponding information from the overlay.
> 
>     At the time of writing the p2psip-diagnostics work was still very early,
>     but I agree that now it would be worth referenced here.
> 
>     --
>     Ciao,
>     Enrico
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> p2prg mailing list
> p2prg@irtf.org
> http://www.irtf.org/mailman/listinfo/p2prg