Subject: [p2p-sip] what's wrong with DNS?

From: adamfisk at gmail.com (Adam Fisk)
Date: Sun, 19 Nov 2006 22:51:32 -0500

I had a conversation with Paul Francis at the recent networking conference
at NYU.  I brought up p2p SIP and the implementation of it I've been working
on, and he said "What's wrong with DNS?"  Specifically, with dynamic DNS.  I
didn't understand his point at first because my work incorporates HTTP web
servers, and I thought he missed that you still need SIP/STUN/TURN/ICE to
negotiate the NATs.  He was talking about for the registrars, though.  If
your registrar goes down for, say, sip:afisk at mysubdomain.p2psip.org, and I
get a new one, why not just use dynamic DNS to remap
mysubdomain.p2psip.orgto the new registrar?

It was something I hadn't thought about before.  Has it been discussed
here?  Granted, there's a lag to the DNS updating, but what if you give each
node a couple of sudmomains and register in a couple of places?  Also, is
churn really high enough to make the lag a major concern?

It's certainly a far simpler solution to the problem, and it would reduce
call latency tremendously in the typical case over a DHT lookup.  Apologies
if this has been covered in detail.

Thanks.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061119/1b8a294f/attachment.html

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Mon, 20 Nov 2006 00:30:05 -0800 (PST)

> your registrar goes down for, say,
> sip:afisk at mysubdomain.p2psip.org, and I

Also, it is entirely possible to build a P2P system
that simply let you register names in a subtree of the
DNS. For example, the PNRP feature in Vista allows
each Vista host to publish a name of the form
"JohnDoe.pnrp.net", or a secure variant thereof,
according to Noah Horton's blog
(http://blogs.msdn.com/noahh/archive/2006/08/23/715894.aspx).
Once you can publish a DNS name, running SIP appears
rather simple, right?

-- Karst

____________________________________________________________________________________
Sponsored Link

$420k for $1,399/mo. 
Think You Pay Too Much For Your Mortgage? 
Find Out! www.LowerMyBills.com/lre

---

From: ggb at tid.es (Gustavo García Bernardo)
Date: Mon, 20 Nov 2006 11:30:17 +0100

> > mysubdomain.p2psip.orgto the new registrar?

That solution continues being centralized (you are only changing the
registrar when the main goes down), you aren't getting the advantages of P2P
like zero infrastructure, load distribution among nodes, working in
isolated/ad-hoc environments... 

> Once you can publish a DNS name, running SIP appears

As far as I know, PNRP uses a DHT like algorithm.  PNRP doesn't register
anything in DNS despite of the fact that it employs IDs like DNS ones
(subdomain.domain).

> -- Karst

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

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Mon, 20 Nov 2006 07:14:33 -0800 (PST)

> anything in DNS despite of the fact that it employs

Sure, but why is that a problem? Suppose that your
implementation of DHT allows for the participants to
publih names like
<some-peer-name>.<DHT-specific-domain>, and to resolve
them using the standard "getaddrinfo" API. You get a
system in which registration is effectively
peer-to-peer, but where the code is very much
compatible with a standard DNS based SIP routing. 

You also get a very neat solution to the "multiple
DHT" issue: just make sure that each
"DHT-specific-domain" incorporates a couple of
gateways to the DNS, so that requests by non-DHT aware
hosts can be resolved. If you want operation on
isolated subnets, you may also incorporate a gateway
with mDNS/LLMNR.

-- Karst 

Degrees online in as fast as 1 Yr
MBA, Bachelor's, Master's, Assoc
http://yahoo.degrees.info

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Mon, 20 Nov 2006 10:41:59 -0500

No -- I'm talking about continuing to have non-firewalled nodes act as
registrars and proxies.  So, you still have a voluntary, fully distributed
system.  In fact, it would be just as decentralized as the current vision
for p2p SIP, except it would use dynamic DNS instead of a DHT.

-Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061120/d10de158/attachment.html

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 20 Nov 2006 15:08:59 -0500

Adam:

Are you suggesting that the P2PSIP Peer  Protocol (as described in
draft-willis-p2psip-concepts-03) could be a combination of SIP and  
dynamic DNS?
Or are you suggesting that we use the existing DNS and SIP  
infrastructure
in some P2P manner?
Perhaps you could go into a bit more detail on how all this would work?

- Philip

On 19-Nov-06, at 22:51 , Adam Fisk wrote:

> I had a conversation with Paul Francis at the recent networking  
> conference at NYU.  I brought up p2p SIP and the implementation of  
> it I've been working on, and he said "What's wrong with DNS?"   
> Specifically, with dynamic DNS.  I didn't understand his point at  
> first because my work incorporates HTTP web servers, and I thought  
> he missed that you still need SIP/STUN/TURN/ICE to negotiate the  
> NATs.  He was talking about for the registrars, though.  If your  
> registrar goes down for, say, sip:afisk at mysubdomain.p2psip.org, and  
> I get a new one, why not just use dynamic DNS to remap  
> mysubdomain.p2psip.org to the new registrar?
>
> It was something I hadn't thought about before.  Has it been  
> discussed here?  Granted, there's a lag to the DNS updating, but  
> what if you give each node a couple of sudmomains and register in a  
> couple of places?  Also, is churn really high enough to make the  
> lag a major concern?
>
> It's certainly a far simpler solution to the problem, and it would  
> reduce call latency tremendously in the typical case over a DHT  
> lookup.  Apologies if this has been covered in detail.
>
> Thanks.
>
> -Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061120/30c2446b/attachment.html

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 20 Nov 2006 15:52:51 -0800

>>What's wrong with DNS?

> you aren't getting the advantages of P2P
Correct.

P2P overlays are supposed to work even when disconnected from the 
big Internet and besides, have their own name space.

Peers can act as proxies to connect the overlay to DNS.

DNS needs some improvements too as argued in 

http://codeen.cs.princeton.edu/codns/ 

Thanks Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Gustavo Garc?a Bernardo
Sent: Monday, November 20, 2006 4:30 AM
To: 'Karst Bjorgson'; 'Adam Fisk'; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

G.

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 20 Nov 2006 16:19:23 -0800

>except it would use dynamic DNS instead of a DHT

This is a terrible idea.

P2P overlays are supposed to work even when disconnected from the big Internet and besides, have their own name space.

Peers can act as proxies to connect the overlay to DNS and ENUM. 

(BTW: In the trapezoid model, adding the outgoing SIP proxy lookup to an ENUM lookup gives you total of 6 (six) DNS lookups).

http://codeen.cs.princeton.edu/codns/ <http://codeen.cs.princeton.edu/codns/> 

Thanks, Henry

________________________________

From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Adam Fisk
Sent: Monday, November 20, 2006 9:42 AM
To: Gustavo Garc?a Bernardo
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

No -- I'm talking about continuing to have non-firewalled nodes act as registrars and proxies.  So, you still have a voluntary, fully distributed system.  In fact, it would be just as decentralized as the current vision for p2p SIP, except it would use dynamic DNS instead of a DHT. 

-Adam

On 11/20/06, Gustavo Garc?a Bernardo <ggb at tid.es> wrote:

> > sip:afisk at mysubdomain.p2psip.org , and I

G.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061120/4dbd40ac/attachment-0001.html

---

From: saikat at cs.cornell.edu (Saikat Guha)
Date: Mon, 20 Nov 2006 20:07:30 -0500

On Mon, 2006-11-20 at 16:19 -0800, Henry Sinnreich wrote:
> P2P overlays are supposed to work even when disconnected from the big
> Internet and besides, have their own name space.

Even P2P overlays need some way to bootstrap in disconnected networks.
While DNS _typically_ bootstraps with hardcoded IP addresses of the 13
root servers, it can bootstrap in a disconnected scenario with a link
level broadcast. See Apple's rendezvous/zero-conf protocol and mDNS.

-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061120/dfec6988/attachment.bin

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 20 Nov 2006 22:14:24 -0500

DNS was designed in the days when long-term store was scarce and so
was bandwidth. Technology was difficult and obtuse, with the number of
human implementors measured in the hundreds, and the number of users
in the thousands. I remember that because I was there. There was no
other way to pass this data. Something had to be first and that was
DNS, which reflected the times and the organizations that invented it
in the first place.

Those days are long gone now in the days of the $20 grocery-store 2G
flash RAM, millions of implementors, and billions of users.

Today's Internet is a consumer-driven multi-modal world which has no
patience for that.
To cripple bootstrap by leashing it to creaky DNS is a disservice to
the future.

Bootstrap should have some criteria requirements for some obvious
things such as satisfying the security AD but the actual
implementation should allow for individual implementations that
reflect a rapidly changing modern world.

Hardcoding is a quaint way of solving the problem, and it is far too
easy for protocol engineers to design in a vacuum. When a single
handheld device can receive inputs by SMS, email, walled and unwalled
IP,  and HTTP the number of sources for a bootstrap is openended and
impossible to mandate without creating limitations on functionality
and usefulness in a hybridized multi-modal world..

A mime message, encrypted by a private key known to that device, could
contain a myriad number of bootstraps, be they DNS, hardcoded IP (IPV4
or IPV6? Which?), local names,  peer names, SMS addresses,sip uris,
whathaveyou.  A list based on operating criteria, that can evolve over
time.

This message, more 'carrier pigeon'  than boostrap, can be delivered
via a variety of means, including via C/S SIP or stored from a
previous DHT. A primitive form of unencrypted messaging is called
'paper'.

In this environment a 'friend' network, of names associated with keys,
could be seeded entirely by SMS messages and never ever need DNS,, and
it works when zeroconf fails, which is often.  It could later use
broadcasts or multicasts to find other 'friends', using one of a
variety of techniques, zeroconf being one.

Create the requirements for the bootstrap that guarantee security,
functionality and interopability.  Create the list of appropriate
beacons, allowing room for more in the future.

Then stop, please.

---

From: Mehdi.Mani at int-evry.fr (Mehdi MANI)
Date: Tue, 21 Nov 2006 06:08:33 +0100

Hi Adam,

According to your suggestion two approaches are possible:
Firstly, the super nodes (or at least the boot-strapt nodes) support DNS
functions instead of DHT.
Secondly, the super nodes only function as registrar and proxy and in addition
some dynamic DNS servers be implemented. In this case, when a node whant to be
localized should contact a DNS, then DNS lets it know on which super node (as a
registrar) it should register its ID. And the same process should be done for a
query.

If you consider the first approach, what would be advantage? DHT works much more
better in that case because it is able to organize efficiently the registery
information.
And the second approach, will be something like the architecture of Napster that
was not scalable enough.

-Mehdi

> > anything in DNS despite of the fact that it employs IDs like DNS ones

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 20 Nov 2006 21:32:39 -0800

> And the second approach, will be something like the architecture of 

If it weren't for the lawsuits, nobody would have ever bothered with 
decentralized indexing.  Scalability was not the problem.

I like Adam's idea.  DNS works and scales in the real world; it's a 
proven solution.  For totally disconnected, ad hoc networks, perhaps we 
should start a P2P-DNS WG and solve that problem by itself.  That's 
bigger than SIP and might benefit from being separated out.

-david

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 09:21:17 -0500

Agree

Let's stick to things we know will work.  

Brian

> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of David Barrett
> Sent: Tuesday, November 21, 2006 12:33 AM
> To: Mehdi MANI; Adam Fisk

---

From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 21 Nov 2006 09:45:01 -0500

Hello;

> Let's stick to things we know will work.

I am not sure what is actually being proposed here, so I am not sure  
what you are saying will work.

To use Dave Singer's mDNS ideas for LAN resource discovery ? Cool.  
There are RFC's - apply.

To extend these ideas, maybe using P2P application layer multicast,  
to the wide area - sounds
like an interesting idea, and could be very cool. I could see this  
being used all over the place.

To expand the core DNS into P2P discovery - i.e., to have P2P RR's  
added into the
root servers ? Is not a good idea, and (I dare say) will not happen  
in the IETF.

I think Michael Dillon put it well in DKIM :

"if someone wants to leverage the DNS protocol and
DNS server software in order to operate a global
distributed database, then there are no barriers to
doing this on ports other than port 53. The IETF barely
needs to be involved at all other than defining the
new RR.

But when someone suggests that port 53 servers should
all support some new RR or anything else that is new,
now we are talking about a major upgrade to the Internet's
mission critical infrastructure impacting millions of
people worldwide. Here the IETF has a major role to play
and the IETF should tread very carefully."

So, I would like to see a clearer description of just what path is  
actually being proposed here.

Regards
Marshall

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 10:01:53 -0500

I meant use of existing mechanisms such as DNS rather than inventing new
ones.

I think the dynamic DNS idea can work.  I think simpler NAPTR based
mechanisms can work (especially if, as I think we're heading for, we have a
"domain" for the community the P2P operates over, where we support multiple
such domains (the concepts document calls these "overlay IDs").

I'm sanguine about multicast mechanisms because multicast in general doesn't
work across the Internet :(

I don't think we need new RRs.

Brian

> From: Marshall Eubanks [mailto:tme at multicasttech.com]
> Sent: Tuesday, November 21, 2006 9:45 AM
> To: Brian Rosen
> Cc: 'David Barrett'; 'Mehdi MANI'; 'Adam Fisk'; p2p-sip at cs.columbia.edu

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 21 Nov 2006 10:39:05 -0500

We've actually discussed this several times at several ad-hocs, and
the general conclusion of the group was that dynamic DNS did not meet
the needs on several fronts:

1) mobility. We want to preserve the (rapid) update ability of a SIP
registrar, for example going from home to the office to the mobile
phone in a period of a few minutes. There is a great deal of concern
if dynamic DNS could meet these requirements.

2) it still requires centralized infrastructure, in the sense that
some known entity is the server -- even if that isn't a fixed server
but one of the "peers", it will be doing much of the work.

3) if it is using the existing DNS approach, it requires Internet
connectivity -- not very useful for disconnected scenarios.

The charter that went around for several months was a reflection of
this -- it was explicitly ruled out of scope as item 4. It is very
interesting as an approach for resolution, but doesn't meet the needs
of the folks looking at this WG because of the points above.

David

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 21 Nov 2006 08:29:44 -0800

I agree with Michael. 

Research folks are reporting on why and how to replace the DNS. 
Here is some good weekend reading to start with :-)

http://www.acm.org/sigs/sigcomm/sigcomm2004/papers/p292-ramasubramanian1
111.pdf 

After homework - reading this paper, we can formulate something better
for p2p bootstrap.

Thanks, Henry

-----Original Message-----
From: Michael Slavitch [mailto:slavitch at gmail.com] 
Sent: Monday, November 20, 2006 9:14 PM
To: Saikat Guha
Cc: Henry Sinnreich; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

Then stop, please.

> > P2P overlays are supposed to work even when disconnected from the
big

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 12:24:33 -0500

I was travelling yesterday, so my apologies for not responding.  Comments
are inline.

> if dynamic DNS could meet these requirements.

This is my biggest area of concern too.  Just the latency of updates.  In my
own use of dynamic DNS, I've known updates to happen extremely quickly.
I've heard of them taking more like 7 minutes to fully propagate though.  To
me this is less a question of mobility and more a question of churn.  How
often are the registrars going up and down?  I think you can influence this
in many ways as well, such as running daemon processes automatically on
system startup.

> but one of the "peers", it will be doing much of the work.

Correct.  The simplest way to do it would be to just use existing dynamic
DNS providers out there.  I suspect the load on these servers is extremely
small because of the "distributed" nature of DNS, but I've never run them
myself so can't say for sure.  You'd still be decentralizing the heavy
lifting of the registrars and SIP proxies, and that certainly seems like the
bulk of the work.

> connectivity -- not very useful for disconnected scenarios.

I certainly agree with you there, although I must say I'm confused on
exactly how and where this system would ever realistically be deployed in
disconnected scenarios.  I can see it for disaster relief, and I've worked
extensively with disaster relief groups at the DoD and elsewhere around how
to use SIP in those scenarios, but I think that's a miniscule fraction of
the realistic use cases.  It's a cool one to think about, but I'm not
convinced on the practicality of it.

> of the folks looking at this WG because of the points above.

I just read that.  I have to apologize because I only participate in the
group intermittently, and I'm certainly not trying to derail the WG
efforts.  I'm not at all sure why it's out of scope though.  If it's a
simpler system that works better for 98% of the realistic use cases, it
seems in scope to me.  Does it work better is the real question, and your
point #1 is the biggest issue in my mind.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/1c6eb228/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 12:48:49 -0500

I don't want to beat a dead horse, but:
1. Most of the dynamic DNS implementations I'm familiar with have update
times measured in a couple of minutes.  It's not "real time", but it's
pretty short.  This is reflected in the TTL of the answer.

2. Any form of DNS requires a set of caching resolvers and authoritative
servers.  If you call that "centralized", then you are correct.  I always
think of DNS as being very decentralized except for the roots, and most
implementations I know work if connection to the root is lost, but the
answer is in the cache. 

3. If you combine a short TTL with a disconnected server, then caching
doesn't work; resolvers need access to the authoritative servers (plural)
that provide the data.  It is servers plural, not singular.  I think this is
the reason dynamic DNS is not the best choice, although we may have been
hasty in coming to that conclusion.

4. I think identifiers in these systems are in the form of user at domain,
where domain is the "Overlay Id".  Humans may never see that, but it's
there.  Resolving "domain" to at least a starter set of peers has to happen
somehow.  We have only a few tricks in our bag for that:
	a. Configuration
	b. Multicast
	c. DNS
Are there other mechanisms?  There are multiple configuration mechanisms,
but they all depend on static information, not dynamic, learned data.

Agree that we explicitly declared dynamic DNS and multicast out of scope.
That leaves basic DNS and Configuration.

When networks become disconnected, local caching resolvers work.  If you are
within a domain, and you want a DNS answer from that domain, it works.  

Many existing systems work by configuration.  I'd rather not do that.

Brian

> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On Behalf Of
> David A. Bryan
> Sent: Tuesday, November 21, 2006 10:39 AM
> To: Brian Rosen
> Cc: Marshall Eubanks; p2p-sip at cs.columbia.edu; Mehdi MANI
> > > >>> And the second approach, will be something like the architecture
> of
> > > >>> Napster that
> > > >>> was not scalable enough.
> > > >>

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 12:46:38 -0500

> I meant use of existing mechanisms such as DNS rather than inventing new

That's certainly my thinking in bringing this up.  Just do what's easy and
knock off the biggest win -- a low-cost SIP infrastructure.

As I see it, this approach has the following advantages:

1) Zero changes to proxy servers and registrars.
    - Non-firewalled peers become proxies and registrars just like before.
They should be able to literally use the same code as the open source
proxies and registrars out there, though, because nothing changes in the
lookup.

2) Eliminating the most complicated part of the current architecture -- the
DHT.  It's also the thorniest to standardize.

3) Lower latency for completing calls.  No more waiting around for the DHT
to respond.  Call completion happens just like it does with any other SIP
call (if the DNS is up-to-date -- more below).

Then there are the disadvantages:

1) Delay of DNS propagation when registrars go down or clients move.  I
think this is the toughest to get a good read on because I don't know how it
would play out in the field.

2) You'd need to run a dynamic DNS *client* on every node (at least that
seems like the best approach to me).

3) You'd be relying on some servers out there to do the dynamic DNS.
Possibly existing dynamic DNS providers?

4) Doesn't work in completely disconnected scenarios.

Keep in mind I'm not necessarily advocating this shift, but it certainly
resonated with me once I realized the full implications of Paul's question
to me the other day.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/1e4764fa/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 13:00:07 -0500

You are going out way too far for me.

I want a simple mechanism to learn peers to get started (bootstrap), not a
replacement for the DHT.

The fundamental problem I think you have is that if you have a classic
registrar, if that registrar fails, you are out of luck.  The DHT stays
running.  I don't think you are going to find a lot of support for this line
of thinking.  

Brian

  _____  

From: Adam Fisk [mailto:adamfisk at gmail.com] 
Sent: Tuesday, November 21, 2006 12:47 PM
To: Brian Rosen
Cc: Marshall Eubanks; David Barrett; Mehdi MANI; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

-Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/2e677995/attachment.html

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 13:30:14 -0500

>  You are going out way too far for me.

I'm again just tossing around ideas here, but from a more traditional
perspective outside of this working group, I'd argue the dynamic DNS
approach is the much less "far out" of the two.  That's what attracted me to
it in the first place.  You're using off-the-shelf working technology to
solve a known problem.  The p2p part of SIP becomes just having some way to
find all the non-firewalled nodes out there running the service, a problem
you have in any scenario.

> running.  I don't think you are going to find a lot of support for this line

I'd say more precisely that there are non-firewalled nodes out there that
stay running.  If you lose your connection to a registrar, you just connect
to another registrar.  If you lose your connection to a DHT node, it's the
same thing -- you just connect to another one.

The fundamental robustness comes from the fact that there will always be
non-firewalled peers who can connect you to the network, not that they're
structured into a DHT or not.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/4016256d/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 13:53:44 -0500

I don't know what you are smoking.

The point of a Distributed Hash Table is that no one node has the whole
thing, and the network can maintain the database if individual nodes go
down.  Any form of classic SIP registration doesn't do anything like that;
you are registered at ONE registrar, and if that registrar becomes
unavailable, you can't get calls.   Commercial implementations often use
redundant databases and proxies to make their registration service reliable,
but you can' use classic registration to do the kind of peer to peer things
a DHT will do.

The problem isn't necessarily you losing connection to a registrar, it's
your peer being unable to connect to your registrar and thus being unable to
contact you.

The fundamental robustness is that the database is distributed and
replicated; any node can get you to any part of the database even when peers
come and go.

Brian

  _____  

From: Adam Fisk [mailto:adamfisk at gmail.com] 
Sent: Tuesday, November 21, 2006 1:30 PM
To: Brian Rosen
Cc: Marshall Eubanks; David Barrett; Mehdi MANI; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

 
-Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/f1c36622/attachment-0001.html

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 21 Nov 2006 13:02:48 -0600

Hi, Brian,

I'm not sure who else may have misunderstood - when I saw your note that said

> Let's stick to things we know will work.  

I thought you were talking about a replacement for the DHT, and others may have as well.

Sorry for (my) misunderstanding - I was confused by the thread you were following up in.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Brian Rosen 
  To: 'Adam Fisk' 
  Cc: p2p-sip at cs.columbia.edu ; 'Mehdi MANI' 
  Sent: Tuesday, November 21, 2006 12:00 PM
  Subject: Re: [p2p-sip] what's wrong with DNS?

  I want a simple mechanism to learn peers to get started (bootstrap), not a replacement for the DHT.

  The fundamental problem I think you have is that if you have a classic registrar, if that registrar fails, you are out of luck.  The DHT stays running.  I don't think you are going to find a lot of support for this line of thinking.  

  Brian

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

  That's certainly my thinking in bringing this up.  Just do what's easy and knock off the biggest win -- a low-cost SIP infrastructure. 

  1) Zero changes to proxy servers and registrars.
      - Non-firewalled peers become proxies and registrars just like before.  They should be able to literally use the same code as the open source proxies and registrars out there, though, because nothing changes in the lookup. 

  2) Eliminating the most complicated part of the current architecture -- the DHT.  It's also the thorniest to standardize.

  3) Lower latency for completing calls.  No more waiting around for the DHT to respond.  Call completion happens just like it does with any other SIP call (if the DNS is up-to-date -- more below). 

  1) Delay of DNS propagation when registrars go down or clients move.  I think this is the toughest to get a good read on because I don't know how it would play out in the field. 

  2) You'd need to run a dynamic DNS *client* on every node (at least that seems like the best approach to me).

  3) You'd be relying on some servers out there to do the dynamic DNS.  Possibly existing dynamic DNS providers?  

  Keep in mind I'm not necessarily advocating this shift, but it certainly resonated with me once I realized the full implications of Paul's question to me the other day. 

  -Adam

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/cd5029d6/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 14:22:20 -0500

Sorry that I confused people.  I was thinking about bootstrap and not DHT
replacement.

Brian

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Spencer Dawkins
Sent: Tuesday, November 21, 2006 2:03 PM
To: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

Hi, Brian,

I'm not sure who else may have misunderstood - when I saw your note that
said

> Let's stick to things we know will work.  

I thought you were talking about a replacement for the DHT, and others may
have as well.

Sorry for (my) misunderstanding - I was confused by the thread you were
following up in.

Thanks,

Spencer

----- Original Message ----- 

From: Brian Rosen <mailto:br at brianrosen.net>  

To: 'Adam Fisk' <mailto:adamfisk at gmail.com>  

Cc: p2p-sip at cs.columbia.edu ; 'Mehdi <mailto:Mehdi.Mani at int-evry.fr>  MANI' 

Brian

  _____  

-Adam

  _____  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/88873614/attachment-0001.html

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 14:25:35 -0500

>  I don't know what you are smoking.

The good weed.

> but you can' use classic registration to do the kind of peer to peer things

OK, let's step back for a moment.  I'm making a pretty simple suggestion
here to offer what to me is the primary benefit of p2p SIP, namely low cost
telephony for the masses, with a much simpler implementation.  In this
system, every node would be a dynamic DNS client.  Every node would be
registered with some non-firewalled peer(s) out there.  If that connection
is severed, the client connects to a new non-firewalled registrar and
updates the DNS.  It's as simple as that.

> your peer being unable to connect to your registrar and thus being unable to

That's where DNS comes in.  Your peer just calls you as your peer normally
would.

> replicated; any node can get you to any part of the database even when peers

The system I just described does the same thing, and it does it using
existing technology that's far less complicated.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/bf3f4df5/attachment.html

---

From: ggb at tid.es (Gustavo García Bernardo)
Date: Tue, 21 Nov 2006 20:50:08 +0100

disconnected scenarios.  

A meeting room without internet connectivity.

A corporate LAN with the ?dynamic dns update? protocol filtered in their
firewalls.

Vehicle2Vehicle communications or other kinds of MANETs.

[http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.txt]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/e67c015b/attachment.html

---

From: victor.pascual.avila at gmail.com (Victor Pascual Ávila)
Date: Tue, 21 Nov 2006 20:55:41 +0100

2006/11/21, Gustavo Garc?a Bernardo <ggb at tid.es>:
> A corporate LAN with the "dynamic dns update" protocol filtered in their
> firewalls.
>
When no infrastructure is available... is it correct?

-- 
Victor Pascual ?vila

mail:victor.pascual.avila at gmail.com
sip:victor.pascual at iptel.org
linux user: 224443

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 21 Nov 2006 15:01:42 -0500

Trade shows.
Emergency Measures Response.
Search and Rescue.
First Responder.
I am working with a company developing systems for the latter three.
Depending On DNS is a non-starter for them as under their operatingrequirements DNS may no longer exist.
M
On 11/21/06, Victor Pascual ?vila <victor.pascual.avila at gmail.com> wrote:> 2006/11/21, Gustavo Garc?a Bernardo <ggb at tid.es>:> >> >> >> > A meeting room without internet connectivity.> >> > A corporate LAN with the "dynamic dns update" protocol filtered in their> > firewalls.> >> > Vehicle2Vehicle communications or other kinds of MANETs.> >> When no infrastructure is available... is it correct?> >

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 15:08:24 -0500

I'll play along for just a little bit more, then I have to go home.

I'm not sure I understand your model.  You start with a domain name
(alice.example.com).  You dynamically change the IP address of, let's say,
the sip "server" at alice.example.com to the non-firewalled peer address.
Now a caller who calls alice.example.com looks that domain name up in the
DNS, gets your non-firewalled peer's address and sends the call to it.  It
sends the call to you.  Have I got that right?  The DNS entry can't point to
you, generally speaking if you are behind a firewall, you can't get an
arbitrary SIP message sent to you. 

What if the non firewalled peer loses connectivity to the caller, but not to
you?  You don't know there is a problem, but a caller can't get to you.  DNS
doesn't help you.  The caller resolves alice.example.com to the
non-firewalled peer, but it can't get the call to the peer.  You don't know,
and he can't tell you.

Also, dynamic DNS layers something on top of the static DNS.  The domain
(alice.example.com) has one (okay, a set of) authoritative nameserver(s).
The dynamic part changes the value (in this case, the IP address for the sip
SRV maybe for the domain).  If the namesever(s) is/are not available, you
are up the creek.

Brian

 

  _____  

From: Adam Fisk [mailto:adamfisk at gmail.com] 
Sent: Tuesday, November 21, 2006 2:26 PM
To: Brian Rosen
Cc: Marshall Eubanks; David Barrett; Mehdi MANI; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

The good weed. 

-Adam 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/02b81405/attachment-0001.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 21 Nov 2006 15:08:56 -0500

Oh I forgot to add:
Marine nets: (HAM+802.11+WiMax+broadband satellite)Industrial sites.Forestry.3rd world/emerging market.
It goes on.
On 11/21/06, Michael Slavitch <slavitch at gmail.com> wrote:> Trade shows.>> Emergency Measures Response.>> Search and Rescue.>> First Responder.>> I am working with a company developing systems for the latter three.>> Depending On DNS is a non-starter for them as under their operating> requirements DNS may no longer exist.>> M>> On 11/21/06, Victor Pascual ?vila <victor.pascual.avila at gmail.com> wrote:> > 2006/11/21, Gustavo Garc?a Bernardo <ggb at tid.es>:> > >> > >> > >> > > A meeting room without internet connectivity.> > >> > > A corporate LAN with the "dynamic dns update" protocol filtered in their> > > firewalls.> > >> > > Vehicle2Vehicle communications or other kinds of MANETs.> > >> > When no infrastructure is available... is it correct?> > >>

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 15:09:01 -0500

These are very important scenarios to be sure.  Maybe there's a different
set of requirements for a completely disconnected environment?

As an implementor of this technology in a connected environment, the dynamic
DNS approach just seems much simpler to me.  I also worry about how much the
added complexity of the DHT routing would deter widespread adoption.

-Adam

On 11/21/06, Michael Slavitch <slavitch at gmail.com> wrote:
> Depending On DNS is a non-starter for them as under their
> operatingrequirements DNS may no longer exist.
> M
> On 11/21/06, Victor Pascual ?vila <victor.pascual.avila at gmail.com> wrote:>
> 2006/11/21, Gustavo Garc?a Bernardo <ggb at tid.es>:> >> >> >> > A meeting
> room without internet connectivity.> >> > A corporate LAN with the "dynamic
> dns update" protocol filtered in their> > firewalls.> >> > Vehicle2Vehicle
> communications or other kinds of MANETs.> >> When no infrastructure is
> available... is it correct?> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/ac9f9523/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 15:15:36 -0500

Michael

While I think the idea of replacing the DHT with dynamic DNS is a
non-starter, I don't understand your problem with DNS in general.

I'm working on systems that deal with the later three.  DNS seems to be
something you CAN rely on within a network you have connectivity to.  You
may lose connectivity to the global Internet, but within, say, an incident
network, assuming that there is some DNS infrastructure seems pretty
reasonable.

I have some sympathy with trying to make things work when, say the only
entities in a network are a pair of first responders (a MANET network with
exactly two members).  It should be possible for those two to talk to one
another.  It IS possible to make such systems use DNS.  One or both of them
have to enable DNS servers.  Working without such mechanisms seems to
require multicast, also on our list of no-no's.

How do you think it works?

Brian

> bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
> Sent: Tuesday, November 21, 2006 3:02 PM
> To: Henry Sinnreich; P2P-SIP
> Subject: [p2p-sip] Fwd: what's wrong with DNS?
> 
> Trade shows.
> room without internet connectivity.> >> > A corporate LAN with the
> "dynamic dns update" protocol filtered in their> > firewalls.> >> >
> Vehicle2Vehicle communications or other kinds of MANETs.> >> When no
> infrastructure is available... is it correct?> >

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 21 Nov 2006 12:29:47 -0800

Help me to understand the proposal more clearly.  Are you suggesting:

1)       Every user chooses a domain name.  Mine might be
'dbarrett.p2psip.org'

2)       When I start my client up, I choose any non-firewalled peer (how do
I find it?) and REGISTER myself with it as something like
'dbarrett at dbarrett.p2psip.org'

3)       After registering with the peer/proxy, I contact some
highly-redundant set of dynamic DNS servers and say "this is the latest IP
address of my proxy, point to it whenever anyone does a DNS lookup on
dbarrett.p2psip.org"

4)       Your off the shelf, totally unaltered SIP client asks DNS for the
IP of 'dbarrett.p2psip.org', gets the latest IP of my proxy, and looks up
the user 'dbarrett at dbarrett.p2psip.org', and then contacts me as normal.

5)       If the peer I chose as my proxy goes down, I detect it immediately
and choose a new non-firewwalled peer (again, how do I find it?), REGISTER
with that as in step (2), and update my dynamic DNS binding as in step (3).

6)       Repeat.

Is this correct? 

-david

PS: And presumably, if my computer is itself non-firewalled, I can act as my
own proxy; then dbarrett.p2psip.org would point directly to me, and I
wouldn't depend on anyone.

  _____  

From: Adam Fisk [mailto:adamfisk at gmail.com] 
Sent: Tuesday, November 21, 2006 11:26 AM
To: Brian Rosen
Cc: Marshall Eubanks; David Barrett; Mehdi MANI; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

The good weed. 

-Adam 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/af38c105/attachment-0001.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 21 Nov 2006 15:33:36 -0500

As far as I understand existing SIP, when combined with a well-donestable DNS database, is already largely peer to peer, and always hasbeen for a end-to-end Internet.  The trouble is that DNS is not stableor universal in application, the Internet is not end to end, and it isgetting more fragmented not less.
Your implementation given your requirements could be fully implementedas peer to peer using existing protocols albeit with the addition ofNAT traversal using ICE and using DDNS for uri location. This worksfine in an environment with a few thousand or even a few hundredthousand of users and devices.  It starts to break down when you go100x that or more. It works only in a single DNS regime.  It doesn'tfederate well with others.
There are several impediments that make such implementations somewhatbrittle in the real world, some of them are technical, (ie NAT) andsome are anti-competitive, ie walled gardens. DNS itself is a form ofwalled garden in of itself.  Can I get the internal DNS table of youremployer? If I gave out mine, I'd be fired, and quick,
Other issues, like the forced used of root-level commercialcertificate authorities, create other problems in a world that is veryad-hoc and not nearly as centrally managed as administrators wouldlike to think.
The world is a self-similar, chaotic, place.  To the top-down worldthat is bad. To the self-organizing world that is a mathematicalrequirement. DNS does not meet the requirements for self-organizingsystems.
SIP/DNS is fine for a top-down Internet. The top-down people are building IMS.
A user-centric environment, where users and communities create theirown namespaces, is exactly counter to the heavily provisionedcentrally authorized centrally administered way of doing things,canonically described by the root servers of DNS.
Military and first-responders are the first to understand  the needfor self-organization, top-down in today's world is the 21st Centuryedition of the Maginot Line.
While the  P2PSIP proposal can use DNS it should not require the useof it.  The best solutions for the generic problems regarding DNSbrittleness and NAT are the ones that allow for flexibility androbustness for the long term.  This allows for a user andapplication-centric edge-defined Internet that can scale into thebillions and hundreds of billions of end-devices.
Henry Sinnreich's presentations on this very issue describe the circleof complexity far better than I can.

Regards
MOn 11/21/06, Adam Fisk <adamfisk at gmail.com> wrote:> These are very important scenarios to be sure.  Maybe there's a different> set of requirements for a completely disconnected environment?>> As an implementor of this technology in a connected environment, the dynamic> DNS approach just seems much simpler to me.  I also worry about how much the> added complexity of the DHT routing would deter widespread adoption.>> -Adam>>> On 11/21/06, Michael Slavitch <slavitch at gmail.com> wrote:> > Trade shows.> > Emergency Measures Response.> > Search and Rescue.> > First Responder.> > I am working with a company developing systems for the latter three.> > Depending On DNS is a non-starter for them as under their> operatingrequirements DNS may no longer exist.> > M> > On 11/21/06, Victor Pascual ?vila <victor.pascual.avila at gmail.com> wrote:>> 2006/11/21, Gustavo Garc?a Bernardo <ggb at tid.es >:> >> >> >> > A meeting> room without internet connectivity.> >> > A corporate LAN with the "dynamic> dns update" protocol filtered in their> > firewalls.> >> > Vehicle2Vehicle> communications or other kinds of MANETs.> >> When no infrastructure is> available... is it correct?> >> > _______________________________________________> > p2p-sip mailing list> > p2p-sip at cs.columbia.edu> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip> >>>

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 21 Nov 2006 12:38:59 -0800

In a disconnected p2p scenario, peers can be provisioned with the IP address of bootstrap peers in the neighborhood. 

There is no need to rely on the DNS except when proxying SIP messages between different p2p systems or when talking p2psip to cs-sip.

For what it's worth, I remember to have seen quite a number of p2p designs and none of them relies on the DNS. See for example http://opendht.org/ and the P2P SIP system reported at Columbia University.

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Tuesday, November 21, 2006 2:16 PM
To: 'Michael Slavitch'; 'P2P-SIP'
Cc: Henry Sinnreich
Subject: RE: [p2p-sip] Fwd: what's wrong with DNS?

Michael

Brian

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 21 Nov 2006 12:40:19 -0800

_____  

From: Brian Rosen [mailto:br at brianrosen.net] 
Subject: RE: [p2p-sip] what's wrong with DNS?

Well, if you lose the nameservers every other internet application that
depends on DNS (like, all of them) is totally screwed anyway - it's no
surprise that your VoIP would stop working if your web browser does too.  So
in an internet application, it seems reasonable to assume that the basic
foundation of the internet continues to function.

The first question is more interesting: a peer isn't a hardened server in a
solid datacenter, so what if it just flakes out for some peers more than for
others.  This is a really good point.  But I think DNS offers a solution
here, too: just register your client with multiple proxies (as many as you
like) and use dynamic DNS to associate all of those IPs with your domain
(alice.example.com).  When the SIP client gets a list of IPs back from that
DNS lookup it tries each in order.

But the real question is how this works "off the net" in an ad-hoc wireless
or other network that lacks nameservers, DNS, and so on.  I don't have a
good answer to that, though any P2P solution might be stuck under the mask
of DNS (and thus transparent to SIP), thereby paving the way for other P2P
applications who will all have the exact same problem.

-david

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/2e02f16c/attachment.html

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 15:45:36 -0500

>  I'll play along for just a little bit more, then I have to go home.
Golly gee, thanks for "playing" Brian.  Gotta love mailing lists.

> I'm not sure I understand your model.  You start with a domain name (
> alice.example.com).  You dynamically change the IP address of, let's say,
> sends the call to you.  Have I got that right?
>

Yes.  The non-firewalled peer is the registrar for Alice, say
registrar1.example.com.  It's a 100% standard SIP registrar/proxy.  Alice
would be a SIP "client" connected to registrar1.example.com (the
non-firewalled peer), and Alice would have set the DNS for
alice.example.comto point to
registrar1.example.com.

The DNS entry can't point to you, generally speaking if you are behind a
> firewall, you can't get an arbitrary SIP message sent to you.
>

Right - it's sending it to registrar1.example.com, the non-firewalled peer
that can get an arbitrary SIP message sent to it.

> non-firewalled peer, but it can't get the call to the peer.  You don't know,

Are you talking about during the call?  At this point we'd just be talking
about a completely normal SIP session, so any failures on any end would be
handled as they normally would.  Let's call the caller bob.example.com.
Let's say Bob is registered at registrar2.example.com.  Bob initiates a
call, his completely standard SIP registrar looks up the authority for Alice
in DNS and sends it along.  You're asking what if the SIP session is broken
because the connection between the 2 proxies in the standard SIP trapezoid
is broken?  All of these scenarios just follow the standard state diagrams.

Also, dynamic DNS layers something on top of the static DNS.  The domain (
> alice.example.com) has one (okay, a set of) authoritative nameserver(s).

I think you'd probably just use standard name servers.  You could use any
public dynamic DNS provider out there.  Sure, they could go out, but that
doesn't happen often.

I think part of the confusion here might be that you need some way of
knowing about all the non-firewalled nodes out there so that when you lose a
connection, you just re-register with another node and remap the DNS.  This
is essentially the bootstrapping problem all over again though.  You just
need some way to know about those nodes.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/698ea6cf/attachment-0001.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 21 Nov 2006 15:51:45 -0500

"I think you'd probably just use standard name servers.  You could use
any public dynamic DNS provider out there.  Sure, they could go out,
but that doesn't happen often. "

My own requirements have to assume that the root nameserver no longer exists.

What if a government turned it off?  Or a corporation? What then? What
if there is a flood?
Or an attack? Does the system go dark?

Katrina exposed such loopholes in systems design.  Let's not design
them in after the fact when there are known alternatives that offer
rewards even when things are working well.

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 15:54:05 -0500

Hi David-

> 1)       Every user chooses a domain name.  Mine might be

Yes.

> I find it?) and REGISTER myself with it as something like 'dbarrett@
> dbarrett.p2psip.org'
>

Yes.  You'd find it in the same way you would with any of the bootstrap
methods.

> address of my proxy, point to it whenever anyone does a DNS lookup on

Yeah.  You could even just use existing free dynamic DNS providers out
there.

> the user 'dbarrett at dbarrett.p2psip.org', and then contacts me as normal.

Yes again.  At this stage it would be a standard SIP call with the standard
trapezoid.

> with that as in step (2), and update my dynamic DNS binding as in step (3).

Again exactly.

> wouldn't depend on anyone.

Yup.  The "how do I find it" question is certainly one of the missing
pieces, but it's there in the DHT scenario anyway.

Thanks for elucidating those steps -- I should have done that first thing
this morning.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/5c1b5c92/attachment.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 21 Nov 2006 13:01:01 -0800

> From: Henry Sinnreich
> Sent: Tuesday, November 21, 2006 12:39 PM
> To: Brian Rosen; Michael Slavitch; P2P-SIP
> Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?
> 
> For what it's worth, I remember to have seen quite a number of p2p designs
> and none of them relies on the DNS. See for example http://opendht.org/
> and the P2P SIP system reported at Columbia University.

Well, it depends on how you define P2P.  By volume today the vast majority
of P2P traffic is BitTorrent, and it uses DNS for tracker lookups and
torrent distribution.  Or even historically, P2P was invented by Napster and
Scour, and they used central indexing servers located via DNS.

I agree that today's research in P2P has given up on DNS, but the actual
implementations that defined the term swore by it.

-david

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 21 Nov 2006 16:18:48 -0500

Right.  Stepping back again for a second, I think we're just talking about
different sets of requirements.  The fascinating and important scenarios
like Katrina where you simply cannot rely on DNS need a solution, and I
think the various ad-hoc bootstrapping ideas may very well be the best
route.  I also ideologically agree with your other points about walled
gardens and user-centric, bottom up design.

For my own use case, though, basically providing a low-cost SIP
infrastructure where you use peers instead of running your own servers, the
dynamic DNS approach struck me as much simpler.  We could call this the
Skype use case.

-Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/a1ae8937/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 21 Nov 2006 18:09:42 -0500

Please be careful.

If you are on a network that suddenly becomes disconnected from the
Internet, but your local network works, then your local DNS works, and any
question within your domain will be answered.  If you ask a question outside
your domain, it won't work, or you get a cached answer if it's still valid.

If your access network blows up, and you have no infrastructure, then
nothing really matters.

So when you say "scenarios like Katrina" the most common circumstances was
that the access network connection was lost.  Nothing you can do about that.
The second most common one was that you had an access network, but no
connections onward to the Internet.  In those cases, DNS works to anyone you
can talk to.

Brian

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Adam Fisk
Sent: Tuesday, November 21, 2006 4:19 PM
To: Michael Slavitch
Cc: P2P-SIP
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

-Adam

My own requirements have to assume that the root nameserver no longer
exists. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061121/dd4fa644/attachment-0001.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 21 Nov 2006 18:50:54 -0500

There is this miracle called radio spectrum.

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 21 Nov 2006 16:24:41 -0800

> require multicast, also on our list of no-no's.

Actually, this is a good point.  There's a lot of talk about emergency ad
hoc networks constructed in disaster zones.  But even in these cases, won't
one of the very first tasks be setting up internet connectivity so they can
get messages out to the outside world?  And won't first on that list be
getting DNS set up?

I mean, VoIP is cool, but email and web are probably even more important.
There are things like satellite telephones, HAM radios, and even walkie
talkies -- hell, loudspeakers that can do wonders in a disaster.  But
there's simply no alternative to email and web access in an emergency, and
thus the priority (if I were FEMA) would be on getting those up first.  If
VoIP comes with it, neat, but I'd have plenty of other voice communication
systems set up well before waiting on net access.

So if we can generally agree that DNS is generally reliable for the 99% of
users in typical, non-disaster usage, can we also agree that DNS will be
available very quickly to most disaster networks as well -- whether the same
DNS as used by the internet, or a private DNS used only within the disaster
network itself (and then later hooked up to the rest of the world?.

If that's the case, then who *are* we targeting this to?  Is this really
being designed exclusively around the needs of the very first hours after
disaster strikes as an alternative to walkie talkies or yelling really loud?

-david

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 21 Nov 2006 19:32:50 -0600

And, on this note...

> If that's the case, then who *are* we targeting this to?

I can almost PROMISE that the authors of 
http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.html would 
love to hear comments about their work to date, and I can GUARANTEE that the 
editor of http://www.p2psip.org/P2PUseCases.php is waiting with bated breath 
for any thoughts that occur to people who are thinking about "then who *are* 
we targeting this to?"

Thanks,

Spencer

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 21 Nov 2006 18:33:11 -0800

Excellent summary.  All but five of the use cases (in fact, all the "big"
use cases affecting 99% of users) support access to the global internet DNS.
Those that do not include: 

- Anonymous communication
- Ad-host and ephemeral groups
- Emergency first responder networks
- Extending the reach of mobile devices
- Deployments in the developing world

It seems that many or even all of these could support private DNS if we set
our minds to it and made it easy.  The problem of resolving names to IPs is
a big one -- it matters to much more than just VoIP.  Rather than creating a
SIP-only solution that lets people talk but do nothing else, why not just
tackle this at the DNS layer and thus make everything "just work"?

Anyway, the reason I liked Adam's solution so much is it seems like *such a
cleaner interface*.  Rather than trying to recreate a new fancy P2P naming
system *and* solve VoIP, why not just take each separately?  Dynamic DNS is
a really clever solution to the naming problem that seems workable on the
internet.  Furthermore, it doesn't seem too difficult (or, rather, any more
difficult) to invent a P2P-DNS system that works for VoIP as well as
everything else, and that handles the five scenarios listed above.

So here's my proposal:
- Use DynamicDNS for 99% of users
- Invent some P2P-DNS to handle the remaining 1%
- Make VoIP work like every other internet application (use DNS)
- Make all internet applications "just work" with P2P-DNS in the cases above

Sometimes circling the wagons differently can make a really hard problem
simple.  I like Alex's proposal because it might offer just that.

-david

> bounces at cs.columbia.edu] On Behalf Of Spencer Dawkins
> Sent: Tuesday, November 21, 2006 5:33 PM
> To: 'P2P-SIP'

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 21 Nov 2006 23:52:07 -0800

So here's my proposal:

-david

---

From: dbildikar at ipunity.com (Darshan Bildikar)
Date: Wed, 22 Nov 2006 13:55:44 +0530

I've been going through the draft (draft-bryan-sipping-p2p) and there's one
thing I don't understand. I'm hoping someone can help me understand it
better. 

Section 5.2 states

"When locating a resource with a particular Resource-ID, the peer will send
the request to the finger table entry with the Peer-ID closest to the
desired Resource-ID"

It also states earlier that the resource ID is a hash of user name whereas
peer-id is a hash of IP and port. In this regard how will a peer determine
closeness of resource id to peer id when the hash values are actually based
on different parameters?

I suspect the explanation lies in this line ("The Resource-IDs map to the
same space as the Peer-IDs") that I don't really understand. Clarification
would help. What is it about the relation between the peer-id and the
resource-id that helps a peer identify where to send the request?

Additionally, it would help if this section were to clearly define what a
resource is and what a peer is. And the overlap between them. 

BR,
Darshan

---

From: jean-francois.wauthy at alcatel.fr (Jean-François Wauthy)
Date: Wed, 22 Nov 2006 13:27:49 +0100

> resource-id that helps a peer identify where to send the request?
The hash function (SHA1 here) is the same for the resource-IDs and 
peer-IDs, the results being a 160bit number in both cases you can 
compare them and therefore find the closest peer to send the request to.

> resource is and what a peer is. And the overlap between them. 
A resource is an information stored in the DHT and a peer can be seen as 
a host participating to the DHT overlay.

HTH,
Jean-Fran?ois Wauthy

---

From: mlepinski at bbn.com (Matt Lepinski)
Date: Wed, 22 Nov 2006 09:47:23 -0500

Darshan,

Perhaps this is best explained by way of an example.

For instance, let's say that I'm a peer and that I have four peers in my 
finger table. Each of these peers has a peer ID obtained by hashing the 
peer's IP address and port. For simplicity, in this example, I'm going 
to assume that the hash function (SHA-1) returns 24 bits (instead of 160 
bits) and so the output can be represented as 6 hexidecimal digits. So 
my finger table contains the following four entries.

Peer                   Peer-ID
------                   ---------
10.0.0.1:5678       12A9 
10.0.0.2:5678       2D8B
10.0.0.3:5678       409C
10.0.0.4:5678       8F25

Now let's say that I want to find the resource sip://bob at p2psip.example.net
I would obtain the Resource ID for this resource by applying the same 
hash (SHA-1) to the name of the resource (sip://bob at p2psip.example.net).
So let's say that I apply the hash and I get a Resource ID of 59FF. I 
would then compare the Resource ID to the Peer ID's in my finger table 
and determine that 409C is closest to the Resource ID that I'm looking 
for. Therefore, I would route request for information about 
sip://bob at p2psip.example.net to the peer at 10.0.0.3:5678.

Hope this helps,
- Matt Lepinski

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 22 Nov 2006 06:53:05 -0800

>- Invent some P2P-DNS to handle the remaining 1%

I suppose we can also add Skype with its >100M users to the 1%  ;-)>

We do not seem to be able have to any better agreement than already in
the proposed charter:

"P2P SIP may use DNS but does not require it" or something like that.

So can we please move on and leave everyone to use DNS or NOT use DNS as
well?

I doubt taking this discussion any further on the list will change
anyone's mind. What was to be said has been said already. Maybe a
balanced group could make a summary offline, but that's beyond the scope
of this list.
Any good implementation will beat arguments anyway...

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Tuesday, November 21, 2006 8:33 PM
To: 'Spencer Dawkins'; 'P2P-SIP'
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

Excellent summary.  All but five of the use cases (in fact, all the
"big"
use cases affecting 99% of users) support access to the global internet
DNS.
Those that do not include: 

It seems that many or even all of these could support private DNS if we
set
our minds to it and made it easy.  The problem of resolving names to IPs
is
a big one -- it matters to much more than just VoIP.  Rather than
creating a
SIP-only solution that lets people talk but do nothing else, why not
just
tackle this at the DNS layer and thus make everything "just work"?

Anyway, the reason I liked Adam's solution so much is it seems like
*such a
cleaner interface*.  Rather than trying to recreate a new fancy P2P
naming
system *and* solve VoIP, why not just take each separately?  Dynamic DNS
is
a really clever solution to the naming problem that seems workable on
the
internet.  Furthermore, it doesn't seem too difficult (or, rather, any
more
difficult) to invent a P2P-DNS system that works for VoIP as well as
everything else, and that handles the five scenarios listed above.

So here's my proposal:
- Use DynamicDNS for 99% of users
- Invent some P2P-DNS to handle the remaining 1%
- Make VoIP work like every other internet application (use DNS)
- Make all internet applications "just work" with P2P-DNS in the cases
above

-david

> love to hear comments about their work to date, and I can GUARANTEE
that
> the

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 22 Nov 2006 10:25:27 -0500

DDNS is fine as one of many possible methods, each method fully
described and fully enumerated in the standard  protocol, for protocol
discovery and for identification. It might even be the first one in
the list, and the one in use in most early-adopter implementations.

It is not fine as the one and only especially since P2P can exploits
alternatives as well.
The same is not true for C/S SIP so that is not an issue.

Regards

M

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Wed, 22 Nov 2006 10:49:33 -0500

> I suppose we can also add Skype with its >100M users to the 1%  ;-)>

I'd argue Skype is the perfect use case for the DDNS approach, actually.

> So can we please move on and leave everyone to use DNS or NOT use DNS as

Sounds good to me.  These conversations are exhausting!

> Any good implementation will beat arguments anyway...

Amen to that.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061122/ccbf1c53/attachment.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 22 Nov 2006 15:57:08 -0800

> > I suppose we can also add Skype with its >100M users to the 1%  ;-)>

Skype depends wholly and entirely on DNS for the first and most critical
function: authentication.

So, let's put those 100M users solidly back in the "utterly dependent upon
DNS" category.  Indeed, even if Skype didn't so completely rely on globally
hosted central servers, that's not my point: the point I'm trying to make is
all Skype users *do* have reliable access to DNS, and so will a
hypermajority of P2P-SIP users.

Again, the number of users who will not have access to DNS is infinitesimal.
Even an extreme "disaster" network will get DNS quickly, and an "ad hoc"
network of nodes 20 feet away from each other is better served by talking
REALLY LOUD.  Anybody sufficiently prepared to establish a long-range
fixed-wireless point-to-point network could easily set up a private DNS
server (and indeed, would probably have one already).

Thus rather than inventing a new DNS and making it specific only to VoIP,
why not just use the existing DNS, and then figure out how to extend DNS
into the incredibly rare networks where it isn't already available?

-david

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 22 Nov 2006 16:56:44 -0800

> server (and indeed, would probably have one already).

And anywhere that you can set up an ad-hoc network you can use
zeroconf/mDNS. I'd love to see a non-null enumeration of the P2P-SIP use
cases where you don't have:
  1) access to the global DNS or,
  2) everyone on the same LAN such that mDNS is sufficient or,
  3) access to a network-local DNS set up by the local infrastructure
provider that you can see via DHCP or manual configuration

As David points out, #3 followed soon thereafter by #1 is likely in any real
disaster scenario, and #2 applies to most if not all ad-hoc wireless (or
wired) cases.

Matthew Kaufman
matthew at matthew.at

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 22 Nov 2006 18:16:35 -0800

Cannot live with web browsing without DNS.

However, to decentralize p2p-sip with best efforts, is it possible that DNS
is used ONLY IN CASE for "evacuation" purpose?

BTW, it seems to me that Skype uses NO DNS on (super)node lookup.

Also, Skype could do authentication without DNS, IMHO.

Peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Michael Slavitch'" <slavitch at gmail.com>; "'Henry Sinnreich'"
<hsinnrei at adobe.com>; "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Wednesday, November 22, 2006 3:57 PM
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Wed, 22 Nov 2006 21:59:42 -0500

> BTW, it seems to me that Skype uses NO DNS on (super)node lookup.

Right, but they could do it more easily *with DNS*.  Just a much simpler
architecture that takes out the bulk of the work.  It would also lower
latency in the average case.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061122/07fbd08b/attachment-0001.html

---

From: saikat at cs.cornell.edu (Saikat Guha)
Date: Wed, 22 Nov 2006 23:01:45 -0500

> Also, Skype could do authentication without DNS, IMHO.

Skype actually resorts to hard-coded IP addresses in the binary for
bootstrap; after the first successful bootstrap, it downloads additional
IPs. The point is moot IMHO, however, since the Skype model is different
from p2p-sip -- the Skype model is adversarial where the network
administrator is assumed to be actively trying to squelch Skype. As a
result Skype attempts to be as hard to detect and block as possible
including its use of random ports, encrypted packets, and a complete
lack of reliance on services provided/controlled by the network admin. 

On the other hand, the P2P primitive woven into Windows Vista is based
on the DNS interface -- each endpoint has a hostname, others can resolve
the IP for an endpoint by issuing a DNS query. That the backend
implementation of this interface (PNRP) is peer to peer is a separate
matter. The interface to name resolution chosen by Vista still is DNS.

-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061122/4a6a7460/attachment.bin

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 22 Nov 2006 21:43:05 -0800

"lower latency"? it seems opposite...

Peter
----- Original Message -----
From: Adam Fisk
To: Peter Pan
Cc: David Barrett ; Michael Slavitch ; Henry Sinnreich ; P2P-SIP
Sent: Wednesday, November 22, 2006 6:59 PM
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

-Adam

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 22 Nov 2006 21:58:37 -0800

Yes, *much* lower latency.  A simple lookup on a central server much faster
than a distributed lookup where you connect to not just one, but multiple
client computers hopping along a DHT.

-david

> From: Peter Pan [mailto:huang-ming.pan at comcast.net]
> Sent: Wednesday, November 22, 2006 9:43 PM
> To: Adam Fisk
> Cc: David Barrett; Michael Slavitch; Henry Sinnreich; P2P-SIP

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 22 Nov 2006 22:10:06 -0800

Problem here is, if you want the central server why p2p for sip?

or, we can be dismissed now :)

Peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Peter Pan'" <huang-ming.pan at comcast.net>; "'Adam Fisk'"
<adamfisk at gmail.com>
Cc: "'Michael Slavitch'" <slavitch at gmail.com>; "'Henry Sinnreich'"
<hsinnrei at adobe.com>; "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Wednesday, November 22, 2006 9:58 PM
Subject: RE: [p2p-sip] Fwd: what's wrong with DNS?

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Thu, 23 Nov 2006 01:17:12 -0500

> Problem here is, if you want the central server why p2p for sip?

Right.  We're actually trying to solve real problems in the simplest way
rather than force a particular solution.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061123/6bf14e11/attachment.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 22 Nov 2006 22:30:08 -0800

> or, we can be dismissed now :)

There are still plenty of P2P problems to be solved.  NAT traversal alone is
a huge one.  But we needn't make things harder than they already are by
embarking on a grand DHT experiment when there are easier solutions to the
name-resolution problem ready and waiting.

-davd

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 23 Nov 2006 15:42:44 -0500

> disaster strikes as an alternative to walkie talkies or yelling  

Our system has the requirement that it must work without Internet  
access,
and we have made a few sales where this is the case. We sell the  
phones in a bundle
with a PoE switch and a PSTN gateway, and the customer is happy.

Despite what people on this mailing list probably think, not EVERYONE
thinks internet access is a must-have. My next-door neighbors don't
even have a computer ...

Adam's idea sounds to me like a way to interface a P2PSIP system
with a CS SIP system. But I don't see it as the P2PSIP system itself.

- Philip

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 23 Nov 2006 15:10:09 -0800

Philip Matthews:
> access, and we have made a few sales where this is the case. We sell the  
> phones in a bundle with a PoE switch and a PSTN gateway, and the 
> customer is happy.

Sounds like mDNS on the devices, or even easier, a smart DNS server on the
PSTN gateway, and you'd be set, if DNS were the node-finding mechanism.

I'm still having trouble thinking of a use case where neither the global
DNS, nor a network-local DNS server, nor mDNS will work for that purpose.

At the same time, I find it hard to believe that the proposed Chord-like DHT
that's been tossed around as a "decentralized" solution to the node-lookup
problem on this list will actually provide useful answers with the sort of
churn one sees on a typical multi-thousand-user P2P overlay.

Personally, I see some real "P2P" things that SIP could use solved in a
standardized way, and while those are interesting problems, and the
solutions would help real users, a DHT isn't the solution, since the actual
problems aren't in the "node lookup" domain at all.

I agree that starting with something like DNS as a base for node lookup
means the actually useful work in the form of making sure that
P2P-SIP-enabled phones could establish direct registrar-less P2P connections
-- with NAT in the way (as it usually is) -- could get taken care of first.
Then, if anyone finds a real use case where DNS or mDNS is insufficient,
maybe we can all go back to experimenting with new signaling message formats
for several-year-old DHT technology.

Matthew Kaufman
matthew at matthew.at

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Fri, 24 Nov 2006 00:13:33 -0800 (PST)

> I can almost PROMISE that the authors of 
http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.html
> would 

Section 3.2 of the use cases drafts reviews high
security environments. AFAIK, many of these
environments have an extra "logging" requirement. For
example, in financial institutions, SEC requires
logging of all communications to enforce compliance
with trading rules. I am not sure that logging is easy
to provie in a P2P system (P2P logging?), but I
believe this requirement should at least be
acknowledged in the draft. 

-- Karst

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Fri, 24 Nov 2006 00:17:56 -0800 (PST)

> name-resolution problem ready and waiting.

Right. Besides, if someone wants to experiment with
DHT, they can use the DHT to provide an alternate DNS
service, resolving names in an ad hoc domain,
something like my-ua-name.dht-example.net.

The big advantage of this approach is risk management.
The P2PSIP can go on solving SIP level problems while
a separate group can experiment with P2P DNS. The two
groups can both succeed or fail without impacting each
other.

-- Karst

____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Sat, 25 Nov 2006 06:12:38 -0800

I would like to add the important application of home network for
consumer electronics that must also work even when disconnected form the
Internet.

Eunsoo Shim could probably expand.

Philip Mathews is right with the observation "Despite what people on
this mailing list probably think": 

Dependency on DNS is in last instance a business decision and all the
major P2P systems out there DO NOT rely on the DNS and will not be
influenced by these interminable discussion anyway. 

Live with it: P2P need not rely on DNS.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews
Sent: Thursday, November 23, 2006 2:43 PM
To: David Barrett; Adam Fisk
Cc: P2P-SIP
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

- Philip

---

From: victor.pascual.avila at gmail.com (Victor Pascual Ávila)
Date: Sat, 25 Nov 2006 15:19:55 +0100

Hi,
> influenced by these interminable discussion anyway.
I agree with you but I'd like to add that, from my point of view, it
should _not_ rely on any Inet service... It should be a closed system
compatible with other networks but with no dependence...
This is the most important key if you are working in special
situations where infrastructure is not available...

-- 
Victor Pascual ?vila

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 27 Nov 2006 00:05:46 -0800

> From: Henry Sinnreich [mailto:hsinnrei at adobe.com]

Seems like VoIP in a home network would have a hard time competing with
TALKING VERY LOUD.  Furthermore, anyone sufficiently geeky to have a fully
wired home would probably have a pretty good internet connection, or the
capacity to run a private DNS server -- especially if we made private,
disconnected DNS dead easy.

> Live with it: P2P need not rely on DNS.

I totally, 100% agree that P2P *need* not rely on DNS.  Indeed, it needn't
rely upon IP -- we could even standardize our own wireless protocol to avoid
the patent problems of 802.11.

But just like it's silly to recreate 802.11, IP, UDP, RTP and other
protocols, it seems a waste to rebuild name resolution.

Even though we *needn't* count on DNS, I don't see why we *couldn't* rely
upon it, or indeed why we *shouldn't*.  So far as I've heard, DNS (private
or public) will or could easily be available anywhere VoIP will be used.

Why is it worth the effort to go further?

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 27 Nov 2006 00:39:29 -0800

> From: Saikat Guha [mailto:saikat at cs.cornell.edu]
> IPs.

Thanks for the correction.  So Skype uses fixed, hard-coded IP addresses
rather than DNS to find the central server. [1]  In that sense, it doesn't
depend on DNS.  Rather, it's even worse: it's even more centralized and less
open than DNS.

Thus at the end of the day, the most successful P2P VoIP application has at
its very heart a completely closed client/server architecture.  All the
fancy P2P stuff is neat, but it can't exist without this big,
privately-owned central infrastructure.  If that central authentication
infrastructure goes down, nobody can login, and Skype goes offline.

So the question is: how can P2P-SIP not suffer the same failing?

Adam proposed that instead of trusting a single private company with the
world's directory, we leverage the existing global consortium of domain
registrars and adopt the existing international conflict resolution
framework of the IANA.  It's there, it works.  It has decades of experience
resolving all the problems that we're just looking at now.

It does what we want to done.  Why not "buy" rather than "build"?

Indeed, I still don't understand what has been proposed we "build" as a
replacement.  How is it possible to manage a unique namespace without
central authorities?  How, fundamentally, does it ensure that anyone in the
world who dials my number rings my phone?  And if someone somehow steals my
identity, how do I get it back?  How can it solve all this and still have
something human-memorable that I can print on my business card?

I've heard people talk about DHTs.  But how can I prevent you from hijacking
my entry?

I've heard people talk about PKI.  But where do you look up the public key
associated with my name, and how can I change my public key without letting
a hacker do the same?

This is much bigger than a technology problem; indeed, technology is an
afterthought.  Skype went the obvious and smart route: build a central
directory.  Adam proposed a decentralized and distributed solution: dynamic
DNS.

What is the competing proposal, and why is it better than DNS?

-david

----------------------------------------------------------------------------
[1] An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol, Baset
& Schulzrinne, 2004

4.2.2 Login Server
After a SC is connected to a SN, the SC must authenticate the user
name and password with the Skype login server. The login server
is the only central component in the Skype network. It stores
Skype user names and passwords and ensures that Skype user
names are unique across the Skype name space. SC must
authenticate itself with login server for a successful login. During
our experiments we observed that SC always exchanged data over
TCP with a node whose IP address was 80.160.91.11. We believe
that this node is the login server. A reverse lookup of this IP
address retrieved NS records whose values are ns14.inet.tele.dk
and ns15.inet.tele.dk. It thus appears from the reverse lookup that
the login server is hosted by an ISP based in Denmark.

---

From: billmcc64 at gmail.com (Bill Mccormick)
Date: Mon, 27 Nov 2006 10:15:16 -0500

Hi David,

The technology difference that I see is that a DHT will push out a
change in URI/IP address binding, whereas DNS (including DDNS) will
rely on cache flushing to occur in a timely manner.   Maybe this is
good enough for some people, maybe not.   I know it's not fast enough
for the 3GPP IMS guys...

I firmly believe the devil is in the details in this stuff.   I find
it hard to believe that we
could use the existing DNS off the shelf.    David Bryan et al have
put together a pretty reasonable description detailing the P2PSIP
proposal - and the charter does specifically exclude the use of DDNS.

If you really want to convince everyone, how about you produce a
document equivalent to the 'A P2P Approach to SIP Registration and
Resource Location' document.   It's pretty hard to compare the 2
approaches based on the traffic on the mailing list.

Bill

-- 
Bill McCormick

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 27 Nov 2006 08:08:00 -0800

David,

> Seems like VoIP in a home network would have a hard time competing 
> with TALKING VERY LOUD.

It's not about VoIP only, but about all consumer electronic devices in
the home that include entertainment, appliances, cars, home security,
garage door, sprinkler system, etc.

You bring home a new camera and it finds the printers, etc. or you can
use any remote control as a phone as well...  

There are papers on this from Panasonic. See p2psip.org.

It is hard to predict what technology will eventually link our consumer
electronic devices, but DNS has not popped up anywhere except on this
list.

Henry

-----Original Message-----
From: David Barrett [mailto:dbarrett at quinthar.com] 
Sent: Monday, November 27, 2006 2:06 AM
To: Henry Sinnreich; 'Philip Matthews'; 'Adam Fisk'
Cc: 'P2P-SIP'; 'Eunsoo Shim'
Subject: RE: [p2p-sip] Fwd: what's wrong with DNS?

TALKING VERY LOUD.  Furthermore, anyone sufficiently geeky to have a
fully

> Live with it: P2P need not rely on DNS.

I totally, 100% agree that P2P *need* not rely on DNS.  Indeed, it
needn't
rely upon IP -- we could even standardize our own wireless protocol to
avoid
the patent problems of 802.11.

Even though we *needn't* count on DNS, I don't see why we *couldn't*
rely
upon it, or indeed why we *shouldn't*.  So far as I've heard, DNS
(private
or public) will or could easily be available anywhere VoIP will be used.

-david

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 27 Nov 2006 08:23:53 -0800

> electronic devices, but DNS has not popped up anywhere except on this

Within LAN/WLANs, uPnP will do it.

Peter
----- Original Message -----
From: "Henry Sinnreich" <hsinnrei at adobe.com>
To: "David Barrett" <dbarrett at quinthar.com>; "Philip Matthews"
<philip_matthews at magma.ca>; "Adam Fisk" <adamfisk at gmail.com>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Monday, November 27, 2006 8:08 AM
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 27 Nov 2006 11:20:44 -0500

As a form of assessing identity DNS is particularly weak and requires
considerable care and expert feeding as provisioning is always
ultimately human-based requiring some kind of authority.  A
self-organizing automated system needs no such crutches.

A key provision of P2PSIP is to eliminate the need for such
authorities in the first place because they are superfluous for the
application.  An extended social network needs no central domain
administrator nor a central certificate authority.   It needs at most
a human facilitator not an engineer.

Such social networks are not trite. For example social networks are
the basis of all peer reviews for medical journals.  Shouting doesn't
work when 500 doctors are to be consulted, on several continents, with
varied access to the Internet, and over time.  The person running the
peer review is a journal editor, a person who uses end-user tools, not
a network engineer.  DNS isn't the selection criteria here, reputation
is.

M

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 27 Nov 2006 11:25:52 -0500

Well, for one thing, there are "credentials".  Think of this as a username,
within some domain.  Might also have some other things related to security.
The domain ("overlay network") is the domain of users that are allowed into
the domain.  

I think we want controls on that.

We have decided, quite a while ago, that a "centralized" credentialing
service was a useful thing to have.

DNS would leave everyone to themselves on SPIT.  I think we now understand
that such an environment is not a good idea.  

We could try leaveraging this high "risk" project on other high risk
projects like DKIM.  I think, at least for now, that we shouldn't do that,
and our current notion of overlay networks with a credentialing service is
the right model.

Brian

> Sent: Monday, November 27, 2006 3:39 AM
> To: 'P2P-SIP'
> Subject: [p2p-sip] Secure decentralized name resolution? (Was "what's
> wrongwith DNS?")
>

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Mon, 27 Nov 2006 11:49:42 -0500

> Within LAN/WLANs, uPnP will do it.

Exactly.  It would be quite a shock for p2p sip to win out in that battle.
I worry this list is trying to create some sort of panacea for all the
problems of the Internet instead of sticking to solving discrete problems
well.  Don't get me wrong, the technology's as cool as it gets, but I worry
it's seductive and becoming a solution in search of a problem.

We've addressed the entire spectrum just on this thread from social networks
to consumer electronic devices to completely disconnected networks to car
based networks, and undoubtedly more that aren't coming to mind at the
moment.  P2P SIP is really the answer for all of these?  Does that scope
strike anyone else as way too ambitious?  Seems cool for a research problem,
but we really think we're going to deploy standards to address all of those
use cases?

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061127/99fe47fc/attachment.html

---

From: fwmiller at cornfed.com (Frank W. Miller)
Date: Mon, 27 Nov 2006 10:02:19 -0700

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Monday, November 27, 2006 1:39 AM
To: 'P2P-SIP'
Subject: [p2p-sip] Secure decentralized name resolution? (Was "what's
wrongwith DNS?")

FM: I'd like to draw attention to this.  Whether or not there is any kind of
central server function that is part of this effort is a (pardon the pun)
central question.

At the very least, it is likely that some kind of centralized, or at least
authoritative service will be necessary for authorization and
authentication.  So, while all this discussion about DNS is interesting, I
think it may be secondary to some larger architectural considerations.
Perhaps the discussion should take up at least this larger question prior to
worrying about naming.

So, will the protocol disallow any kind of centralized functionality?

If not, what specific functions will allowed to be centralized and which
will not?  Here's a list:

1) Authorization: i.e. I call myself something and the P2P cloud authorized
me and me alone to call myself that

2) Authentication: i.e. I tell somebody who I am and that somebody has the
ability to determine whether I am who I say I am

3) Location discovery: i.e. If I want to find "somebody", figuring out where
that somebody is in the overlay

4) Signaling: i.e. telling somebody that I want to setup a session and
carrying that out

5) Media: i.e. the session media streams

IMHO, the first two items require some sort of centralized (or at least
authoritative) function to keep all the user client software honest.
Thoughts?

FM

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 27 Nov 2006 09:50:17 -0800

> Within LAN/WLANs, uPnP will do it.

I am not sure if UPnP meets all the security requirements for the
control of home systems. Besides, it is not a given that all consumer
electronic devices will be developed along a Wintel specification.

Is there a UPnP expert on the list to brief us on the status of UPnP
security and acceptance for home electronics?

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net] 
Sent: Monday, November 27, 2006 10:24 AM
To: Henry Sinnreich; David Barrett; Philip Matthews; Adam Fisk
Cc: P2P-SIP
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

Peter
----- Original Message -----

> Seems like VoIP in a home network would have a hard time competing
with

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 27 Nov 2006 13:05:59 -0500

I think we have agreed that issuing a credential is centralized.  Checking
it is probably not.  Depending on exactly how you want to define
"authorization", it may be centralized or not.

All the rest are decentralized among the peers.  We haven't really decided
how bootstrapping works.  There may be some kind of distinguished entities
that assist bootstrapping.

Brian

> bounces at cs.columbia.edu] On Behalf Of Frank W. Miller
> Sent: Monday, November 27, 2006 12:02 PM
> To: 'David Barrett'; 'P2P-SIP'
> Subject: Re: [p2p-sip] Secure decentralized name resolution? (Was
> "what'swrongwith DNS?")
> 
> 
>

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 27 Nov 2006 10:10:43 -0800 (PST)

> Within LAN/WLANs, uPnP will do it.

Along with zeroconf using mDNS (already being used to find printers, webcams, etc.
in the home or SOHO network environment)

Which gets back to my previous question about use cases that can't use any of
global DNS, locally-administered private DNS, or mDNS.

Matthew Kaufman
matthew at matthew.at

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 27 Nov 2006 10:18:00 -0800 (PST)

Michael Slavitch:
> ultimately human-based requiring some kind of authority. 

Agreed. Though in small disconnected networks, zeroconf using mDNS avoids
much of this, and in large networks the IT guys or your ISP manage the
complexity for you (though they haven't solved the security problem yet)

> A self-organizing automated system needs no such crutches.

Except for bootstrapping to get the first two nodes talking. Which, if on
the Internet, means a way to find IP addresses of those nodes. Which, on
today's Internet, could use DNS. Or, as the Skype folks do, hardcoded bootstrap
addresses. But either way, bootstrap is such a crutch.

> a human facilitator not an engineer.

So P2PSIP includes a web-of-trust security model? If so, why not leverage
existing solutions for that as well (like PGP)?

> a network engineer.  DNS isn't the selection criteria here, reputation

But DNS is how the journal's mailing list manager finds the mail hosts
for each of the 500 doctors. Delivery of the article and reply comments
across several continents over time works today just fine without P2P
or DHTs or reputation-based web-of-trust security models. See this mailing
list as an existence proof.

Matthew Kaufman
matthew at matthew.at

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 27 Nov 2006 22:49:34 -0800

I think Matthew highlights the Achilles heel of so-called "pure" P2P: it
never is.  In the real world, there's always a central service behind the
curtain:

- In Skype's case, it's a central directory at a hard-coded IP address.

- In P2P-SIP's case (if Frank and Brian are right) is some kind of
centralized authorization/authentication/bootstrapping service.

So granted, there's the question of "how do you find this service?"  The
obvious choice favored by every other application on the internet (and most
private networks) is "DNS".

But ignoring that, there's an even more important question:

	"Who controls this service?"

If we build some fancy DHT solution we imply "some unnamed benevolent
dictator yet to be appointed" will rule us all.  We've sorta assumed this
(or similarly vague explanations) for the entire course of the P2P-SIP
discussion.  For a long while I was not only on board, I was promoting this
"let's solve security later" approach.

But then Adam proposed a different owner, the IANA.  And the way to do that
is through the existing, tried-and-true interface of DNS (specifically,
dynamic DNS).  I think this is obvious and brilliant.

Building a nonpartial, internationally represented, neutral global third
party isn't easy, and while the IANA hasn't wildly succeeded in this,
they're closer than anybody else (and decades ahead of anything we'd invent
while searching for our benevolent dictator).

Now I'll grant DNS is limited to only, say, 99.999% of users.  And I
understand that there's a lot of interest in how the remaining 0.001% of
users will work without it.  But I'm having a hard time understanding why
we're even discussing them.  Indeed, Matthew's repeated calls for a
real-world use case of a network that doesn't already have, won't quickly
get, or couldn't easily be configured to have DNS has remained unanswered.
(And I'd add to that filter "outside of loud talking range.")
 
Furthermore, I'll grant you could build a DHT layer that serves as a
read-through cache of the central security mechanism that provides a faster
response and propagation time than DNS.  But Akamai, UltraDNS, and other
massive, global organizations have proven that DNS can propagate pretty dang
quick.

And while I think it's an excellent, open question on how to improve DNS to
make it even faster (perhaps with some kind of P2P layer), or how to make it
work better in partially or totally disconnected scenarios, or how to make
it more resistant to spamming/phishing and so forth, that seems like a much
bigger problem than SIP alone and thus better suited to its own group.

And finally, I agree there are open questions as to how my car-of-the-future
will talk to my garage door and sprinkler system.  But why is this relevant?
I share Adam's concern that we're dreaming up a panacea to every conceivable
problem rather than standardizing a solution to problems that actually exist
with technologies that are already at hand.

I apologize for being obtuse, but dynamic DNS (even with today's
limitations, and perhaps with future improvements) seems like such an
obvious way to solve the distributed name resolution problem that I'm
astonished it's being discounted so easily in favor of complex solutions to
nebulous problems experienced by nonexistent userbases.

I'll admit the conclusion is anticlimactic -- I'm a P2P developer who likes
high tech as much as anybody.  But where has my reasoning fallen off track?

-david

> bounces at cs.columbia.edu] On Behalf Of Matthew Kaufman
> Sent: Monday, November 27, 2006 10:18 AM
> To: hsinnrei at adobe.com; slavitch at gmail.com

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 28 Nov 2006 09:28:19 -0500

The point of a "centralized" credentials service is to limit who can call
you to someone who has credentials you accept.

Is any userid in any domain in the DNS acceptable to you for a credential?
It's not to me.  I think one of the reasons our charter will be accepted is
that we have allowed for a plausible credential issuing system.  If we had
said that we don't plan to have one, credentials are not needed, and all you
need is any domain to give you user at domain identity, then a lot of tough
questions would have been asked.  By saying you need credentials, and
credentials can be issued by some kind of authority, we create a feasible
way to control SPIT.

Skype works pretty much the way we see p2psip working.  It has a centralized
credential service; that's the website at skype.com where you sign up to get
a SkypeId.  It also has a set of hardwired addresses of peers that lets you
bootstrap your way to the cloud.  The addresses are not those of centralized
directory servers.  They are just known to be available peers.  Any peer
will do, and they start with the well known ones.  Once you get going and
are attached to the cloud, you don't need those peers any more, but they are
your way to get started.  We'll need a bootstrap mechanism, and we haven't
had any serious discussion on what that would be.

Brian

> Sent: Tuesday, November 28, 2006 1:50 AM
> To: 'Matthew Kaufman'; hsinnrei at adobe.com; slavitch at gmail.com

---

From: eunsooshim at gmail.com (Eunsoo Shim)
Date: Tue, 28 Nov 2006 09:30:17 -0500

I am not sure what your proposal is.
Could you provide more specifics on your proposal?
For example, are you suggesting that we use existing DNS servers to store
whatever we want to store at the P2P(SIP) network?
Or are you suggesting that we use the DNS PROTOCOL as (part of) the protocol
for P2P SIP and build a separate (global or ad-hoc) DNS-like infrastructure?
Thanks.

Eunsoo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/eae1d548/attachment-0001.html

---

From: fwmiller at cornfed.com (Frank W. Miller)
Date: Tue, 28 Nov 2006 08:15:51 -0700

I would propose something like this:

There are two elements, User Agents and the Identity Service. Identity
refers to messages that are sent between an Internet host and the
Identity Service to authorize and authenticate UAIs.  The Identity
Service is assumed to be authoritative and trusted, and very likely a
centralized service.  Identity operations include the following
functions:

   1.  Authorization

   2.  Authentication

Authorization

I call the user portion of a SIP URI the User Agent Instance (UAI).
The UAI is allocated to the UA by some means outside of the scope of this
protocol, i.e. by visiting a website or something.  Authorization refers
to the registration of a UA instance for a UAI with an Identity Service.
UAs are generally authorized when a user wants to begin interacting with
other UAs, e.g. when their UA client program is started.  (Note that these
messages are notional.  They don't have to even be SIP.  The idea of
these templates is to list the information moving between the elements)

   Frank            Identity Service
     |      AUTHORIZE      |
     |-------------------->|
     |       200 OK        |
     |<--------------------|
     |                     |

   AUTHORIZE
   UAI: Frank
   Password: ... Frank's password ...
   CSeq: 2 AUTHORIZE

Frank's UA requests authorization of the UAI.  The request includes a
shared secret that was setup when the UAI was issued.  The shared secret must
be sent encrypted.

   200 OK
   UAI: Frank
   Authorization: ... Cookie sent to anyone authenticating Frank ...
   CSeq: 2 AUTHORIZE

Frank's UA is returned a Cookie.  This cookie will be sent to other UAs
for subsequent interactions.  Other UAs can use the cookie for authenticating
Frank's UA.  Note that this assumes the Authorization cookie is encrypted.

Authentication

Authentication refers to the process of querying the Identity Service
regarding a UAI.  The procedure described herein is usually attempted
when a UA receives its first request for interaction from another UA.

    Bob            Identity Service
     |     AUTHENTICATE    |
     |-------------------->|
     |       200 OK        |
     |<--------------------|
     |                     |

   AUTHENTICATE
   UAI: Frank
   Password: ... Bob's password ...
   CSeq: 2 AUTHORIZE

Bob send's an authentication request to the Identity Service.  Bob is
only allowed to authenticate Frank if his UA is authorized using the
shared secret for Bob's UAI.  The shared secret must be encrypted.

   MSP 200 OK
   UAI: Frank
   Authentication: ... Cookie sent to Frank during authorization ...
   CSeq: 2 AUTHORIZE

The identity service returns the cookie that was sent by Frank with
the initial interaction.  Bob's UAI can compare the two and determine
if Frank is really Frank.  Again, the cookie must be encrypted.

This proposal requires some level of encryption in all these
messages.  I am actually in favor of SSL/TLS being required for
transport of these messages, whether that is for this separate
protocol blurb or for SIP in general.

The management of UAIs for each p2p cloud becomes the authoritative
information for that cloud.  I can imagine services like FWD providing
it for free and I can also imagine commercial services charging for
the service.

FM

On Tue, 2006-11-28 at 09:30 -0500, Eunsoo Shim wrote:
> For example, are you suggesting that we use existing DNS servers to
> store whatever we want to store at the P2P(SIP) network?
> Or are you suggesting that we use the DNS PROTOCOL as (part of) the
> protocol for P2P SIP and build a separate (global or ad-hoc) DNS-like
> infrastructure?
> Thanks.
> 
> Eunsoo
> 
>         > today's Internet, could use DNS. Or, as the Skype folks do,
>         hardcoded 
>         > bootstrap

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 28 Nov 2006 10:56:12 -0500

Wow.

You understand that you are proposing a centralized service that
authenticates you every time you boot, and a centralized authorization
service that authorizes you AT CALL TIME, at least the first time per boot?

The direction we are going is that you use the centralized credentialing
service to get credentials effectively once in a lifetime of the credential,
which might last at least months, and maybe years.  Thereafter, the
distributed hash table takes care of authentication and authorization peer
to peer without any central service.

I would definitely not call what you are proposing a peer to peer service;
it relies on centralized authentication and centralized authorization
services in real time.

Brian

> Sent: Tuesday, November 28, 2006 10:16 AM
> To: Eunsoo Shim

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 28 Nov 2006 10:58:41 -0500

"The direction we are going is that you use the centralized credentialing
service to get credentials effectively once in a lifetime of the credential."

Indeed. That is the whole point of a the DHT store.

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 28 Nov 2006 07:59:18 -0800

Brian's comments and the analogy with Skype sum it up quite well, though
P2P in the real world does not end with Skype. 

BTW: Existing P2P traffic is independent of the DNS and it dominates the
Internet traffic. Numbers between 60% and 80% have been published.

Also to consider is the use of a commercialized openDHT as has been
proposed (maybe already well funded by VC) that can not only act to
bootstrap new P2P systems but also as an _"Overlay Internet"_ in its own
right. 

See the papers on the openDHT web site. They are certainly a must read
for folks interested in this discussion.

As pointed out in reports on the Columbia University P2P system, the DHT
can be used (1) in the service mode and (2) in the data mode.

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Tuesday, November 28, 2006 8:28 AM
To: 'David Barrett'; 'Matthew Kaufman'; Henry Sinnreich;
slavitch at gmail.com

The point of a "centralized" credentials service is to limit who can
call
you to someone who has credentials you accept.

Is any userid in any domain in the DNS acceptable to you for a
credential?
It's not to me.  I think one of the reasons our charter will be accepted
is
that we have allowed for a plausible credential issuing system.  If we
had
said that we don't plan to have one, credentials are not needed, and all
you
need is any domain to give you user at domain identity, then a lot of tough
questions would have been asked.  By saying you need credentials, and
credentials can be issued by some kind of authority, we create a
feasible
way to control SPIT.

Skype works pretty much the way we see p2psip working.  It has a
centralized
credential service; that's the website at skype.com where you sign up to
get
a SkypeId.  It also has a set of hardwired addresses of peers that lets
you
bootstrap your way to the cloud.  The addresses are not those of
centralized
directory servers.  They are just known to be available peers.  Any peer
will do, and they start with the well known ones.  Once you get going
and
are attached to the cloud, you don't need those peers any more, but they
are
your way to get started.  We'll need a bootstrap mechanism, and we
haven't
had any serious discussion on what that would be.

Brian

> massive, global organizations have proven that DNS can propagate
pretty
> dang
> quick.
> 
> And while I think it's an excellent, open question on how to improve
DNS
> to
> make it even faster (perhaps with some kind of P2P layer), or how to
make
> it
> astonished it's being discounted so easily in favor of complex
solutions
> to
> > Except for bootstrapping to get the first two nodes talking. Which,
if
> on
hardcoded

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 28 Nov 2006 11:14:59 -0500

Google's "I'm feeling lucky" on "Overlay Internet" is a good one.

http://tinyurl.com/y4rmms

The Overlay Internet cat is no longer in any bag.  It is mainstream thinking.

M

---

From: fwmiller at cornfed.com (Frank W. Miller)
Date: Tue, 28 Nov 2006 09:32:36 -0700

> service that authorizes you AT CALL TIME, at least the first time per boot?

Not exactly.  Authorization happens at boot, i.e when your client starts
up.  Authentication happens at the first interaction between two UAs.

> to peer without any central service.

Understood.  I question the practicality of this for at least a couple
of reasons.

First, my view is that credentials should be changed periodically.  The
longer a credential is available, the more likely it is that it can be
hacked.

Second, the only real difference is how often the credentials are issued
and checked.  The DHT approach would do it "once" for all time, my
proposal does it "once" at client boot time and at the beginning of a
UA->UA interaction.  The need or lack of need for a centralized
authority does not go away because of the use of a DHT to lengthen the
time that credentials are valid.

> it relies on centralized authentication and centralized authorization

Well, its P2P except for initial authorization and subsequent initial
authentications.

FM

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 28 Nov 2006 12:36:10 -0500

I think you are confusing a credential validation from a credential
issuance.

I think what you have in mind is that you get a credential that changes
every few months: it's the password you use to authenticate.  That
credential is validated every time you boot.

The plan I think most of us have in mind is that you get a credential,
perhaps something like an x.509 cert, good for a couple of months or years,
that is validated every time you boot (e.g. connect to the overlay).

The difference is you want a centralized service to do the authentication,
and we want a p2p distributed service.

Then, you want a centralized authorization service, where we think the DHT
provides that also as a p2p distributed service.

Are there other people on the list who think what Frank is advocating is a
good idea?

Brian

> From: Frank W. Miller [mailto:fwmiller at cornfed.com]
> Sent: Tuesday, November 28, 2006 11:33 AM
> To: Brian Rosen
> Cc: 'Eunsoo Shim'; p2p-sip at cs.columbia.edu

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 28 Nov 2006 12:53:03 -0500

Anyone using a Windows notebook that authenticates to a domain is
using this technology right now.  This is not open research.

---

From: fwmiller at cornfed.com (Frank W. Miller)
Date: Tue, 28 Nov 2006 11:24:17 -0700

> credential is validated every time you boot.

Well, in the proposal I made, there are actually two "credentials."
There is the password that is issued however you like, its outside the
scope of the proposal other than the Author/Authen authority being aware
of it.  Then there is the "cookie."  This is the thing that changes
frequently.  The password is long lived but the cookie is regenerated
when the client attaches to the overlay.  Then other UAs use the cookie
to do authentication.  This proposal isn't all that different than
current SIP, i.e. A registrar challenges the UA when it registers and
certainly anyone can challenge a call setup when that happens.

> that is validated every time you boot (e.g. connect to the overlay).

K, so the x.509 cert would be the "password", and the difference would
be that the "validation" would yield value, i.e. the "cookie", that
would be used for authentication.  So, you're thinking that you just
pass the 509 cert around?

> and we want a p2p distributed service.

Yes, I am a firm believer in a trusted third party acting as an
authority.

> provides that also as a p2p distributed service.

I'm leery of this.  At the bottom of that is some peer vouching for some
other peer.  I don't think thats good enough in many situations.  The
central authority doesn't have to be Big Brother, it just has to be
something trusted.  Who knows, that may be one or a group of peers
acting as the trusted authority in some deployment situations, but it
could be Big Brother too if thats required.

Its interesting, you've mentioned the DHT a number of times.  I've been
following this list for quite some time.  Maybe I missed it but is the
protocol being done such that the use of a DHT is assumed?

FM

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 28 Nov 2006 12:30:25 -0600

Without reference to the specific proposal, this is a good example of the 
level of detail we need in order to have discussions that go someplace and 
terminate in finite time - we'll be chartered to produce specifications, not 
to fill up working group mailing list archives!

Frank, thanks for being concrete. The followups show that this posting 
helped people understand what was being proposed.

Spencer

>>         solutions to

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 28 Nov 2006 14:15:49 -0500

We haven't designed the whole mechanism for authenticating to the overlay
network yet, so it's hard to really compare ideas.  Cookies, as a way to
shortcut more expensive authentication/authorization mechanisms can be
useful.  Don't know yet whether we'll be using such ideas.

I do think that one way this could work is that the centralized credential
authority issues a cert which contains the identity in the domain.
Authentication would be a typical RSA operation using the cert to prove that
the peer is the identity in the cert.

We'll all agree we need a trusted entity to issue credentials.  The question
is do we need one to validate the credential (that is, provide
authentication services)?  I'd say, no, we don't.  If you get a credential
from a trusted source, we can use p2p mechanisms to validate that
credential.  We don't have to trust another peer; each peer can do the
authentication itself.  In the current environment, the idea of doing a full
credential check with RSA-1024 seems quite reasonable, done at a peer, per
call, as long as it only takes ONE hunk of crypto.  We don't need to
optimize that.  Similarly, we can do that kind of validation before we start
accepting the DHT data exchange messages that manage the distributed hash
table from a peer.  There doesn't seem to be a need for a centralized
mechanism for that either.  

I'm sure there are other mechanisms that would have distributed credential
checking, and they may have advantages over the above.  I don't see any
substantial advantage of your idea over mine, and mine is p2p past the
issuing of the cert, which is a substantial advantage I think.

Yes, I think we have agreed we will use a DHT.  Our charter actually says we
choose one mandatory-to-implement DHT.  I don't think the text actually has
to limit the overlay mechanism to using a DHT, but we'll see how torturous
the text gets if we make it neutral as to mechanism.

Brian

> Sent: Tuesday, November 28, 2006 1:24 PM
> To: Brian Rosen

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 28 Nov 2006 15:05:22 -0500

User auth is cached locally on a PC , and can be cached for a long time
without access to the DC, the ticket duration can be tuned.  On connection
to the DC via a VPN or local connection the ticket is refreshed, which
allows a single user login session to be indefinitely long, which is why
login scripts fail for many users: they log in once per reboot.

>From a user perspective they logged in once many months ago with sessions
that are stored via hibernation.

For service tickets, the valid range is from 0 to 99,999 minutes. For user
tickets, the valid range is from 0 to 99,999 hours. A value of zero
effectively turns off expiration. Any other value sets a specific ticket
lifetime. Under the hood tickets get renewed, DC's get contacted, but only
once in a while.  A roaming user can be away for months without a DC
login.

A ticket value of zero is the common ticket length for road warriors for
just this purpose.

The same can be true for P2PSIP of course,  the tickets can be renewed on
contact with supernodes, which are identical to domain controllers at the
data level, with the provisio that their databases are cached.

A domain controller is nothing but a DHT with a hash ratio of 100%, a full
table.

In fact, in my analysis, ongoing moves and changes that are inherent in
Domain Controllers reduce the hash value to 98-99%.  In effect Active
Directory is already a DHT, and a good proof of viability.

Regards

M

On 11/28/06, Sean Olson <seanol at exchange.microsoft.com> wrote:
> A key difference with domain auth is that you do need access to the DC for
most auth needs. Kerb tickets last hours not months. Cert based auth can
give you those longer durations at a cost. We've also implemented other auth
techniques with P2P in Vista.
> From: p2p-sip-bounces at cs.columbia.edu [mailto:
p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
> Sent: Tuesday, November 28, 2006 9:53 AM
> To: Brian Rosen
> > > > service that authorizes you AT CALL TIME, at least the first time
per
> > > boot?
> > > > distributed hash table takes care of authentication and
authorization
> > > peer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/7b73de0f/attachment.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 28 Nov 2006 12:32:45 -0800

I agree with Spencer, detail is useful for fleshing out these issues.

Regarding the DHT/certificate proposal, am I correct in understanding it
would work something like this?

1) User installs client from any number of vendors
2) User chooses from any number of certificate authorities (eg, "@blah.com")
3) That CA grants the user a unique name (eg, "david at blah.com")
4) The client generates a public/private keypair
5) The client uploads the public key to the CA
6) The CA digitally signs a certificate with its public key saying:
	"The client with public key X is 'david at blah.com'"
7) The client publishes its current IP address in a DHT
8) Some other user types "david at blah.com" into his P2P-SIP client
8) That client contacts "blah.com" to download the CA's public key
10) That client contacts the DHT to find the IP for "david at blah.com" 
11) That client connects to "david at blah.com" directly
12) That client asks "david at blah.com" for its certificate
13) That client validates the certificate's digital signature
14) That client trusts the remote peer is actually "david at blah.com"

Is this about right?  I think this is all great, except for one key usecase:

	What happens if my laptop gets stolen?

There are only two possible answers:

a) Your identity is stolen until your certificate expires (ie, months)
b) The CA publishes a "certificate revocation list" that is checked on call

The first case is just simply unacceptable.  Imagine if you lost your cell
phone and said "Hi, I'd like to prevent whoever stole my phone from using
it" and they said "Sure thing, let's just wait for the old one to expire in
6 months."  Users would reject this in a heartbeat.  I expect they'd
continue to reject it even if it were measured in days; possibly even hours.

The second case reduces this super complex really fancy distributed solution
back down to a simple centralized directory lookup conducted every time you
call someone.  And if we do that, why not just skip all the useless PKI and
just do a simple directory lookup on "@blah.com" (as Frank suggests)?

And if you do *that*, why are we bothering with the DHT -- why not just have
the "@blah.com" server also keep track of my IP address?

Or am I misunderstanding the PKI proposal?

-david

> Sent: Tuesday, November 28, 2006 10:30 AM

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 28 Nov 2006 15:36:47 -0500

Again using Windows as the use-case, you  encrypt the file system and have a
strong password.

Both file system and access control depend on a strong password.

In fact this is exactly how it done in their new mobile operating system,
the implications being that it would be a strong vessel for P2PSIP.

Regards

M

On 11/28/06, David Barrett <dbarrett at quinthar.com> wrote:
> > > shared secret that was setup when the UAI was issued.  The shared
> secret
> > > must
> > > be sent encrypted.
> > >
> > >
> > >   200 OK
> > >   UAI: Frank
> > >>         never is.  In the real world, there's always a central
> service
> > >>         behind the
> > >>         curtain:
> > >>
> > >>         - In Skype's case, it's a central directory at a hard-coded
> IP
> > >>         address.
> > >>
> > >>         (or similarly vague explanations) for the entire course of
> the
> > >>         P2P-SIP
> > >>         understand that there's a lot of interest in how the
> remaining
> > >>         0.001% of
> > >>         get, or couldn't easily be configured to have DNS has
> remained
> > >>         unanswered.
> > >>         response and propagation time than DNS.  But Akamai,
> UltraDNS,
> > >>         and other
> > >>         work better in partially or totally disconnected scenarios,
> or
> > >>         how to make
> > >>         > Except for bootstrapping to get the first two nodes
> talking.
> > >>         Which, if on
> > >>         > So P2PSIP includes a web-of-trust security model? If so,
> why
> > >>         not leverage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/3e900e65/attachment-0001.html

---

From: fwmiller at cornfed.com (Frank W. Miller)
Date: Tue, 28 Nov 2006 13:43:31 -0700

> mechanism for that either.  

This is my lack of security background showing through but how does this
actually work?  I mean, when you go to validate, how can you do so
without consulting the trusted entity?

So, lets say some UA wants to set up a call with you.  They send you a
credential and you RSA it. This gets you some other value.  Are you
saying that you already know what the resulting value is supposed to be
so you don't need to consult the authority?  If so, how did you find out
that value?

> the text gets if we make it neutral as to mechanism.

This worries me a little bit (although not hugely).  As an implementor,
I'd like to be able to use some flooding algorithm like Gnutella or
something just cuz its a lot easier to implement.  Is it possible to
just define the interface to the P2P overlay, maybe with some indication
of the algorithm being used internally, and leave it at that?  It seems
to me that DHT algorithms and P2P overlay algorithms in general are
going to evolve going forward.  It would be a shame to tie the protocol
to one unnecessarily.

FM

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 28 Nov 2006 15:51:43 -0500

That is a current architectural limitation of Active Directory, one that
clearly delineates clients and servers as separate entities. Clients do not
normally trust each other. Remove those two restrictions and the need for
servers is eliminated using existing authentication regimes.

Regards

M

On 11/28/06, Sean Olson <seanol at exchange.microsoft.com> wrote:
>
>  User auth caching is for local login.  Kerb ticket caching works when **
> you** cannot access the DC. It won't work for the remote peer in a P2P
> system.
>
>
>
> *From:* Michael Slavitch [mailto:slavitch at gmail.com]
> *Sent:* Tuesday, November 28, 2006 12:05 PM
> *To:* Sean Olson
> *Cc:* Brian Rosen; p2p-sip at cs.columbia.edu
> *Subject:* Re: [p2p-sip] Fwd: what's wrong with DNS?
>
>
>
> > A key difference with domain auth is that you do need access to the DC
> for most auth needs. Kerb tickets last hours not months. Cert based auth can
> > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu
> ] On Behalf Of Michael Slavitch
> > On 11/28/06, Brian Rosen < br at brianrosen.net> wrote:
> > >
> > > > From: Frank W. Miller [mailto: fwmiller at cornfed.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/b6b8dd33/attachment.html

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 28 Nov 2006 14:51:31 -0600

Hi, Frank,

> going to evolve going forward.  It would be a shame to tie the protocol

This is roughly the same situation as crypto algorithms - where the state of 
the art will never be stable.

We want to be "algorithm-agile", so we're not tied to today's state of the 
art forever, but we also select one algorithm as "mandatory-to-implement", 
so there is some chance that you'll be able to communicate with a device 
from another source.

Hope this helps,

Spencer

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 28 Nov 2006 12:56:05 -0800

I'm not sure I understand this answer.  Are you saying that someone stealing
my laptop doesn't matter because my file system is encrypted, and thus they
can't log in as me anyway?  This seems to overstate the prevalence of
encrypted hard drives; I'd wager that nearly 0% of users on a global scale
do this.

Are you suggesting that P2P-SIP's security model should assume a totally
encrypted hard drive?

And even assuming this, are you saying that if someone steals my laptop
*and* my password, there is no resolution to the problem other than to wait
it out?

I'm not sure users will like this.

-david

  _____  

From: Michael Slavitch [mailto:slavitch at gmail.com] 
Sent: Tuesday, November 28, 2006 12:37 PM
To: David Barrett
Cc: Spencer Dawkins; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

Regards

M

1) User installs client from any number of vendors 
2) User chooses from any number of certificate authorities (eg, "@blah.com")
3) That CA grants the user a unique name (eg, "david at blah.com
<mailto:david at blah.com> ")
4) The client generates a public/private keypair
5) The client uploads the public key to the CA
6) The CA digitally signs a certificate with its public key saying:
        "The client with public key X is ' david at blah.com'"
7) The client publishes its current IP address in a DHT
8) Some other user types "david at blah.com" into his P2P-SIP client 
8) That client contacts "blah.com" to download the CA's public key
10) That client contacts the DHT to find the IP for "david at blah.com "
11) That client connects to "david at blah.com" directly
12) That client asks "david at blah.com" for its certificate
13) That client validates the certificate's digital signature 
14) That client trusts the remote peer is actually "david at blah.com"

-david

> >> On 11/28/06, David Barrett < dbarrett at quinthar.com> wrote:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/ae260669/attachment-0001.html

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Tue, 28 Nov 2006 12:56:59 -0800

> so you don't need to consult the authority?  If so, how did you find out

The credential contains:
   - Your information
   - The identity of the trusted third party
   - A signature from the trusted third party.

RSA lets you verify that that signature is in fact from the trusted
third party is in fact over that data.

> going to evolve going forward.  It would be a shame to tie the protocol

The issue isn't about tying it to a single protocol but ensuring
that two independent implementations can talk to each other.
That requires that they implement a common protocol.

-Ekr

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 28 Nov 2006 13:29:37 -0800

> Internet traffic. Numbers between 60% and 80% have been published.

I apologize, but I think that's just simply false and misleading.

First, virtually all of that traffic is file-sharing traffic designed to
preserve anonymity, which is the direct opposite of our problem.  Using that
as justification to keep our system "clean" of DNS is a red herring.

But even ignoring that, most of that traffic is Bittorrent, which *does* use
DNS not only for search (to find torrents on btjunkie.org and so forth), but
to find peers (to contact the tracker).

At the end of the day, DNS is a fundamental part of the internet, used by
virtually very user not only ever day, but almost every minute.  If DNS went
down globally, the vast majority of internet traffic would also slow to a
stop (web, email, bittorrent, etc).  There would be a few survivors -- Skype
with its hard-coded IPs would persevere, along with eDonkey, Kazaa and other
anonymous or totally closed/private services, but about everything else
would grind to a halt.  Planning on how to keep working without DNS is like
planning on how to work without power -- you just don't.  If DNS goes down,
we have bigger problems to worry about.

We certainly *can* reinvent the wheel and figure out how to keep working in
this apocalypse scenario, I just don't see why we should bother. 

-david

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 28 Nov 2006 18:20:34 -0500

I couldn't have said it better, David (I probably would have said it much
worse!).  I have yet to hear any arguments against this approach compelling
enough to warrant the complexity of the proposed solutions.  I continue to
think the solution is not appealing to people because it's too simple and
not sexy enough, regardless of real-world applicability -- it's
anticlimactic, as you said.

I unfortunately don't have the incentive or the time to keep pushing this
perspective, though.  If the decisions of this list actually affected me in
some way, I'd argue this thing to the ground, because I think it's clearly
the winning idea.  It's tragic for decisions at this high a level to be
decided by attrition rather than technical merit, but that appears to be
what's happening barring some groundswell of support from the group's core
participants.  Maybe there's some compelling argument out there against the
DNS solution for the connected-internet case, but I have yet to hear it.

There's a lot of talk about what happens in "real p2p systems."  Both David
and I have a great deal of experience with these systems, folks (core
developers of LimeWire/Last Bamboo and RedSwoosh/iGlance).  We don't need
convincing about the merits of DHTs, the various bootstrapping solutions out
there, etc etc.  I think it's interesting, though, that the p2p guys are the
ones arguing for the more "centralized" approach.  It's in the interest of
seeing the work here deployed on a meaningful scale, which to me means
implementing the simplest solution that will work.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/fe6fc350/attachment.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 28 Nov 2006 15:25:01 -0800

Signed credentials are encrypted in local filesystem as files or Windows
registry entries. The filesystem needs not be encrypted entirely.

If you ever act as multiple Skype users with your laptop, you should have
found that you need different passwords to retrieve individual credentials
as you switch among the userids you've applied from Skype server. This is
what I meant by "sophistication" (of Skype) long time ago, which is an issue
of software design instead of protocol standardization :(

Peter
----- Original Message -----
From: David Barrett
To: 'Michael Slavitch'
Cc: p2p-sip at cs.columbia.edu
Sent: Tuesday, November 28, 2006 12:56 PM
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

-david

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Tue, 28 Nov 2006 18:35:26 -0500

David's breakdown described in best, earlier in this thread.  Here it is
again:

 2)       When I start my client up, I choose any non-firewalled peer (how
do I find it?) and REGISTER myself with it as something like 'dbarrett@
dbarrett.p2psip.org'

 6)       Repeat.

On 11/28/06, Eunsoo Shim <eunsooshim at gmail.com> wrote:
> > make it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/6f8c0b51/attachment-0001.html

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 28 Nov 2006 16:29:45 -0800

Adam Fisk:

6)       Repeat.

I would add to this that if you are yourself not firewalled, you should be
able to REGISTER with "yourself" and your machine should be able to directly
process inbound calls that arrive.

If you are firewalled, clearly a node is needed that can relay call setup
messages to you, and pretty clearly those should just be normal SIP
messages. There's a good argument for allowing one to register with more
than one at a time and point the dynamic DNS appropriately.

Additionally, you should also answer mDNS queries for you.p2psip.org with
your local self-proxy, so that machines on your LAN can call you directly
whether or not the DNS is reachable, if their SIP clients are mDNS-aware.

As for your open issue of finding a non-firewalled peer to register with?
Use the DNS to get an address of one inside of p2psip.org (if that's the
domain within which you're operating) Note that this covers the case of an
organization that wants the clients registered with a stable machine or
machines that it operates instead of with client machines acting as
registrars. The organization can also set policy around what addresses can
be registered, if credentials are required, etc.

The real work that needs doing is coming up with a minimal set of
recommended existing standards plus the minimal extensions necessary such
that a working system can be built. Clearly STUN or better is needed for NAT
traversal. Clearly SIP itself is the call signaling, though extensions might
enable neat P2P capabilities. There's some work around using mDNS for the
detached-from-real-Internet cases. There's some work around what the
necessary security infrastructure, if any, might need to be. There's some
work around the canonical way of finding non-firewalled peers and
distributing load among them. There might need to be work around how the DNS
entries get updated. And there might need to be some work around building a
big distributed dynamic DNS system for the case where a domain needs many
thousands of peer entries but can't afford or doesn't want to operate a
centralized cluster of those servers. I would point out, however, that the
last item is already an active research topic, and not really a P2P SIP
issue at all.

Using DNS as the protocol for the node-finding mechanism (and possibly as
the credential-lookup mechanism) means that inbound calls from existing SIP
clients should "just work", and that each domain can set its own policies
around whether the node-lookup (DNS) function is centralized or distributed
and whether the registrar function itself is centralized or distributed.
Then enabling zeroconf mDNS on top of that covers the case where you can't
talk to anyone but other clients on your ad-hoc network. And I think that's
100% of the enumerated use cases.

With no time spent on new signaling messages for outdated DHT architectures
as mandatory client components.

Matthew Kaufman

matthew at matthew.at

ps. To reflect on what Adam said about people who've built "real p2p
systems", we built a secure P2P VOIP softphone at amicima, and we spent a
lot of time thinking about per-domain policy for architecture (distributed
vs. centralized name to address lookup and NAT traversal functionality) and
security (centralized vs. distributed trust models, certificate signing,
etc.), which our MFPNet protocol supported. We used our secure media flow
protocol to transport the signaling messages, the audio, and the
simultaneous file transfers rather than pure SIP for signaling and RTP for
the audio (because we think that media prioritization is a big deal and that
even RTP is going to wish it had TCP-compatible congestion control some
day), but what we see here is essentially the same problem, and I too am
looking to make sure that what gets specified as the "P2P extensions to SIP"
is the simplest solution that will serve real user needs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/04421453/attachment.html

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 28 Nov 2006 17:14:36 -0800

The outstanding question is in (2) and (5): how do I find a willing,
non-NAT'd volunteer SIP proxy?  (And the same question can be asked of STUN
and TURN servers.)  And for this task, a DHT might be well suited.
(Non-NAT'd nodes that are willing to volunteer their resources run a
standard SIP proxy and STUN/TURN server, and then register themselves in a
global DHT.  One is as good as any other, so a DHT is well-suited to this
task.)

But the user identification itself is done and enforced through DNS.  The
only way to steal dbarrett.quinthar.com <mailto:dbarrett at phone.quinthar.com>
from me is to steal my domain name, which already has legal and trademark
protections, international conflict resolutions, and so on.  

So wherever "I" am on the internet, I update "my" IP address for
dbarrett.quinthar.com using dynamic DNS.  This way I can run a webserver,
Jabber server, FTP server, SIP phone, or whatever else I want on my laptop,
and it follows me wherever I go.

There is of course the problem that most of the time my laptop is behind a
NAT, so the IP address stored in the DNS record is probably 192.168.xxx.yyy,
but at least if we're behind the same NAT you'll just be able to type in my
DNS name and connect to my computer.  (Though I could publish multiple IP
addresses in the DNS record - one for the LAN, one for my NAT.)

And this neatly extends to an mDNS world, thus enabling you to access me in
exactly the same way, whether we're on opposite sides of the planet via
internet, or sitting next to each other in the middle of a desert connected
by a 12" crossover cable.

We could even use other DNS records to publish my latest public key hash, my
human name, my real telephone number, and so on.

And all this could work *today*.

-david

  _____  

From: Adam Fisk [mailto:adamfisk at gmail.com] 
Sent: Tuesday, November 28, 2006 3:35 PM
To: Eunsoo Shim
Cc: David Barrett; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

6)       Repeat.

Eunsoo

-david

> To: hsinnrei at adobe.com; slavitch at gmail.com  <mailto:slavitch at gmail.com> 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/b72c4b80/attachment-0001.html

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Tue, 28 Nov 2006 21:39:55 -0500

For what it's worth, there was some discussion on the list and in  
meetings that mDNS and similar approaches could well be valuable, but  
that existing venues, such as SIPPING, would be sufficient to discuss  
the likely minor details that need to be specified. Indeed, we're  
working on such a specification. (One of the tactical problems is  
that mDNS is not an IETF standard and unlikely to become one in its  
current form, if I'm judging the zeroconf state correctly. Somebody  
with more familiarity with the group's fate can chime in here, as  
zeroconf is no longer an active WG.)

The main problem I see with DNS is more practical: setting up an  
authoritative DNS server correctly seems to require a fair amount of  
deep networking knowledge. Words like "lame delegation" come to mind.  
(This gets worse since you are supposed to set up at least two such  
servers that synchronize with each other, in independent networks.)  
Whether that's a failure of current implementations or something more  
fundamental, I don't know. One of the attractions of the DHT model is  
that you can set up a local system by just installing software on a  
laptop, plus maybe a credentialing system for larger systems with  
potentially malicious users.

While every enterprise runs a DNS server, I'd wager that the large  
majority are not set up to allow individual users (as opposed to,  
say, the DHCP server) to update individual DNS entries. This isn't an  
issue for a carrier wanting to build a public service, but then I'm  
confused as to why such a carrier doesn't just use the current SIP  
server model. Just saving a few registrar boxes doesn't seem worth  
the hassle.

In general, nobody keeps people from doing work. I personally think  
that having a team of interested individuals work out what needs to  
happen for dynamic DNS to work on a realistic scale would be quite  
interesting. Depending on the details, this work could well find a  
home in SIPPING or a DNS-related WG, or maybe neither, if this is all  
just combining existing protocols.

The ability to find willing registrars and STUN servers is likely to  
be shared by any DHT or DNS solution, although a simpler centralized  
registry (e.g., via SLP, see our work on domain-based SLP) is also  
feasible.

Henning

On Nov 28, 2006, at 6:20 PM, Adam Fisk wrote:

> I couldn't have said it better, David (I probably would have said  
> it much worse!).  I have yet to hear any arguments against this  
> approach compelling enough to warrant the complexity of the  
> proposed solutions.  I continue to think the solution is not  
> appealing to people because it's too simple and not sexy enough,  
> regardless of real-world applicability -- it's anticlimactic, as  
> you said.
>
> I unfortunately don't have the incentive or the time to keep  
> pushing this perspective, though.  If the decisions of this list  
> actually affected me in some way, I'd argue this thing to the  
> ground, because I think it's clearly the winning idea.  It's tragic  
> for decisions at this high a level to be decided by attrition  
> rather than technical merit, but that appears to be what's  
> happening barring some groundswell of support from the group's core  
> participants.  Maybe there's some compelling argument out there  
> against the DNS solution for the connected-internet case, but I  
> have yet to hear it.
>
> There's a lot of talk about what happens in "real p2p systems."   
> Both David and I have a great deal of experience with these  
> systems, folks (core developers of LimeWire/Last Bamboo and  
> RedSwoosh/iGlance).  We don't need convincing about the merits of  
> DHTs, the various bootstrapping solutions out there, etc etc.  I  
> think it's interesting, though, that the p2p guys are the ones  
> arguing for the more "centralized" approach.  It's in the interest  
> of seeing the work here deployed on a meaningful scale, which to me  
> means implementing the simplest solution that will work.
>
> -Adam
>
>
>

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 28 Nov 2006 23:29:35 -0800

> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> (One of the tactical problems is

mDNS appears to be on the standards track:

http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt

Submitted 2006/8/10, expires 2007/2/10.

> deep networking knowledge. ...
> fundamental, I don't know.

Good question.  It might be hard merely because there's been no reason to
make it easy, until now.  There seems no fundamental reason why it need be
complex.

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 29 Nov 2006 00:49:05 -0800

I completely agree with Matthew here.  Basing this on DNS gives the domain
owner extreme flexibility over how he wants to manage the users on that
domain.  For example:

-          A large provider (eg, Yahoo) might offer a standard public SIP
proxy for millions of general users at [email-masked]

-          A large company (eg, Intel) might manage its own private SIP
proxy for thousands of employees [email-masked]

-          A small company on a DSL connection might have a simple desktop
computer running a standard SIP proxy a dozen employees at [email-masked],
updating the IP of the proxy using a standard dynamic DNS client.

-          An individual, fixed user might have a static IP on his
cablemodem and thus run both a SIP proxy and SIP client on the same computer
for dbarrett at dbarrett.quinthar.com

-          An individual, mobile user might have a laptop running an
integrated SIP-proxy/SIP-client/dynamic-DNS/mDNS client that updates the
dbarrett.quinthar.com <mailto:dbarrett at dbarrett.quinthar.com>  record to
wherever the laptop is right now (perhaps using a DHT to find volunteer
anonymous SIP proxies and STUN/TURN servers if behind a NAT), and that
advertises itself on dbarrett at dbarrett.quinthar.com.local for totally
infrastructureless, ad-hoc environments

This spans the entire range of the largest to the smallest, the most fixed
to the most mobile environment.  With the exception of some kind of DHT to
find a cloud of public resources (ie, SIP proxies that will let anybody
register with them from any domain, as well as STUN and TURN servers),
everything is done with existing technologies.

Furthermore, only the "individual, fixed" and "individual, mobile" use cases
require anything that can't be deployed off the shelf right now, and even
that is just a repackaging of existing technologies (with the exception of
the public-resource DHT, if we choose to go that route).  Indeed, it's not
hard to imagine a well-packaged SIP client that has an install wizard
saying:

What is your SIP address?

a)       I already have an address assigned to me (eg, dbarrett at yahoo.com)

b)      I have no address, please help me create one

(Choose B) Every address consist of a username and a domain.  What domain do
you want to use?

a)       I want to use an existing domain (choose from a list of public
providers, eg @yahoo.com)

b)      I want to buy a new domain (choose from a list of domain providers)

c)       I want to get a free domain (choose from a list of free providers,
such as DynDNS)

d)      I want to use a domain I already own (enter the domain)

(Choose D) Testing. dbarrett.quinthar.com is registered with 'DynDNS, Inc',
which is a recognized dynamic DNS provider.  Enter your DynDNS name and
password and we will automatically update dbarrett.quinthar.com to be
associated with this computer, even if it changes networks.

(Enter name/pw) Testing. we've confirmed our ability to update
dbarrett.quinthar.com.  Your new SIP address is
dbarrett at dbarrett.quinthar.com. 

Basically, make the client aware of dynamic DNS, use the standard dynamic
DNS update protocols, and it can be made really easy for the user.
Similarly, this SIP client could act as an mDNS server (on OS's that don't
already support it) and thus autodetect other P2P-SIP clients on an ad-hoc
network.  

It can be totally self-configuring and seamlessly scalable from huge to tiny
deployments, without requiring a benevolent dictator or inventing a
replacement for the IANA.

-david

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Matthew Kaufman
Sent: Tuesday, November 28, 2006 4:30 PM
To: 'Adam Fisk'; 'Eunsoo Shim'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

Adam Fisk:

6)       Repeat.

 

Matthew Kaufman

matthew at matthew.at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061129/8dc0b6cc/attachment-0001.html

---

From: edpimentl at gmail.com (Ed Pimentel)
Date: Wed, 29 Nov 2006 04:33:05 -0500

In vehement agreement on thinking of new more efficient methods to  
look up, besides DNS.
We do not have to view every problem like a nail and use the hammer(DNS)
However if a  kindler, gentler and 1000 points of light  - better/ 
faster/cheaper DNS is to be implemented
please look into steroid performance of CoDnS
http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/ 
codons.html

> DNS, which reflected the times and the organizations that invented it

Sincerely,

Ed Pimentel
AgileCO.net

Mail:   edpimentl at gmail.com
sip:    sip:2150112 at truphone.com
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile Payment/P2P
http://agilepay.ws/ws

Mobile Social Network (Private Label)
http://GooGaYa.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061129/333024e3/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Wed, 29 Nov 2006 08:01:48 -0500

<not as chair, although at present, I?m not chair of anything>
I suggest that you take Henning?s advice, write up an Internet Draft, and
submit it to sipping.  
It may be an interesting enough idea to enough folks that you can get an RFC
out of it.

It does not meet the charter of p2psip as determined by list and BOF
consensus.  It really is a different set of ideas.  Those ideas may have
merit, they just don?t fit here.

As a suggestion if you do decide to proceed:
Consider defining the idea as a DDDS application
Consider that dbarrett at dbarrett.quinthar.com is not really what you want,
you want dbarrett at quinthar.com.  You want that sip address to resolve to a
host who is named dbarret.quinthar.com for this purpose.  A DDDS application
could start with that string, convert it to dbarrett.quinthar.com, and do a
DNS query for a NAPTR that got you what you wanted.
You might want something in the quinthar.com domain that indicates that it
participates in the scheme you describe, since a normal sip client getting a
request for dbarrett at quinthar.com would try to find the sip proxy at
quinthar.com.  If quinthar.com doesn't operate a sip proxy, but instead has
a resolution scheme like you imagine, you might want it to say so
explicitly.

Please do consider the security implications of this proposal.  I think
those are the real Achilles heel of the idea.  Proxy servers provide a
useful capability that controls incoming calls.  Our current ideas work
pretty much like a "Closed User Group", using a credential to authorize
placement of a call within the CUG.  We may need more controls that that.

Brian

________________________________________
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Wednesday, November 29, 2006 3:49 AM
To: matthew at matthew.at; 'Adam Fisk'; 'Eunsoo Shim'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

I completely agree with Matthew here.? Basing this on DNS gives the domain
owner extreme flexibility over how he wants to manage the users on that
domain.? For example:

- A large provider (eg, Yahoo) might offer a standard public SIP proxy for
millions of general users at [email-masked]
- A large company (eg, Intel) might manage its own private SIP proxy for
thousands of employees [email-masked]
- A small company on a DSL connection might have a simple desktop computer
running a standard SIP proxy a dozen employees at [email-masked], updating
the IP of the proxy using a standard dynamic DNS client.
- An individual, fixed user might have a static IP on his cablemodem and
thus run both a SIP proxy and SIP client on the same computer for
dbarrett at dbarrett.quinthar.com
- An individual, mobile user might have a laptop running an integrated
SIP-proxy/SIP-client/dynamic-DNS/mDNS client that updates the
dbarrett.quinthar.com record to wherever the laptop is right now (perhaps
using a DHT to find volunteer anonymous SIP proxies and STUN/TURN servers if
behind a NAT), and that advertises itself on
dbarrett at dbarrett.quinthar.com.local for totally infrastructureless, ad-hoc
environments

to the most mobile environment.? With the exception of some kind of DHT to

Furthermore, only the ?individual, fixed? and ?individual, mobile? use cases
require anything that can?t be deployed off the shelf right now, and even
that is just a repackaging of existing technologies (with the exception of
the public-resource DHT, if we choose to go that route).? Indeed, it?s not
hard to imagine a well-packaged SIP client that has an install wizard
saying:

(Choose B) Every address consist of a username and a domain.? What domain do
you want to use?
a) I want to use an existing domain (choose from a list of public providers,
eg @yahoo.com)
b) I want to buy a new domain (choose from a list of domain providers)
c) I want to get a free domain (choose from a list of free providers, such
as DynDNS)
d) I want to use a domain I already own (enter the domain)

(Choose D) Testing
 dbarrett.quinthar.com is registered with ?DynDNS, Inc?,
which is a recognized dynamic DNS provider.? Enter your DynDNS name and
password and we will automatically update dbarrett.quinthar.com to be
associated with this computer, even if it changes networks.

(Enter name/pw) Testing
 we?ve confirmed our ability to update
dbarrett.quinthar.com.? Your new SIP address is
dbarrett at dbarrett.quinthar.com. 

Basically, make the client aware of dynamic DNS, use the standard dynamic
DNS update protocols, and it can be made really easy for the user.?
Similarly, this SIP client could act as an mDNS server (on OS?s that don?t
already support it) and thus autodetect other P2P-SIP clients on an ad-hoc
network.? 

-david

________________________________________

Adam Fisk:
David's breakdown described in best, earlier in this thread.? Here it is
again:
1)?????? Every user chooses a domain name.? Mine might be
'dbarrett.p2psip.org' 
2)?????? When I start my client up, I choose any non-firewalled peer (how do
I find it?) and REGISTER myself with it as something like
'dbarrett at dbarrett.p2psip.org'
3)?????? After registering with the peer/proxy, I contact some
highly-redundant set of dynamic DNS servers and say "this is the latest IP
address of my proxy, point to it whenever anyone does a DNS lookup on
dbarrett.p2psip.org"
4)?????? Your off the shelf, totally unaltered SIP client asks DNS for the
IP of 'dbarrett.p2psip.org', gets the latest IP of my proxy, and looks up
the user 'dbarrett at dbarrett.p2psip.org', and then contacts me as normal.
5)?????? If the peer I chose as my proxy goes down, I detect it immediately
and choose a new non-firewwalled peer (again, how do I find it?), REGISTER
with that as in step (2), and update my dynamic DNS binding as in step (3).
6)?????? Repeat.

I would add to this that if you are yourself not firewalled, you should be
able to REGISTER with ?yourself? and your machine should be able to directly
process inbound calls that arrive.

If you are firewalled, clearly a node is needed that can relay call setup
messages to you, and pretty clearly those should just be normal SIP
messages. There?s a good argument for allowing one to register with more
than one at a time and point the dynamic DNS appropriately.

As for your open issue of finding a non-firewalled peer to register with?
Use the DNS to get an address of one inside of p2psip.org (if that?s the
domain within which you?re operating) Note that this covers the case of an
organization that wants the clients registered with a stable machine or
machines that it operates instead of with client machines acting as
registrars. The organization can also set policy around what addresses can
be registered, if credentials are required, etc.

The real work that needs doing is coming up with a minimal set of
recommended existing standards plus the minimal extensions necessary such
that a working system can be built. Clearly STUN or better is needed for NAT
traversal. Clearly SIP itself is the call signaling, though extensions might
enable neat P2P capabilities. There?s some work around using mDNS for the
detached-from-real-Internet cases. There?s some work around what the
necessary security infrastructure, if any, might need to be. There?s some
work around the canonical way of finding non-firewalled peers and
distributing load among them. There might need to be work around how the DNS
entries get updated. And there might need to be some work around building a
big distributed dynamic DNS system for the case where a domain needs many
thousands of peer entries but can?t afford or doesn?t want to operate a
centralized cluster of those servers. I would point out, however, that the
last item is already an active research topic, and not really a P2P SIP
issue at all.

Using DNS as the protocol for the node-finding mechanism (and possibly as
the credential-lookup mechanism) means that inbound calls from existing SIP
clients should ?just work?, and that each domain can set its own policies
around whether the node-lookup (DNS) function is centralized or distributed
and whether the registrar function itself is centralized or distributed.
Then enabling zeroconf mDNS on top of that covers the case where you can?t
talk to anyone but other clients on your ad-hoc network. And I think that?s
100% of the enumerated use cases.

Matthew Kaufman
matthew at matthew.at

ps. To reflect on what Adam said about people who?ve built ?real p2p
systems?, we built a secure P2P VOIP softphone at amicima, and we spent a
lot of time thinking about per-domain policy for architecture (distributed
vs. centralized name to address lookup and NAT traversal functionality) and
security (centralized vs. distributed trust models, certificate signing,
etc.), which our MFPNet protocol supported. We used our secure media flow
protocol to transport the signaling messages, the audio, and the
simultaneous file transfers rather than pure SIP for signaling and RTP for
the audio (because we think that media prioritization is a big deal and that
even RTP is going to wish it had TCP-compatible congestion control some
day), but what we see here is essentially the same problem, and I too am
looking to make sure that what gets specified as the ?P2P extensions to SIP?
is the simplest solution that will serve real user needs.

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 29 Nov 2006 06:08:24 -0800

Full agreement.

This list was created for P2P SIP as hammered out in the existing charter.

Other good ideas and approaches must start with an I-D that people can discuss.

I am personally using dyndns for my home SIP service and am sure new DNS approaches deserve a better status as IETF WGs. Henning's proposed approaches for such work is right. There is no need to tie up this WG with another topic.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Brian Rosen
Sent: Wednesday, November 29, 2006 7:02 AM
To: 'David Barrett'; matthew at matthew.at; 'Adam Fisk'; 'Eunsoo Shim'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?

<not as chair, although at present, I'm not chair of anything>
I suggest that you take Henning's advice, write up an Internet Draft, and
submit it to sipping.  
It may be an interesting enough idea to enough folks that you can get an RFC
out of it.

It does not meet the charter of p2psip as determined by list and BOF
consensus.  It really is a different set of ideas.  Those ideas may have
merit, they just don't fit here.

Brian

the public-resource DHT, if we choose to go that route).? Indeed, it's not

(Choose D) Testing... dbarrett.quinthar.com is registered with 'DynDNS, Inc',
which is a recognized dynamic DNS provider.? Enter your DynDNS name and
password and we will automatically update dbarrett.quinthar.com to be
associated with this computer, even if it changes networks.

(Enter name/pw) Testing... we've confirmed our ability to update
dbarrett.quinthar.com.? Your new SIP address is
dbarrett at dbarrett.quinthar.com. 

-david

Adam Fisk:

Matthew Kaufman
matthew at matthew.at

---

From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 29 Nov 2006 14:04:45 -0500

Hello;

> http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt

There are two variants of mDNS, as I understand it.

There is the Stuart Cheshire version that is not a WG product, but
is standards track, and is used :

http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-06

Then there is the official WG product,
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-47.txt

which may or may not be deployed. (There was a long email discussion  
of this forking of the
mDNS effort, I believe on the ietf list in 2005. Suffice it to say  
that Stuart was not very
happy about it.)

Regards
Marshall

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 29 Nov 2006 11:23:33 -0800

That's totally fair; I agree what we're discussing is far off the normal
P2P-SIP track.  I've just been trying to nail down precisely what we're
doing and why, as it seems a little unfocused.  For example, each of the
following questions has been individually answered different ways by
different people, and I'm struggling to get a coherent picture in my head of
what the true answers are all together:

- Do we have a centralized service in the sky that does realtime
authentication/authorization before every call is set up?  Or do we have
absolutely no servers and anybody can install a client and choose a name and
it magically just works and is totally secure?  I've heard everything across
the board on this, even though they're wildly divergent in terms of
architecture.

- Do we support the "change password" use case (I lost my laptop and my
competitor is taking my calls)?  I've heard absolutely nothing on this
front, suggesting the answer is "no" despite it being absolutely crucial.
Furthermore, I've heard no explanation for how we can support that use case
without a centralized realtime authentication/authorization service.

- I've heard absolute certainty that we'll have a DHT *somewhere*, but no
clear explanation for what it'll hold.  Credential information?  Does it
look up SIP proxies?  *Is* it a SIP proxy somehow?  It seems like we're
scrambling to justify its use.

- I've heard absolute certainty that DNS/mDNS can't be trusted for some
critical set of users, though nobody has been able to give a real-world
situation where that's true, and logically it seems like it will nearly
always be available.

- I heard gasps when I suggested that VoIP isn't useful when people are
sitting in easy voice and eyeball range of each other and thus that use case
isn't valuable, but no acknowledgement or rebuttal.

Basically, I've heard a wide ranging desire to support every protocol, every
networking environment, every conceivable use case, across every conceivable
timeline and deployment size.  But I've heard no consensus on anything that
we *won't* do. 

Except, of course, use DNS.

Regardless, like Adam, I've got no real skin in the game and thus only have
a sideline interest in helping P2P-SIP succeed, so I'll step down and let
you guys continue your work.  Thanks for the vigorous debate!

-david

> Sent: Wednesday, November 29, 2006 6:08 AM
> To: Brian Rosen; David Barrett; matthew at matthew.at; Adam Fisk; Eunsoo Shim
> I am personally using dyndns for my home SIP service and am sure new DNS
> approaches deserve a better status as IETF WGs. Henning's proposed
> approaches for such work is right. There is no need to tie up this WG with
> another topic.
> 
> Thanks, Henry
> 
> bounces at cs.columbia.edu] On Behalf Of Brian Rosen
> providers,

---

From: edpimentl at gmail.com (EdPimentl)
Date: Wed, 29 Nov 2006 14:40:17 -0500

The condundrum is that P2P_SIP as the infrastructure/technology and protocol
is its embryonic phase. A number of the questions which are being ask is
what will tackle during the operationalization of the service, along with
the business process, billing supports system and operational support
systems.

Having said that the WG wants to make sure that there is inherent
flexibility in P2P_SIP for JohnQPublic to call/connect/collaborate with
SusieAnyBody with out the fear  they will be encarcerated in an
unwilling-partner ims four-wall garden.
So if they ever completely builded with their enumerous ever changing
interfaces, their customer will be safely outside.

On 11/29/06, David Barrett <dbarrett at quinthar.com> wrote:
> > could start with that string, convert it to dbarrett.quinthar.com, and
> do
> > a
> > participates in the scheme you describe, since a normal sip client
> getting
> > a
> computer
> > using a DHT to find volunteer anonymous SIP proxies and STUN/TURN
> servers
> > if
> such
> > do
> > Additionally, you should also answer mDNS queries for you.p2psip.orgwith
> > entries get updated. And there might need to be some work around
> building
> > a

-- 
-Ed

Mail:       edpimentl[at]gmail[dot]com
VoIP:      edpimentl [Skype | GoogleTalk]
IM:          edpimentl [ AOL | Jabber | Yahoo | MSN ]

Mobile Content Management
http://mobilecentral.ws

Mobile Social Networks(Private Label)
http://GooGaYa.com

Mobile Payment
http://AgilePAY.ws
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061129/4e652731/attachment-0001.html

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 29 Nov 2006 14:47:12 -0500

> isn't valuable, but no acknowledgement or rebuttal.

SIP is useful in that case, for text (see the use of Jabber in IETF 
meetings, even within a room). We were never restricted here to just 
classical 'voice', as no RAI groups are.

Henning

---

From: br at brianrosen.net (Brian Rosen)
Date: Wed, 29 Nov 2006 14:48:50 -0500

I don't think we have much divergence of opinion.  We have a couple of

> the board on this, even though they're wildly divergent in terms of
You get a credential from a centralized credentialing service.  Thereafter,
you can use that credential (as long as it's valid) on any client and join
the overlay network.

> without a centralized realtime authentication/authorization service.
Here, we have not had much discussion, so we have no consensus.  I don't
THINK anyone is contemplating a centralized real time anything.

If you used a cert as a credential, then you might want to consult the CA's
CRL, or do something equivalent to make sure it was not revoked.

> scrambling to justify its use.
The DHT holds the data necessary to convert an address within the domain to
where you send an INVITE.  It may (I would say 'would') be the case that
before you can join the peer network and get access to the DHT, your
credential will be checked.  I don't think the DHT holds credentials.  A SIP
proxy may be a peer in the overlay network, so you could do name resolution
to that proxy within the overlay network.  It is NOT a SIP proxy.  We're not
scrambling to justify its use; we've chosen DHT as the mechanism for doing
address resolution.  Read the concepts document.

> situation where that's true, and logically it seems like it will nearly
Not an issue where there would be a consensus opinion within the p2psip
community.  I personally think this is not a big deal; you can get, and
really need DNS in a real network.

> isn't valuable, but no acknowledgement or rebuttal.
Ever watch people IM each other while they were in the same conference room?
No, I don't think p2psip is about voice.  It's about multimedia session
establishment, just like real sip.  No more, no less.  All the media works
the same way, which means IM and presence (and video and real time text)
work.

> timeline and deployment size.  But I've heard no consensus on anything
It's everywhere sip might be used, but where instead of proxies, we use p2p.
We allow a proxy to be a peer, so that UAs connected to that proxy
conventionally can call other p2psip peers/clients and vice versa.

> Except, of course, use DNS.
I expect we'll use DNS.  We haven't talked a lot, for example, about WHAT,
EXACTLY, you get from the DHT.  Is it a domain name or an IP address?  I'd
think it was a domain name, and you use DNS to resolve that to an IP
address.  No consensus on that, and it hasn't come up yet.

> you guys continue your work.  Thanks for the vigorous debate!
Thanks.  It's been interesting.

Are we now back to our regularly scheduled program?  Adam? Matthew?

Brian

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 29 Nov 2006 20:58:24 +0100

> address.  No consensus on that, and it hasn't come up yet.

The DNS can solve only the address resolution of the non-NAT-ed peer.  
One needs
more than dynamic DNS to merge a self-organizing network with SIP
functionality. No DNS server will be able to do parallel and serial
forking, aggregate presence information, NAT traversal, buddy list
synchronization among devices, redirect for not online to name a few
things one needs in the day-to-day communications. DNS is good for
bootstrap and and for providing global addressable URIs.

I think the WG should concentrate on a methodology of how to make a  
generic lookup
for a given resource when you have a list of boot strap nodes.  
Something like:

1. Use DNS or other bootstrap method to find a live peer in the P2P  
network
2. Perform a lookup function to the node to find a resource/service  
for a specific user in the P2P network

Example:

lookup sip_proxy for user at example.com
lookup voicemail for user at example.com
lookup storage for user at example.com
..

Adrian

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 29 Nov 2006 12:22:53 -0800

>You get a credential from a centralized credentialing service.  
>Thereafter, you can use that credential (as long as it's valid) on any
>client and join the overlay network.

This is correct and some folks also call it an enrollment server.

Note the enrollment server is basically similar to any e-commerce
enrollment server, except the usage mode may be very different depending
on the particular e-commerce scenario and business model. 
Why should the enrollment for Internet communications be different from
any other e-commerce enrollment?

We had discussed including the enrollment server on the list and
discarded it as out of scope. This was the right decision, since
blessing business models is not the business of the IETF (I wish this
would be also applied to IMS, and other walled garden extensions to
SIP).

Henry

-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Wednesday, November 29, 2006 1:49 PM
To: 'David Barrett'; Henry Sinnreich; matthew at matthew.at; 'Adam Fisk';
'Eunsoo Shim'

I don't think we have much divergence of opinion.  We have a couple of
pieces that have had scant attention paid thus far:

> absolutely no servers and anybody can install a client and choose a
name
> the board on this, even though they're wildly divergent in terms of
You get a credential from a centralized credentialing service.
Thereafter,
you can use that credential (as long as it's valid) on any client and
join
the overlay network.

If you used a cert as a credential, then you might want to consult the
CA's
CRL, or do something equivalent to make sure it was not revoked.

> scrambling to justify its use.
The DHT holds the data necessary to convert an address within the domain
to
where you send an INVITE.  It may (I would say 'would') be the case that
before you can join the peer network and get access to the DHT, your
credential will be checked.  I don't think the DHT holds credentials.  A
SIP
proxy may be a peer in the overlay network, so you could do name
resolution
to that proxy within the overlay network.  It is NOT a SIP proxy.  We're
not
scrambling to justify its use; we've chosen DHT as the mechanism for
doing
address resolution.  Read the concepts document.

> sitting in easy voice and eyeball range of each other and thus that
use
> case
Ever watch people IM each other while they were in the same conference
room?
No, I don't think p2psip is about voice.  It's about multimedia session
establishment, just like real sip.  No more, no less.  All the media
works
the same way, which means IM and presence (and video and real time text)
work.

> timeline and deployment size.  But I've heard no consensus on anything
It's everywhere sip might be used, but where instead of proxies, we use
p2p.
We allow a proxy to be a peer, so that UAs connected to that proxy
conventionally can call other p2psip peers/clients and vice versa.

> Except, of course, use DNS.
I expect we'll use DNS.  We haven't talked a lot, for example, about
WHAT,
EXACTLY, you get from the DHT.  Is it a domain name or an IP address?
I'd
think it was a domain name, and you use DNS to resolve that to an IP
address.  No consensus on that, and it hasn't come up yet.

Brian

---

From: br at brianrosen.net (Brian Rosen)
Date: Wed, 29 Nov 2006 15:57:56 -0500

Yeah.  I don't see a point in standardizing the enrollment server
interfaces.  I see some point in defining at least one
mandatory-to-implement form of credential tho.

Brian

> Sent: Wednesday, November 29, 2006 3:23 PM

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 29 Nov 2006 15:07:46 -0600

> mandatory-to-implement form of credential tho.

Strongly agree with Brian here.

Thanks,

Spencer

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 29 Nov 2006 16:13:56 -0500

Very much in agreement.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061129/f2d92a80/attachment.html

---

From: eunsooshim at gmail.com (Eunsoo Shim)
Date: Wed, 29 Nov 2006 16:51:27 -0500

http://www.p2psip.org/drafts/draft-singh-p2p-sip-00.txt

> scrambling to justify its use.

Kundan and Henning wrote a nice document that might give some answer to your
question.

http://www.p2psip.org/drafts/draft-singh-p2p-sip-00.txt

BTW, I have almost the same question about DNS for P2PSIP.

> Except, of course, use DNS.

I am still looking forward to hearing what is your  proposal exactly.
However, if you want to step down,  you can send me your thought off the
list.
For I don't want to revive the debate about DNS if it is fading out.

Thanks.

Eunsoo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061129/8603c5a7/attachment-0001.html

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Thu, 30 Nov 2006 08:13:55 -0800

> I see some point in defining at least one
> mandatory-to-implement form of credential

This is business decision for the owner(s) of the P2P system.

It would help though to have some BCP documents that cover several usage
scenarios.

Henry

-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Wednesday, November 29, 2006 2:58 PM
To: Henry Sinnreich; 'David Barrett'; matthew at matthew.at; 'Adam Fisk';
'Eunsoo Shim'

Brian

> > it magically just works and is totally secure?  I've heard
everything
> > across
> > Furthermore, I've heard no explanation for how we can support that
use
> > - I've heard absolute certainty that we'll have a DHT *somewhere*,
but
> no
> > clear explanation for what it'll hold.  Credential information?
Does
> > Basically, I've heard a wide ranging desire to support every
protocol,
> > every
> > timeline and deployment size.  But I've heard no consensus on
anything
> > Regardless, like Adam, I've got no real skin in the game and thus
only
> > have
> > a sideline interest in helping P2P-SIP succeed, so I'll step down
and
> let