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

Mary Barnes <> Mon, 08 November 2010 05:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA3F73A68DA for <>; Sun, 7 Nov 2010 21:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q+9zg4SYTKSp for <>; Sun, 7 Nov 2010 21:19:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8866F28C0E4 for <>; Sun, 7 Nov 2010 21:19:05 -0800 (PST)
Received: by ywp6 with SMTP id 6so3428107ywp.31 for <>; Sun, 07 Nov 2010 21:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RWRYa9Euy81icD3r7yIb3Hi8trRBtjf/uQ92fEQeuR4=; b=kHfPqimdvVNCVAU7T0Ng0xVPVxnEgVowj/HjFtlxrGdTrd2BySunPdkYkF9AmXX8ko Dx5YD0WomMKhD8fvGUCbo0o40xN/qZ2Qz9rwUlKvlqDVQ69FPS+AUaYAMSgQvuXgaojE 9Vr50lfhBbAIPra4zPI4P6c4oHnlaCghOq69Y=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TUJvCSJRZ/zPBUoWqPRjTJg+9cS7LHYzAGEVX8glHO0PZ9RkwAMIWMW7YxFWfog3gA f6wDDd+ZSNiN91cCz4IY/FG3bJdKWgFIiKEZywiScKGa0t2TEboyBl5OKrYhvqdRh0rj xRhIrkhS1kf5Vu1w4Ej1GEnhHCg/4zc/NOVD8=
MIME-Version: 1.0
Received: by with SMTP id 13mr4733382agy.33.1289193565089; Sun, 07 Nov 2010 21:19:25 -0800 (PST)
Received: by with HTTP; Sun, 7 Nov 2010 21:19:25 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Sun, 07 Nov 2010 23:19:25 -0600
Message-ID: <>
From: Mary Barnes <>
To: Shida Schubert <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "Barnes, Mary" <>
Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Nov 2010 05:19:07 -0000

A few additional comments inline below [MB].


On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert <> 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 anonymous@anonymous.invalid. 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 anonymous@anonymou.invalid 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 anonymous@anonymous.invalid).
>  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
>> 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
> _______________________________________________
> sipcore mailing list