Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.co m]

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Fri, 13 Jan 2006 14:50:32 -0500

PP:
 
Before becoming too abstracts, let us define what are those underlying
infrastructures clearly (i.e.., security, routing, others, etc.) that you
might have in your mind.
 
You have explained so many things, this is good. Now, it is the time, I
think, to put in a IETF draft listing those items with related problem
definitions and solution objectives.
 
Best regards,
Radhika

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of PP
Sent: Fri 1/13/2006 2:24 PM
To: Michael Slavitch; Benny Prijono; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com]

Quoted: "But first, let us build the underlying infrastructure that supports
this.  Let's stop pussyfooting around."
 
I agree with Michael <mailto:slavitch at gmail.com>  on putting "underlying
infrastructure" on the first place, before P2P and SIP, in my opinion. This
is why I've been curious and worry why nobody here so far would like to
address the "security" layer of the underlying infrastructure, which seems
to be the most bottom layer of the foundation above transport layers. 
 
Sorry, I must mention Skype again, but Skype did spend lots of (smart)
efforts on its security mechansim, though it is based on grandpa's
RSA-1536/2048 public-key cryptograph that consumes much network bandwidth on
key exchanging and negotiation among nodes, and not a little cpu time on
private-key related operations especially on the signup servers which are
responsible for signing node certificates. 
 
Without STRONG and EFFICIENT security, even 100% of SIP-related RFCs and
aboundance of features are placed upon the infrastructure, the network will
be severely criticized and challenged, won't it?

peter

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Fri, 13 Jan 2006 22:37:22 -0600

So far I've heard ideas ranging from replacing DNS with a global search 
mechanism to finding a way to make a SIP supergalaxy that includes all 
known federations, the GSTN/PSTN, and rogue black holes in its gravitic 
clutches.

I'm not committed to solving the general P2P problem at this time, and I 
have no intent to sponsor or support that work within the IETF right 
now. It's a fine IRTF problem, but it needs a lot more thinking before 
it becomes an IETF problem.

So I'd like to propose reducing the discussed scope to something I think 
is suitable for an IETF working group.

Mission: To apply P2P techniques for correspondent or resource discovery 
within a P2P federation for the establishment of SIP transactions 
between nodes of that P2P federation. This is an alternative to the 
"proxy routed" model of conventional SIP.

Assumptions:

1) Session establishment, capabilities negotiation, session termination, 
subscription, notification, messaging, and related functions 
traditionally performed using SIP will continue to be performed using SIP.

2) We will develop new protocol mechanisms for the purpose of 
correspondent (other users) or resource (NAT traveres, VM servers, etc.) 
discovery and declaration (insertion, publishing, whatever) within the 
P2P federation.

3) Some elements of each P2P federation MAY be rooted in the DNS such 
that they can be used for bootstrapping operations. However, a 
federation that is operating entirely in an isolated (or disconnected, 
or autonomous, whatever) mode will rely on alternate means of 
bootstrapping the federation based on the "zeroconf" work.

4) The DNS conditions of #3 will commonly be true when the P2P 
federation in question is not operating in isolation from the greater 
Internet.

5) The DNS conditions of #3 will by definition be true when there are 
communications originating from the greater Internet toward elements of 
the P2P federation.

6) Elements of the P2P federation will interact as conventional SIP UAs 
with non-P2P network nodes.

7) The identity of users or nodes will be expressed within a namespace 
defined at the federation level. It will not be unbounded.

8) The level of authenticity of identity will vary by the federation. 
However, we will define at least one mechanism that will provide 
assertion of identity having strength equivalent to that provided by the 
"SIP Identity Mechanism" RFC, perhaps by reusing some or all of the 
mechanism of that RFC.

Where do I think this sort of solution would be useful?

1) Self-organizing and highly available proxy farms, as opposed to the 
rigid hierarchical topologies of today's IMS.

2) Disconnected or partly-disconnected topologies such as those found in 
mesh networks, emergency response, battlefield, and other highly fluid 
environments.

3) Slightly coooperative communities of users distributed across the 
Internet (aka Skype-like communities).

4) Enterprise-like communities, both on private networks and on the 
greater Internet.

--
Dean Willis

---

From: lists at bulukucing.org (Benny Prijono)
Date: Sat, 14 Jan 2006 12:13:52 +0000

> is suitable for an IETF working group.

Agreed (completely). It was not my intention to burden IRTF 
researchers with developing something that is completely in different 
scope/assumptions that current works.

But I felt that goal is not too far/unreachable either. All we need to 
do, for now, is just to add couple more assumptions below between your 
item number 7 and 8.

7.5) Federations that are connected to Internet are expected to have a 
globally unique federation name/id.

7.6) P2P nodes MUST be able to associate P2P communications with the 
federation where the communication belongs. This MAY imply that the 
federation id is embedded in each P2P message.

That's all! Those assumptions may even be the case now, although 
perhaps not explicitly stated.

What do you or others think?

-benny

---

From: henry at pulver.com (Henry Sinnreich)
Date: Sat, 14 Jan 2006 17:53:57 -0600

I agree with Dean.

Besides, federations are not scalable and smack of cartel behavior, of
discrimination.

Bigcarrier.com will not federate with my home.net. 
They will not even answer my calls.

Thanks, Henry

-----Original Message-----
From: Benny Prijono [mailto:lists at bulukucing.org] 
Sent: Saturday, January 14, 2006 6:14 AM
To: Dean Willis
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Towards Reining In the Scope

-benny

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 16 Jan 2006 16:04:14 -0600

On Jan 14, 2006, at 6:13 AM, Benny Prijono wrote:

> 7.5) Federations that are connected to Internet are expected to  
> have a globally unique federation name/id.
>

This may be overspecified. What says there can't be multiple names  
for the federation? As long as it preserves a consistent namespace, I  
think we're ok.

> 7.6) P2P nodes MUST be able to associate P2P communications with  
> the federation where the communication belongs. This MAY imply that  
> the federation id is embedded in each P2P message.

Given that user identity is dependent on "federation  
identity" (assumption 7), I think this property is already preserved  
by the identity assertion of assumption 8.

>
>> 7) The identity of users or nodes will be expressed within a  
>> namespace defined at the federation level. It will not be unbounded.
>> 8) The level of authenticity of identity will vary by the  
>> federation. However, we will define at least one mechanism that  
>> will provide assertion of identity having strength equivalent to  
>> that provided by the "SIP Identity Mechanism" RFC, perhaps by  
>> reusing some or all of the mechanism of that RFC.
>

--
Dean

---

From: lists at bulukucing.org (Benny Prijono)
Date: Tue, 17 Jan 2006 00:15:43 +0000

Dean Willis wrote:
>> 7.5) Federations that are connected to Internet are expected to  have 
>> a globally unique federation name/id.
>>
> 
> This may be overspecified. What says there can't be multiple names  for 
> the federation? As long as it preserves a consistent namespace, I  think 
> we're ok.
> 

Right, okay.

I guess I was wrong (mainly because I thought a federation is 
synonymous with a p2p overlay). What I wanted say is there should be 
some kind of identification of which overlay a user belongs, so that 
it is possible to make communications between overlays.

But with federation, it is clear that communications between overlays 
are possible, so I guess this requirement is already implied in the 
assumptions.

It all make sense now.

-benny