Re: [sipcore] privacy handling

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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: [e-mail] [[e-mail]] 
> On Behalf Of Mary Barnes [[e-mail]]
> > 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 
> <[e-mail]<mailto:[e-mail]>> 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 
> <[e-mail]<mailto:[e-mail]>
>  
> <mailto:[e-mail]<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 
> <[e-mail]<mailto:[e-mail]>
> >    <mailto:[e-mail]<mailto:[e-mail]>>> 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
> >                [e-mail]<mailto:[e-mail]> 
> <mailto:[e-mail]<mailto:[e-mail]>>
> > 
> >                https://www.ietf.org/mailman/listinfo/sipcore
> > 
> > 
> >            _______________________________________________
> >            sipcore mailing list
> >            [e-mail]<mailto:[e-mail]> 
> <mailto:[e-mail]<mailto:[e-mail]>>
> > 
> >            https://www.ietf.org/mailman/listinfo/sipcore
> > 
> >        _______________________________________________
> >        sipcore mailing list
> >        [e-mail]<mailto:[e-mail]> 
> <mailto:[e-mail]<mailto:[e-mail]>>
> > 
> >        https://www.ietf.org/mailman/listinfo/sipcore
> > 
> > 
> > 
> > 
> > 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>