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

[Shida Schubert <[e-mail]>]

Hi John;

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

On Nov 4, 2010, at 12:29 AM, Elwell, John wrote:

> 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.

 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 just the URI anonymized and with the value [e-mail]. Is this how it MUST be done?

 I personally don't have a strong opinion about prescribing the [e-mail] 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 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.

 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.
 

> 
> 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?

 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.

> 
> 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).

 Agree. 

> 
> 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"

 Agree.

> 
> 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?

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

> 
> 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.

 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 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.

 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.

> 
> 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 [e-mail]).

 Agree that text should be added. 

> 
> 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.

 Indeed. 

> 
> 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".

 Agree. 

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