Subject: [p2prg] Review of draft-irtf-p2prg-rtc-security-01

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 Jun 2009 19:11:08 -0500

This is a survey-oriented draft concentrating on the security
issues related to using realtime communications as a p2p
service.  It compares and contrasts the use of p2p DHTs
used for file-serving applications with those used for
realtime communications applications.  As a research
community, we have a lot of expertise and literature in
the former usage of p2p networks, and are developing more
expertise in the latter.  The draft looks at how existing work
in file-serving applications can help us address the issues
with realtime communications p2p networks.

The draft is in fairly good shape; detailed comments from
the review are below.

General comments:
1) In the References, please identify the name of the publication
  wherever appropriate.

2) There are many compound sentences, separated by commas,
  that can be broken down for readability (for instance, in S7,
  the second bullet item contains a rather long sentence that
  is hard to read.  I have suggested some alternate text for
  this in the substantive comments section, but there are other places
  that the author/editor should pay attention to as well.)

Substantive comments:

1) S1, page four: "Once the threat has been identified, admission
  control is the first step towards security."  I do not quite
  understand this sentence.  Is admission control an answer to all
  p2p security problems?  I suspect that it is an answer to an
  awful lot of problems, but p2p networks can be attacked even after
  admissions control has granted admission to an attacking peer, no?

2) S1, page four, last paragaph does not read smoothly.  There are
  many qualifiers that detract from comprehension of the paragraph.
  I would suggest a rewrite as follows (please feel free to edit as
  you see fit):

    In the remainder of this document, we outline the main security
    issues and proposed solutions for P2P systems.  Following this,
    we focus on a particular P2P application: realtime communications.
    Realtime communications use the same DHTs used by file-sharing
    applications, however, the data that is saved in these DHTs is
    different.  In realtime communications, the contents stored in
    the DHTs comprises of user location, the DHT being the substitute
    for a centralized registration server.

    From a technical point of view, it appears that realtime
    communication services are no different than file-sharing
    services, Table 1 demonstrates that there are sizeable
    differences related to privacy, availability, and a marked
    increase in the general security requirements.

3) In Table 1, first row, second column: "...often hundreds or thousands
  per user."  Do you mean "per peer"?  I do not know what you mean by
  "user" here.

4) In Table 1, first row, third column: "...rarely more than one per
  user."  Same comment as above -- I am not sure what you mean by
  "user".

5) In Table 1, the row "Availability": I am not sure I follow the
  difference here.  Yes, in file-sharing, a file can be replicated at
  many places in the DHT.  This is also true of realtime communications,
  where a user's location can have many replicas in the DHT.  Users
  are unique, but so are files.  An instance of a file may not be
  unique, any more than an instance of an user is; but the underlying
  object (user or file) itself is unique.

  So, given this, I am trying to fathom what role availability plays
  here in the context of a difference between realtime communications
  and file-sharing applications.  Maybe I am missing something that
  is not stated there (or it may be stated, but I just don't get it.)

6) S2.3:
  s/malcontent/malicious content/

7) S3, last sentence: I think you should note that CAPTCHAs are not
  a panacea.  Visual captchas have been vulnerable to machine learning
  techniques and have been broken quite easily [2,3].  Audio captchas
  have suffered the same fate -- 71% of them can be easily identified by
  an automata [1].

8) S5.2, I am not sure I follow the sentence "Most reputation
  management systems proposed in the literature ... are for
  file-sharing applications."  Indeed, that is true of the p2p
  literature in general, so I am unsure the intent of pointing this
  out now.  That said, are there any novel dynamics that are only
  applicable to a realtime communication p2p service?  If so, it may
  be worth pointing those out here.

  In the same paragraph, I am not sure that listing the five design
  considerations of [Kamvar] adds anything substantive to the
  discussion, unless, of course you were later to evaluate these
  with an eye towards realtime communication services in p2p.

9)  S7, second bullet item as written is rather long and does not read
  easily.  I would suggest the following rewrite:

    In file-sharing applications, eavesdropping and identity theft
    do not constitute real threats; after all, files are supposed to
    be made publicly available.  This is not true in realtime
    communications, where the privacy and confidentiality of the
    participants is of paramount importance.  Furthermore, the
    notion of identity plays an important role in realtime
    communications since it is the basis for starting a communication
    session.  As such, it is essential to have mechanisms to
    unequivocally assert identities in realtime communication
    systems.

10) S7.1 is not so much about admission as it is about promotion;
  i.e., when does a client get promoted to a peer?  In traditional
  file-serving p2p networks, this concept of promotion does not
  exist.  As such, I would consider renaming that section to
  be something other than "Admission" -- "Peer Promotion" is a
  good start, for instance.

11) S7.2.1: The targeted denial of service attack described here
  is no different than it would be if this was a file-sharing p2p
  network, right?  Just curious why you consider it germane to
  a realtime communications p2p network.

Nits:

General nit: in many places, the draft uses "et. al"; it should
be "et al."

1) S1, break into a new paragraph on the sentence "P2P overlays can be ..."

2) S1, page four

3) S2.1, page six: "However, such attacks are ..."  By "such attacks" you
  mean [D]DoS attacks, or "attacks for monetary gains"?  I would suggest
  you spell out which type of attack you have in mind.

4) S2.1, page 6:
  s/as botnet),/as botnet)/

5) S2.1, page 6:
  s/other incentives, only indirectly/other incentives indirectly/

6) S2.1, page 6:
  s/known to attempt polluting/known to have polluted/

7) S2.2, page 7:
  s/sybil/Sybil/g

8) S3, paragraph 2:
  s/The latter,/In the latter case,/

9) S3, paragraph 2:
  s/Saxena et. al/Saxena et al./

10) S4, page 10:
  s/Yu et al [Yu]./Yu et al. [Yu]/

11) S6.2:
  s/log$N$/log(N)/

12) S7, first sentence:
  s/boils down to/essentially implies/

13) S7, last paragraph:
  s/issues, and security/issues and security/

14) S7.1.1:
  s/make it the responsibility of/leave it to the/

15) S7.2.1: The two instances of "which" in this section should
  be replaced by "that".  The use here is that of a non-
  restrictive clause (see
  http://www.kentlaw.edu/academics/lrw/grinker/LwtaThat_Versus_Which.htm
  for a good writeup on when to which -- or is it when to use what ;-) )

16) S7.2.4, title: I don't think there is such a word as "signalization".
  Maybe "signaling" will suffice here?

References:
[1] Jennifer Tam, Jiri Simsa, Sean Hyde, and Luis von Ahn.
  Breaking Audio CAPTCHAs. In Advances in Neural Information
  Processing Systems (NIPS).
[2] G. Mori and J. Malik. “Recognizing Objects in Adversarial
  Clutter: Breaking a Visual CAPTCHA,” In Computer Vision and
  Pattern Recognition CVPR'03, June 2003.
[3] K. Chellapilla, and P. Simard, “ Using Machine Learning to
  Break Visual Human Interaction Proofs (HIPs),” Advances in Neural
  Information P rocessing Systems 17, Neural Information Processing
  Systems (NIPS'2004), MIT Press.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 25 Jun 2009 09:49:15 +0200

Thank you for an extremely accurate review, Vijay! We'll go through your
comments and will issue an updated version by the draft submission
cutoff date.

Enrico