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

[<[e-mail]>]

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
   

>-----Original Message-----
>From: ext Jonathan Rosenberg [mailto:[e-mail]] 
>Sent: 14 July, 2007 00:49
>To: P2PSIP WG
>Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP
>
>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
>

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