Subject: FW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

From: "Michael Slavitch" <[email-masked]>
Date: Sun, 8 Apr 2007 15:16:09 -0400

"Isn't IMS all about everything in the network and the endpoints are
under total control?"

Yes.  However I fear that the flipside is no better, a pure-peer
environment without any control may create a tragedy of the Internet
commons, one that expects something for nothing without boundries or
checks and balances. There is a vast gulf between greedy Stalinist
totalitarianism and doctrinaire anarchy.

"Mobile operators may see the light and adopt P2P, but would it be IMS
as it is defined today?"

Certainly not.  IMS as it stands today will go the way of FDDI and ATM
et al.
Too expensive, too complex, and not enough value.

What a P2P successor could be called depends on who is doing the
marketing.  Gigabit Ethernet isn't coax CDMA either.  Just try buying
a token-ring or FDDI card.   If I had the answers to these questions
they'd be in a set of power-point slides doing the VC samba on Sand
Hill Road.

The mobiles will adopt it under the following circumstances:

1. It puts the issue of recurring revenues to bed long enough for a bond
issue.
2. It permits a level of certainty regarding customer retention.
3. It allows them to offer different services at different prices to
    different people.
4. It allows them to shrink their OPEX enough to make more and charge
less.
5. It keeps E911/DHS/FBI/NSA happy enough.
6. It allows them to do what they do best, bury costs in ongoing
charges and fees.

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. 

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 9 Apr 2007 12:57:11 -0700

>However I fear that the flipside is no better, a pure-peer environment
>without any control may create a tragedy of the Internet commons, one
>that expects something for nothing without boundries or checks and
>balances.

100% agreement here.

The DHT overlay and SIP part require strong identity: The krypto keys
issued by the owner of the P2P SIP network. Not less but also not more.

To prevent Sybil attacks, the certificate issuer can use various options
that go beyond our topic discussed here.

Henry

-----Original Message-----
From: Michael Slavitch [mailto:[email-masked]] 
Sent: Sunday, April 08, 2007 2:16 PM
To: [email-masked]; P2PSIP Mailing List
Subject: FW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

-- 

This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely
those of the author and may not represent those of Objectworld
Communications Corp.

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Apr 2007 17:12:36 -0500

> issued by the owner of the P2P SIP network. Not less but also not  

There are, of course, people interested in "ownerless" P2PSIP overlays.

A model of how this might work uses a "first come, first served"  
model, something like:

An "ownerless" overlay exists at overlay.example.org. It uses a  
distributed file-store model to store public credentials.

Bob makes himself a self-signed cert.

Bob uses this self-signed cert to enroll in the overlay, which works  
as long as there is nobody else named [email-masked] (first  
come first severd). As a result, Bob's public cert is stored in the  
overlay.

Bob then inserts into the overlay using his private key, which  
establishes that he is the previously registered Bob.

And people talk to him.

Now, nothing says I can't come along and register as Henry, if Henry  
hasn't already done so. So the names don't really "mean" anything --  
they're just index values that are human memorable so you can know  
that the Henry you talk to today is the same as the Henry you talked  
to last week.

Now, if the whole overlay resets such that the name-enrollments are  
lost, everybody gets to re-enroll, and there's a land-rush on being  
called Henry instead of Bob (or vice-versa).

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2007 19:51:20 -0400

Dean,

In such a scenario, I gather there is no way for an outside caller to 
know that the Henry today is based on a different enrollment than the 
Henry from yesterday?

	Paul

Dean Willis wrote:
> A model of how this might work uses a "first come, first served" model, 
> something like:
> 
> Bob uses this self-signed cert to enroll in the overlay, which works as 
> long as there is nobody else named [email-masked] (first come 
> first severd). As a result, Bob's public cert is stored in the overlay.
> 
> they're just index values that are human memorable so you can know that 
> the Henry you talk to today is the same as the Henry you talked to last 
> week.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2007 19:54:24 -0400

BTW,

This sounds very much like the a server for nicknames that seems to be a 
requirement for chat proposal over in SIMPLE.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Apr 2007 19:13:58 -0500

On Apr 9, 2007, at 6:51 PM, Paul Kyzivat wrote:

> Dean,
>
> In such a scenario, I gather there is no way for an outside caller  
> to know that the Henry today is based on a different enrollment  
> than the Henry from yesterday?
>

Well, one would hope the overlay was sufficiently stable that Henry  
lasts indefinitely, something like one of those army Meals Ready to  
Eat things (three lies in one box, we always called 'em. Not a Meal,  
not Ready, and you wouldn't want to Eat it.).

Remember, enrollment is not registration. It persists as long as the  
distributed database doesn't get nuked or the enrollment isn't  
explicitly revoked.

--
Dean

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Tue, 10 Apr 2007 09:56:19 +0200

> [discussion about unique nicknames and their registration]
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
discusses an interesting idea. It goes like this:

- every user has a globally known nickname, which isn't
necessarily unique. 
- To ensure uniqueness, every user has some sort of public key.
It is not memorable (a string of hex), though.
- If I have different users with the same nickname in my address book,
I'd locally assign different 'petnames' to them. 

This scheme has some weaknesses, though. You would have to put
your nickname and key on you business card (and worse, read the
key from a business card and enter it into the client). It doesn't fit
too well into SIP messages either (sip:nickname?[email-masked]?)

I'm not sure if it has been discussed already.

Wolfgang

(sorry about the long sig, EU regulations require it)
--
T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*,
Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG

---

From: "Michael Slavitch" <[email-masked]>
Date: Tue, 10 Apr 2007 11:21:01 -0400

"This scheme has some weaknesses, though. You would have to put
 your nickname and key on you business card (and worse, read the 
 key from a business card and enter it into the client). It doesn't fit
 too well into SIP messages either (sip:nickname?[email-masked]?)"

Smartcard-enabled business cards, like hotel room pass keys, solve
this issue and more, and many PC's support smart-card readers.  Other
solutions for this include using a bar code on the back of the card,
bar code readers are cheap too.  Many people use OCR for scanned
business cards already,  which is fraught with errors, scanning and
reading a bar-code is easy.  If the identity is a machine-readable key
use a machine-readable card to solve the problem. They are cheap.

Michael Slavitch              
Lead, Technology Initiatives
[email-masked]

-----Original Message-----
From: Beck01, Wolfgang [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 3:56 AM
To: [email-masked]; [email-masked]
Subject: AW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Wolfgang

--

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 10 Apr 2007 10:58:34 -0700

Actually, I believe Dean's idea makes sense without any server and
ownership - just like in http://openid.net/ 

Could this concept of lack of ownership in http://openid.net/ be applied
to ownerless p2p systems?

Ownerless P2P systems would be a powerful and complementary alternative
to service provider P2P. What do you think?

Thanks, Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 4:54 PM
To: Dean Willis
Cc: Henry Sinnreich; [email-masked]; P2PSIP Mailing List
Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

BTW,

	Paul

> A model of how this might work uses a "first come, first served"
model, 
> Bob uses this self-signed cert to enroll in the overlay, which works
as 

> they're just index values that are human memorable so you can know
that

---

From: "Michael Slavitch" <[email-masked]>
Date: Tue, 10 Apr 2007 11:07:49 -0400

>You would have to put
> too well into SIP messages either

reading a bar-code is easy.

M

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Wed, 11 Apr 2007 09:52:13 +0200

Henry wrote:
> 
> Actually, I believe Dean's idea makes sense without any 
> server and ownership - just like in http://openid.net/ 
Openid relies on the DNS to get unique user ids, it's not exactly ownerless.

> > called Henry instead of Bob (or vice-versa).
The land-rush is an inevitable result of using a human-memorable name as key. If we
are using something different, the problem will go away. Theoretically, the public
key of a user is a good candidate. In practice, we might use something shorter
for routing (and business cards), like the user name plus some fingerprint of
the public key .

The result of the P2PSIP user location would be a list of candidate pairs,
(IP addresses, public key). The calling UA would pick the IP address with
the public key of the user I wanted to call:

henry?<public key fingerprint of henry sinnreich, adobe>@overlay.example.org
-> [(10.0.0.1, <full public key of henry sinnreich, adobe>),
   (10.1.0.100, <full public key of some other user having the same fingerprint>]
-> send INVITE to 10.0.0.1

If the public keys get signed in the fashion of PGP, the scheme would
be ownerless.

Wolfgang