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

[JiangXingFeng <[e-mail]>]

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
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: Saturday, July 14, 2007 5:49 AM
> 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