Re: [sipcore] 4244bis and privacy

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

That's another use case.
But given your set of info, I think that is correct.

/Hans Erik van Elburg

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

> 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]<[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>;ind
> > ex=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
> >
> >
> >
> >
> >
>