Subject: [sipcore] Yet more comments on rfc4244bis-02

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Nov 2010 17:29:38 +0100

1. Section 7.3.1.
"If there is a Privacy header in the request with a priv-
   value of "header" or "history", then the initial hi-entry MUST be
   anonymized and the header removed when the request leaves a domain
   for which the SIP entity is responsible."
I think it should say "...and the Privacy header removed" - there is no point in removing the H-I header field if we have anonymized it.

2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show just the URI anonymized and with the value [email-masked]. Is this how it MUST be done?

3. In the same sentence, is it sufficient to anonymize only the first hi-entry? There could be further hi-entries for the same domain, and just revealing internal routing within the domain might be considered a breach of privacy. Perhaps in that case you would need to rely on those additional hi-entries being separately marked for privacy. If that is so, it would seem to be OK.

4. "In addition, the History-Info header can reveal general routing and
   diverting information within an intermediary, "
Is it only routing information within an intermediary, or also routing information within a domain that you might want to make private? I think text later in the paragraph concurs with the latter view.

5. "Finally, the terminator of the request may not want to reveal the
   final reached target to the originator.  In this case, the terminator
   uses the a value of "history" in the Privacy header in the last hi-
   entry in the response.  The SIP entity that forwards the response
   MUST anonymize that hi-entry and remove the Privacy header."
Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been marked by proxies in the final domain as private? These will get passed back in the response without anonymization since they are not the final hi-entry and are not covered by this statement. Should the final sentence apply to any hi-entry?

6. Section 7.3.3:
"To
       accomplish this, the processing entity MUST read the value from
       the History-Info header in the received request and MUST add
       another level of indexing "
Should make it clear it is the last hi-entry of the received request (after adding entries on behalf of previous hops).

7. "followed
       by an initial index for the new level of 1"
I think this would be clearer if it said:
"followed by an initial index of 1 for the new level"

8. "MUST be calculated by incrementing the last/lowest digit
       at the current level"
and 
"That is, the lowest/last digit of the index MUST be
       incremented "
What if an index is a double-digit integer?

9. Section 8:
"an
   application might need to provide special handling in some cases
   where there are gaps."
Should there be a note discussing the fact that some gaps are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, say, is missing.

10. Should we say anything in section 8 about anonymized entries? Note that what we might say depends to some extent on whether what exactly gets anomymised. For example if an application searches for an rc or mp entry, if those parameters have been anonymized it will not find them (but might find others that have not been anonymized!), but if those parameters have not been anonymized it will find them but the URI will be useless.

11. Section 9:
"With the level of security provided by TLS (SEC-req-3), the
   information in the History-Info header can thus be evaluated to
   determine if information has been removed by evaluating the indices
   for gaps (SEC-req-1, SEC-req-2).  "
This is subject to the limitation pointed out in a comment above, about not all gaps being detectable.

12. I would expect to see something in section 9 concerning privacy. We should mention the privacy mechanism and discuss its limits (i.e., depends on trust of downstream entities to anonymize privacy-marked entries). Also there should probably be some discussion on strength of anonymization algorithms (unless we are indeed prescribing [email-masked]).

13. Section 10.2:
"This document defines a priv-value for the SIP Privacy header:
   history The following changes have been made to
   http://www.iana.org/assignments/sip-priv-values The following has
   been added to the registration for the SIP Privacy header:"
I am not sure how to parse this.

14. Section 12.1:
"This specification adds an
   optional SIP header field parameter to the History-Info and Contact
   headers.  "
In fact it adds two parameters to each.

15. "Entities that have not implemented this specification MUST
   ignore these parameters, "
We cannot place a normative requirement on entities that don't implement this. Change "MUST" to "will".

John

---

From: Shida Schubert <[email-masked]>
Date: Sun, 7 Nov 2010 13:28:27 +0800

Hi John;

 My responses on some of the comments, I think 
Mary may be responding on the same issues but here are mine.

> I think it should say "...and the Privacy header removed" - there is no point in removing the H-I header field if we have anonymized it.

 You are right. The intention was to say "remove the priv-value and remove the privacy 
header itself if there are no other priv-value left (id may exists which needs 
to remain in the request until it reaches the egress point)". 

> 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show jus…

 I personally don't have a strong opinion about prescribing the [email-masked] but 
I think it would be useful to specify what the anonymized URI should look like. This would avoid 
anonymous URI anonymized numerous time by different privacy service for example...
 As for the parameter, if rc/mp tag, index and encoded reason(RFC 3326) are intact, 
anonymized hi-entry can still provide some value, so I think only hi-targeted-to-uri should be 
anonymized.  

> 3. In the same sentence, is it sufficient to anonymize only the first hi-entry? There could be further hi-entries for the same domain, and just revealing internal routing within the domain might be…

 Your last suggestion/assumption was exactly the motivation and our 
attempt to simplify privacy handling, by saying Privacy header with priv-value 
of "history"/"header" (not in hi-entry) for anonymizing first hi-entry only and to use 
privacy=header in hi-entry for any other hi-entries. 

 It would mean;  

   1. UA requests H-I privacy by using Privacy:history or Privacy:header
   2. Proxy request H-I privacy by using History-Info:<proxy-url>?privacy=history

 Which we thought would clarify the timing of when Privacy:history / Privacy:header 
and privacy=history are used.

 But thinking further, it doesn't really simplify the overall 
privacy handling of H-I  and furthermore it changes the semantics of 
header privacy in RFC3323.

 Excerpt from RFC3323 on header privacy says:
 
   "If a privacy level of 'header' is requested, then the originating
   user has asked the privacy service to help to obscure headers that
   might otherwise reveal information about the originator of the
   request."

 This can encompass entries revealing internal routing and domain 
information as you mentioned above, so restricting the use of Privacy:header 
to first entry only can be seen as changing the semantics defined in RFC3323. 

 I think we should align the handling of H-I privacy of Privacy:history 
and Privacy:header to that of RFC3323, allowing privacy service to 
anonymize not only the first hi-entry but any other entries that 
are from its domain. 

 I guess we need to further clarify how these two means of requesting 
privacy interact, since you can have both privacy:history and few hi-entries 
with privacy=history. I am assuming that when privacy service anonymizes 
history-info header based on privacy:history or privacy:header, it also  
needs to remove the privacy=history from hi-entries that it's anonymizing. 

 Lastly what about the interaction with privacy:none? According to  
section 5.1 of 4244bis, if UAC doesn't want privacy on its identity it sets 
Privacy header with priv-value of "none", but I am having a hard time 
envisioning the need for this. When do you ever get the hi-entry representing 
your own AoR or contact address? 

 I think the hi-entry with privacy=history should still be anonymized, even when
the Privacy:none is set in request because the privacy is requested by proxy, I 
think we need to add text on this as well.

> Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been marke…

 RFC3323 recommends that privacy service to be included in the 
request/response path if privacy is desired. The privacy handling 
in 4244bis is based on RFC3323 so I don't know if we need to add 
anything specific here for anonymizing the response.

> Should make it clear it is the last hi-entry of the received request (after adding entries on behalf of previous hops).

 Agree. 

> "followed by an initial index of 1 for the new level"

 Agree.

> What if an index is a double-digit integer?

 How about we remove the "lowest/last" and simply 
say incrementing the digit at the current level by 1 or 
something like that.

> Should there be a note discussing the fact that some gaps are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, say, is missing.

 This would happen, say for example if request was 
parallel forked, each branch would have the hi-entry 
that only the forked request traversed but missing 
the information of the other forks. I don't know if I would 
consider what you describe as a gap. You may be 
missing the other branches but you should be able to 
identify the gap in index for the branch that request 
traversed. (You may be missing the actual hop in the 
logical tree of History-Info that does not support 
4244/4244bis but as they won't add the hi-entry  
there won't be a gap in index itself). 

> 10. Should we say anything in section 8 about anonymized entries? Note that what we might say depends to some extent on whether what exactly gets anomymised. For example if an application searches…

 URI will be useless but one can still determine how many times 
request  was retargeted, for example (Of course this is true only 
if all the proxies are rfc4244bis compliant), which I think remains 
useful.

> 12. I would expect to see something in section 9 concerning privacy. We should mention the privacy mechanism and discuss its limits (i.e., depends on trust of downstream entities to anonymize priva…

 Agree that text should be added. 

> In fact it adds two parameters to each.

 Indeed. 

> We cannot place a normative requirement on entities that don't implement this. Change "MUST" to "will".

 Agree. 

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

---

From: Mary Barnes <[email-masked]>
Date: Sun, 7 Nov 2010 23:19:25 -0600

A few additional comments inline below [MB].

Mary.

>> 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show ju…

[MB] It is only the hi-targeted-to-uri that needs to be anonymized -
it is a MUST. The other parameters MUST not be changed. [/MB]
> anonymize not only the first hi-entry but any other entries that
[MB] I don't have a strong opinion here.  The suggestion above makes
alot of sense.  [/MB]
> needs to remove the privacy=history from hi-entries that it's anonymizing.
[MB] Yes, we should clarify.  With the approach discussed above, the
privacy:history would "override" the privacy for each entry (within
that domain).  And, yes, per a previous thread, we do need to update
the privacy text to indicate the removal of the privacy for each
hi-entry as it is anonymized. [/MB]

> your own AoR or contact address?
[MB]  We originally did not include privacy of "none" as relevant to
History-info (in 4244). That was added in -bis and I to question the
value.  I do not think it has any value as applied to History-Info and
I would suggest we remove it or note that it has no impact in terms of
the processing of privacy for the hi-entries. [/MB]
> think we need to add text on this as well.
[MB] Agreed. [/MB]
>> Is it only routing information within an intermediary, or also routing information within a domain that you might want to make private? I think text later in the paragraph concurs with the latter…
[MB] yes, it's the latter -  within a domain for which the
intermediary is responsible. [/MB]
>> Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been mark…
[MB] Yes. that sentence should apply to all responses - i.e., in
general if there are hi-entries with an escaped privacy header, they
should be anonymized and the privacy header removed. [/MB]

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Nov 2010 07:31:02 +0100

Replying to both Shida and Mary: 

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 08 November 2010 05:19
> To: Shida Schubert
> Cc: Elwell, John; Barnes, Mary; [email-masked]
> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
> 
> >> I think it should say "...and the Privacy header removed" 
> - there is no point in removing the H-I header field if we 
> have anonymized it.
> >
> >> 2. What is meant by anonymizing a hi-entry (in this 
> paragraph and elsewhere)? Is it only the hi-targeted-to-uri 
> that needs to be anonymized, or also its parameters? The 
> examples in annex B show just the URI anonymized and with the 
> value [email-masked]. Is this how it MUST be done?
> 
[JRE] You didn't express any opinion whether we should mandate the way in which hi-targeted-uri is to be anonymized.

<snip/>

> > say incrementing the digit at the current level by 1 or
[JRE] Why can't we specify the field as an integer, and then we can say we increment the integer?

> >> Should there be a note discussing the fact that some gaps 
> are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I 
> cannot detect if 1.2 or 1.1.2, say, is missing.
> >
[JRE] Yes, I understand that, and that is why I just asked the question - I don't have a strong opinion as to whether this is good enough or not.

<snip/>

John

---

From: Shida Schubert <[email-masked]>
Date: Mon, 8 Nov 2010 15:50:13 +0900

Hi John;

 My comments inline.

> [JRE] You didn't express any opinion whether we should mandate the way in which hi-targeted-uri is to be anonymized.

 To avoid redundant anonymization in case there are numerous 
proxy acting as a privacy services, it would be good to mandate 
how hi-targeted-uri is anonymized, so I am happy to say MUST 
here. 

> [JRE] Why can't we specify the field as an integer, and then we can say we increment the integer?

 Sounds good to me. 

> [JRE] Yes, I understand that, and that is why I just asked the question - I don't have a strong opinion as to whether this is good enough or not.

 I think we can definitely add a text saying the hi-entries 
an entity receives may not represent the whole picture 
of where request was sent (other branches etc.). 

 Regards
  Shida

---

From: Mary Barnes <[email-masked]>
Date: Mon, 8 Nov 2010 00:55:48 -0600

A few more comments below [MB2].

Thanks,
Mary.

> [JRE] You didn't express any opinion whether we should mandate the way in which hi-targeted-uri is to be anonymized.

[MB2] My opinion is that we should mandate the anonymization in the
same form as in RFC 3323.   I can't think of a reason why it shouldn't
be mandated.  [MB2]
> [JRE] Why can't we specify the field as an integer, and then we can say we increment the integer?
[MB] It can't be an integer since it can't have negative values.  But,
you are correct, we do need to allow multi-digit indices, so the ABNF
needs to be fixed. [/MB]

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 08:55:36 +0100

Shida,
Do I understand you correct that you woulf like to mandate the uri format e.g. anonymus@anonymus,invalid? 
Why you would like it to be stronger than in RFC3323 mandated?

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Shida Schubert
Gesendet: Montag, 8. November 2010 07:50
An: Elwell, John
Cc: Barnes, Mary; [email-masked]
Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02

Hi John;

 My comments inline.

 Sounds good to me. 

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Mon, 8 Nov 2010 17:32:06 +0900

Hi Roland;

 I meant to say, mandate the use of domain name "anonymous.invalid" as 
it is mandated in RFC3323 and used as a means to distinguish anonymized 
URI in RFC5079. This would help privacy service to see if other privacy 
service has already obfuscated the URI in H-I. 

 Regards
  Shida

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Nov 2010 05:21:07 -0500

Why do you think that Privacy:none is not important for H-I?
IIUC, Privacy:none is a way for a caller to get identity info passed e2e 
even if there are SPs along the path that wish to block things.

Why would that not apply to H-I as well? I may want the callee to know 
the history of the call even if my SP does not wish that.

	Thanks,
	Paul

On 11/8/2010 12:19 AM, Mary Barnes wrote:
> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert<[email-masked]>  wrote:
>>
>> Hi John;
>>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 8 Nov 2010 20:01:44 +0900

Paul;

 Privacy:none is used when caller (UAC) wants his/her identity delivered 
to the destination (callee) despite the existence of privacy service, but 
with regards to H-I, when does it ever contain the URI that identifies the 
caller (UAC) ? 

 I agree that privacy:none will be valid if we can find a situation where 
URI of UA will be one of the hi-entry but my imagination is not strong 
enough to see this. 

 Regards
  Shida 

On Nov 8, 2010, at 7:21 PM, Paul Kyzivat wrote:

> IIUC, Privacy:none is a way for a caller to get identity info passed e2e even if there are SPs along the path that wish to block things.
> 
> Why would that not apply to H-I as well? I may want the callee to know the history of the call even if my SP does not wish that.
> 
> 	Thanks,
> 	Paul
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Nov 2010 10:01:39 -0500

> URI of UA will be one of the hi-entry but my imagination is not strong

But that also begs the question of why we need a Privacy header of "history" to begin with. (I mean a real Privacy header in the message, not an embedded one in a particular HI URI)

The only case I could imagine for such things is that the caller doesn't want their domain known about.  I.e., I make an anonymous call from my SIP phone through my corporate SIP proxy, and my SIP phone sets "Privacy: history" so that Acme Packet's anonymization proxy removes "acmepacket.com" from any H-Is, before sending it out our SIP trunk, etc.

-hadriel

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 16:18:54 +0100

Hi Hadriel,
is has also an other reason. When you send from the retargeting SIP Server an call Forwarding (Retargeting) notification in backward direction (181 Response) with an History Info, the target should be marked as private, because the retargeting server has no knowledge about the privacy instructions of the terminating user.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
Gesendet: Montag, 8. November 2010 16:02
An: Shida Schubert
Cc: [email-masked]
Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Nov 2010 17:04:34 -0500

Right but isn't that done with the _embedded_ Privacy header in the H-I URI?  I was talking about the Privacy header of the request message itself - that's what I meant by "(I mean a real Privacy header in the message, not an embedded one in a particular HI URI)".  Sorry for the confusion.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 00:55:14 -0500

> the history of the call even if my SP does not wish that.

I can't comment on the "none" setting bit, but expecting it to prevent an SP from anonymizing (or more likely, removing) H-I entries is silly.  Most of the H-I entries have absolutely nothing to do with the *caller*, and in fact are far more revealing about the SP's equipment/nodes than revealing anything about the caller's identity.

Even *allowing* a UAC to tell some downstream node what the downstream node can/cannot reveal about the downstream node is a joke.

Think of it this way: let's say we were talking about email SMTP, and there were some SMTP header named "Privacy" which you could set to tell your Cisco email server to anonymize your name from the email you send out.  Imagine that the Cisco Email server was actually a cluster of decomposed roles in separate physical boxes, with some internal SMTP message passing between the boxes. (like one did storage, one did virus checking access, one did spam filtering, one was for external SMTP, etc.)  Between each of these systems they add a History-Info header.  Now imagine the Cisco IT department removes these H-I headers when an email gets sent out of Cisco, in order to not reveal this internal design and addresses.  Do you really think Cisco's IT department would allow your email client to tell their servers to expose these headers?? 

-hadriel