Re: [sipcore] privacy handling

[Paul Kyzivat <[e-mail]>]

Hadriel Kaplan wrote:
> On Aug 31, 2010, at 8:28 PM, Paul Kyzivat wrote:
> 
>> 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?
> 
> Because the first Proxy adds it anyway, and because it is presumably useful within the originator's trust-domain.
> 
>> 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.
> 
> In what way does 3325 guarantee such a thing?  Afaik, just by mandating that a Proxy implementing 3325 anonymize if its next-hop isn't in the same trust-domain.  I assume there is going to be the same type of language in this 4424bis draft.

IIRC it "guarantees" this by mandating that there be a spec(T) that 
provides that guarantee. Its just passing the buck, but at least it tries.

I don't see any comparable language in 4244bis yet. Referencing 3323 
doesn't give it. So that language needs to be added.

>> 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?
> 
> No, though I expect some SBCs will probably remove all H-I entries other than "mp" ones, and change those to not include IP addresses.

If you assume that SBCs are deployed at all the boundaries of 
"management domains" as seems typically to be the case, then they are 
indeed likely candidates to assume the privacy service role.

Of particular note is Privacy:none. I think we could make a case that 
SBCs should honor the provisions of this. (But its hard to write a 
requirement for that since we don't standardize SBC behavior.)

	Thanks,
	Paul