[P2PSIP] HBH vs. E2E SIP in P2PSIP

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

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