Re: [sipcore] 4244bis and privacy

[Hans Erik van Elburg <[e-mail]>]

Yes.
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 6:27 PM, Francois Audet <[e-mail]> wrote:

>  You mean "should not prohibit B to choose to deliver the identity of B to
> C", right?
>
>  ------------------------------
> *From:* Hans Erik van Elburg [mailto:[e-mail]]
> *Sent:* Thursday, June 25, 2009 08:48
> *To:* Ian Elz
> *Cc:* Barnes, Mary (RICH2:AR00); Christer Holmberg; Shida Schubert;
> [e-mail]; Audet, Francois (SC100:3055)
> *Subject:* Re: 4244bis and privacy
>
> Ok Ian, now I see what you mean.
> You are saying that if A calls B which forwards to C, that A indicating
> that privacy is required should not prohibit B to choose to deliver its
> identity to C, right?
>
> I think I agree with you that this is a point that needs to be addressed by
> 4244bis.
>
> Best Regards,
> /Hans Erik van Elburg
>
> On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz <[e-mail]> wrote:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> We have an opportunity to allow presentation of specific identities and
>> to solve this particular problem so we should take it.
>>
>> 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]<[e-mail]>
>> ;user=phone;p=x
>> Privacy: history
>> History-Info:
>> <sip:[e-mail] <[e-mail]>;user=phone;p=x>;index=1;rt;aor
>>         (1)
>> History-Info: <sip:[e-mail] <[e-mail]>
>> >;index=1.1;mp;aor
>> (2)
>> History-Info: <sip:bob@192.0.2.3 <sip%3Abob@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]<[e-mail]>to
>> sip:[e-mail] <[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]<[e-mail]>;
>> user=phone;p=x
>> Privacy: history
>> History-Info:
>> <sip:[e-mail]?Privacy=none;user=phone;p=x>;index=1;rt;ao
>> r
>> History-Info: <sip:[e-mail] <[e-mail]>
>> >;index=1.1;mp;aor
>> History-Info: <sip:bob@192.0.2.3 <sip%3Abob@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
>>
>>
>>
>>
>>
>