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

[<[e-mail]>]

Hi,
seen from network operator perspective. The stronger value hits.
So if there is a "history" and "none" in the same Message then the History Info will be anonymised and the rest will stay as it is.

Best Regards

Roland
 

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Paul Kyzivat
Gesendet: Dienstag, 9. November 2010 01:09
An: [e-mail]
Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02



On 11/8/2010 1:10 PM, Ian Elz wrote:
> Mary,
>
> I am a bit late replying.
>
> The reason for the Privacy of "none" was probably due to my comments.
>
> Regarding "Privacy:history" being used to anonomise all H-I URI then this probably looks OK as it makes everything private.
>
> The problem is that making the Privacy header take precedence over the individual entries is when you have "Privacy:none" and some of the H-I entries have Privacy=history. If you take the Privacy:history case then the ":none" will override "=history" which effectively means that the originator of the request can specify the privacy of URIs belonging to someone who diverts or re-targets the request.
>
> This is just not correct.

Why do you say this is not correct?
ISTM the purpose of Privacy:none is precisely to demand that nothing be 
removed or anonymized. For instance, IIUC this would apply to Route 
headers, which present some of the same issues as H-I headers.

Elements along the way that don't like this can either:
- fail the call
- omit information in the first place if they want it kept private

	Thanks,
	Paul

> The purpose of allowing "privacy=none" in the H-I entry was to allow the future possibility of the overriding the Privacy header.
>
> We need to remember that RFC3323 was written when cocepts of diversion etc were not part of sip.
>
> Ian Elz
>
> ----- Original Message -----
> From: "Mary Barnes"<[e-mail]>
> To: "Shida Schubert"<[e-mail]>
> Cc: [e-mail], "Mary Barnes"<[e-mail]>
> Sent: Monday, 8 November, 2010 5:19:25 AM
> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
>
> 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