Re: [sipcore] privacy handling

[Hadriel Kaplan <[e-mail]>]

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.


> 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.

-hadriel