Subject: [Sip] comments on draft-munakata-sip-privacy-clarified-00

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2007 21:32:11 -0400

Thanks for putting this together. I think this is a big improvement from 
the previous version. Some additional work is needed I think to progress 
it to the next step. My main comments here are:

1. The draft is similar to rfc3323 in that it is using the privacy 
header field as a flag to be used by b2bua to provide additional privacy 
services. I think we need to really separate the cases where b2bua is 
required and where it is not. In particular, I see two cases:

CASE 1: A UA can meet the UA requiremets in this spec (use GRUU, TURN, 
etc.) and can construct a request which is totally anonymous to start 
with. Thus, all we need is to signal to the network that the call is 
anonymous so that the network does not ADD additional identification 
information, or if it does, it removes it. My suggestion at the last 
meeting is that this be done with a single value of the Privacy header 
field (namely 'id' for backwards compatibility) and thats it. There are 
still multiple values for Privacy and I do not see why that is needed. 
Furthermore, an entity that 'obeys' the privacy header field is NOT a 
privacy service; it is merely removing what it had already inserted. 
That is different from the b2bua function that literally rewrites 
headers and acts completely like a UA.

CASE 2: A UA cannot for some reason meet these requirements, or it has 
requirements around not even having its originating domain be 
identified. So, it routes the request to a privacy service which is 
really the TARGET of the request, which then re-initiates that request 
towards the called party. The privacy 'service' in the network is just a 
standin for the UA and behaves *exactly* like a UA would behave had it 
implemented this spec. If you do it this way, the spec ONLY needs to 
describe how a UA constructs an anonymous request, and those rules would 
be followed by either a UA or this privacy server acting like a UA.

So, the only rules we need to specify here on request construction are 
how a *UA* constructs a request.

2. I do not advise using the Privacy header field to target a request to 
a privacy service. Indeed I think since you need to think of the privacy 
service as the target that will re-initiate, really the r-uri identifies 
the privacy service. This is how you can guarantee a privacy service 
gets used without Proxy-Require or something which was kind of a 
weakness in RFC3323. So for example:

INVITE sip:[email-masked]

This is using the concepts of rfc3087 again for how we would invoke 
privacy services.

Your document in some places suggests that the privacy service is 
invoked when Privacy is 'all' and other places suggests Route header. My 
suggestion above is closer to Route, but I think its better to use 
rfc3087 techniques.

3. The draft suggests that Via is constructed by the UA using TURN *and* 
the network removes it. You don't need both, and using TURN is 
problematic for the Via header field. Signaling addresses should be 
constructed using non-TURN techniques (Contact and From are temp-gruu), 
and Via contains the hosts IP address but it is removed the proxy when 
privacy: ID is present.

4. I think its also really important to note that the best we can do in 
the absence of a privacy service in a trusted third party domain is, 
that the anonymization function doesn't reveal the identity of the user 
but will still reveal the identity of the domain of the originator. So 
just because a header reveals the domain of the originator, does not 
mean it needs to be fixed or removed. Indeed, for this reason, 
history-info which is inserted by the network, and even record-routes, 
are not revealing information about the *user*, only the identity of 
their *network*. A user doesn't care if an INVITE says that the call 
passed through proxies edge.example.com and home.example.com. How does 
that say anything about the identity of the *user*? It doesn't. So these 
have no user privacy implications and do not need to be removed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip