Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03

From: ekr at networkresonance.com (Eric Rescorla)
Date: Mon, 30 Oct 2006 17:51:42 -0800

$Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54 ekr Exp $

GENERAL COMMENTS
Overall, this document is pretty good, however I think the bit about
the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of
confusing.

I definitely agree that there will be two kinds of nodes

- Those which store other people's state data.
- Those which don't.

The terms you've chosen (Peers and Clients) seem to be as good as any
for this purpose.

With that said, there are three basic designs:

1. Clients understand the overlay network, they just don't 
   store data. To take a concrete example from Chord, there's
   no reason you can't connect to a Chord node, suck down an
   appropriate finger/routing table and then send messages
   to other Chord nodes just as if you were a Peer. The 
   only thing you don't do is *register* with the network.

2. Clients don't understand the overlay network, they just
   treat some subset of peers as servers to which they can
   do gets/puts. This is roughly the architecture that OpenDHT
   implements now. 

3. Clients don't understand the overlay network and just treat
   it as one big clustered SIP server.

I think the intention here is for this document to be agnostic between
these three designs (and if it's not, it should be) but I don't think
it does that that well in a number of cases. In particular,
the question of whether the client protocol should be SIP sort
of confuses two questions: the fundamental architectural issue
above with the detail of wire encoding.

DETAILED COMMENTS
S 2.
      P2PSIP Client:  A node participating in a P2PSIP Overlay that
      provides neither routing nor route storage and retrieval functions
      to that P2PSIP Overlay.  The P2PSIP Client interacts with the
      P2PSIP Overlay by having an association (details TBD) with one or
      more P2PSIP peers.

This wouldn't be that accurate a description of case (1) above, since
there isn't an association with any peers. You just have a routing
table and contact whoever is appropriate.

   P2PSIP Resource-ID:  A non-human friendly value that uniquely
      determines which P2PSIP Peer is responsible for storing
      information about this resource (user). 

Well, "uniquely" isn't right here since most such schemes replicate
for high availability.

    P2PSIP Client Protocol:  The protocol spoken between P2PSIP Clients
      and the P2PSIP Peer they use to store or retrieve information from
      the P2P Overlay. 

Who says there's just one? See above.

      is expected to be a principle topic of the detailed design work.

s/principle/principal/

S 3.5.2.
   P2PSIP Peers directly interact with and contain the routing and
   storage fabric of the overlay.  P2PSIP Clients simply use the routing
   and storage facilities provided by the peers to get and put
   information.  The peers speak the P2PSIP Peer Protocol, which can
   express all the necessary routing and storage operations required for
   the overlay.  Clients speak the P2PSIP Client protocol, which is
   presumably a subset of the peer protocol, and is limited to storage
   insertion (put) and storage retrieval (get).  Some designs do not
   require a separate client protocol.

If it's SIP, I don't see how it's a subset of the peer protocol.

S 3.5.3.
   To get started, users must be enrolled in the overlay.  We do not
   have a process or protocol for this, nor are we certain we need a
   standardized mechanism.  We presume that after enrollment, the user
   has a distinguished name within the overlay (example:

Don't use "distinguished name" here. It's a technical term from
PKIX and it doesn't mean this. "unique name"?

S 4.5.

   When forwarding requests, are the bodies of the requests visible to
   peers?  If so, this creates substantial security problems that the
   deployers of conventional SIP have been willing to mostly ignore.
   Can we make peers cryptotransparent (like HTTP proxies) when security
   is requested?

I don't think I understand what "cryptotransparent" means, and since
HTTP proxies operate in a bunch of different modes, some quite transparent
and some quite invasive. Maybe just rename this to "security of requests"
and remove the last sentence?

-Ekr

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 30 Oct 2006 21:53:42 -0500

Thanks for the comments.
Just let me quickly provide my thought on the first comment since it
seems a quite significant point.

>- Those which store other people's state data.
I think whether a node participates in the routing in the overlay
network is a more important point distinguishing Peers from Clients.
So the concept draft assumes two kinds of nodes:
- Those which route messages and store data for other nodes.
- Those which don't either.

>   only thing you don't do is *register* with the network.
I guess you mean 'joining the overlay network' by 'register with the
network'.
Then, this design does not conflict with the concept presented in the draft.
I don't know about other authors but at least I did not think of this
design.
I think this design is possible but the Clients do not need to
understand the overlay algorithm or the routing tables.

>   do gets/puts. This is roughly the architecture that OpenDHT
This is precisely what was assumed at least in my mind.

>   it as one big clustered SIP server.
To be more precise, one can consider the overlay network as a big
clustered LOCATION SERVER and  STORAGE but not SIP proxy, SIP registrar
or SIP redirect server. In that sense, it seems to me that design #3 is
just a different expression of design #2.

>it does that that well in a number of cases. 
>
I thought the design #2 was clear and good enough. Other designs are
also valid views but wouldn't it make the concept more clear if we focus
on and stick with design #2?

>In particular,
Please let me get to the comments below later.
Thanks.

Eunsoo

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

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 30 Oct 2006 21:01:53 -0600

Hi, Eric,

> The terms you've chosen (Peers and Clients) seem to be as good as any

I'm still not happy with the combination of terms ("a Client-Peer 
architecture" should confuse anyone who has done protocol design since 
1980), but they certainly seem to be less worse than most :-)

I understand that we've tabled the choice of names while we nail down rough 
functionality. If I got this wrong, someone please say so.

> these three designs (and if it's not, it should be) but I don't think

Could you say more about "and if it's not, it should be"? Is this a question 
about whether we would find each design useful in at least one P2PSIP use 
case, or are you saying we should allow for all three designs because they 
cover the waterfront on possible designs?

> above with the detail of wire encoding.

I agree with this concern. We've changed a fair amount of text fairly 
quickly, so it's probably still catching on internal consistency in a few 
places. It's just so easy to say "but if SIP is the client protocol, designs 
two and three are more or less the same".

> If it's SIP, I don't see how it's a subset of the peer protocol.

I asked the same question earlier, and the answer at the time was that 
"subset" was talking about protocol functionality, not about a protocol 
specification that subsets another protocol specification.

> and remove the last sentence?

I confess to having been assimilated here. The word sort of made sense to 
me, and I "understood" the section, for some value of the word "understood". 
When I actually read the words in this section, I am slightly confused 
between concerns about whether

- third party can tell there was a request, and what the request was, and 
read the request body

- third party can tell there was a request, and what the request was, but 
can't read the request body

- third party can tell there was a request, but can't tell what the request 
was, or

- third party can't tell there was a request

What was the question we were asking here? I don't think the third 
alternative is interesting, but can imagine that the others might be. The 
text seems to be talking specifically about request BODIES, and Eric is 
interpreting this as "security of requests", which seems broader.

Thanks,

Spencer

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Mon, 30 Oct 2006 19:06:40 -0800

> - Those which don't either.

Sure. In nearly every system I'm familiar with, the set of
nodes which route messages is the same as the set of nodes
which stores data.

> I guess you mean 'joining the overlay network' by 'register with the

I mean that you don't take on a section of the data space or 
agree to route packets.

> understand the overlay algorithm or the routing tables.

Sorry? In this design they *do* need to understand the overlay 
algorithm. But that's not necessarily a bug. For instance,
it's likely to have superior load spreading properties, since
you don't need to find some way to load balance over the
Peers who are willing to talk to Clients.

> just a different expression of design #2.

Topologically, yes, but not necessarily in other ways. For starters,
it begins to imply that you have to do a whole bunch of SIP things
that are potentially more complicated than just store and retrieve
data.

> on and stick with design #2?

Well, no, because it tends to lock design (1) out of the discussion,
and since it's not like any actual conclusion has been reached
on that point, it's premature.

-Ekr

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Mon, 30 Oct 2006 19:10:28 -0800

> functionality. If I got this wrong, someone please say so.

That's my understanding as well. I'm OK with calling them
Foo and Bar.

> cover the waterfront on possible designs?

I'm saying that it's premature to decide on a single architecture,
at this time and in each document. That's a topic to be decided
*after* the WG is formed.

> specification that subsets another protocol specification.

Maybe some editorial work is in order here, then :)

> interpreting this as "security of requests", which seems broader.

Until we know what format requests are in, I'm not sure how we know
what are bodies and what aren't. I.e., are we just talking
about the SIP messages or about the P2PSIP Peer Protocol, which
we don't even know has bodies....

-Ekr

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 30 Oct 2006 23:11:58 -0500

>I mean that you don't take on a section of the data space or 
I guess you mean 'registering with the network means that it takes on a
section of the data space or agree to route packets'. And you mean
Clients don't do that.

>Peers who are willing to talk to Clients.
I guess my comment was confusing.
I mean Clients do not need to understand the overlay network according
to the concept draft (or the design I had). In design #1, yes, Clients
*do* need to do so.

>that are potentially more complicated than just store and retrieve
I am not sure I understand your comment.
Do you mean that the overlay network should provide a bunch of things
SIP Proxy, Registrar, and/or SIP redirect server do?
Or do you mean such implication is bad or wrong?

>on that point, it's premature.
Do you think it is important to consider design #1 in addition to design #2?
Personally I don't see much benefit in letting/requiring Clients
understand the overlay network. Could you elaborate why it should be
considered?

BTW, in deployments, the software package will typically contain both
the Peer Protocol stack and the Client Protocol stack so that a physical
node may become a Client or a Peer depending on its network environment.
So whether to be a Peer or Client just depends on what role a particular
physical node decides to play at a particular moment in typical cases.
In this sense, it is true that even a Client node may actually have the
capability to understand the overlay network. But I am not sure whether
we should consider it in the architecture description.

Thanks.

Eunsoo

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 30 Oct 2006 21:48:38 -0600

Hi, Eric,

From: "Eric Rescorla" <ekr at networkresonance.com>

> *after* the WG is formed.

I got this, and it was even clearer in your note to Eunsoo

> on that point, it's premature.

Thanks for explaining what you were thinking.

> Maybe some editorial work is in order here, then :)

"some *more* editorial work", of course. Thanks to all of the editors so far 
:-)

> we don't even know has bodies....

So, if I got your suggestion for the text, it would now look like

4.5.  Security of Requests

   When forwarding requests, are the requests themselves visible to
   peers?  If so, this creates substantial security problems that the
   deployers of conventional SIP have been willing to mostly ignore.

This is still not QUITE working for me, for a couple of reasons...

- are we talking about more than confidentiality here? I didn't think so in 
the original text, but am now wondering if Eric could be talking about more 
than confidentiality in his comments.

- I take Eric's point about "don't even know has bodies", but I'm having a 
hard time thinking that we don't have at least two choices - peers can say 
"oh, look, a request", or peers can say "oh, look, a request from EKR to 
Spencer". Which one are we worried about in 4.5?

Again, thanks for the comments and feedback - especially before the BOF.

Spencer

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Mon, 30 Oct 2006 21:57:45 -0800

> to the concept draft (or the design I had). In design #1, yes, Clients

Yes, that's correct.

> Or do you mean such implication is bad or wrong?

I mean that being a SIP *anything* is more complicated 
than just storing and retrieving opaque data blobs.

> Do you think it is important to consider design #1 in addition to design #2?

Yes.

> understand the overlay network. Could you elaborate why it should be

A number of reasons:

1. It lets you use a generic overlay network rather than one
   that's tied to P2PSIP.
2. It automatically load shares across all the Peers in the
   overlay without any additional load balancing.
3. It's architecturally cleaner.

-Ekr

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Mon, 30 Oct 2006 22:00:26 -0800

> than confidentiality in his comments.

Definitely. Indeed, message integrity may be more important in many
cases.

-Ekr

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 31 Oct 2006 00:09:08 -0600

Hi, Eric,

> Definitely. Indeed, message integrity may be more important in many

So then, something like

   When forwarding requests, are the requests themselves visible to
   peers? Is messaging integrity protected? Decisions in this area
   might create substantial security problems that the deployers
   of conventional SIP have been willing to mostly ignore.

?

Thanks,

Spencer

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 31 Oct 2006 01:31:25 -0600

>    only thing you don't do is *register* with the network.

Actually, I was originally trying to avoid design #1.

>    it as one big clustered SIP server.

For clarity, the above design #3 doesn't have "clients" as per the  
current definition. It just has peers and conventional client-server  
SIP nodes.

> above with the detail of wire encoding.

Indeed it does. In later discussion, David and I reached an  
understanding that if the client protocol is really vanilla SIP, then  
we have neither a clinet protocol nor clients according to the  
current definition, and that's OK.

So this question "is the client protocol SIP" is misleading. The  
question should be "Does the architecture have client nodes or not?"

> table and contact whoever is appropriate.

Right, I had design #2 in-mind when writing this definition.

> Well, "uniquely" isn't right here since most such schemes replicate

Good point. Should be "that determines which P2PSIP peer or peers are  
responsible / / /
> Who says there's just one? See above.

I don't understand this comment.

Yes.

> If it's SIP, I don't see how it's a subset of the peer protocol.

Right you are. SIP is not a client protocol candidate by the current  
definition. It is an alternative to client protocol.

> PKIX and it doesn't mean this. "unique name"?

Actually, "distinguished name" is a technical term from directory  
services work that predates PKIX, and AFAIK, the usage in this doc is  
correct.

See:

http://www.jguru.com/faq/view.jsp?EID=17639

or X.500

I believe the usage of DN in PKIX comes through X.509's inclusion of  
X.500 terminology. Of course, DN also occurs in LDAP.

> and remove the last sentence?

Actually, it's intended to mean "like HTTPS proxies", as discussed in  
draft-gurbani-sip-sipsec-00.txt:

    RFC 2817 [11], on the other hand, secures HTTP in a manner that is
    much more amenable to how SIP operates today with intermediaries
    aiding in routing the request.  In HTTP, cryptotransparency across
    intermediaries is obtained by upgrading a normal TCP connection from
    browser to origin server through proxies to use TLS once a tunnel is
    set up.  After the the tunnel is established, an upgrade is  
requested
    and the X.509 certificates are exchanged and ciphers negotiated
    directly between the browser and the origin server.

In the P2P model it's fairly important that the peers being transited  
NOT participate in the cryptography, since they can be expected to be  
hostile.

--
Dean

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 31 Oct 2006 05:47:46 -0800

I would like to join Eric's comments (excellent paper!) and add that
besides the types of nodes, there are also to type of interfaces to
define:

- the data interface,
- the service interface.

http://www.p2psip.org/drafts/draft-singh-p2p-sip-00.txt 

The service interface is especially critical for using external
overlays, such as the openDHT.

Sorry for not proposing a complete wording to this effect, but the paper
should consider adding these concepts. Maybe these extracts are a useful
reminder and the detailed XML examples are given in the reference.

--------

5.1.  Data Model

   In this model the DHT is used as a shared data storage and the P2P-
   SIP operations are performed by the user by directly updating the
   corresponding DHT data.  For example, a user stores his contact
   information and a caller stores the offline messages in the DHT.
   Similarly a P2P proxy updates the data in the DHT on behalf of the
   user to provide transparent SIP service to non-P2P users.

   There are several limitations to this approach.  For example,
   presence composition or programmable call routing are not easy to
   implement.  Moreover, we need service discovery for STUN and TURN
   servers anyway.  An alternative service model solves this problem as
   described below.

5.2.  Service Model

   In this model, every P2P-SIP client or proxy, joins the DHT for the
   p2p-sip service namespace.  The p2p-sip service includes SIP
   registrar, presence agent, offline message storage, and STUN and TURN
   servers at the minimum.

   When a user, Alice, wants to send a SIP message to, say
   sip:bob at example.net, she looks up the DHT to find the service node
   responsible for this user identifier, and sends the SIP request to
   that node.  The service node acts as the proxy, registrar and
   presence server for all the users for which it is responsible.  The
   service node also does any safe programmable call handling scripts
   and presence composition.

   For signed or encrypted data such as contact information, there are
   two approaches: either the user sends the signed contacts in the SIP
   message or the user authorizes the service node to sign the contacts
   on his behalf.  The first approach requires changes in existing SIP
   clients, whereas the second approach just uses a chain of
   certificates for verification of signed contacts.

   The service model is more extensible than the data model.  A P2P-SIP
   service node readily interworks with any non-P2P clients who just
   happen to know one or more service node addresses.  The service mode
   readily extends to built-in DHT architecture since only the service
   interface (join and lookup) is used in the DHT, instead of the data
   interface (get and put) by the user agent.
   Typically, the data interface can be built on top of the service
   interface.  Note however that the ReDiR interface of OpenDHT
   [Rhea0510:opendht], which is a service interface, is in fact built on
   top of the data interface and resides purely on the client side.

Authors: Are you amenable to add text to this effect?

------

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eric Rescorla
Sent: Monday, October 30, 2006 7:52 PM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03

$Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30 20:44:54
ekr Exp $

GENERAL COMMENTS

DETAILED COMMENTS
S 2.

s/principle/principal/

S 3.5.2.

S 3.5.3.

S 4.5.

I don't think I understand what "cryptotransparent" means, and since
HTTP proxies operate in a bunch of different modes, some quite
transparent
and some quite invasive. Maybe just rename this to "security of
requests"
and remove the last sentence?

-Ekr

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Tue, 31 Oct 2006 06:47:43 -0800

> Actually, I was originally trying to avoid design #1.

Well, as I said, that's premature, since there's been
no adequate WG (or even pre-WG) discussion of the merits
of the various designs.

Let's not nitpick about details of the rest of this document just
yet. My interest is in having the WG make the right architectural
decision (whatever that is) and in order for that to happen we need
not to have a set of founding documents that precludes one major
architectural choice without first having an adequate architectural
discussion. Do you disagree with this?

> current definition. It just has peers and conventional client-server

Exactly. That's why 2 and 3 are architecturally very different
even though topologically the same.

> I don't understand this comment.

There are a number of cases in which you'd talk to multiple Peers
to store and retrieve information. One of which would be design
1. Another is if you open connections to two Peers for high 
availability.

> services work that predates PKIX,

Yes, it's from X.500. But since X.500 is basically dead and PKIX
is basically alive, I figured I'd be kind and not point all the
way back.

> and AFAIK, the usage in this doc is
> correct.

Your distinguished names are going to be tree-based name structures
with elements like C, O, OU and CN encoded in ASN.1? 

> NOT participate in the cryptography, since they can be expected to be

In *which* cryptography and for which purpose? I don't think you've
defined the usage or threat model anywhere near enough to make
this kind of assertion.

-Ekr

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 31 Oct 2006 10:15:02 -0600

>    registrar, presence agent, offline message storage, and STUN and  

Henry has actually given a reasonably good description of the  
difference between "clients" and "peers" as described in the current  
document.

Peers participate in the overlay via the "service model" above.  
Clients participate via the "data model".

A  given realization might or might not have clients. It might have  
peers that use a new protocol, or it might have peers that do  
something like run OpenDHT.

We could do something as small as declare that OpenDHT provides the  
peers and define a simple XML-RPC for the client protocol.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 31 Oct 2006 10:36:33 -0600

> discussion. Do you disagree with this?

I'm torn. I see your argument, but I'm hesitant to design vampire  
nodes (things that look like peers, but don't actually contribute  
resources) into the protocol.

> 1. Another is if you open connections to two Peers for high

So you'd change the text to something like:

P2PSIP Client Protocol:  The protocol spoken between P2PSIP Clients  
and the P2PSIP Peers they use to store or retrieve information from  
the P2P Overlay.

> with elements like C, O, OU and CN encoded in ASN.1?

What's the format (aka ASN.1) got to do with anything?

The thing that makes a name distinguished within a directory is that  
its credential association is unique: that is, every DN is unique  
within the directory. You might have several John Smiths, but they  
are DIFFERENT John Smiths. There are distinguishing components of the  
identity that differentiate where the common name does not.

Certainly I envision it having parts that correspond to C and CN,  
whereas I suspect the O and OU may correspond to the overlay  
identifier. However, some models where we posit multiple "domain  
names" within a single overlay seem to require O and OU-like elements.

> defined the usage or threat model anywhere near enough to make

Ok, help us out here, because this is pretty fundamental. To me this  
means that nodes relaying messages between endpoints only see the  
cyphertext of those messages and do not possess the keys for those  
cyphertexts. This is unlike SIP's commonly-deployed proxy model,  
where the proxies are generally expected (and in practice, often  
required) to see the plaintext of the messages. Since most of the  
nodes in a P2P overlay are expected to be end-user controlled, one  
could reasonably believe that all of them are data-mining within the  
messages they relay.

In practice, this means you can't have a P2PSIP peer node that also  
serves as a SIP proxy running on Joe User's home PC that acts as an  
"outbound proxy" for users other than Joe, unless we change the way  
the SIP proxy function works so that Joe can't see all the message  
contents. Today's proposals for doing this include S/MIME and HTTPS- 
style proxy tunneling (aka sipsec:).

--
Dean

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 31 Oct 2006 09:19:08 -0800

Thanks Dean for accepting to include terminology for the data model and
the service model!

BTW: The descriptions were copied from the paper

> define a simple XML-RPC for the client protocol

Section 6 in the paper defines an XML schema definition that may be a
useful starting point.

Henry

-----Original Message-----
From: Dean Willis [mailto:dean.willis at softarmor.com] 
Sent: Tuesday, October 31, 2006 10:15 AM
To: Henry Sinnreich
Cc: Eric Rescorla; p2p-sip at cs.columbia.edu; Kundan Singh
Subject: Re: [p2p-sip] Comments on draft-willis-p2psip-concepts-03

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 31 Oct 2006 11:25:17 -0600

> Section 6 in the paper defines an XML schema definition that may be a

Actually, I was more thinking that we should use the Singh  
definitions of service and data model to supplement the existing  
definitions of client and peer, rather than adding service and data  
model as terminology in their own right.

--
Dean

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Tue, 31 Oct 2006 10:19:06 -0800

> resources) into the protocol.

Huh? The basic design of all these protocols is that there are
nodes (what you're calling Clients) who use the services of
the Peers but don't contribute resources. This question is
purely about how they interact with the Peers.

> and the P2PSIP Peers they use to store or retrieve information from

Sure.

> identity that differentiate where the common name does not.

Yes, that's what makes a name "distinguished". But a Distinguished Name
is this:

   DistinguishedName ::=   RDNSequence

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

And since you don't mean that you're going to use the construct
from PKIX, it's super-confusing to use this term.

> style proxy tunneling (aka sipsec:).

Well, let's take a step back here and examine model (3), in
which each Client speaks SIP to some Peer. 

1. Client A does a REGISTER of name "Alice" to proxy P. Now, P
   doesn't control the section of the overlay corresponding to
   Alice so it stores Alice's contact info with the appropriate
   node. This is all done with the P2PSIP Peer Protocol.
   So, there's the issue of security for these messages.

2. Client B is associated with proxy Q and wants to call A.
   It sends an INVITE to Q (see S 3.4.3) which then forwards
   it to P and then on to A. So, there's the issue of 
   security for these messages.

And this all goes back to the threat model of what you think
the trust relationships are between the various Peers in
the overlay ring.

-Ekr

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 31 Oct 2006 13:33:48 -0500

> above with the detail of wire encoding.

I agree that the document should be agnostic between these three  
designs.

If we interprete #3 as being equivalent to
      "the client protocol is just SIP"
then I think the document does an OK job of presenting #2 and #3.
(Of course, it could be better ... ;-).

However, #1 had never come up in our discussions, which is why it is  
not discussed
in the document.

- Philip

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 31 Oct 2006 14:45:45 -0500

Inline...

> purely about how they interact with the Peers.

So would a case where they client protocol is a (proper logical and
syntactic, that is, you can't tell if a query is coming from another
client or a peer) subset of the peer protocol, and a client just
happened to know about many peers (and which is "closest" to send the
search to) rather than a single one that services it, an example of a
case 1?

It seems that many optimizations of case 2 would start looking like 1
(which might be an ok or even good thing)

--David

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Tue, 31 Oct 2006 11:54:09 -0800

> (which might be an ok or even good thing)

Under some circumstances, perhaps, but it's not clear it goes the
other way. I.e., I don't think it's the case with all DHTs that you
can just talk to a single node and have it route arbitrary traffic to
a node of your choice. It certainly doesn't have great performance
properties.

-Ekr

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 31 Oct 2006 15:17:16 -0500

> a node of your choice. It certainly doesn't have great performance

I'm a bit confused about what you have in mind above, I think I am
missing part of what you are getting at. I can't really see how using
an arbitrary peer as a proxy for a client can result in the cost to
the client being worse than the cost of messages originating from that
peer itself+1 to communicate between client and peer...or am I missing
a subtle point of your distinction?

That said, obviously having more clients to choose from is better (and
I see the many ways 1 is different than 2 in your email), but in many
designs, very often the reason for being a client (rather than a peer)
in the first place is NAT related, that is, it is difficult to have
connections to many peers, so you let one serve on your behalf.
(personally I think we can be more clever than that, but it is the
motivation in many traditional P2P implementations that have both
peers and clients)

David

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 31 Oct 2006 14:55:38 -0500

> definition. It is an alternative to client protocol.

Dean:

I don't see why you say that SIP is an alternative to the client  
protocol.

Say SIP is NOT the client protocol. Then I think we have both
clients (that speak the client protocol) and SIP UAs (that speak SIP)
that can connect to the P2PSIP Overlay. Presumably, clients could
do more than ordinary SIP UAs.

So if there is a client protocol, then I think it exists in addition  
to SIP.

- Philip

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 31 Oct 2006 14:47:27 -0600

> do more than ordinary SIP UAs.

Using SIP as David does is a design alternative to using a client  
protocol. If you use SIP that way, you don't need a client protocol,  
because you don't have any "clients" as defined in the draft.  
Therefore SIP (used that way) is an alternative to using a client  
protocol.

> So if there is a client protocol, then I think it exists in  
> addition to SIP.

Right, but you may well design a system that uses IP instead of using  
a client protocol. Or to reverse your words: So if there is no client  
protocol, then I think its existence was obviated by a usage of SIP.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 31 Oct 2006 14:50:31 -0600

> motivation in many traditional P2P implementations that have both

I actually envision an "outbound peer" that has the same kind of  
relationship to a client (or to another peer) as an "outbound proxy"  
does to a UA. It acts as the NAT-traversal anchor for requests from  
outside the NAT to reach the peer or client behind a NAT.

Of course, a robust design requires each behind-nat node to have  
multiple "outbound" relationships. That's why I talk about storing a  
set of route vectors into the overlay -- one route vector for each  
outbound relationship that is being maintained.

--
Dean

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Tue, 31 Oct 2006 12:53:30 -0800

> a subtle point of your distinction?

The issue is the cost to the peer, which is suddenly in the
middle of every communication. See previous comments about
load sharing, etc., as well as potentially suboptimal
routes.

> motivation in many traditional P2P implementations that have both

Now, I must be missng something here. You don't need connections
tied up to everyone in your routing table. You create them on demand.
Even if you feel like you have to cache them, we're only talking
order 10 connections, and of course you can only partially populate
the routing table.

-Ekr

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 31 Oct 2006 16:02:49 -0500

> load sharing, etc., as well as potentially suboptimal

Ok, fully agree there is more cost to the peer serving. Optimizing
something else. Gotcha.

> order 10 connections, and of course you can only partially populate

Might be true in this case, now that I think about it, since these are
going to be outbound only (since you aren't serving/storing
information). (Obviously a peer behind a NAT may not be able to do the
same, since it must accept incoming connections and would possibly
need to keep the connections open)

Of course the number of connections needed decision is very different
for different DHT implementations and the size (total number of
participants) for a DHT, but I agree for a client it can likely be a
fairly small number.

Think I understand your thoughts a bit better now...

David