Subject: [P2PSIP] Forking in P2PSIP

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 24 Jul 2007 00:25:23 -0400

I was curious which (or maybe all) of the proposals for the P2P signaling
protocol support the SIP forking behavior and how it is envisioned to work
in a P2P environment. It seems to me that the SIP node doing the query for
the SIP URI receives multiple contacts which have been registered from the
P2P network. The node then goes ahead and sends out the request to one or
more contacts. Is this correct?

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2007 10:19:08 -0400

This is how it works in ASP at least.

The only other approach is if one of the nodes in the p2p network acts 
as a proxy. But then there is a trust issue I don't like, and there is 
no particular reason that some other node in the network can do the 
forking better than the originator.

-Jonathan R.

Medhavi Bhatia wrote:
> I was curious which (or maybe all) of the proposals for the P2P 
> signaling protocol support the SIP forking behavior and how it is 
> envisioned to work in a P2P environment. It seems to me that the SIP 
> node doing the query for the SIP URI receives multiple contacts which 
> have been registered from the P2P network. The node then goes ahead and 
> sends out the request to one or more contacts. Is this correct?
> 
> Medhavi.
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 24 Jul 2007 10:29:21 -0400

I guess forking will need be implemented in the P2PSIP  nodes. MY thinking
is that it could be happen at the originator (for cases where location
happens before sending request) or at the node where the URI is registered
(in cases where P2P network is providing request forwarding service as
well).

-- 
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2007 11:48:46 -0400

Medhavi Bhatia wrote:
> I guess forking will need be implemented in the P2PSIP  nodes. MY 
> thinking is that it could be happen at the originator (for cases where 
> location happens before sending request) or at the node where the URI is 
> registered (in cases where P2P network is providing request forwarding 
> service as well).

Well, that introduces a large number of additional attack vectors, for a 
benefit I don't understand. I think this should be the originator. 
Anything else requires other nodes in the p2p network, all of which are 
untrusted, to act as my sip proxy, and brings with it the countless 
attacks possible when a proxy is malicious.

-Jonathan R.

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 24 Jul 2007 10:52:31 -0500

>From a pure P2P standpoint, and the issue of SIP aside, it is always
better (when possible) to have the peer requesting services or the
peer providing the service (as opposed to intermediate devices) do the
work.

In the SIP case, this means that, when possible, the caller and called
should do as much of the work as you can. We want it to be as painless
as possible to be a peer, so forking is best done by the originator,
in my opinion.

my 2 cents (as individual)

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 24 Jul 2007 11:28:44 -0500

For use cases where P2PSIP is intended to form a proxy (use case "P2P
for Redundant SIP Proxies" is the most obvious, but I think there is
another use case where clients are configured with a single local
proxy that happens to be a peer in a P2PSIP deployment but the clients
don't have to be aware of it), the use case implies the same trust
relationship that would be present in a conventional SIP deployment
(effectively the P2PSIP portion is only a backend).  In those cases,
because the trust relationship is the same, I think it would be fine
to have the P2PSIP peer (in role as proxy) handle the forking.

In deployments where such a trust relationship is not present, I agree
that the caller should handle the forking.

Bruce

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jul 2007 14:59:17 -0500

> that the caller should handle the forking.

In SIP, traditionally we have not encouraged endpoints to fork.
Forking is a service provided by proxies.  Endpoints are encouraged
to handle the results of a fork in the form of expecting multiple 2xx
responses, but AFAIK very few, if any SIP endpoints support forking
natively.  They leave that to a proxy.

There are other ways to mitigate the trust relationship.  sipsec
comes to mind; right now it sort of skirts around the forking
issue.  But there could be some time spent in making it work
with forking.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 24 Jul 2007 15:05:15 -0500

> issue.  But there could be some time spent in making it work

I don't think solving that problem is very useful.  Or, at least,
maybe it might be useful, but it doesn't eliminate needing to have
endpoints handle forking.  In a pure P2PSIP environment (serverless
PBX, let's say, where there are 100 P2PSIP hardphones and maybe a
couple gateways) there is no "proxy" box.  Forking has to be done on
the endpoints.  (unless you want to have one phone handling forking
for another phone, but I don't see a compelling argument for that.)

Bruce

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Jul 2007 15:43:53 -0500

> In SIP, traditionally we have not encouraged endpoints to fork.

Hmm ... probably not too relevant for the conversation here but this  
has been a relatively hot topic in SIP at times. I realize most  
deployments today fork at the proxy but I'm not sure ti would say  
that everyone in the SIP WG has exactly encouraged this.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jul 2007 18:22:34 -0500

Cullen Jennings wrote:
> Hmm ... probably not too relevant for the conversation here but this has 
> been a relatively hot topic in SIP at times. I realize most deployments 
> today fork at the proxy but I'm not sure ti would say that everyone in 
> the SIP WG has exactly encouraged this.

In rfc3261, the string "fork" (and its variation "forking") appears
25 times.  20 out of 25 times, the string appear in context of a
proxy discussion.  5 out of 25 times, it appears alone or in context
of an UA.

Thus, an implementor, bereft of direct IETF feedback, reading
rfc3261 to code up a SIP stack will associate forking with
proxies ;-)

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jul 2007 18:23:59 -0500

> for another phone, but I don't see a compelling argument for that.)

Agreed.  I am just pointing out that we should not make assumptions
that existing SIP UAs will support native forking form the get-go.
We can certainly mandate that a P2PSIP UA support forking natively.

- vijay

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 24 Jul 2007 20:21:32 -0400

> We can certainly mandate that a P2PSIP UA support forking natively.

SIP UAs shouldn't need to support Forking. We are talking about P2PSIP Nodes
here. Existing SIP UAs should act as client's to the P2P network. I think
the entry point (as Bruce said) will act as an interworking proxy for these
UAs with the P2PSIP network and it will need to support forking. I think
forking should be part of P2PSIP requirements (I haven't checked if the
requirements doc already covers this, but will do).

- vijay

-- 
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 25 Jul 2007 14:46:45 +0800

I agree with Jonathan that forking is better implemented by the originator. 

I want to point out another issue from implementing fork action at the node
where the resource is registered. Peer MUST speak peer protocol and some
peers may speak other protocol, for example SIP protocol, while some peers
only speak peer protocol. In that case, if the node where the resource is
registered is to perform fork action, this node should speak the
corresponding application protocol, for example SIP protocol and know how to
explain the value associated with the registered key. Then it will make use
of the information in the key to fork the request. 

Regards!
--
Jiang XingFeng

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2007 11:49 PM
> To: Medhavi Bhatia
> Cc: P2PSIP WG
> Subject: Re: [P2PSIP] Forking in P2PSIP
> 
> 
> 
> Medhavi Bhatia wrote:

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 25 Jul 2007 10:46:42 -0500

Medhavi Bhatia wrote:
> SIP UAs shouldn't need to support Forking. We are talking about P2PSIP 
> Nodes here. Existing SIP UAs should act as client's to the P2P network. 
> I think the entry point (as Bruce said) will act as an interworking 
> proxy for these UAs with the P2PSIP network and it will need to support 
> forking. I think forking should be part of P2PSIP requirements (I 
> haven't checked if the requirements doc already covers this, but will do).

Getting forking right is hard; not impossible, but hard.
Forking at the endpoint makes certain intractable issues in SIP
like HERFP easier since the forking entity does not need to choose
a best response to send upstream and has access to all the
potential responses to choose a repairable one.  OTOH, the
maintaining the response context machinery and the rules to
handle crossed final responses et al. can get very intricate.

- vijay

---

From: Dean Willis <[email-masked]>
Date: Wed, 25 Jul 2007 11:35:28 -0500

On Jul 24, 2007, at 10:48 AM, Jonathan Rosenberg wrote:

>> thinking is that it could be happen at the originator (for cases  
>> where location happens before sending request) or at the node  
>> where the URI is registered (in cases where P2P network is  
>> providing request forwarding service as well).
>
> Well, that introduces a large number of additional attack vectors,  
> for a benefit I don't understand. I think this should be the  
> originator. Anything else requires other nodes in the p2p network,  
> all of which are untrusted, to act as my sip proxy, and brings with  
> it the countless attacks possible when a proxy is malicious.
>

Devil's advocate question coming:

Let's say I have a half-dozen SIP UAs I want to use with an overlay.  
They register C/S with a SIP proxy under my control. My AOR using RFC  
3263 points at this proxy.

Why couldn't MY SIP proxy register my AOR into the overlay, then run  
SIP in the usual way (including evil forking) on my behalf? No trust  
issues that way, as far as I can see.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Jul 2007 14:44:03 -0400

Vijay K. Gurbani wrote:
>> Nodes here. Existing SIP UAs should act as client's to the P2P 
>> network. I think the entry point (as Bruce said) will act as an 
>> interworking proxy for these UAs with the P2PSIP network and it will 
>> need to support forking. I think forking should be part of P2PSIP 
>> requirements (I haven't checked if the requirements doc already covers 
>> this, but will do).
> 

This is not necessary. When the client 'forks', its not like a proxy 
forking where the request forks downstream and a proxy needs to collect 
responses for forwarding upstream.

The model is effectively redirect. The originating peer would query the 
DHT, and learn one or more contacts. Each contact would either be 
another AOR, or identify a peer. If it identifies a peer, the 
originating peer connects to it, and sends an INVITE. That INVITE cannot 
fork since its targeted directly to the UAS. Thus, its almost as if the 
UAC had sent an INVITE to the home proxy, and gotten redirected to each 
registered contact, and then recursed.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Jul 2007 14:46:36 -0400

inline.

Dean Willis wrote:
>>> where location happens before sending request) or at the node where 
>>> the URI is registered (in cases where P2P network is providing 
>>> request forwarding service as well).
>>
>> Well, that introduces a large number of additional attack vectors, for 
>> a benefit I don't understand. I think this should be the originator. 
>> Anything else requires other nodes in the p2p network, all of which 
>> are untrusted, to act as my sip proxy, and brings with it the 
>> countless attacks possible when a proxy is malicious.
>>
> 
> Why couldn't MY SIP proxy register my AOR into the overlay, then run SIP 
> in the usual way (including evil forking) on my behalf? No trust issues 
> that way, as far as I can see.

This use case is fine; but it is different from the one we are 
discussing. In the case we are discussing, you are trusting your own 
proxy to reach your own UA. What I disagree with, is that a peer in the 
DHT would trust some other, arbitrary peer, to act as its proxy and to 
reach towards the UASes on its behalf. That, I believe, is fundamentally 
a bad idea.

-Jonathan R.