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

From: Song Haibin <[email-masked]>
Date: Tue, 14 Apr 2009 10:26:16 +0800

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

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 14 Apr 2009 14:44:27 +0200

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:
> 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.

> [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.

> [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

---

From: Song Haibin <[email-masked]>
Date: Wed, 15 Apr 2009 11:25:02 +0800

Enrico,

>-----Original Message-----
>From: Enrico Marocco [mailto:[email-masked]] 
>Sent: Tuesday, April 14, 2009 8:44 PM
>To: Song Haibin
>Cc: [email-masked]
>Subject: Re: [p2prg] Comments to 
>draft-schulzrinne-p2prg-rtc-security-00
>
>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]."
>>  
>> 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.
>

Good example.

>> 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. 

I guess any peers located in a victim company could be the target of such
attack, if the p2p application is open on the internet. However, I don't
have a real example at my hand for such attack incentive in p2p
applications, but for c/s scenarios, google can give many good real
examples.

>OTOH I agree that competition could be a real incentive.
>
>> 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.
>
>> number of clients attached, bandwidth usage for DHT maintenance, 
>> memory usage for DHT routing table. I hope p2psip diagnostics
>At the time of writing the p2psip-diagnostics work was still 
>very early, but I agree that now it would be worth referenced here.

I agree.

BR
Haibin

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 15 Apr 2009 06:31:23 -0700

> architecture and turned to client/server architecture. It's better to
> remove this reference.

There is still Bittorrent and several others.

Henry

On 4/14/09 7:44 AM, "Enrico Marocco" <[email-masked]> wrote:

Song Haibin wrote:
> architecture and turned to client/server architecture. It's better to
> remove this reference.

--
Ciao,
Enrico

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 Apr 2009 16:28:31 +0200

Hey Henry,

> 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
> ------------------------------------------------------------------------
> 
> _______________________________________________
> p2prg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/p2prg