Re: [sipcore] 4244bis and privacy
"Mary Barnes" <mary.barnes@nortel.com> Thu, 25 June 2009 17:17 UTC
Return-Path: <mary.barnes@nortel.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3953A6960 for <sipcore@core3.amsl.com>; Thu, 25 Jun 2009 10:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.286
X-Spam-Level:
X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+JDdG92Q60H for <sipcore@core3.amsl.com>; Thu, 25 Jun 2009 10:17:57 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3D4A03A6B1A for <sipcore@ietf.org>; Thu, 25 Jun 2009 10:17:57 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PGP0512536; Thu, 25 Jun 2009 16:25:00 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Jun 2009 11:28:50 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com>
In-Reply-To: <C0E80510684FE94DBDE3A4AF6B968D2D05F042EC@esealmw118.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 4244bis and privacy
thread-index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAAAvtR7AAAMWtOA=
References: <CA9998CD4A020D418654FCDEF4E707DF0B168320@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <CA9998CD4A020D418654FCDEF4E707DF0B168323@esealmw113.eemea.ericsson.se> <C0E80510684FE94DBDE3A4AF6B968D2D05EDBB6C@esealmw118.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <C0E80510684FE94DBDE3A4AF6B968D2D05EDC4E0@esealmw118.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <C0E80510684FE94DBDE3A4AF6B968D2D05F042EC@esealmw118.eemea.ericsson.se>
From: Mary Barnes <mary.barnes@nortel.com>
To: Ian Elz <ian.elz@ericsson.com>
Cc: sipcore@ietf.org, Shida Schubert <shida@agnada.com>
Subject: Re: [sipcore] 4244bis and privacy
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 17:17:59 -0000
Hi Ian, Responses inline below [MB2]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Thursday, June 25, 2009 10:13 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; 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:mary.barnes@nortel.com] Sent: 24 June 2009 17:27 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, Responses inline below [MB]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 10:37 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; 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:mary.barnes@nortel.com] Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; 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:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; 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:+18001234567@example.com;user=phone;p=x Privacy: history History-Info: <sip:+18001234567@example.com;user=phone;p=x>;index=1;rt;aor (1) History-Info: <sip:bob@biloxi.example.com>;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 +18001234567 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 +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com 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:+18001234567@example.com; user=phone;p=x Privacy: history History-Info: <sip:+18001234567@example.com?Privacy=none;user=phone;p=x>;index=1;rt;ao r History-Info: <sip:bob@biloxi.example.com>;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:mary.barnes@nortel.com] 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:christer.holmberg@ericsson.com] 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
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy R.Jesske
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy R.Jesske
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy R.Jesske
- Re: [sipcore] 4244bis and privacy Mary Barnes
- Re: [sipcore] 4244bis and privacy Elwell, John
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Ian Elz
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Elwell, John
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Francois Audet
- Re: [sipcore] 4244bis and privacy Hans Erik van Elburg
- Re: [sipcore] 4244bis and privacy Ian Elz