Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 17:49:27 -0400

draft-bryan-p2psip-requirements-00 talks about how SIP relates to the 
P2P protocol. It says:

> The above discussion suggests at least two paradigms for SIP 
>    operation in a p2p setting: the end-to-end paradigm where a SIP user 
>    agent uses the p2p location service to discover the location of 
>    callee, and then send the SIP message directly to the callee, or a 
>    hop-by-hop paradigm where each peer forwards the SIP request to a 
>    peer which is more 'closer' to the callee. The former can be thought 
>    of as a RPC whereas the later can be thought of as a local procedure 
>    call to determine the next hop. 

I'd like to propose that, any model which views the peers in the p2p 
network as proxies (things that add Via headers, follow proxy rules as 
defined in RFC 3261, and so on), is basically fatally flawed from a 
security perspective.

SIP was not designed on a model of untrusted proxies. I know this keeps 
coming up time and time again in the core SIP mailing list. The problem 
is, the design of SIP quite purposefully gives SIP proxies pretty wide 
latitude in manipulating message contents and doing things. We have some 
limited protection, if you believe in things like S/MIME, but by its 
very definition, SIP allows proxies to do lots of stuff. They can send 
requests to different places, they can fork, they can send responses, 
they can add and remove headers, they can change the destination of a 
request. All of it is legal and makes sense in a proxy-routed model.

However, in P2PSIP, if you think of the peers as proxies, you enter a 
use case where you trust none of the proxies, and in fact every call has 
a whole lot of them on the signaling path (O(logN)). I guarantee you 
that these untrusted proxies will launch attacks that are hard to fix 
without basically completely changing the way the SIP protocol works.

So, don't do it.

The way you limit what peers can do is by using a protocol to 
communicate with peers whose very design limits what can be done. A 
protocol built from the ground up to do nothing but give an intermediary 
the ability to move a message around based on DHT topology. You wouldn't 
need to worry about things modifying media destinations since there is 
no SDP. You needn't worry about spoofing caller ID since there is no 
caller ID in the protocol. All you do is use this protocol to allow you 
to set up a secure, e2e, TLS connection between you and the UA you want 
to talk to, and then run SIP over that.

The great benefit is that SIP already allows UA to UA communications. It 
always has. P2PSIP then slides in as a pure, clean replacement for 
RFC3263, allowing you to identify the target UA that you want to connect 
to, and provide a means for connecting to them through firewalls and NATs.

Thus I'd like to suggest that the E2E SIP model described in the 
requirements document be the one we are shooting for.

Thanks,
Jonathan R.

-- 
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

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 13 Jul 2007 14:56:56 -0700

Jonathan,

Though I have co-authored the document, I believe you are right here:

>> peer which is more 'closer' to the callee.

> is basically fatally flawed from a security perspective.

On 2nd thought it is also not desirable for other reasons, such call
setup delay, higher risk of packet loss and more bandwidth/computing
consumption.

Good catch.

Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Friday, July 13, 2007 2:49 PM
To: P2PSIP WG
Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP

So, don't do it.

to, and provide a means for connecting to them through firewalls and
NATs.

Thanks,
Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Sat, 14 Jul 2007 14:03:50 -0500

On Jul 13, 2007, at 4:49 PM, Jonathan Rosenberg wrote:

> draft-bryan-p2psip-requirements-00 talks about how SIP relates to  
> the P2P protocol. It says:
>
>> operation in a p2p setting: the end-to-end paradigm where a SIP  
>> user    agent uses the p2p location service to discover the  
>> location of    callee, and then send the SIP message directly to  
>> the callee, or a    hop-by-hop paradigm where each peer forwards  
>> the SIP request to a    peer which is more 'closer' to the callee.  
>> The former can be thought    of as a RPC whereas the later can be  
>> thought of as a local procedure    call to determine the next hop.
>
> I'd like to propose that, any model which views the peers in the  
> p2p network as proxies (things that add Via headers, follow proxy  
> rules as defined in RFC 3261, and so on), is basically fatally  
> flawed from a security perspective.

Unless the system uses the SIPSEC model, where following an initial  
SIP request the proxies form a cryptotransparent tunnel between UAs.

That's the real reason I've been pushing the SIPSEC draft.

If we have a SIP-based P2P layer where peers act as SIP proxies (as  
in dSIP), then we must have something like SIPSEC to provide for  
secure transport.

If we use something other than SIP, then that "something" must have  
equivalent functionality. We just can't go around handing cleartext  
to peers (even if the peer is a STUN relay instead of a SIP proxy)  
and hoping they don't abuse it.

--
Dean

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Sat, 14 Jul 2007 17:57:23 -0400

> defined in RFC 3261, and so on), is basically fatally flawed from a

I think this is a fair statement, not only for the security reasons,
but also because the routing requirements of SIP proxies don't mesh
very well with the routing (and route stability) characteristics of
P2P overlay networks.

> to, and provide a means for connecting to them through firewalls and NATs.

One of the current shortcomings of this requirements drafts is that
section 9.2, SIP Security, is still work-in-progress.  It seems like
one security requirement here is:

- If the peer protocol allows for the routing of SIP messages across
the overlay, then it MUST provide an integrity mechanism to ensure
that the message is not modified by the routing peers.

I'm unsure whether I believe that message secrecy should be the
responsibility of the Peer protocol or the E2E (SIP) protocol.  It's
certainly not hard to provide such a mechanism in the Peer protocol,
so I think we should also list that capability as a requirement for
the protocol.

Bruce

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 14 Jul 2007 23:01:18 -0400

I agree with Jonathan's suggestion.
That's what I have been proposing for almost two years.
And that's why a client protocol different from SIP brings a clean
separation between the protocols for the overlay and SIP.

Thanks.

Eunsoo

---

From: <[email-masked]>
Date: Mon, 16 Jul 2007 11:45:27 +0300

Hi Jonathan,

The authors discussed this problem and decided to leave two options. As
Henry said there are pros and cons of either these but... I agree with
you that the first option should be a MUST from the security
perspective.
Actually this issue is discussed in
http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-re
quirements-01.txt document.

Marcin

>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: 14 July, 2007 00:49
>To: P2PSIP WG
>draft-bryan-p2psip-requirements-00 talks about how SIP relates 
>to the P2P protocol. It says:
>
>I'd like to propose that, any model which views the peers in 
>the p2p network as proxies (things that add Via headers, 
>follow proxy rules as defined in RFC 3261, and so on), is 
>basically fatally flawed from a security perspective.
>
>SIP was not designed on a model of untrusted proxies. I know 
>this keeps coming up time and time again in the core SIP 
>mailing list. The problem is, the design of SIP quite 
>purposefully gives SIP proxies pretty wide latitude in 
>manipulating message contents and doing things. We have some 
>limited protection, if you believe in things like S/MIME, but 
>by its very definition, SIP allows proxies to do lots of 
>stuff. They can send requests to different places, they can 
>fork, they can send responses, they can add and remove 
>headers, they can change the destination of a request. All of 
>it is legal and makes sense in a proxy-routed model.
>
>However, in P2PSIP, if you think of the peers as proxies, you 
>enter a use case where you trust none of the proxies, and in 
>fact every call has a whole lot of them on the signaling path 
>(O(logN)). I guarantee you that these untrusted proxies will 
>launch attacks that are hard to fix without basically 
>completely changing the way the SIP protocol works.
>
>So, don't do it.
>
>communicate with peers whose very design limits what can be 
>done. A protocol built from the ground up to do nothing but 
>give an intermediary the ability to move a message around 
>based on DHT topology. You wouldn't need to worry about things 
>modifying media destinations since there is no SDP. You 
>needn't worry about spoofing caller ID since there is no 
>caller ID in the protocol. All you do is use this protocol to 
>allow you to set up a secure, e2e, TLS connection between you 
>and the UA you want to talk to, and then run SIP over that.
>
>The great benefit is that SIP already allows UA to UA 
>communications. It always has. P2PSIP then slides in as a 
>pure, clean replacement for RFC3263, allowing you to identify 
>the target UA that you want to connect to, and provide a means 
>for connecting to them through firewalls and NATs.
>
>Thus I'd like to suggest that the E2E SIP model described in 
>the requirements document be the one we are shooting for.
>
>Thanks,
>Jonathan R.
>
>
>--

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 17 Jul 2007 09:56:41 +0800

Hi, Jonathan:

My two cents...
Yes, E2E paradigm could avoid security issues arising from forwarding SIP
message among the peers in the overlay. 
As for hop-by-hop paradigm, if we could make a overlay tunnel between two
peers and make sure that the destination peer for the overlay message, for
example, GET message, is the same as the peer where the callee hosts, then
the destination peer could use the upper layer application information
carried in the peer message to de-multiplex and distribute the applications
message encapsulated in the peer messages to the specific application
protocol entity, for example, SIP protocol stack. 

The application messages could be protected by the message sender by making
use of various security mechanisms and intermediary peer will not process
the application message and only forward the messages according to the DHT
routing algorithms. 
If used in this way, overlay will become a general platform to transport
various upper layer messages, for example, SIP message.

Obviously, peer protocol should support transporting application protocol
first and maybe need do some special work to make the application protocol
work as it is used in the Client/Server modes. For example, as for SIP, the
destination peer will check some headers and Request-URI to determine
whether it is a right message, so peer protocol may do some adaptation work
to make the destination does not care about how this message arrived at it. 

I am not sure it could be done. Presenting here is for your comments? 

Regards!

--
Jiang XingFeng
> Sent: Saturday, July 14, 2007 5:49 AM
> To: P2PSIP WG

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Jul 2007 08:02:18 -0500

JiangXingFeng wrote:
> Hi, Jonathan:
> 
> My two cents... Yes, E2E paradigm could avoid security issues arising
> from forwarding SIP message among the peers in the overlay. As for
> hop-by-hop paradigm, if we could make a overlay tunnel between two 
> peers and make sure that the destination peer for the overlay
> message, for example, GET message, is the same as the peer where the
> callee hosts, then the destination peer could use the upper layer
> application information carried in the peer message to de-multiplex
> and distribute the applications message encapsulated in the peer
> messages to the specific application protocol entity, for example,
> SIP protocol stack.
[...]
> I am not sure it could be done. Presenting here is for your comments?

It can.  See the sipsec URI scheme at
http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01

We have an implementation of this as well.

- 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