[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

privacy without b2bua, was: Re: third alternative (was RE: [Sip] RE: Identity after reinvite)





Peterson, Jon wrote:

A few notes on the "Monica property": as RFC3323 suggests, I think that some
sort of anonymization service, which could be instantiated by a B2BUA, is an
appropriate way to conceal the identity of a called or calling party. What
scares me a little is the way people suggest that retargeting, as opposed to
redirection, can inherently be expected to provide privacy. When I register
a contact, I can't always guarantee that the location service in question
will be used exclusively for retargeting rather than redirection; moreover,
the revelation of the target Request-URI to the caller is not the only way
that the caller can learn who the connected-party is: contact headers of new
requests in the backwards direction of the dialog, SDP in a 200 OK, and so
on, are information leaks that are not addressed at all by retargeting, but
would be addressed by an anonymization service.

RFC3323 is about due for an update, I think, because the major functions
that it provides can be performed without a B2BUA, thanks to new SIP
mechanisms like GRUUs and session-policy. So while I agree that an
anonymization service is the right approach to this problem, these days I
think you can probably build an anonymization service without building a
B2BUA.

I believe this is probably true. Here's how I think it'd work:

A client that wants to make an anonymous call contacts a TURN server providing anonymization services. That server provides the client with IP addresses and ports that it can use in its Via, contact, and SDP. The From field is anonymized. A privacy header is inserted. The request is sent via the TURN server to the user's outbound proxy. That proxy can still authenticate the client, and even insert an identity header that at least vouches that the client is a legit client that is just anonymous.

The provider of the anonymization server (turn in this case) can be completely decoupled from the sip provider. That provides an excellent level of anonymity compared to even a b2bua. The b2bua approach would still allow the recipient to trace the IP address in the SDP and Contact to the particular provider; this might not be sufficient (I don't recall off hand if rfc3323 discusses this problme).

It also means that there is no need to signal things like header or media level privacy. The client simply chooses to obfuscate (using the learned turn addresses) whatever fields it wishes to anonymize. This has the impact of simplifying the privacy spec significantly. Indeed, it would seem that it is hardly needed at all...

-Jonathan R.


-- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen at cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip