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

[Shida Schubert <[e-mail]>]

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:

> 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:
>> A few additional comments inline below [MB].
>> 
>> Mary.
>> 
>> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert<[e-mail]>  wrote:
>>> 
>>> 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?
>> 
>> [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]
>>> 
>>>  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.
>> [MB] I don't have a strong opinion here.  The suggestion above makes
>> alot of sense.  [/MB]
>>> 
>>>  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.
>> [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]
>> 
>>> 
>>>  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?
>> [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]
>>> 
>>>  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.
>> [MB] Agreed. [/MB]
>>> 
>>> 
>>>> 
>>>> 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.
>> [MB] yes, it's the latter -  within a domain for which the
>> intermediary is responsible. [/MB]
>>>> 
>>>> 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?
>> [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]
>>> 
>>>  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
>>> 
>>> _______________________________________________
>>> sipcore mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>> 
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore