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

[Enrico Marocco <[e-mail]>]

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