Re: [sipcore] 4244bis and privacy

["Francois Audet" <[e-mail]>]

So, let's say A calls B, B forwards to C.

B has privacy turned on.

A calls B. A history-info entry is added with sip:B.

B retargets to C and sets privacy.

I guess that would mean that B's proxy would have to parse the
History-Info
and anonymize all entries corresponding to B?

Is this correct? 

> -----Original Message-----
> From: Barnes, Mary (RICH2:AR00) 
> Sent: Thursday, June 25, 2009 09:29
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; 
> [e-mail]; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
> 
> Hi Ian,
> 
> Responses inline below [MB2].
> 
> Mary.
> 
> -----Original Message-----
> From: Ian Elz [mailto:[e-mail]]
> Sent: Thursday, June 25, 2009 10:13 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; 
> [e-mail]; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
> 
> Mary,
> 
> I am a little concerned about one answer that you gave:
> 
> 
> If you have a Privacy header with a value of "none" and a H-I 
> entry with Privacy header parameter with value "history" what 
> is the privacy of the individual H-I entry?
> [MB] We did not explicitly address the "none" in RFC 4244, 
> but the general statement is the privacy headers at the 
> request level override any at the hi-entry level. [/MB]
>  
> This means that if privacy is required for an individual H-I 
> entry but the originating user included "Privacy:none" in the 
> request then there is no option to include the real URI in 
> the H-I entry.
> [MB2] I'm confused here - the "none" definition is as you 
> note below, thus "none" prohibits the removal or 
> anonymization of the entries, thus I would think you would 
> fine this functionality desireable. However, this does not 
> prohibit an entity based on policy to anonymize (or remove 
> entries if privacy is required for that domain if the entity 
> does not have access to a privacy service). [/MB2]
> 
> This occurs as RFC3323 states in section 4.3: "However, if 
> the Privacy header value of 'none' is specified in a message, 
> privacy services MUST NOT perform any privacy function and 
> MUST NOT remove or modify the Privacy header."
> 
> The only option for an intermediate node including a H-I 
> entry where "Privacy:none" is specified and privacy for the 
> H-I URI is required is to include an anonymous entry or not 
> include the H-I entry.
> [MB2] If privacy is required then yes, you include anonymous 
> entries or don't include. That's the basic privacy mechanism 
> for privacy levels of "session" "header" and "history" in the 
> R-URI or "history" in the specific entries, as well as when 
> there is a policy for privacy for the entries added by a 
> specific domain. The "none" really has no influence on the 
> later case per se. [/MB2]
> 
> In your previous response you stated that we would violate 
> RFC3323 if we specified additional behaviour for privacy 
> explicitly stated with a URI -n the H-I entry. I don't 
> believe that this is the case as RFC3323 only considered 
> privacy in a two party scenario and did not consider third 
> party identities being included in a message between two 
> parties. H-I is not the only case where this occurs as the 
> Referred-By header when included in the INVITE (or other 
> request) which results from the REFER has the same issue.
> [MB2] I can't necessarily disagree on this one (we can debate 
> it either way). But to fix it requires an update to RFC 3323 
> and shouldn't be something that we want to fix in 4244bis. [/MB2]
> 
> RFC4244 was the first time that there was a recognition that 
> privacy for these individual third party identities may be 
> required. To allow this explicit statement of privacy to be 
> overridden by a generic statement which is applicable to a 
> different user is counterintuitive.
> [MB2] See my comment above. But, as I have consistently said, 
> the idea that an entity might want to override the "none" is 
> entirely based on policy and 4244 and 4244bis allow privacy 
> to be applied to the entries that are added by that entity if 
> the policy dictates so (and we already say that). [/MB2]
> 
> The original Privacy header is usually included by or on 
> behalf of the originating user and should not be allowed to 
> specify the privacy of the original called user, e.g. the 800 
> number, and prevent this identity being presented if this 
> user does not have the same level of privacy.
> [MB2] As I tried to say in a previous response, a random 
> entity (i.e., one for whom the R-URI is not in a domain under 
> its control) cannot add a privacy header to the Request. Per 
> RFC 3323 an entity may add the header to a request only if it 
> has the appropriate relationship/authorization with the 
> original called user who intiated the request. And, I would 
> find it very surprising if an entity that did have 
> responsibility would apply privacy since that would be 
> counter intuitive and I would hope that SPs would be 
> judicious in specifying the appropriate and inappropriate 
> manner in which the proxies they deploy and interface with 
> privatize the messages. The protocol CANNOT control this 
> behavior and that's why there is the policy clause in 4244 
> and 4244bis. [/MB2]  
> 
> The real issue with the 800 scenario is as you have stated is 
> that the answerer will not know the original called identity 
> and will not be able to correctly handle the call. As more 
> generic call centres are used which will answer calls on 
> behalf of many different organizations using CTI and the 
> original called identity to have to implement a generic 
> system asking the caller who he originally called appear 
> unprofessional, is inefficient and unproductive.
> [MB2] And, as I noted, it is rare for a call centre to route 
> a call directly to an agent without a user providing some 
> sort of input. Even companies like American Airlines, even 
> though they have the info that I enter via the IVR, they 
> still ask some basic questions and there are times when they 
> have to reroute me. I don't think we can totally automate 
> things.  And, again, once the call hits the domain that is 
> responsible for that 800 number the entities in that domain 
> have control over how they muck with the R-URI, such that 
> they should be able to use any IVR info to appropriately 
> direct the call - it's not the number that's meaningful, but 
> how the system gets the call to the right user and the 
> additional information they provide as the call is presented 
> to the agent. I would honestly think that having something 
> other than an 800 number show up on the display would be far 
> more useful and in my experience in the systems I developed 
> we're usually talking about CTI interfaces so you have a lot 
> you can do.  And, actually all of this really doesn't matter 
> in that you MUST be able to handle this situation independent 
> of the privacy since History-Info is optional, you need 
> default behavior assigned. [/MB2] 
> 
> We have an opportunity to allow presentation of specific 
> identities and to solve this particular problem so we should take it.
> [MB2] The most we can do is to document the risks/impacts of 
> the use of the Privacy headers at the R-URI level. There is 
> already general text in 4244 and 4244bis that the privacy may 
> impact whether the applications get the information.  And, as 
> I noted before, most commercial systems are using B2BUAs 
> which will allow you far more control over the use of the 
> Privacy headers in the network. But, again, I don't think 
> that's something that should be address in 4244bis.  [/MB2]
> 
> I hope that we can get some wider discussion on this issue so 
> a more general consensus can be obtained.
> 
> Regards
> 
> Ian
> 
> 
> 
> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: 24 June 2009 17:27
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; 
> [e-mail]; Francois Audet
> Subject: RE: 4244bis and privacy
> 
> Hi Ian,
> 
> Responses inline below [MB].
> 
> Mary. 
> 
> -----Original Message-----
> From: Ian Elz [mailto:[e-mail]]
> Sent: Wednesday, June 24, 2009 10:37 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; 
> [e-mail]; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
> 
> Mary,
> 
> I was not proposing that we change the handling of H-I which 
> is based upon local policy. If that causes an issue for a 
> network operator then they can modify their local policy 
> accordingly or arrange with the proxy vendor to modify their 
> equipment to be more flexible with regards to policy.
> 
> Can you clarify for me:
> 
> If you have a Privacy header with either "session" or 
> "header" doe this impact the H-I entries or will only a value 
> of "history" impact the H-I entries?
> [MB] Yes, both "session" and "header" level privacy, 
> consistent with RFC 3323, mandate that entries be anonymized 
> or dropped, with the latter being the recommendation for 
> "session" level privacy. RFC 4244 mandated that they be 
> dropped and 4244bis recommends they be anonymized. The 
> original intent for the value of "history" was for the 
> tagging of the individual entries, but you end up getting the 
> header level functionality as well. [/MB] 
> 
> If you have a Privacy header with a value of "none" and a H-I 
> entry with Privacy header parameter with value "history" what 
> is the privacy of the individual H-I entry?
> [MB] We did not explicitly address the "none" in RFC 4244, 
> but the general statement is the privacy headers at the 
> request level override any at the hi-entry level. [/MB]
> 
> From reading RFC4244 a Privacy header with value "history" 
> will effectively make all H-I entries private and there is 
> currently no option to  include a H-I Privacy header 
> parameter with value "none".
> [MB] Correct, per my comment above. [/MB]
> 
> H-I at present allows the inclusion of Privacy header 
> parameters to explicitly express privacy for an individual 
> H-I entry but a single node which includes a header "Privacy: 
> history" makes all H-I entries private even if this is not 
> the requirements for the specific URI.
> [MB] Correct, but the only node that should add the header is 
> a node which is responsible for the domain associated with 
> the Request URI in the incoming request or is authorized to 
> do so. [/MB]
> 
> I will admit that having worked in a telephony environment 
> for a long time I am used to having privacy of identities set 
> on a per number basis and the relative inflexibility of the 
> IETF Privacy header is relatively restrictive as to 
> specifying which identities may be presented and which not.
> [MB] Yes, this is an entirely different paradigm.  I 
> developed telephony s/w for over a decade and this is 
> entirely different - it provides a lot more flexibility, 
> which makes things far, far less deterministic than what you 
> have in telephony switches where your routing and 
> translations are configured for the most part, with just a 
> few capabilities for controlling the privacy and it's a 
> closed network.  
> 
> With RFC4244/4244bis, there MUST be a mechanism at the UAS or 
> end application that can handle a request that doesn't have 
> the appropriate information either because nodes didn't 
> support History-Info or some random node in the network 
> applied privacy (which I think is highly
> unlikely) - this is normative per section 5 of RFC 4244.  So, 
> the worst case scenario I see for this 800 service  (which 
> will get to the right UAS but without the exact 800 number 
> that was dialed) is that it goes to a default ACD 
> group/customer service agent, etc. who then needs to gather 
> the appropriate information and in my experience this is 
> often an IVR system these days.  So, the service is not 
> broken when privacy is applied in an undesireable manner, 
> it's just not optimal.  This is something that should be 
> addressed in the target-uri draft which has all the details 
> of how specific services use History-Info.
> One other thing to consider is that most networks that are 
> emulating telephony type features use B2BUAs, which follow 
> the UAS/UAC rules for the header rather than the proxy rules, 
> noting that the UAC can set the Privacy header to whatever 
> value it sees as appropriate for the request.
> [/MB]
> 
> 
> Regards 
> 
> Ian
> 
> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: 24 June 2009 15:48
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; 
> [e-mail]; Francois Audet
> Subject: RE: 4244bis and privacy
> 
> Hi Ian,
> 
> I do not believe we should do the "override" behavior as I 
> think that violates RFC 3323, as the "history" is really a 
> subset of the cases whereby a UAC or proxy would add 
> "session" or "header" to the request.
> And, the latter two cases have the same (undesireable) 
> result.   I agree
> this impacts your services, but we can't mandate that proxies 
> provide information that might violate their local policies 
> and indeed a proxy's local policies can result in the 
> information being anonymized (or removed if they can't 
> anonymize) even in the "none" case. 
> 
> I do believe it's reasonable that we strongly recommend that 
> the request level (versus specific hi-entries) not be used 
> and if it is used, the consequence is that some services will 
> not have the information they need - this was the gist of my 
> previous response (to which I did not get any additional 
> feedback). Now, we could add some text that the "none"
> case SHOULD be used (e.g., added by first hop proxy) if it is 
> desired that the information not be subject to privacy 
> restrictions. I do not think it is then particularly useful 
> to add logic around the proxy then being able to tag the 
> entries within their domain as subject to privacy.
> I think that conflicts with the intent of the request level "none".
> However, as I mention above, per the current text, a proxy 
> can (based on local policy) remove entries - so a proxy can 
> capture hi within their domain and not forward any of that 
> information to the next hop in another domain - you already 
> have that functionality.  But, I think this introduces the 
> general problem that you might be impacting other services 
> further down the line, which I thought was the problem you 
> were wanting to solve - not specifically your example service 
> but, for example, in the case that someone is debugging and 
> they want the entire history, so depending upon the service, 
> this is also undesirable behavior.  
> 
> 
> Regards,
> Mary. 
> 
> -----Original Message-----
> From: Ian Elz [mailto:[e-mail]]
> Sent: Wednesday, June 24, 2009 2:57 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; 
> [e-mail]; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
> 
> 
>  Mary,
> 
> [I have added the list to this thread for wider comment.]
> 
> In the previous discussions I commented that in RFC4424 that 
> a Privacy header with value "history" effectively makes all 
> H-I entries private with the result that the H-I entries may 
> be removed.
> 
> There has now been a comprehensive discussion on indication 
> of the initial 'target' to the final recipient for call 
> handling purposes.
> 
> The main use case related to a freephone example where the 
> answering location may be a call centre where the original 
> freephone number may be required for correct call handling.
> 
> If you now consider the following example (modified from 
> Francois' text in the latest draft - excuse any errors that I 
> may have inserted)
> 
> INVITE sip:sip:[e-mail];user=phone;p=x
> Privacy: history
> History-Info:
> <sip:[e-mail];user=phone;p=x>;index=1;rt;aor  
>        (1)
> History-Info: <sip:[e-mail]>;index=1.1;mp;aor
> (2)
> History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc
> (3)
> 
> In this case due to the Privacy header all of the H-I entries 
> are considered private and the [phone] will not be 
> delivered to the final destination with the result that call 
> handling may not be correct.
> The Privacy header may have been inserted by any of the nodes 
> which routed the message and inserted a H-I entry.
> 
> If however the H-I was allowed to include a header parameter 
> of "?Privacy=none" in the H-I entry and that an explicit H-I 
> entry privacy value would be considered to have precedence 
> over a Privacy header with a value of "history" then the 
> mapping of the [phone] could be explicitly specified as 
> not private and may be passed on.
> 
> Thus when the mapping from sip:[e-mail] to 
> sip:[e-mail] when H-I entry (2) above is 
> included could also insert the Privacy header parameter in 
> H-I entry (1).
> 
> Thus the message would appear as follows:
> 
> INVITE sip:sip:[e-mail]; user=phone;p=x
> Privacy: history
> History-Info:
> <sip:[e-mail]?Privacy=none;user=phone;p=x>;ind
> ex=1;rt;ao
> r
> History-Info: <sip:[e-mail]>;index=1.1;mp;aor
> History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc
> 
> This would result in all the H-I entries except (1) being 
> considered private with the result that the =1800... Number 
> is passed for call handling purposes.
> 
> This change is backward compatible with the existing 
> implementation as any node using the existing functionality 
> as defined in RFC4244 will continue to be supported.
> 
> The alternative is to remove the ability to include the value 
> "history"
> in the Privacy header and only allow this value in the 
> Privacy header parameter. This alternative is not backward compatible.
> 
> Without this change a single node in the message path which 
> includes a header "Privacy: history" will prevent delivery of 
> the aor and thus prevent proper call handling.
> 
> Ian Elz
> 
> 
> 
> -----Original Message-----
> From: Christer Holmberg
> Sent: 23 June 2009 19:40
> To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; 
> Shida Schubert
> Cc: Ian Elz
> Subject: RE: 4244bis and privacy
> 
>  
> Hi,
> 
> I include Ian, so he can comment to your resposne himself.
> 
> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: Tuesday, June 23, 2009 9:40 PM
> To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; 
> Shida Schubert
> Subject: RE: 4244bis and privacy
> 
> Here was the thread of response and the last comment was from 
> Ian that he would consider the response:
> http://www.ietf.org/mail-archive/web/sip/current/msg26948.html
> 
> And, there was not agreement on the "none" but rather to 
> qualify the SHOULD NOT forward.  However, in the 
> sipcore-4244bis-00, rather than changing the text such that 
> the headers SHOULD be removed, we recommend that they be 
> anonymized (in section 4.3.3.3.1).  That is entirely 
> consistent with RFC 3324 and thus we have removed the 
> recommendations to remove the headers entirely. However, that 
> changed never got done in section 3.2, so we would need to 
> change this:
>    "Thus, the History- Info header
>    SHOULD NOT be included in Requests where the requestor has 
> indicated
>    a priv-value of Session- or Header-level privacy."
> 
> But, I'm really beginning to be of the mindset that we should 
> just remove all the subsections of section 3 (i.e., leave the 
> text in the upper level section), so we don't have to keep 
> worrying about consistency.
> 
> So, lets either fixt the text in 3.2 or remove altogether and 
> then I think we are really at the point of needing to submit 
> this version so folks that actually have an interest in it 
> can review the updated document. 
> 
> Mary. 
> 
> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Tuesday, June 23, 2009 1:10 PM
> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); 
> Hans Erik van Elburg; Shida Schubert
> Subject: 4244bis and privacy
> 
> 
> Hi,
> 
> Below is a comment/proposal which one of my collegues (Ian 
> Elz) gave on the list a while ago, when the first version of 
> 4244bis was submitted, but was not incorporated. Do you think 
> it would be useful?
> 
> -------
> 
> While the HI approach to target may solve the problem of 
> being able to deliver the target URI to the final destination 
> there is no guarantee that it will actually be delivered.
> 
> The problem arises with how Privacy is defined for HI.
> 
> 4424 defines a new Privacy value "history" which may be 
> placed in either the Privacy header or as a header parameter 
> to the HI entry.
> 
> If one node uses the former option "Privacy: history" then 
> this will make all headers private and will result in all HI 
> entries being removed or made anonymous when the message 
> containing the HI is delivered to the user.
> 
> There is a simple solution to this and that is to also allow 
> the use of the "none" Privacy value as a header parameter in 
> the HI entry. This would explicitly state that no privacy is 
> required to the HI entry and this would override a "history" 
> value in the Privacy header.
> 
> I pointed this out to Mary when the 4424bis draft was first 
> published but the change has not been made in the latest draft.
> 
> The change is backward compatible and would not cause an 
> issue with any existing implementations.
> 
> ------
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>