Subject: [p2p-sip] Comments on concepts-02

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 17 Oct 2006 16:04:42 -0500

1) We have an inconsistency between "short form" and "other form" in  
definitions. The original intent here was to include "also known as"  
terms that people are likely to use accidentally. I think as we  
harden the vocabulary consensus, we can withdraw some or most of these.

2) Need to reconcile Resource and User. Question: Is a STUN relay a  
user or a resource? If it differs from a "user", what are the  
implications from a definitional perspective? Is its identifier of a  
different class? Do we have different classes of resources? How does  
this relate to having multiple types of resource records?

3) Definition P2PSIP Overlay Neighbor can be reduced to P2PSIP  
Neighbor, as we did with other terms.

4) Need to reconcile two instances of user record definition. Both  
definitions have useful content, and I don't want to lose the "stored  
route" text.

5) Currently, question 4.9 is written as:

4.9.  Peer and User Credentials

    We believe we need some sort of credentials for authenticating peers
    and users of each P2PSIP Overlay.  What should we use for these
    credentials?  Certificates?  PGP keys?  Passwords?  If certificates,
    should these be signed by a CA associated with the overlay, or can
    self-signed certificates work in some or all cases?  Do we need to
    specify a standard credential format, or should we allow different
    implementations to use different credential formats?

Cullen suggested instead something like:

    We assume a security model based on the issuance of credentials by
    an authority (presumably centralized) for each P2PSIP Overlay. What
    form of credential should be used? Do we need to specify a standard
    certificate format, or should we allow different implementations to
    use different certificate formats?

Note that the above doesn't actually work in some of the use cases,  
such as the anonymous-communication scenarios or the overlay that  
requires initial self-organization under ad-hoc network conditions  
and lacks a centralized source of authority. Under certain  
circumstances, it might be suitable to do something like generate  
randomized distinguished names and self-signed certificates for those  
names. How shall we account for this in the draft?

--
Dean

---

From: zhuxian at huawei.com (zhuxian)
Date: Wed, 18 Oct 2006 20:55:56 +0800

Hi:
     As to the peer and user credentials, I think using certificate is a
reasonable selection. Because it has already been used in many p2p  platform
design, such as JXTA and microsoft PNRP.  And also, it is a reasonable
distributed authentication mechanism for p2p. If we use password, who know
your password, except the centralized user server. 
      A big question is, whether we use a CA or self-signed certificate. I
think it is related to the security level we want to attain in the p2p sip
world. Just using the self-signed certificate work well in some situation.
But it can not defend the sybil and eclipse attacking, whick may turn the
p2p sip overlay down in some situation. Use a certificate be signed by a CA
is Ok. But we need to do more in the p2p sip world. Because
anonymous-communication is an important character we want to achieve. And
also the revoke problem in CA is more serious in p2p sip as the number of
user may be huge and user may be dynamic. 

   As for the overlay that requires initial self-organization under ad-hoc
network conditions and lacks a centralized source of authority, we can not
get the security level when the overlay is accompany with a CA. Use the
self-signed ceritficate is ok in these scenarios. But i think it's
compatible with the CA approach in the peer/client implementation.
Peer/client can just downgrade the security level in these sitution.

     As to the credential format, why don't we use a standard credential
format, such as X.509? Does the standard credential format can't fulfill the
credential requirement in p2p sip?

Xian Zhu

 ----- Original Message -----
from : p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu]  Dean Willis wrote:
send: Oct 18, 2006 5:05 am
to: p2p-sip at cs.columbia.edu
subject: [p2p-sip] Comments on concepts-02

Note that the above doesn't actually work in some of the use cases, such as
the anonymous-communication scenarios or the overlay that requires initial
self-organization under ad-hoc network conditions and lacks a centralized
source of authority. Under certain circumstances, it might be suitable to do
something like generate randomized distinguished names and self-signed
certificates for those names. How shall we account for this in the draft?

--
Dean

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: swb at employees.org (Scott W Brim)
Date: Wed, 18 Oct 2006 11:07:36 -0400

> Peer/client can just downgrade the security level in these sitution.

This all makes sense, and should all be included in security
discussions -- not just in the concepts draft but in protocol drafts.
We need to ensure that the mechanisms _can_ provide the security
needed for global deployments, with the possibility of less overhead
in more casual environments.  That should all be explained (as above)
as background for mechanism selection.

swb

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 18 Oct 2006 10:10:13 -0500

I mentioned to Zhuxian privately that my understanding from yesterday's call 
is that the authors agree with his statement, and that Dean was likely 
documenting the issue for the mailing list so that we are all thinking about 
it, not just people on the call.

Thanks,

Spencer

From: "Scott W Brim" <swb at employees.org>

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 18 Oct 2006 08:59:15 -0700

X.509 for P2P-SIP is like butcher knife for tomato.

Even in known C/S deployments X.509 is rarely seen used with CPEs for
signaling or provisioning.

Peter

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 18 Oct 2006 15:42:49 -0400

> harden the vocabulary consensus, we can withdraw some or most of  

Yup. I am planning to remove all but those that people tell me are  
critical to keep.

> this relate to having multiple types of resource records?

Very good question. I didn't see any consensus on how to do this on
yesterday's call, so I am planning to leave things as is in the -03  
version.
[But folks, let's discuss so we can fix things for the -04 version!]

> Neighbor, as we did with other terms.

Yup.

> definitions have useful content, and I don't want to lose the "stored

On yesterday's call, I read the consensus as being to remove the second
definition, because the first definition subsumed it. So right now,  
this is
what I am planning to do.

I don't see this as a big loss, because "stored route" is just one  
more piece
of data about a user, and we don't have document that describes what  
this
might really look like yet.

> names. How shall we account for this in the draft?

[Disclaimer: I am a security neophyte, so take this response with a big
grain of salt.]

My view, which I tried to express yesterday, is that the use of such  
a centralized
authority is optional. In other words, if a P2PSIP Overlay doesn't  
want to use it
(because it wants to allow anonymous peers and/or is running under  
conditions
where contacting a central authority is not practical or desired),  
then it just doesn't.

I will try to add this somehow to the text above which you ascribe to  
Cullen.

- Philip

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 18 Oct 2006 23:10:28 -0500

On Oct 18, 2006, at 2:42 PM, Philip Matthews wrote:

> of data about a user, and we don't have document that describes  
> what this

I do see it as a major loss, because the "stored route" is the most  
important piece of data to have about a user. Without it, we have  
absolutely no means of ever contacting them.

--
dean

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 19 Oct 2006 09:58:47 -0400

On 19-Oct-06, at 00:10 , Dean Willis wrote:

>> definition, because the first definition subsumed it. So right  
>> now, this is

How about the following definition for "P2PSIP Resource (User) Record"?
This is a slightly modified version of the text of the first definition.
Does this satisfy your concern?

           A block of data, stored using the data
           mechanism of the P2PSIP Overlay, that includes information  
relevant to a specific
           resource. We presume that there may be multiple types of
           resource records. Some may describe
           routes to a P2PSIP Peer or Client at which the user or  
resource is presumed reachable
           (e.g., a "user routing record" like a SIP "Contact:").  
Others might store presence information.
           The types, usages, and formats of user records are a  
question for future study.

- Philip

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Thu, 19 Oct 2006 10:28:45 -0400 (EDT)

Node and peer definitions.

The concept draft considers 'peer' as an entity that participates in
the p2p network (routing decisions, storage) and equates 'peer' with a
'node'.

The peer typically means 'super node' in the unstructured P2P literature
and a 'node' in the DHT literature.

A 'node' encompasses both 'peer' and 'client' functionality in some
papers and architectures. See for example, "Understanding KaZaA" paper
where it is prefixed with 'super'-node and 'ordinary' node.

I think it will be helpful to make those distinctions a bit more clear in
the concepts draft.

Regards,
Salman

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 19 Oct 2006 11:01:20 -0400

> I think it will be helpful to make those distinctions a bit more  

As I see it, a key difference between a P2PSIP Overlay and some other  
P2P systems
is that we are not making the peer / super-peer distinction, but are  
allowing
peers with full functionality to lie behind NATs.  In other words
              "P2PSIP Peer"    !=   super-peer (or super-node), and
              "P2PSIP Client"  !=   peer (or ordinary node).

I think this is what you are driving at with your comments.
I will add some text to try to make this clear.

- Philip

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Thu, 19 Oct 2006 23:09:48 -0500

On Oct 19, 2006, at 8:58 AM, Philip Matthews wrote:

>           mechanism of the P2PSIP Overlay, that includes  
> information relevant to a specific

I like it.

Thanks.

--
Dean

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Fri, 20 Oct 2006 11:36:12 -0400 (EDT)

I want to clarify the relationship between a 'node' and the definitions of
'peer' and a 'client'.

In one of your earlier posts, you had mentioned that you have added the
following text to the concepts doc:

"(Note: The P2P literature often uses the term  "node" instead of "peer")"
https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/001497.html

I would rather say something like:

"Note: The P2P literature often uses the term "super-node" instead of a
"peer" and generally assumes that peers cannot be behind a NAT or a
firewall. There is no such restriction for a peer as defined in
this draft. Further, the P2P literature uses the term "ordinary-node" for
a "client".

regards,
Salman

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 20 Oct 2006 13:24:30 -0400

> this draft. Further, the P2P literature uses the term "ordinary- 

Yesterday, I added the following text to my working draft under the  
definition of
P2PSIP Peer:
           A notable property of P2PSIP Peers is that
           they can be fully functional peers while residing behind  
NATs. Contrast this with
           some other P2P systems which make a distinction between  
"peer" and "super-peer"
           (or "node" and "super-node") where the latter must have a  
public IP address.

I think this captures the first part of your comment (albeit in  
different words).
Do you agree?

As for the statement that client = ordinary-node, I am not sure that  
this is true.
It seems to me that in our architecture, a client has a more limited  
role than
a "ordinary-node" has in most P2P systems.

Anyone else care to comment on this?

- Philip

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Fri, 20 Oct 2006 14:29:19 -0400 (EDT)

> I think this captures the first part of your comment (albeit in

Yes.

> a "ordinary-node" has in most P2P systems.

I think of an "ordinary-node" as an entity that does not participate in
routing and storage functions which is similar to the definition of a
'P2PSIP client'. See for example "Understanding KaZaA" paper.

My worry is about the mixing of the term 'node' with 'peer' and 'client'.
Perhaps, there is no need for such a clarification. Maybe, others can
comment?

Regards,
Salman

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 20 Oct 2006 11:43:10 -0700

----- Original Message ----- 
From: "Salman Abdul Baset" <salman at cs.columbia.edu>
To: "Philip Matthews" <philip_matthews at magma.ca>
Cc: <p2p-sip at cs.columbia.edu>
Sent: Friday, October 20, 2006 11:29 AM
Subject: Re: [p2p-sip] Comments on concepts-02

> Perhaps, there is no need for such a clarification. Maybe, others can

There seems no need. 

'Peer' vs 'Client' seems like 'MAY' vs 'MUST' (RFC 2119).

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 20 Oct 2006 15:33:12 -0400

> Perhaps, there is no need for such a clarification. Maybe, others can

On the conference call on Tuesday, some people  were proposing
alternative names for the term "Client", since Peer and Client doesn't
mix very well, and Client makes people think of a SIP UAC.
However, none of the alternatives
seemed to resonate  with the participants on the  call. In the end,
someone  suggested a bar session in San Diego to try to come up with
alternative names.

Ignoring the names for now, are you happy with the definitions?

- Philip

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Sat, 21 Oct 2006 10:26:19 -0400

>'P2PSIP client'. See for example "Understanding KaZaA" paper.
I agree with Salman.
I don't see any difference between the concept of ordinary node and the
P2P SIP Client.

>Perhaps, there is no need for such a clarification. Maybe, others can
Well, currently we have not found good names for these terms most of us
are satisfied with. :-(

Thanks.

Eunsoo