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

["Eunsoo Shim" <[e-mail]>]

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

On 7/13/07, Jonathan Rosenberg <[e-mail]> wrote:
>
> 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