Re: [sipcore] 4244bis and privacy

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

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] <mailto:[e-mail]> ;user=phone;p=x
		Privacy: history
		History-Info:
		<sip:[e-mail] <mailto:[e-mail]> ;user=phone;p=x>;index=1;rt;aor         (1)
		History-Info: <sip:[e-mail] <mailto:[e-mail]> >;index=1.1;mp;aor
		(2)
		History-Info: <sip:bob@192.0.2.3 <mailto: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] <mailto:[e-mail]>  to
		sip:[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]> >;index=1.1;mp;aor
		History-Info: <sip:bob@192.0.2.3 <mailto: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