RE: [P2PSIP] Re: HIP pros and cons

["David Barrett" <[e-mail]>]

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

> -----Original Message-----
> From: Salman Abdul Baset [mailto:[e-mail]]
> Sent: Tuesday, December 18, 2007 1:12 PM
> To: David Barrett
> Cc: [e-mail]
> Subject: RE: [P2PSIP] Re: HIP pros and cons
> 
> 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:[e-mail]]
> >> Sent: Tuesday, December 18, 2007 10:09 AM
> >> To: Brian Rosen; 'Miika Komu'; 'Eric Rescorla'
> >> Cc: [e-mail]
> >> 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     [e-mail]
> >> Phone: [phone]  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" <[e-mail]>
> >>
> >> Date: Tue, 18 Dec 2007 12:36:34
> >> To:"'Miika Komu'" <[e-mail]>, "'Eric Rescorla'"
> >> <[e-mail]>
> >> Cc:[e-mail]
> >> 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:[e-mail]]
> >>> Sent: Tuesday, December 18, 2007 12:29 PM
> >>> To: Eric Rescorla
> >>> Cc: [e-mail]
> >>> 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
> >>> [e-mail]
> >>> https://www1.ietf.org/mailman/listinfo/p2psip
> >>
> >>
> >> _______________________________________________
> >> P2PSIP mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/p2psip
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >


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