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

[Mary Barnes <[e-mail]>]

Yes - the use of trust domain in this document is intended to be that
defined in RFC 3325.  The use of the term "responsible domain" is based on
core RFC 3261 - e.g., "....domains the proxy is configured to be responsible
for" as noted in section 16.4.

RFC 4244 did not introduce any new definitions or concepts wrt domains/trust
domains and relies entirely on RFC3261 and RFC3325 for these concepts. I
can't see that the text in RFC 4244bis contradicts with the usages of the
terms defined in those RFCs. But, I might be too familiar with the doc to
see that.

Thanks,
Mary.


On Mon, Jul 26, 2010 at 1:22 AM, DRAGE, Keith (Keith) <
[e-mail]> wrote:

> 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:[e-mail]]
> > Sent: Friday, July 23, 2010 3:12 PM
> > To: DRAGE, Keith (Keith)
> > Cc: [e-mail]; [e-mail]
> > 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: [e-mail]
> > >> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> > >> Sent: Friday, July 23, 2010 2:12 PM
> > >> To: [e-mail]
> > >> Cc: [e-mail]
> > >> Subject: Re: [sipcore] Updated 4244bis and new call flow document
> > >>
> > >>
> > >>
> > >> [e-mail] 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/sipcore
> > >>
> >
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>