Subject: Re: [sipcore] privacy handling

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 Aug 2010 13:05:26 -0400

Mary Barnes writes (in the middle of a long exchange quoted below):
> 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."

I think the problem can be fixed by deleting the phrase "within its domain" (and also
"a priori", which doesn't add anything):

"..., unless the processing entity knows that it can rely on a downstream processing
entity to apply the requested privacy ..."

The crucial fact is "entity A knows that entity B will do it", not whether or how the
two entities are related to each other.  And in practice, whether or not "entity A knows ..."
is clearer than whether or not "entity A is in the same trust domain as entity B",
and possibly clearer than "entity A is in the same SIP domain as entity B" --
the latter two questions are fraught with definitional problems, whereas the first
question is purely functional.

Dale
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mary Barnes [[email-masked]]
Sent: Wednesday, August 25, 2010 2:18 PM
To: Paul Kyzivat
Cc: SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis

Paul,

In the context of 4244/-bis, the term domain is a DNS domain (per RFC 3261) and not a SPEC-T Trust Domain per RFC 3325.  However, the specific terminology we are referring to is also in RFC 3261 in that a SIP entity can be responsible for multiple domains, which is not a Trust domain, but is something that can be configured.  That's the context meant in RFC 4244/-bis.  It is outside the scope of RFC 3261 (and thus RFC 4244/-bis) as to how those relationships are configured. It could certainly be done using the Trust domain model, but again, that's out of scope.

If it helps, I can add in the terminology section that domain (and the terminology around the domains for which an entity is responsible, etc. ) is used in the same context as RFC 3261, but I personally don't think that should be necessary.

Mary.
On Wed, Aug 25, 2010 at 1:01 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Mary Barnes wrote:
Actually, I did respond to that message, per the following:
http://www.ietf.org/mail-archive/web/sipcore/current/msg03088.html

(threading in the email archives is no better than my archiving method for emails).

Hmm. I cannot find that one anywhere in my own archives, and I don't recall seeing it. Don't know why. :-(

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.

That doesn't do it for me. I think one way or another you need to address whether "domain" means "DNS domain" or "trust domain". And if it means "trust domain" then of course we need a ref to 3325.

You seem to mean DNS domain, but the kinds of actions you are discussing seem more related to 3323 and 3325. ISTM that if you mean DNS domain then you mean it based on an assumption that "DNS domain" = "trust domain".

       Thanks,
       Paul

Thanks,
Mary.
On Wed, Aug 25, 2010 at 11:51 AM, Mary Barnes <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

   Sorry, I should have replied to that thread, but I didn't think
   there was a change necessary.  I'll reply now.

   Mary.

   On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

       [as individual]

       There was some discussion on the -00 version back in July that
       was not, AFAICT, addressed in the -01 version. There is a thread
       emanating from mary's announcement of the -00 version. The
       following is a hook into that thread:

       http://www.ietf.org/mail-archive/web/sipcore/current/msg03056.html

       It has to do with when privacy should be applied.

              Thanks,
              Paul

       Adam Roach wrote:

            [as chair]

           As a reminder, we're just over halfway through this WGLC,
           and have not yet seen any comments. Please take some time to
           review this draft.

           /a

           On 8/16/10 4:29 PM, Adam Roach - SIPCORE Chair wrote:

               [as chair]

               A major author of draft-ietf-sipcore-rfc4244bis-01
               believes that the document has no remaining open issues,
               and is ready for evaluation. Today, we are starting a
               two-week working group last call period. This last call
               period ends on Tuesday, August 31st.

               The latest version of the document can be retrieved here:

               http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

               Any comments on the document should be sent to the
               SIPCORE mailing list.

               /a

               _______________________________________________
               sipcore mailing list
               [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

               https://www.ietf.org/mailman/listinfo/sipcore

           _______________________________________________
           sipcore mailing list
           [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

           https://www.ietf.org/mailman/listinfo/sipcore

       _______________________________________________
       sipcore mailing list
       [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

       https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Aug 2010 13:19:12 -0400

What Dale says would help.

But I'm still concerned with which entities this requirement applies to.
RFC 3323 is being cited for Privacy header processing. But it assigns 
responsibility for that to a privacy service, and makes the UAC/UAS 
responsible for ensuring that the request passes through such a service.
IIUC 42444bis is assuming that every server that supports 4244bis is 
potentially a privacy service.

I'll be happy to learn that I'm entirely wrong in that assumption. I'd 
like to understand how privacy of H-I is intended to work in real use 
cases, and where the privacy service(s) are located to make that happen.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 31 Aug 2010 16:15:55 -0500

Paul,

The intent of 4244/4244bis was to follow the same model as RFC 3323
and use the concept of network-provided privacy.  So, this should not
be anything different than the case where Header privacy is requested.
There is no assumption that the proxy is a privacy service.  The
current text was written as if that was obvious (i.e., assumes you are
using a privacy service, etc. per RFC 3323 without saying such), but
clearly it's not.  I think the best approach is to rewrite the privacy
section entirely using context and terminology consistent with RFC
3323   I think that can also help with the domain issue since the
context of domain is exactly that used in RFC 3323 (with regards to
privacy).

Mary.

On Tue, Aug 31, 2010 at 12:19 PM, Paul Kyzivat <[email-masked]> wrote:
> I'll be happy to learn that I'm entirely wrong in that assumption. I'd like
> to understand how privacy of H-I is intended to work in real use cases, and
> where the privacy service(s) are located to make that happen.
>
>        Thanks,
>        Paul
>
>> In the context of 4244/-bis, the term domain is a DNS domain (per RFC
>> 3261) and not a SPEC-T Trust Domain per RFC 3325.  However, the specific
>> terminology we are referring to is also in RFC 3261 in that a SIP entity can
>> be responsible for multiple domains, which is not a Trust domain, but is
>> something that can be configured.  That's the context meant in RFC
>> 4244/-bis.  It is outside the scope of RFC 3261 (and thus RFC 4244/-bis) as
>> to how those relationships are configured. It could certainly be done using
>> the Trust domain model, but again, that's out of scope.
>>
>> If it helps, I can add in the terminology section that domain (and the
>> terminology around the domains for which an entity is responsible, etc. ) is
>> used in the same context as RFC 3261, but I personally don't think that
>> should be necessary.
>>
>> Mary.
>> On Wed, Aug 25, 2010 at 1:01 PM, Paul Kyzivat
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>> Mary Barnes wrote:
>> 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:
>>
>> That doesn't do it for me. I think one way or another you need to address
>> whether "domain" means "DNS domain" or "trust domain". And if it means
>> "trust domain" then of course we need a ref to 3325.
>>
>> You seem to mean DNS domain, but the kinds of actions you are discussing
>> seem more related to 3323 and 3325. ISTM that if you mean DNS domain then
>> you mean it based on an assumption that "DNS domain" = "trust domain".
>>
>>       Thanks,
>>       Paul
>>
>> Thanks,
>> Mary.
>> On Wed, Aug 25, 2010 at 11:51 AM, Mary Barnes
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>>
>> wrote:
>>
>>   On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat
>> <[email-masked]<mailto:[email-masked]>
>>               [email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>
>>
>>           [email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>
>>
>>       [email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Aug 2010 17:24:31 -0400

Mary,

The implication of what you say is that if the UAC wants privacy for the 
H-I, then it must do something to ensure that the request goes through a 
privacy service, AND, that only those entries added prior to reaching 
the privacy service will be anonymized. If some element downstream from 
the UAC wants privacy for the information it adds, then it must ensure 
that the request will subsequently transit a privacy service. 
Anonymizing of responses is even more problematic.

Are those realistic assumptions for practical use of H-I? (I don't know.)

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 31 Aug 2010 16:50:38 -0500

If the UAC adds an hi-entry and wants privacy, then yes it would need
to use a privacy service.  However, if the privacy header is set for
that request, any HI entries added as the request is forward to the
destination would also be anonymized by a privacy service independent
of whether an element downstream might want to apply privacy to
specific HI entires.  But, none of this is any different than using
the privacy service for any other requests.  The response issue is no
different yet again than other headers that are subject to
privacy/anonymized.  I'm not sure what you mean by anonymizing of
responses unless you're talking about whether or not the privacy
service has been stateful enough to restore the values.

Thanks,
Mary.

On Tue, Aug 31, 2010 at 4:24 PM, Paul Kyzivat <[email-masked]> wrote:
> privacy service, AND, that only those entries added prior to reaching the
> privacy service will be anonymized. If some element downstream from the UAC
> wants privacy for the information it adds, then it must ensure that the
> request will subsequently transit a privacy service. Anonymizing of
> responses is even more problematic.
>
>>> like
>>>> "..., unless the processing entity knows that it can rely on a
>>>> downstream
>>>> processing
>>>> The crucial fact is "entity A knows that entity B will do it", not
>>>> whether
>>>> or how the
>>>> and possibly clearer than "entity A is in the same SIP domain as entity
>>>> B"
>>>> --
>>>> (threading in the email archives is no better than my archiving method
>>>> for
>>>> emails).
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Aug 2010 18:35:56 -0400

> service has been stateful enough to restore the values.

3323 strongly recommends that a UAC desiring privacy establish a direct 
tls connection to the privacy service and send the request there.

If so, and assuming all the interesting routing of the request happens 
further downstream, then its only the UAC's entry that will be 
anonymized. All the others will be added after the privacy service has 
forwarded the request. The only other thing the privacy service can do 
is anonymize the H-I in the response back to the UAC, so that the UAC 
won't have any indication where the request went.

I guess an alternative is for the UAC to have some expectation that a 
privacy service will be present at the boundary between the caller's 
domain and some other domain, whatever that means. But 3323 doesn't 
specify any way to ensure that.

Another point I just realized while reviewing 3323: when a privacy 
service acts on a privacy value, such as "Privacy:header", or 
"Privacy:history", it also removes that value from the Privacy header. 
So those actions are only performed *once*. If "Privacy:history" is 
included by the UAC, and is processed by the first proxy encountered, 
subsequently added H-I information will not be anonymized. (Unless 
"Privacy:history" is added *again* by a proxy after that.)

Regarding responses, ISTM that often servers along the way want their 
identity exposed to those further downstream (e.g. the proxy for the AOR 
wanting the AOR exposed to the VM server), but may not want that stuff 
visible to the caller. That would call for anonymization of the response 
by something upstream of those things that want their identity hidden. 
To accomplish this, the UAS will have to had a Privacy header to the 
response, and there will have to be a privacy service on the path that 
will act on it.

I think perhaps Dale had it right, that much of this can be resolved by 
abandoning passive voice for active voice, thus forcing the 
identification of the agent for each action.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Aug 2010 19:42:32 -0400

> "Privacy:history" is added *again* by a proxy after that.)

But isn't that the right thing, and what we really want?  I mean if you make a call to me, you may want to anonymize your H-I so I don't find out the call is coming from you/Cisco, but that is really only possible and practical for the H-I entries generated by Cisco or some privacy service under your control - once the request reaches Acme you can't expect my servers to anonymize who it's from.  And I need and should expect H-I entries generated by my local servers to reach me, regardless of whether you put a Privacy header in or not.
If I divert the request to Dale at Avaya, then I can add my own Privacy header and my servers/service will anonymize before sending it to Avaya.

> response, and there will have to be a privacy service on the path that

Right, but that's what rfc3323 does/says for privacy of responses.

> identification of the agent for each action.

What email message was that in?  I missed it.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Aug 2010 20:28:55 -0400

> If I divert the request to Dale at Avaya, then I can add my own Privacy header and my servers/service will anonymize before sending it to Avaya.

If the caller only wants his own entry removed, why doesn't he just 
leave it out in the first place?

It only makes sense to put it in if there is reason to expect that it 
will be used before being removed. My *inference* was that the purpose 
of Privacy:history was to cause all the entries then present to be 
removed when the request is passed to a server that isn't acting on 
behalf of the caller. With assumption that between the caller and that 
point there was some possibility of it being useful.

But that only works if the caller knows that the privacy service is 
positioned in such a place. That is the sort of guarantee that 3325 
tries to put in place. But it isn't there in 3323.

Is the elephant in the room here an assumption that Privacy headers are 
really directives to SBCs, and everybody assumes there is one acting on 
their behalf in the path?

> Right, but that's what rfc3323 does/says for privacy of responses.

While its implicit, I didn't see anything in 3323 that mentions the UAS 
inserting a Privacy header in the response. There is verbage that an 
intermediate server might add its own based on local knowledge. The 
first proxy (SBC) on the callee side is the one to be the privacy 
service for this, and is likely to do it whether requested or not.

> What email message was that in?  I missed it.

I don't recall, but I'm pretty sure I saw it.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Aug 2010 21:06:37 -0400

> leave it out in the first place?

Because the first Proxy adds it anyway, and because it is presumably useful within the originator's trust-domain.

> tries to put in place. But it isn't there in 3323.

In what way does 3325 guarantee such a thing?  Afaik, just by mandating that a Proxy implementing 3325 anonymize if its next-hop isn't in the same trust-domain.  I assume there is going to be the same type of language in this 4424bis draft.

> their behalf in the path?

No, though I expect some SBCs will probably remove all H-I entries other than "mp" ones, and change those to not include IP addresses.

-hadriel