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

From: Mary Barnes <[email-masked]>
Date: Thu, 1 Jul 2010 14:30:35 -0500

Hi folks,

I have not seen any responses to this email. So, either folks don't
see any issues with the documents and 4244bis is ready for WGLC or
folks have not reviewed the documents.  I'm happy to assume the
former, however, it would be good for folks that have read the docs to
post a note on the mailing list as to whether they think  4244bis is
ready for WGLC.  And, if not, please detail your concerns, so that we
can determine whether they warrant discussion in Maastricht.

Also, opinions on how/where to progress the call flow document would
be welcome.  I personally do not think it's worthwhile to pursue this
in DISPATCH, but it's not clear to me whether informational docs like
this are under the purview of the SIPCORE charter.  Since BLISS is
trying to close down, it is also not appropriate to pursue the work
there.

Thanks,
Mary.

On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes <[email-masked]> wrote:
> Hi folks,
>
> The 4244bis draft has been updated and a separate call flow document
> created per the earlier summary of proposed changes:
> http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html
>
> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt
> http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.txt
>
> There are  two voicemail examples in the new call flow document.  The
> 4244bis has 3 call flows - the basic sequential forking and two
> privacy examples. All the rest are now in the call flow document.
>
> The other changes we made were updates to the UAC, UAS and application
> considerations section - adding additional text as to how the UAC and
> UAS process hi-entries (including related to responses).  The
> application considerations section now describes how the tags can be
> used to derive specific information and the past guidelines were
> removed since 4244bis has much definitive guidance on the normative
> aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via
> anonymization rather than removing entries, etc.) as summarized in
> Section 11.
>
> Please review and provide any additional comments. We believe that
> 4244bis is pretty much ready to go. We can fine tune the details in
> the call flows and should be able to get that ready very soon, as
> well.  Let us know if you see additional use cases you would like to
> add.
>
> Thanks,
> Mary et al
>

---

From: <[email-masked]>
Date: Fri, 23 Jul 2010 11:15:21 +0200

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"

 The Rest of the document looks good for me.

Best Regards

Roland

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobil)
E-Mail: [email-masked]
www.telekom.com  

Erleben, was verbindet. 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Mary Barnes
Gesendet: Donnerstag, 1. Juli 2010 21:31
An: SIPCORE
Betreff: Re: [sipcore] Updated 4244bis and new call flow document

Hi folks,

Thanks,
Mary.

> well.  Let us know if you see additional use cases you would like to
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jul 2010 09:11:56 -0400

> 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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 23 Jul 2010 15:24:49 +0200

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, July 23, 2010 2:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [sipcore] Updated 4244bis and new call flow document
> 
> 
> 
> > 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.
> > 
> 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:
> 
>   ...

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jul 2010 10:12:07 -0400

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

---

From: <[email-masked]>
Date: Sun, 25 Jul 2010 03:09:24 +0200

Hi Mary and all,

I have some comments on draft-ietf-sipcore-rfc4244bis-01:

1- Regarding the "hit" and "target" parameters, is it really necessary to create both? 
   I mean the "hit" parameter seems almost useless as it has to be removed from the R-URI just 
   after its creation (kept only in the Contact header after a 3xx).
   Why the hi-target couldn't be a single parameter to tag URIs?

2- §4.1 it is said that 
   "The entries SHOULD be evaluated to determine gaps in indices, 
   which could indicate that an entry has been maliciously removed.  
   Either way, an application SHOULD be aware of potentially missing information." 
  If the removed hi-entry is the last destination (leaf) of an unsuccessful route (branch), 
  how is it possible, at the end, to know that there is a missing entry?

3- §5.1.1 At the end of the second sentence, there are 2 right parenthesis.
   §6.3.1 after reference to [RFC3261], there are 2 right square brackets.

4- §6.1 In the rules after the header syntax, the sentence 
   "There MUST be no more than one hi-target parameter." 
   should be completed with "per hi-entry" to be more precise (as it is the case in the previous item).

5- §6.3.2 In the sentence 
	"This is accomplished by adding a new priv-value,
   	history, to the Privacy header [RFC3323] indicating that a specific
   	History-Info header entry can not be forwarded outside the domain."
   It should be better to complete with : To do this, the Privacy header with the priv-value history is 
   escaped in the hi-entry corresponding to the concerned URI.

6- §7: 
	"For example, an Automatic Call Distribution (ACD)/Call center application
   	that utilizes the entry prior to the first History-Info entry with an
   	hi-target value of "mp", ..."
   Do you mean the entry with the index that matches the first History-Info entry with an hi-target value of "mp"? (instead of the prior)

7- Appendix B.2 and B.3: what is the "p=x" in the URI?

Cheers,
Marianne 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Mary Barnes
Envoyé : jeudi 1 juillet 2010 21:31
À : SIPCORE
Objet : Re: [sipcore] Updated 4244bis and new call flow document

Hi folks,

I have not seen any responses to this email. So, either folks don't see any issues with the documents and 4244bis is ready for WGLC or folks have not reviewed the documents.  I'm happy to assume the former, however, it would be good for folks that have read the docs to post a note on the mailing list as to whether they think  4244bis is ready for WGLC.  And, if not, please detail your concerns, so that we can determine whether they warrant discussion in Maastricht.

Also, opinions on how/where to progress the call flow document would be welcome.  I personally do not think it's worthwhile to pursue this in DISPATCH, but it's not clear to me whether informational docs like this are under the purview of the SIPCORE charter.  Since BLISS is trying to close down, it is also not appropriate to pursue the work there.

Thanks,
Mary.

---

From: Shida Schubert <[email-masked]>
Date: Sun, 25 Jul 2010 17:22:08 +0200

Hi Marianne;

Thanks for the review, comments inline..

>  Why the hi-target couldn't be a single parameter to tag URIs?

I can't clearly recall why we added this "hit" parameter but 
we had some problems delivering the "to-be hi-entry" that 
caused the 3xx. We talked about escaping the history-info header 
in the contact header in 3xx so entity receiving the 3xx can construct 
the hi-entry but decided to go with using the "hit" parameter. 

> how is it possible, at the end, to know that there is a missing entry?

It's true that if a leaf at an unsuccessful forked branch isn't 
captured there is no way to find out if there is a leaf is missing, but you 
will still get an hi-entry showing the unsuccessful branch with 
a reason that triggered the request received(e.g. 
branch that failed due to 487 for example will show up in the H-I 
but contact address(leaf) at the end of the failed branch won't).. 

>  Do you mean the entry with the index that matches the first History-Info entry with an hi-target value of "mp"? (instead of the prior)

I will let Mary answer this one.. 

Regards
 Shida

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 26 Jul 2010 08:22:45 +0200

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, July 23, 2010 3:12 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]
> 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.
> 
> 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.
> 
> 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
> 
> > 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
> > 
> >> 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.
> >> 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.
> describe the 
> >> talking about *DNS* domains, not

---

From: Mary Barnes <[email-masked]>
Date: Mon, 26 Jul 2010 01:34:58 -0500

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) <
[email-masked]> wrote:

> 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
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 26 Jul 2010 02:51:05 -0500

Marianne and Shida,

Responses inline below [MB].

Thanks,
Mary.

On Sun, Jul 25, 2010 at 10:22 AM, Shida Schubert <[email-masked]> wrote:

> On Jul 25, 2010, at 3:09 AM, <[email-masked]> <
> [email-masked]> wrote:
>
> > Hi Mary and all,
> >

[MB] Yes, both are necessary. If you look at the last individual version of
the doc, the handling for the 3xx had been changed from RFC4244 and had the
redirect server adding hi-entries. However, that was broken since the
redirect server cannot know whether the URIs it puts in the Contact header
are actually used to retarget the request. But, the redirect server is the
only entity that knows the mechanisms by which the URIs it adds to the
contact were determined.  So, we added the "hit" as a URI parameter for the
URIs in the Contact header. Then, the proxy/entity that is actually building
the hi-entries can use this information to include the right "hi-target".
 This really ended up making the processing far less different than RFC 4244
and far less complex - both good things.  [/MB]

> but contact address(leaf) at the end of the failed branch won't)..
[MB] The text you are referencing has to do with how you can know that
entries are missing if there are gaps in the values of the index - e.g., an
entry with an index of 1.1 and then the next having a value of 1.3, etc.
This actually should not occur with 4244bis since the privacy was changed to
anonymize rather than remove.  The only time that might happen is if you
have a rogue proxy or a proxy that has not properly implemented 4244(-bis).
This document relies on the fundamental SIP model that the proxies are
trusted. That text is not referring to the case where the request for that
branch does not result in a successful termination. However, the proxy
should include all the information associated with that branch IF it is
received before the request is successfully targeted. Note, that this gets
to the point that Paul raised wrt to the need to clarify the processing for
forking. For sequential forking, there is no issue, however, parallel
forking introduces the possibility that the entity to which a request is
successfully targeted not receiving the complete information. However, the
information is complete in terms of what is available at that point in time.
As Paul highlighted, we do need to add additional normative text to describe
the handling of the header in the case of forking.

As far as the case of a 487, if a proxy supports HI then the Request-URI for
that branch should be included. But, since it wasn't successful that entry
will not be the contact address as Shida notes. However, that is NOT
considered a missing entry since the request was not sent to the contact.
 [/MB]

> >  §6.3.1 after reference to [RFC3261], there are 2 right square brackets.
[MB] Will fix both of those - thanks. [/MB]

> case in the previous item).
[MB] Good point - I'll clarify. [/MB]

> >  escaped in the hi-entry corresponding to the concerned URI.
[MB] Okay, I'll clarify that.  [/MB]

> >  Do you mean the entry with the index that matches the first History-Info
> entry with an hi-target value of "mp"? (instead of the prior)
>
[MB]   Yes - that needs to be fixed. [/MB]

> > 7- Appendix B.2 and B.3: what is the "p=x" in the URI?
[MB] That was intended to represent a privacy header of "x", with x being
any value for the privacy header with "history". However, there is no
compact form for the privacy header, so really we should just show it inline
as we did in an earlier version. The gist of that call flow was to show that
rather than remove the entries they are now anonymized when they go outside
the domain responsible for the Request-URI. [/MB].

> > I have not seen any responses to this email. So, either folks don't see
> any issues with the documents and 4244bis is ready for WGLC or folks have
> not reviewed the documents.  I'm happy to assume the former, however, it
> would be good for folks that have read the docs to post a note on the
> mailing list as to whether they think  4244bis is ready for WGLC.  And, if
> not, please detail your concerns, so that we can determine whether they
> warrant discussion in Maastricht.
> >
> > Also, opinions on how/where to progress the call flow document would be
> welcome.  I personally do not think it's worthwhile to pursue this in
> DISPATCH, but it's not clear to me whether informational docs like this are
> under the purview of the SIPCORE charter.  Since BLISS is trying to close
> down, it is also not appropriate to pursue the work there.
> >
> > Thanks,
> > Mary.
> >

---

From: Mary Barnes <[email-masked]>
Date: Mon, 26 Jul 2010 03:23:03 -0500

Hi Roland,

That sentence is written within the context of core RFC 3261.  We really
didn't get into the RFC 3325 trust domain concept in RFC 4244 - in
particular because RFC 3325 is informational.  However, there is an UNLESS
later in that section:

"...,unless the processing entity knows a priori that it can rely on a
downstream processing entity within its domain to apply the requested
privacy or local policy allows the forwarding."

So, I will include that same clause in the sentence you are concerned about.

Thanks,

Mary.

On Fri, Jul 23, 2010 at 4:15 AM, <[email-masked]> wrote:

> 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.
>