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

I suspect the text was meant to mean trust domain as in RFC 3325.

Note that it is not necessarily the RFC 3325 trust domain (different headers can have different trust domains). But it does need to do a similar job to RFC 3324/3325 in defining the concept of the trust domain.

regards

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Friday, July 23, 2010 3:12 PM
> To: DRAGE, Keith (Keith)
> Cc: R.Jesske@telekom.de; sipcore@ietf.org
> Subject: 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
> >>
> 