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

[Song Haibin <[e-mail]>]

Hi,
 
I have read this draft last week and found it a really interesting document
to read. It is a good tutorial for real time application security in p2p
environment.
 
Here are some detailed comments after my reading.
 
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.
 
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.
 
3. In Section 2.2 "IP addresses are also an important resource for the
attacker since in DHTs such as Chord [Stoica], the position in the overlay
is determined by using a base hash function such as SHA-1 [SHA1]on the
node's IP address"
 
[Haibin] It is bad to determine a peer's ID using hash function on the
node's IP address because IP address may change. But IP address is indeed an
important resource for attackers, because it becomes hard for you to track a
malicious node if it uses multiple IP addresses. And some authentication
methods usually assign only one identity to a single IP address, an attacker
with multiple IP addresses can get multiple identities for their attack.
 
4. I think the analysis in Section 4 is quite intersting and helpful,
because many attacks are based on your position in the p2p overlay.
 
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".
 
6. In section 7 Peer-to-peer in realtime communication
 
[Haibin] I agree that confidentiality is one of the most important issue. In
file sharing, one does not care too much from whom the contents are
downloaded, but in real time apps, one extraordinarily cares about whom he
talks with. 
 
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.
 
8. In section 7.1.4 Incentives for clients, it is said "Peers could restrict
the number or types of calls that they allow clients to make."
 
[Haibin] It must be careful that giving this power to peers could bring
denial of service attack against clients.
 
9. I think some black list or white list mechanism is quite interesting and
helpful in P2P overlays, I am interested in the maintenance of a black/white
list in p2p overlay, on how to establish it, how to access it, and how to
update it, and the security about the black list itself.
 
Best Regards,
Haibin
Skype: alexsonghw