Subject: Re: [sipcore] privacy handling

From: "Elwell, John" <[email-masked]>
Date: Wed, 1 Sep 2010 10:36:29 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 31 August 2010 18:19
> To: Worley, Dale R (Dale)
> Cc: SIPCORE (Session Initiation Protocol Core) WG
> Subject: Re: [sipcore] privacy handling
> 
> 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.
[JRE] Paul has put into words what I was wrestling with during my review of the draft (and failed to capture in my comments). It does seem that an H-I-supporting proxy has to also provide a privacy service. Rather than referring to RFC 3323 on what to do under conditions where an hi-entry is subject to privacy and cannot be forwarded (in a request or in a response), it would be better to specify exactly what the proxy must do. The possibilities seem to be to remove the hi-entry or to substitute an anonymous value. The latter does not seem very useful , except that the History-Info header field would still indicate the number of retargets that have occurred (possibly of some use). In the case of an anonymous hi-entry in a request, the proxy could change it back to the original value when passing back the response.

John

> 
> 	Thanks,
> 	Paul
> 
> Worley, Dale R (Dale) wrote:
> > 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:mary.ietf.barnes@gma
> il.com>>> 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
> > 
> > 
> > 
> > 
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Sep 2010 11:18:29 -0400

Hadriel Kaplan wrote:
> On Aug 31, 2010, at 8:28 PM, Paul Kyzivat wrote:
> 
>> Hadriel Kaplan wrote:
>>> On Aug 31, 2010, at 6:35 PM, Paul Kyzivat wrote:
>>>
>>>> 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.)
>>> 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.
>> If the caller only wants his own entry removed, why doesn't he just 
>> 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.
> 
>> 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.
> 
> 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.

IIRC it "guarantees" this by mandating that there be a spec(T) that 
provides that guarantee. Its just passing the buck, but at least it tries.

I don't see any comparable language in 4244bis yet. Referencing 3323 
doesn't give it. So that language needs to be added.

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

If you assume that SBCs are deployed at all the boundaries of 
"management domains" as seems typically to be the case, then they are 
indeed likely candidates to assume the privacy service role.

Of particular note is Privacy:none. I think we could make a case that 
SBCs should honor the provisions of this. (But its hard to write a 
requirement for that since we don't standardize SBC behavior.)

	Thanks,
	Paul