Subject: [sipcore] Understanding Privacy: history invoked by UAS

From: "Elwell, John" <[email-masked]>
Date: Tue, 9 Nov 2010 03:32:48 +0100

Suppose a request from A is targeted initially at B, this is mapped to C, and then to registered contact D. The UAS (D) puts Privacy: history in the response, and therefore prevents A learning about C and D. Fine.

Now, supposing D is not registered at the time, i.e., there is no registered contact for C. This results in a 4xx response to A. How do we ensure that the identity of C is not disclosed to A, in line with what is achieved when D is registered?

John

---

From: Shida Schubert <[email-masked]>
Date: Tue, 9 Nov 2010 15:23:47 +0900

Hi John;

 In practice, if C cares about its privacy, there should be 
a priori arrangement with the service provider or 
configuration in proxy to withhold its identity.

 This will allow the proxy sending the 4xx which sets the hi-entry 
to ensure privacy is applied by setting escaped privacy header 
or Privacy:header. 

 Regards
  Shida 

On Nov 9, 2010, at 11:32 AM, Elwell, John wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Nov 2010 02:30:04 +0100

In which case we don't need Privacy: history in the response, since it is only a partial solution?

John 

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 09 November 2010 06:24
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
> 
> 
> Hi John;
> 
> > Suppose a request from A is targeted initially at B, this 
> is mapped to C, and then to registered contact D. The UAS (D) 
> puts Privacy: history in the response, and therefore prevents 
> A learning about C and D. Fine.
> > 
> > Now, supposing D is not registered at the time, i.e., there 
> is no registered contact for C. This results in a 4xx 
> response to A. How do we ensure that the identity of C is not 
> disclosed to A, in line with what is achieved when D is registered?
> > 
> > John
> >

---

From: Shida Schubert <[email-masked]>
Date: Wed, 10 Nov 2010 12:50:16 +0900

I think RFC4244 was quite vague about how privacy is 
requested and due to that, both privacy header outside 
H-I header or part of hi-entry are used without any clear 
distinction.

 Thus for backward compatibility, I don't think we can 
eliminate the use of Privacy:history, I think we can definitely 
clarify the use of them by saying proxy SHOULD or MUST 
use privacy=header and UAC uses Privacy:history. 

 I do think we should clarify the procedure of how history-info 
is anonymized, may be something along the line as follows.

1. Setting privacy indication.

 UAC sets privacy by setting privacy:header or privacy:history
 Proxy/UAS sets privacy by setting privacy=history in hi-entry

2. Applying privacy to request.

 Privacy service at the boundary of domain checks if privacy:header 
or privacy:history exists.

 If privacy:history or privacy:header exists then it anonymize all the 
hi-entry from its responsible domain by changing the hi-target-to-uri 
to URI with anonymous.invalid. 

 If the hi-entry that is a target of anonymization and has privacy=history, 
it will remove the privacy=history after anonymizing the hi-entry.

 If the hi-entry is already anonymized (URI with anonymous.invalid) it 
will leave the entry as is. 

 After anonymizing all the hi-entry from its responsible domain it will 
remove the priv-value of "history" from Privacy header (real header).

 If there are no priv-value remaining in the Privacy header then it will 
remove the Privacy header itself following the procedure in RFC3323.

 If there is no priv-value of "history" or "header", privacy service 
looks through hi-entries and see if there are URI from its domain 
with privacy=history.

 For each hi-entry with privacy=history, privacy service will anonymize 
the hi-target-to-uri and remove the privacy=history after anonymizing 
the hi-entry. 

3. Privacy:none

 With regards to privacy:none, it's tad tricky because 
as Ian said, how it's honored depends on the regulation etc. 

 Regards
  Shida

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 23:52:43 -0500

Out of curiosity, will anything "break" if the anonymized H-I entries are simply removed?  I'm not suggesting we document doing that in the draft, just asking if any apps/use-cases/whatever will break if it happens.  Because my guess is some of us will just remove them, and I'd like to know if there's any real reason I shouldn't.

-hadriel

---

From: Shida Schubert <[email-masked]>
Date: Wed, 10 Nov 2010 14:46:53 +0900

If you remove an entry or entries, I guess you may end 
up with a gap in index and depending on when and how 
much is removed, the index can deliver a false 
representation of request path (if 1.1 and 1.1.1 was 
removed entity receiving the request will add hi-entry 
probably with an index of 1.1, missing 2 hops) and 
may provide an erroneous "forwarding count" etc. 

 But this is something that would happen already with 
RFC4244. 

 RFC4244bis enforces privacy service to anonymize 
the hi-entry by changing the hi-target-to-uri into 
anonymized URI and tries to prohibit (at least on the 
specification) privacy service from removing the hi-entry. 

 RFC4244 on the other hand, was pretty flexible with 
how privacy service would conduct anonymization, 
it didn't prohibit privacy service from removing the 
hi-entry.

 So I don't think anything would break as things are 
working now without this enforcement added in 
RFC4244bis. I think in most deployment where this is 
important, how hi-entry is anonymized is probably 
enforced and consistent within the environment where 
it matters. 
 
 Regards
  Shida

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 17:29:59 +0800

Inline

> is anonymized, may be something along the line as follows.

What you outline here is a great improvement.

> as Ian said, how it's honored depends on the regulation etc.

ISTM that privacy:none is pretty explicit about how it is to be 
implemented. Either you comply or you don't. If you feel that allowing 
the request to proceed while complying with privacy:none is contrary to 
your policy, then you have the option of failing the call, and just be 
up front with your users that you don't permit them to use privacy:none. 
Then they can decide if they still want to do business with you.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 11 Nov 2010 02:57:03 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]

Actually, D isn't really the center of this.  If D's user wants to prevent his AOR (C) from being disclosed, he will have to make an arrangement with the home proxy for C.  The home proxy can add "Privacy: history" to any 4xx response it generates for requests to C.  Indeed, it will probably add "Privacy: history" to requests or responses to C even when D is registered.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 11 Nov 2010 02:59:39 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]

Hmmm...  Another reason that we need to definitively define what constitutes a valid H-I value and what does not.  (This is tracker issue 34: http://tools.ietf.org/wg/sipcore/trac/ticket/34)

Dale

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 09:22:55 +0100

For call forwarding the entries will be counted when a "mp" is included. This is due to avoid to many Call forwardings.
3GPP has defined their service in counting the entries where a "cause" regarding RFC4458 is included.

So if such entries will be deleted then the counter number of diversions is not correct, which is also needed for the interworking with the PSTN.

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Donnerstag, 11. November 2010 09:00
> An: Hadriel Kaplan; Shida Schubert
> Cc: [email-masked]
> Betreff: Re: [sipcore] Understanding Privacy: history invoked by UAS
>
> From: [email-masked] [[email-masked]] On
> Behalf Of Hadriel Kaplan [[email-masked]]
>
> Out of curiosity, will anything "break" if the anonymized H-I
> entries are simply removed?  I'm not suggesting we document
> doing that in the draft, just asking if any
> apps/use-cases/whatever will break if it happens.  Because my
> guess is some of us will just remove them, and I'd like to
> know if there's any real reason I shouldn't.
> Hmmm...  Another reason that we need to definitively define
> what constitutes a valid H-I value and what does not.  (This
> is tracker issue 34: http://tools.ietf.org/wg/sipcore/trac/ticket/34)
>
> Dale

---

From: Mary Barnes <[email-masked]>
Date: Thu, 11 Nov 2010 03:59:21 -0600

Responses inline below [MB].

On Thu, Nov 11, 2010 at 1:59 AM, Worley, Dale R (Dale) <[email-masked]>wrote:

> Out of curiosity, will anything "break" if the anonymized H-I entries are
> simply removed?  I'm not suggesting we document doing that in the draft,
> just asking if any apps/use-cases/whatever will break if it happens.
>  Because my guess is some of us will just remove them, and I'd like to know
> if there's any real reason I shouldn't.
>
[MB] Hadriel - There is text that describes that applications must be able
to handle gaps and thus not break. We can't police the protocol, but
removing the entries would not be normative behavior since it could impact
an end application that wants to make use of the information. This is the
usual be generous in what you receive...[/MB]

> Hmmm...  Another reason that we need to definitively define what
> constitutes a valid H-I value and what does not.  (This is tracker issue 34:
> http://tools.ietf.org/wg/sipcore/trac/ticket/34)
>
[MB] Dale - I don't see that Issue 34 is related to this specific issue.
Please see my response to issue 34 on the mailing list. [/MB]