Subject: RE: [Sipping] Discussions ondraft-munakata-sipping-privacy-clarified-00

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 7 Nov 2006 14:15:05 -0500

We should also try to minimize churn on PTSN GW designs as much as
possible.

Mike

> -----Original Message-----
> From: Jonathan Rosenberg (jdrosen) 
> Sent: Monday, November 06, 2006 5:55 PM
> To: Mayumi Munakata
> Cc: [email-masked]
> Subject: Re: [Sipping] Discussions 
> ondraft-munakata-sipping-privacy-clarified-00
> 
> Let me follow up some more to my remarks at the microphone today.
> 
> We clearly have a need for privacy services in SIP, and a 
> revision of RFC 3323 is warranted.
> 
> What I think such a revision should do is:
> 
> 1. give guidance on how a UA can construct a completely 
> anonymous request, utilizing anonymous gruu and using TURN to 
> obtain IP addresses and ports for media relay. This would 
> need to have guidance on various header fields, as rfc 3323 
> does today. However the context there is how to construct (or 
> omit) them, rather for guidance on removal or manipulation.
> 
> 2. Once you define (1), the additional service you need from 
> the network is not to insert additional information into the 
> request which identify the user. Thus, you need a flag that 
> indicates the request is anonymous. 
> We could use the Privacy: id value for this, or use the 
> presence of an anonymous URI in the From as this flag. What I 
> assert we do NOT want is anything more than just a single 
> flag. We don't want specific guidance on whether its allowed 
> to insert header foo vs. header bar. That is too complicated 
> and I think is not useful.
> 
> 3. Additionally, one might want a solution for UA which, for 
> some reason, cannot construct messages using (1). In that 
> case, the UA will want to invoke a privacy service in the 
> network. I would argue that we DONT want complex features 
> that allow the UA to micro-manage the behavior of that 
> privacy service. As a privacy service, it does a 
> "full-processing" on the request - removing or obfuscating 
> anything that could reveal user identity. Thus, the only 
> thing we need to signal is a way for a UA to invoke that 
> service, thats it. We could use a Privacy value for that, or 
> we could use other techniques we have developed for service 
> invocation. For example a route header field that points to 
> an anonymization service.
> 
> 
> I will point out that RFC 3323 itself has only seen 
> deployment in the context of RFC 3325. That is, to my 
> knowledge, the only value of the Privacy header ever used is "id".
> 
> -Jonathan R.
> 
> 
> Mayumi Munakata wrote:
> 
> > Jonathan,
> > 
> > Thank you for the valuable comments.
> > 
> > To my knowledge, RFC 3323 is widely deployed already, so it is 
> > necessary to keep the mechanism and clarify it as much as 
> possible for 
> > the already deployed implementations.
> > 
> > Your sip-identity-privacy draft may solve all the privacy problems, 
> > but still, we need RFC 3323, even if it is a short-term solution.
> > 
> > If everybody views RFC 3323 in the same way, I can change 
> the text in 
> > Section 4.2. (Guidelines on specifying new priv-values) to 
> something 
> > like "it is RECOMMENDED to avoid defining a new priv-value 
> in future 
> > RFCs".
> > 
> > Thanks, Mayumi
> > 
> 
> -- 
> 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
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP