RELOAD is a rendezvous protocol - it yields a URI to send SIP messages to in order to establish a p2p connection.
It uses an algorithm (the RELOAD spec is designed around a pluggable algorithm) of which Distributed Hash Table examples like Chord are good candidates. The algorithm defines how a p2p distributed databases of these URIs is created, and how you query the DHT to find the URI of the party you want to talk to. You start with an identifier, query the DHT and get the URI. Then you send a normal SIP INVITE to that URI. This means the SIP signaling itself does not go through any intermediaries, nor does the media (assuming a TURN relay is not needed). Contrast this with how normal SIP calling works, where you send the INVITE to a proxy server in your local domain (carrier) who routes it through some set of proxy servers to the destination domain (possibly including a transit domain) who routes it to the destination. Along the way, as implemented, any number of changes to the SIP INVITE are made, including changing the media end point IP addresses, so the media is forced through middle boxes in the carrier network. So RELOAD is privacy friendly by turning calling into true p2p with signaling and media not transiting any third party. The concern I have is that to get credentials enabling you to store your URI in the DHT, you interact with an enrollment server. That server only issues credentials, it's not in the path of the call, but if it was co-opted, it could create mischief with those credentials. Brian On Sep 9, 2013, at 11:30 AM, Stephen Farrell <[email protected]> wrote: > > Hi Brian, Dean, > > RELOAD [1] is a bit of a gigantic spec though but I agree could > be promising in this space. I wonder if anyone might be interested > enough to write a draft saying how to use RELOAD to be more > privacy friendly? > > I've no idea if that'd be easy or a huge amount of effort for > someone who already knows the protocol, but I'm pretty sure it'd > be a major task for someone starting from scratch. > > S. > > [1] http://tools.ietf.org/wg/p2psip/draft-ietf-p2psip-base/ > > On 09/09/2013 04:09 PM, Brian Rosen wrote: >> I'm still worried about the role of the enrollment server. If it got >> compromised, then mischief would be possible (you may not know who you are >> talking to). I think MITM would be hard. >> >> I think we need to come up with a new way to come up with credentials that >> is less dependent on servers that are subject to co-opting by the >> authorities. >> >> It's a HECK of a lot better than conventional VoIP though. >> >> Brian >> >> On Sep 9, 2013, at 10:46 AM, Dean Willis <[email protected]> wrote: >> >>> I think we can mostly get there with RELOAD, but the implementations are >>> still pretty early. >>> >>> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" <[email protected]> >>> wrote: >>> Hi Linus, >>> >>> thanks for the comments. >>> >>> I have indeed skipped that topic. I will have to read into the Mumble >>> project to see what security and privacy guarantees it provides. >>> >>> My current conclusion from using VoIP/IM systems without using Tor is that >>> you cannot really protect against collecting this transaction data (i.e., >>> you have to at least trust the two VSPs, our own and then the VSP of your >>> communication partner). While you can influence routing of the data traffic >>> to a certain extend it does not work too well when your VSP is working >>> against you. >>> >>> With IM you could at least set up your own server (e.g., by using an XMPP >>> server) but with VoIP that's more complicated because nobody else will >>> accepted your connection attempts (as explained in the interconnection part >>> of my write-up). >>> >>> I will come back to you on that issue. >>> >>> Ciao >>> Hannes >>> >>> >>> On 09.09.2013 14:31, Linus Nordberg wrote: >>> Hannes Tschofenig<[email protected]> wrote >>> Mon, 09 Sep 2013 11:26:39 +0300: >>> >>> | http://www.tschofenig.priv.at/wp/?p=997 >>> | >>> | It contains a number of recommendations, which are addressed to VoIP >>> | providers and vendors but have to be enforced by data protection >>> | authorities. >>> | >>> | The recommendations unfortunately highlight some challenges... >>> >>> Indeed. And still, I miss any mention on protection against collecting >>> data about who's talking to who. >>> >>> Without claiming any expertise at all in this area, the closest thing to >>> something implementing this that I've heard of is Mumble over >>> Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote >>> [1] about this earlier this year. Some people seem to use it [2]. >>> >>> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 >>> [1] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble >>> [2] >>> https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ >>> _______________________________________________ >>> perpass mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >>> >>> _______________________________________________ >>> perpass mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >>> _______________________________________________ >>> perpass mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >> >> >> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
