Subject: RE: [P2PSIP] Re: HIP pros and cons

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 18 Dec 2007 16:12:19 -0500 (EST)

Skype does not have a distributed authentication mechanism. Their p2p 
solution is for search and selecting voice/video relays.
-s

On Tue, 18 Dec 2007, David Barrett wrote:

> The Skype outage demonstrates precisely the opposite of what you're
> claiming.  Rather, it shows that inappropriate use of decentralization turns
> minor spikes into fatal calamities due to congestion-collapse scenarios.
>
> Had they simply authenticated everything globally, then a spike in login
> requests would result in a slowdown of logins for an hour or so, and that's
> it.
>
> But because they built a totally unnecessary p2p solution, the spike caused
> *days* of instability.
>
> Skype is the very example of why we should build central authentication.
>
> -david
>
>> -----Original Message-----
>> From: Dan York [mailto:[email-masked]]
>> Sent: Tuesday, December 18, 2007 10:09 AM
>> To: Brian Rosen; 'Miika Komu'; 'Eric Rescorla'
>> Cc: [email-masked]
>> Subject: Re: [P2PSIP] Re: HIP pros and cons
>>
>> Two words: "Skype outage". As best we can understand, (a) is similar to
>> the architecture used by Skype. A Skype client must be able to communicate
>> with the authorization/enrollment servers to be able to access the Skype
>> P2P cloud. When those servers then became inaccessible, the scenario
>> unfolded that led to the 2-day outage.
>>
>> I don't want to debate Skype's outage, but my point is that I would think
>> we want to avoid anything that introduces a "single point-of-failure"
>> which (a) seems to me to do. It seems to me to be the opposite of what we
>> are trying to do with P2P SIP.
>>
>> (So I agree with the comments from Brian and EKR that (a) is not
>> advisable.)
>>
>> My 2 cents,
>> Dan
>> --
>> Dan York, CISSP, Director of Emerging Communication Technology
>> Office of the CTO    Voxeo Corporation     [email-masked]
>> Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
>> Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
>>
>> Bring your web applications to the phone.
>> Find out how at http://evolution.voxeo.com
>>
>>
>>
>> -----Original Message-----
>> From: "Brian Rosen" <[email-masked]>
>>
>> Date: Tue, 18 Dec 2007 12:36:34
>> To:"'Miika Komu'" <[email-masked]>, "'Eric Rescorla'"
>> <[email-masked]>
>> Cc:[email-masked]
>> Subject: RE: [P2PSIP] Re: HIP pros and cons
>>
>>
>> <as individual>
>> While a) proves your point, I think we're not really interested in a
>> solution that requires the enrollment server to be reachable by any peer
>> to
>> determine admittance to the overlay.  It's one thing to need to be able to
>> reach the enrollment service once to enroll; it's quite another to require
>> it to be available to join the overlay.
>>
>> Brian
>>
>>> -----Original Message-----
>>> From: Miika Komu [mailto:[email-masked]]
>>> Sent: Tuesday, December 18, 2007 12:29 PM
>>> To: Eric Rescorla
>>> Cc: [email-masked]
>>> Subject: Re: [P2PSIP] Re: HIP pros and cons
>>>
>>> On Mon, 17 Dec 2007, Eric Rescorla wrote:
>>>
>>> Hi Eric,
>>>
>>>> At Mon, 17 Dec 2007 18:04:42 +0200 (EET),
>>>> Miika Komu wrote:
>>>>> The same way as without public keys. I fail to see the problem here.
>>>>
>>>> I don't even understand what you're proposing any more.
>>>>
>>>> If you want to describe a specific proposal, I'll be happy to address
>>>> its merits.
>>>
>>> This is one example how it could work:
>>>
>>> You connect with your web browser to the enrollment server. The DNS
>>> contains the HIT of the enrollment server, which triggers a base
>>> exchange with the enrollment server and makes the HTTP(S) connection to
>>> use HIP. You fill in a web form and give your bank card number for the
>>> enrollment server. The web server software stores the HIT and the bank
>>> card number for enrollment purposes. From this on, we could have two
>>> alternative design solutions:
>>>
>>> a) When the new peer joins the network, DHT nodes that have been already
>>>     accepted in the network will ask the enrollment server if the new
>> peer
>>>     has enrolled successfully.
>>> b) The enrollment server could give the new peer a certificate which the
>>>     peer could be using directly when actually joining the DHT.
>>>
>>> I believe approach (a) proves my original point that you can use
>>> host-generated DHT identifiers without certificates.
>>>
>>> --
>>> Miika Komu
>> http://www.iki.fi/miika/
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
>

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

---

From: "David Barrett" <[email-masked]>
Date: Tue, 18 Dec 2007 13:29:34 -0800

Ah, I'm sorry, you're right -- authentication wasn't the problem, it was
that the network couldn't reform after the loss of all the supernodes.

So the specific lesson from Skype isn't about lack of centralized
authentication capacity (which -- you're right -- had nothing to do with the
problem), but rather the unnecessary use of supernodes for search/rendezvous
leading to a congestion collapse scenario.

-david

> From: Salman Abdul Baset [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2007 1:12 PM
> To: David Barrett
> Cc: [email-masked]