Re: [sipcore] privacy handling

[Paul Kyzivat <[e-mail]>]

Hadriel Kaplan wrote:
> On Aug 31, 2010, at 6:35 PM, Paul Kyzivat wrote:
> 
>> Another point I just realized while reviewing 3323: when a privacy
>> service acts on a privacy value, such as "Privacy:header", or
>> "Privacy:history", it also removes that value from the Privacy header.
>> So those actions are only performed *once*. If "Privacy:history" is
>> included by the UAC, and is processed by the first proxy encountered,
>> subsequently added H-I information will not be anonymized. (Unless
>> "Privacy:history" is added *again* by a proxy after that.)
> 
> But isn't that the right thing, and what we really want?  I mean if you make a call to me, you may want to anonymize your H-I so I don't find out the call is coming from you/Cisco, but that is really only possible and practical for the H-I entries generated by Cisco or some privacy service under your control - once the request reaches Acme you can't expect my servers to anonymize who it's from.  And I need and should expect H-I entries generated by my local servers to reach me, regardless of whether you put a Privacy header in or not.
> If I divert the request to Dale at Avaya, then I can add my own Privacy header and my servers/service will anonymize before sending it to Avaya.

If the caller only wants his own entry removed, why doesn't he just 
leave it out in the first place?

It only makes sense to put it in if there is reason to expect that it 
will be used before being removed. My *inference* was that the purpose 
of Privacy:history was to cause all the entries then present to be 
removed when the request is passed to a server that isn't acting on 
behalf of the caller. With assumption that between the caller and that 
point there was some possibility of it being useful.

But that only works if the caller knows that the privacy service is 
positioned in such a place. That is the sort of guarantee that 3325 
tries to put in place. But it isn't there in 3323.

Is the elephant in the room here an assumption that Privacy headers are 
really directives to SBCs, and everybody assumes there is one acting on 
their behalf in the path?

>> Regarding responses, ISTM that often servers along the way want their
>> identity exposed to those further downstream (e.g. the proxy for the AOR
>> wanting the AOR exposed to the VM server), but may not want that stuff
>> visible to the caller. That would call for anonymization of the response
>> by something upstream of those things that want their identity hidden.
>> To accomplish this, the UAS will have to had a Privacy header to the
>> response, and there will have to be a privacy service on the path that
>> will act on it.
> 
> Right, but that's what rfc3323 does/says for privacy of responses.

While its implicit, I didn't see anything in 3323 that mentions the UAS 
inserting a Privacy header in the response. There is verbage that an 
intermediate server might add its own based on local knowledge. The 
first proxy (SBC) on the callee side is the one to be the privacy 
service for this, and is likely to do it whether requested or not.

>> I think perhaps Dale had it right, that much of this can be resolved by
>> abandoning passive voice for active voice, thus forcing the
>> identification of the agent for each action.
> 
> What email message was that in?  I missed it.

I don't recall, but I'm pretty sure I saw it.

	Thanks,
	Paul