Subject: [Sip] Re: privacy-clarified draft

From: Paul Kyzivat <[email-masked]>
Date: Sun, 18 Mar 2007 22:17:36 -0400

This draft has been on my list to comment on. I just got to it while in 
the airport. The following isn't very well organized - mostly notes made 
while reading the draft front to back. I've quoted sections of the doc 
(indented) to comment on and/or referenced a section number.

I think this has potential to be an improvement over RFC 3323. But I do 
think it needs more work to reach this potential. Thanks for getting 
this started.

	Paul

    Privacy is defined in this document as the withholding of the
    identity of a person (and related personal information) from one or
    more parties in an exchange of communications, specifically a SIP
    dialog.  These parties potentially include the intended
    destination(s) of messages and/or any intermediaries handling these
    messages.

There is a potential problem with the above definition, since the 
privacy mechanisms, in part, depend on intermediaries to accomplish the 
privacy. So it isn't really withholding info from *any* intermediary - 
rather only from *some* intermediaries.

And that adds some complexity to this process that isn't discussed too 
much. There is in fact conflict in goals among the policies regarding 
which intermediaries get what info. In the case of Privacy:id the goal 
is that the id remain visible to all intermediaries within a "trust 
domain" and only be removed when the message exits that domain. For some 
of the other privacy types I think the expectation, if not the goal, is 
that information may be removed sooner, even if the request remains 
within a trust domain.

    This document also makes an assumption that when user requests
    privacy, it is based on a binary decision.  The user either requests
    privacy for the whole message or no privacy at all.

Really? Then why are there still degrees of privacy?

    privacy service: A network entity which executes privacy functions
                     before forwarding messages to elements that are not
                     trusted.  It is sometimes abbreviated to PS in this
                     document.

I'm not sure this is quite right. If it is a service, then presumably 
you need to forward to this service when you want it. If included, are 
its actions still conditional on whether the next hop is trusted or not?

Its a little unclear whether a privacy service is something that is 
intended to be in the path of every request, or if it is something that 
is to be included in the path when the UA, or some intermediary, decides 
that it is needed for a particular request. My suspicion is that we are 
trying to support multiple models of how this should work without 
clearly understanding what those models are.

    A privacy service can execute partial or full privacy functions on
    behalf of a user agent when requested.

The above seems in conflict with the earlier statement that privacy is a 
binary decision. (Well, maybe not. I guess the choice of full or partial 
is based on how much the UA did for itself and how much it has delegated 
to the privacy service.)

    If a user agent can execute all the privacy functions for the user
    inserted information, then the functions SHOULD be executed at the
    user agent.  If a user agent can provide only partial or no privacy
    function, the user agent SHOULD NOT execute any privacy functions and
    rather it SHOULD delegate the task to the privacy service.

These SHOULDs and SHOULD NOTs don't seem like something that needs to be 
normative. It doesn't hurt anything, except performance, for the UA to 
do something which the service will do again. I think this could better 
be stated that a UA that *can* execute all the user privacy functions 
SHOULD do so, and then that a UA that has not executed all the user 
privacy functions, but that desires privacy, MUST request a privacy 
service to do them. There could be a note that if a server is asked to 
do user privacy functions then there is probably no point in the UA 
doing any of them.

Section 4.1: Syntax:

Others have noted this... Here the syntax is presented as a total 
replacement for that provided in the previous RFCs on the subject, yet 
this isn't a total replacement for those RFCs. Is this intended to 
replace fully RFC 3323 while leaving 3325 and 4244 in place?

There is no mention of "critical". Is this intentional? Is there another 
solution to the problem that "critical" was intending so solve? (Its not 
clear that it actually solved it.)

    With this document, "user", "session", and "critical" are NOT
    RECOMMENDED to be used and be kept solely for the backward
    compatibility reason.

If they are being kept, then they are still needed in the revised syntax.

       Note: Location of privacy service is out of scope.  It depends on
             deployments and network policy.

I think more is needed than this. At the least, "id" depends on being 
done at the edge of the trust domain. And for the others, there must be 
*some* mechanism to ensure that the privacy service is included, so at 
the least there should be some mention of whether the UA must do 
something to involve the PS.

Call-Info: There are many potential uses for call-info. Its not at all 
clear that all of them disclose identity. (This is info about the 
*call*, not the *caller*.) And it may be that some are needed. So 
blocking this is "all" mode might be a problem.

Other headers, such as Alert-Info could conceivably reference the 
caller. Its not clear there is any way a PS could tell if this is the 
case, so maybe this MUST be the responsibility of the UA to anonymize.

     5.2.  Target SIP Parameters and SDP Attributes for Each priv-value

Shouldn't this be "Target SDP Parameters and SDP Attributes..."?

What about other body parts, other than SDP? For instance this could be 
an issue with MESSAGE or NOTIFY and content indirection. This seems to 
be a hard subject.

In section 6.2 or maybe in 8.1, I think there needs to be some 
discussion of whether the PS must be a B2BUA, or if it can sometimes be 
just a proxy. I can't see any other way to do "all", but it does seem 
that it is probably possible to do so for "nw-level". If that is right, 
should just say so explicitly.

    6.4.3.  Replaces Header/Parameter
    ...
    Main challenge for this to function properly is that privacy service
    has to be on a signaling path to the originator for every dialogs.
    Which is generally not possible.

Its not very useful to say that a general solution is not possible. What 
is needed is demonstration that a solution *is* possible.

The examples suggest some strategies:

If the UAC explicitly requests privacy for a call, and then does  a 
REFER that references that call, it must arrange for the same PS to be 
involved in the REFER. And then the PS must do the right thing, even if 
no privacy is requested for the REFER.

If the UAC doesn't know the PS is involved - because some intermediate 
node makes the request on its behalf - then it should arrange that the 
PS be involved in every call to/from the UA that might use REFER to a 
call the PS is providing privacy for. This imposes some pretty stringent 
topology requirements on the network, but that is the consequence of 
attempting to provide privacy without the assistance of the UA.

Note that it seems that replacing the callid will always require the PS 
to be a B2BUA. This is needed to ensure it gets control (to fix up 
refer-to) when a UA the received a private call transfers the caller.

Processing of Path and Service-Route:

The conclusion that these aren't subject to privacy processing seems 
reasonable. But it does highlight that not all intermediate nodes are 
equal in privacy processing. It seems to be part of the concept of trust 
domains. Trust domains are discussed in 3325 in application to 
Privacy:id, and they may apply to Privacy:history too. But they aren't 
related to other privacy processing as discussed in 3323. And it 
certainly isn't covered thoroughly in this draft.

    7.1.  Locating Privacy Service

    If the originating user agent is aware of the URI for the privacy
    service it SHOULD address the privacy service by setting the URI of
    the privacy service in the "Route" header.

The guidelines here don't address the expectations around Privacy:id. 
Here the goal is to get to a privacy service quickly. Then the remainder 
of the path to the callee is private. But Privacy:id wants the id to 
remain non-private as long as the call remains within the trust domain.

These goals seem to conflict. But it may be possible to satisfy them 
both. Inserting a Route header for the PS using the ";lr" parameter, and 
putting it after any other routes known to be in the trust domain can 
help. Then intermediate nodes prior to the PS will have the opportunity 
to insert other intermediate routes ahead of the PS, thus deferring the 
invocation of the PS until the trust domain is to be exited or the 
target is to be reached. (Unlike existing 3325 rules, this would not 
permit the callee to avoid the privacy if it is part of the trust domain.)

Another way to achieve this might be to separate the treatment of 
Privacy:id from other kinds of privacy - notably "all" and "nw-level". 
Specifically, "all" and "nw-level" would be processed as in this 
document, while "id" processing would be defered until the trust domain 
is exited. Of course this makes little sense if the UA contacts an 
independent PS directly, but in that case "id" also makes little sense.

    Note that when a privacy service is handling a request and providing
    privacy on behalf of the destination of the request, providing
    privacy for Record-Route headers downstream of the privacy service is
    significantly more complicated.  This document recommends no way of
    statefully restoring those headers if they are stripped.

This is part of a more general problem of providing privacy for the 
target of a call. This should perhaps bedeclared out of scope in general.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Shida Schubert <[email-masked]>
Date: Mon, 19 Mar 2007 15:39:51 +0100

Paul;

 Thanks for you comprehensive comments.

 My comments inline.

Paul Kyzivat wrote:
> This draft has been on my list to comment on. I just got to it while 
> in the airport. The following isn't very well organized - mostly notes 
> made while reading the draft front to back. I've quoted sections of 
> the doc (indented) to comment on and/or referenced a section number.
>
> I think this has potential to be an improvement over RFC 3323. But I 
> do think it needs more work to reach this potential. Thanks for 
> getting this started.
>
>     Paul
>
> privacy mechanisms, in part, depend on intermediaries to accomplish 
> the privacy. So it isn't really withholding info from *any* 
> intermediary - rather only from *some* intermediaries.
 Agree. Needs to be fixed.
> domain" and only be removed when the message exits that domain. For 
> some of the other privacy types I think the expectation, if not the 
> goal, is that information may be removed sooner, even if the request 
> remains within a trust domain.
 I believe the goal would really depend on the deployment and its 
policy. Even for priv-values such as
"all", depending on the policy the privacy function may be located close 
to the UA or possibly at the
egress point. Recommendation on where privacy function to be allocated 
was something we contemplated to
add but because different deployment has different policy, we saw this 
to be useless.

 Location of privacy service and its ramification to surrounding 
intermediaries may be worth while to
cover in the draft.
> Really? Then why are there still degrees of privacy?
 If you preclude the priv-values remaining for the purpose of backward 
compatibility,
the end user requests privacy to be either enabled or disabled. I see 
this as a binary decision
from end user's perspective. When enabled the degree of how much task UA 
delegates
to PS for providing privacy and how much UA takes on solely depends on 
UA's capability.

> its actions still conditional on whether the next hop is trusted or not?
 You are completely right, this definitely needs to be rewritten. As you 
noted before the privacy functions are not always executed before
forwarding the request to an untrusted entity.

> intended to be in the path of every request, or if it is something 
> that is to be included in the path when the UA, or some intermediary, 
> decides that it is needed for a particular request. My suspicion is 
> that we are trying to support multiple models of how this should work 
> without clearly understanding what those models are.
 Yes that's the intention.
 Generally speaking I believe privacy, if requested at the establishment 
of the session would
require the PS to be on the path for every request until the session is 
terminated.
> The above seems in conflict with the earlier statement that privacy is 
> a binary decision. (Well, maybe not. I guess the choice of full or 
> partial is based on how much the UA did for itself and how much it has 
> delegated to the privacy service.)
 It's a binary decision as far as end user is concerned. I think this 
obviously needs to be
clarified. How much UA does and how much privacy service does really 
depends on UA's ability as
you noted above.
> These SHOULDs and SHOULD NOTs don't seem like something that needs to 
> be normative. It doesn't hurt anything, except performance, for the UA 
> to do something which the service will do again. I think this could 
> better be stated that a UA that *can* execute all the user privacy 
> functions SHOULD do so, and then that a UA that has not executed all 
> the user privacy functions, but that desires privacy, MUST request a 
> privacy service to do them. There could be a note that if a server is 
> asked to do user privacy functions then there is probably no point in 
> the UA doing any of them.
>
 Agree, will fix the text accordingly.

> There is no mention of "critical". Is this intentional? Is there 
> another solution to the problem that "critical" was intending so 
> solve? (Its not clear that it actually solved it.)
 Currently the text reads to say that it suggests to use proxy-require 
to use
> If they are being kept, then they are still needed in the revised syntax.
 Understood. Will add them in the syntax.
> done at the edge of the trust domain. And for the others, there must 
> be *some* mechanism to ensure that the privacy service is included, so 
> at the least there should be some mention of whether the UA must do 
 I added a note in the section 8 about this problem, and regretfully I 
couldn't come up with any idea to accomplish what
you are requesting.

 The PS like any other network provided services such as sip-identity, 
proxy inserted location solely depends
on the availability of the services in the network thus UA has no way to 
assure its involvement. Of course mechanisms
such as config-fw etc. may be used to discover PS in which case UA can 
add them explicitly in a Route header to ensure
request gets routed through PS but that's as far as we can do, as far as 
I can see. Any suggestions to improve this
situation is much appreciated.
> blocking this is "all" mode might be a problem.
 Will add a text to make this conditional.
> case, so maybe this MUST be the responsibility of the UA to anonymize.
 Okay.
> What about other body parts, other than SDP? For instance this could 
> be an issue with MESSAGE or NOTIFY and content indirection. This seems 
> to be a hard subject.
 content indirection I agree.
 NOTIFY was obviously overlooked.
> discussion of whether the PS must be a B2BUA, or if it can sometimes 
> be just a proxy. I can't see any other way to do "all", but it does 
> seem that it is probably possible to do so for "nw-level". If that is 
> right, should just say so explicitly.
 Will add the text to make it more explicit.
> Its not very useful to say that a general solution is not possible. 
> What is needed is demonstration that a solution *is* possible.
>
> involved in the REFER. And then the PS must do the right thing, even 
> if no privacy is requested for the REFER.
>
> call the PS is providing privacy for. This imposes some pretty 
> stringent topology requirements on the network, but that is the 
> consequence of attempting to provide privacy without the assistance of 
> the UA.
 Agree replacing addressing component (URI/IP) that would be used in the 
REFER so any requests
derived from REFER would result in passing the PS would be a way to 
solve this. The simplest solution
would be to ensure UA executes the privacy service but the real world is 
not that friendly.
>
> Note that it seems that replacing the callid will always require the 
> PS to be a B2BUA. This is needed to ensure it gets control (to fix up 
 Agree. I think what you are saying is that some recommendation which 
may impose some particular
topology should be given as a possible solution to the issue mentioned.
> equal in privacy processing. It seems to be part of the concept of 
> trust domains. Trust domains are discussed in 3325 in application to 
 What do you want to see in respect to these headers?
> Here the goal is to get to a privacy service quickly. Then the 
> remainder of the path to the callee is private. But Privacy:id wants 
> the id to remain non-private as long as the call remains within the 
> trust domain.
 Agree. Consolidating the execution of privacy on P-A-ID both in 
"nw-level" and "all" introduced this issue.
> both. Inserting a Route header for the PS using the ";lr" parameter, 
> and putting it after any other routes known to be in the trust domain 
> can help. Then intermediate nodes prior to the PS will have the 
> opportunity to insert other intermediate routes ahead of the PS, thus 
> deferring the invocation of the PS until the trust domain is to be 
> exited or the target is to be reached. (Unlike existing 3325 rules, 
> this would not permit the callee to avoid the privacy if it is part of 
> the trust domain.)
This is if the location of PS is known. Or were you thinking of 
something like Service-URN in the Route header as suggested in
Jonathan's service identity draft?
> document, while "id" processing would be defered until the trust 
> domain is exited. Of course this makes little sense if the UA contacts 
> an independent PS directly, but in that case "id" also makes little 
> sense.
 Right. I was thinking of this but I was wanting to avoid any kind of 
micro-management of the priv-values but this may be the simplest solution.
> target of a call. This should perhaps bedeclared out of scope in general.
 Agree.

 Regards
  Shida