Re: [sipcore] Updated 4244bis and new call flow document

Keith,

You raise a good point. It forced me to go back and review 3323 and 3325.

3323 defines a "privacy service" which the UAC can use to assist it in 
obtaining privacy. The UAC is expected to arrange for its requests to be 
routed through a privacy service.

The notion of trust domain is introduced in 3325. It introduces the "id" 
privacy value, which is to be removed at the boundary of the trust 
domain, but not before then. It doesn't say anything about where privacy 
services exist in the network. Its my assumption that there must be a 
privacy service on the boundary of the trust domain that acts on the 
"id" privacy type. But this is not explict. And even if this is implied, 
its hard to say if it would be a full privacy service that can be 
counted upon to act upon other privacy types in the request.

Hence, a UAC that wishes "header" or "session" privacy has nothing 
better to go on than 3323, which recommends that it route its outbound 
request directly to a privacy service. If that privacy service is 
compliant with 4244bis, it will anonymize what is in the H-I header at 
that time. But then any entries added downstream of that point will not 
be anonymized.

So I think there really is something wrong with the referenced text.
If the use of "domain" was intended to be "trust domain" then its 
dependent on 3325. If it was intended to mean "DNS domain", then its 
still implying there is a privacy service that will magically be 
traversed when leaving the DNS domain.

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
> If we are going to talk about trust domains in the document, then you will have to say what they are.
> 
> For the RFC 3325 stuff there is most of a document that talks about that. Moreover, you need to say what to "trust" the next entity to do if you do not do it.
> 
> To give some idea of what I mean. Statements like "I will give you the identity if you do not reveal it to anyone outside our area of trust" are slightly different to "I trust you to implement the privacy that I otherwise would have done so if I did not trust you".
> 
> regards
> 
> Keith
> 
>> -----Original Message-----
>> From: sipcore-bounces@ietf.org 
>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: Friday, July 23, 2010 2:12 PM
>> To: R.Jesske@telekom.de
>> Cc: sipcore@ietf.org
>> Subject: Re: [sipcore] Updated 4244bis and new call flow document
>>
>>
>>
>> R.Jesske@telekom.de wrote:
>>> Hi Mary,
>>> With regard to your question for comments/review, I went 
>> thought the draft.
>>> For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt
>>>
>>> I have the following comments: 
>>>
>>>
>>> 6.3.2.  Privacy in the History-Info Header
>>>
>>> ...
>>> If the requestor has indicated a priv-
>>>    value of "session" or "header" in the request, all History-Info
>>>    entries MUST be anonymized when the request leaves a 
>> domain for which
>>>    the intermediary is responsible.
>>> ...
>>>
>>> In this section it is mentioned that the entries must be 
>> anonymized when leaving the domain. I thought that if a trust 
>> relationship between domains are existing and the following 
>> domain secures the "privacy" then the information could be 
>> forwarded and will then deleted by the succeeding domain 
>> before reaching the terminating user. 
>>> Some regulators are requesting to pass identities until the 
>> last domain where it is possible to execute the privacy 
>> regarding RFC3323. So I think this is a MAY based on domain 
>> policy. And it is a MUST when the succeeding network cannot 
>> guarantee the privacy.
>>> Or do I misunderstand the meaning of "domain for which the 
>> intermediary is responsible"
>>
>> I'm not an expert on this, but ISTM that in the case you 
>> describe the request is not leaving the *trust* domain.
>>
>> But that does point out ambiguity in the text you quote. That 
>> kind of wording "domain for which the intermediary is 
>> responsible" is usually talking about *DNS* domains, not 
>> *trust* domains. So maybe that should say:
>>
>>   ...
>>   If the requestor has indicated a priv-value of "session" or "header"
>>   in the request, all History-Info entries MUST be anonymized when the
>>   request leaves a *trust* domain for which the intermediary is
>>   responsible.
>>   ...
>>
>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>