Re: [sipcore] Understanding Privacy: history invoked by UAS

Shida Schubert <> Wed, 10 November 2010 05:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06B913A68AF for <>; Tue, 9 Nov 2010 21:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.672
X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3clehivc2QN4 for <>; Tue, 9 Nov 2010 21:46:34 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id D25BA3A68A3 for <>; Tue, 9 Nov 2010 21:46:33 -0800 (PST)
Received: (qmail 29797 invoked from network); 10 Nov 2010 05:46:26 -0000
Received: from ( by with SMTP; 10 Nov 2010 05:46:26 -0000
Received: from [] (port=60503 by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1PG3WG-0002rP-M3; Tue, 09 Nov 2010 23:46:54 -0600
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert <>
In-Reply-To: <>
Date: Wed, 10 Nov 2010 14:46:53 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Hadriel Kaplan <>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Cc: "" <>
Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2010 05:46:35 -0000

 If you remove an entry or entries, I guess you may end 
up with a gap in index and depending on when and how 
much is removed, the index can deliver a false 
representation of request path (if 1.1 and 1.1.1 was 
removed entity receiving the request will add hi-entry 
probably with an index of 1.1, missing 2 hops) and 
may provide an erroneous "forwarding count" etc. 

 But this is something that would happen already with 

 RFC4244bis enforces privacy service to anonymize 
the hi-entry by changing the hi-target-to-uri into 
anonymized URI and tries to prohibit (at least on the 
specification) privacy service from removing the hi-entry. 

 RFC4244 on the other hand, was pretty flexible with 
how privacy service would conduct anonymization, 
it didn't prohibit privacy service from removing the 

 So I don't think anything would break as things are 
working now without this enforcement added in 
RFC4244bis. I think in most deployment where this is 
important, how hi-entry is anonymized is probably 
enforced and consistent within the environment where 
it matters. 

On Nov 10, 2010, at 1:52 PM, Hadriel Kaplan wrote:

> Out of curiosity, will anything "break" if the anonymized H-I entries are simply removed?  I'm not suggesting we document doing that in the draft, just asking if any apps/use-cases/whatever will break if it happens.  Because my guess is some of us will just remove them, and I'd like to know if there's any real reason I shouldn't.
> -hadriel
> On Nov 9, 2010, at 10:50 PM, Shida Schubert wrote:
>> I think RFC4244 was quite vague about how privacy is 
>> requested and due to that, both privacy header outside 
>> H-I header or part of hi-entry are used without any clear 
>> distinction.
>> Thus for backward compatibility, I don't think we can 
>> eliminate the use of Privacy:history, I think we can definitely 
>> clarify the use of them by saying proxy SHOULD or MUST 
>> use privacy=header and UAC uses Privacy:history. 
>> I do think we should clarify the procedure of how history-info 
>> is anonymized, may be something along the line as follows.
>> 1. Setting privacy indication.
>> UAC sets privacy by setting privacy:header or privacy:history
>> Proxy/UAS sets privacy by setting privacy=history in hi-entry
>> 2. Applying privacy to request.
>> Privacy service at the boundary of domain checks if privacy:header 
>> or privacy:history exists.
>> If privacy:history or privacy:header exists then it anonymize all the 
>> hi-entry from its responsible domain by changing the hi-target-to-uri 
>> to URI with anonymous.invalid. 
>> If the hi-entry that is a target of anonymization and has privacy=history, 
>> it will remove the privacy=history after anonymizing the hi-entry.
>> If the hi-entry is already anonymized (URI with anonymous.invalid) it 
>> will leave the entry as is. 
>> After anonymizing all the hi-entry from its responsible domain it will 
>> remove the priv-value of "history" from Privacy header (real header).
>> If there are no priv-value remaining in the Privacy header then it will 
>> remove the Privacy header itself following the procedure in RFC3323.
>> If there is no priv-value of "history" or "header", privacy service 
>> looks through hi-entries and see if there are URI from its domain 
>> with privacy=history.
>> For each hi-entry with privacy=history, privacy service will anonymize 
>> the hi-target-to-uri and remove the privacy=history after anonymizing 
>> the hi-entry. 
>> 3. Privacy:none
>> With regards to privacy:none, it's tad tricky because 
>> as Ian said, how it's honored depends on the regulation etc. 
>> Regards
>> Shida
>> On Nov 10, 2010, at 10:30 AM, Elwell, John wrote:
>>> In which case we don't need Privacy: history in the response, since it is only a partial solution?
>>> John 
>>>> -----Original Message-----
>>>> From: Shida Schubert [] 
>>>> Sent: 09 November 2010 06:24
>>>> To: Elwell, John
>>>> Cc:
>>>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
>>>> Hi John;
>>>> In practice, if C cares about its privacy, there should be 
>>>> a priori arrangement with the service provider or 
>>>> configuration in proxy to withhold its identity.
>>>> This will allow the proxy sending the 4xx which sets the hi-entry 
>>>> to ensure privacy is applied by setting escaped privacy header 
>>>> or Privacy:header. 
>>>> Regards
>>>> Shida 
>>>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote:
>>>>> Suppose a request from A is targeted initially at B, this 
>>>> is mapped to C, and then to registered contact D. The UAS (D) 
>>>> puts Privacy: history in the response, and therefore prevents 
>>>> A learning about C and D. Fine.
>>>>> Now, supposing D is not registered at the time, i.e., there 
>>>> is no registered contact for C. This results in a 4xx 
>>>> response to A. How do we ensure that the identity of C is not 
>>>> disclosed to A, in line with what is achieved when D is registered?
>>>>> John
>>>>> _______________________________________________
>>>>> sipcore mailing list
>> _______________________________________________
>> sipcore mailing list