Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Apr 2002 08:19:58 -0400

But (3) is achievable now with a B2BUA, and there is no standardization 
work necessary.  Jonathan correctly pointed out that it is non-trivial
to achieve what appears to be desired, and a B2BUA that thoroughly
scrubbed all fields, including relaying of media, will be needed.
No additional headers can help you.

I think we should stop worrying about this case, and try to focus on
something we can't reasonably do now, which is to provide a network
asserted identity when the UA itself provides anonymity.  That is a
case worth working on, and it represents the way I think it SHOULD work.
The UA is by far in the best position to determine the level of
anonymity it wishes, and if it can't get enough (because, for example,
it wants it's IP addresses obscured), it will have to employ a
B2BUA as above.  

Brian

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, April 11, 2002 11:29 AM
To: 'Jonathan Rosenberg'
Cc: [email-masked]; Ben Campbell; Flemming Andreasen; Peterson, Jon; 'William
Marshall'
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Just on this one issue of obfuscation of the From/To field.... 
Let's be really clear about why this has come about: 
Some Service Providers *believe* in the following proposition: 
(*) IF the UA is allowed to put identity information into From/To, THEN the
Service Provider will be forced (by Data Protection) to provide services
which modify these fields, in order to protect the privacy of people other
than the actual calling user - subscriber, forwarding etc.
First, set aside the question of whether to agree with (*) or not. 
There are three options for people with this belief: 
1) *Require* permanantly that the UA does not put identity information into
From/To 
2) Reject requests where the UA puts identity information in From/To if
privacy is required 
3) Build network services which provide the necessary modification
(+whatever else is needed) 
I do not think there are any other options. 
We all agree that (1) is bad. (2) looks attractive but is not backwards
compatible, requires a double request (not good for wireless) & has issues
as to whether you trust the UA (in redirection scenarios).
I was looking for a consensus that (3) is a possible and valid thing to do
for these Service Providers. If the IETF SIP group agree that (3) and not
(1) is _a_ valid solution to this problem, then there is more chance of
other fora adopting (3) instead of (1).
So far, people have been arguing against the belief (*). The question is not
whether (*) is demonstrably true but whether there is sufficient *chance* of
it being true to justify serious consideration. A significant group of
Service Providers obviously think it is - they are worried they will be in
this situation and want a solution defined - that should be enough for us to
discuss solutions.
So, can we agree to recommend at least that people with belief (*) adopt
solution (3) and not solution (1) ? 
...Mark 

> -----Original Message----- 
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 11 April 2002 08:28 
> To: Watson, Mark [MDN05:EP10:EXCH] 
> Cc: [email-masked]; Ben Campbell; Flemming Andreasen; Peterson, Jon; 
> 'William Marshall' 
> Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft 
> 
> 
> 
> 
> Mark Watson wrote: 
> > 
> > All, 
> > 
> > I feel profoundly lucky that yesterday and Friday were 
> public holidays 
> > in the UK :-) 
> > 
> > Perhaps I can take advantage of this vantage point to offer 
> a summary of 
> > the thread. Protagonists please speak up if I have 
> mis-represented you 
> > below, but please don't re-open old fronts. 
> 
> Thanks for the summary. It is well needed. I suspect much of 
> the lack of 
> comment derives from the difficulty in following this long thread. 
> 
> I would kindly request all participants to please keep the discussions 
> technical. A lot of the emails in this thread were personal attacks. 
> Many more were threats along the general line of "do X or 
> standards body 
> Y will do Z". I really hate the latter ones. Let us hear no more of 
> either type of nonsense. It is not the IETF way. 
> 
> > 
> > 1) Call-Info 
> > 
> > Long arguments about the alledged similarities/differences between 
> > Call-Info and RPID. Suffice to say that the point has been made that 
> > Call-Info (and perhaps other things) could be abused to do 
> the things 
> > that RPID does, and in particular to do the 'Bad Things' 
> that some are 
> > worried about with RPID. The point of disagreement was 
> whether in the 
> > case of Call-Info, this would be 'major abuse', with RPID 
> was set up to 
> > make these 'Bad Things' easy, or whether there was some equivalence. 
> > 
> > The key point is that this kind of abuse of Call-Info may 
> happen if we 
> > do not provide an alternative. 
> 
> It was never our intent for Call-Info to provide any form of network 
> asserted identity that could be used in any useful way. Generally, the 
> idea was that insertion of Call-Info was either done by the UA, or in 
> the case of proxy-inserted values, was for "opt-in" services were the 
> user had signed up for content to be added. That said, there are 
> certainly cases where the caller may opt in for this service 
> but require 
> privacy for a particular call, and we need a mechanism to 
> support that. 
> 
> However, in no way would I support or advocate the use of Call-Info as 
> an alternative for R-P-ID. 
> 
> > 
> > 2) Abuse of From/To headers 
> > 
> > Jon is concerned that 'untrusted RPID' provides a standardised 
> > alternative to From/To, allowing Bad Things, like never 
> putting the real 
> > From/To information in the From/To fields. 
> 
> I think that the proper way to handle this, as pursued in 
> other threads, 
> is to provide a sane alternative to 3gpp so that they don't do this. I 
> believe we all agreed it would be bad. 
> 
> > 
> > Others have pointed out that the draft explicitly states 
> that untrusted 
> > UAs MUST NOT add RPID. However the draft explicitly described proxy 
> > handling of RPID headers from untrusted sources (proxies OR 
> UAs), and 
> > allows these to be propogated, marked as untrusted. 
> > 
> > Therefore, a UA which DID add RPID, although non-compliant 
> to the draft, 
> > would have its RPID propogated through the network. 
> > 
> > 3) 'Untrustworthy RPID' 
> > 
> > Flemming, Bill et al argued that RPID information is still 
> useful when 
> > it is 'untrustworthy'. This can occur legitimately within 
> the draft when 
> > an RPID which is not 'private' (and so not encrypted) 
> crosses a trust 
> > boundary. This would represent an identity asserted by Network A and 
> > passed to Network B, when B has no explicit trust 
> relationship with A. 
> > 
> > The contention was that since this information still has 
> some value, it 
> > should be passed to the UAS for display, and might also have some 
> > application for call trace, although obviously not as useful as a 
> > 'trustworthy' identity. 
> > 
> > Jon argued that the From field provides well enough for 
> display, and the 
> > value of untrustworthy information for call trace is 
> debatable (and has 
> > been debated at length). 
> 
> IMHO, 'untrusted RPID' is identical to the From, except that it is 
> purportedly inserted by a network element, whereas From is purportedly 
> inserted by the end user. Neither provides any guarantees. The essence 
> of the debate, I think, is whether you believe there is value 
> to the end 
> user in a field which is the identity purportedly inserted by some 
> network element.  Since there is apparently value to the identity 
> purportedly inserted by the end user, I see no reason why we should 
> discriminate. 
> 
> -Jonathan R. 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue 
> Chief Scientist                         First Floor 
> dynamicsoft                             East Hanover, NJ 07936 
> [email-masked]                 FAX: (973) 952-5050 
> http://www.jdrosen.net                  PH:  (973) 952-5000 
> http://www.dynamicsoft.com 
> 

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Apr 2002 09:00:38 -0400

> it wants it's IP addresses obscured), it will have to employ a

I agree that, in general, the UA should be treated like a mature adult
and get to make decisions as to what information it wants to include in
its call setup requests or not. I don't agree that anonymity requires a
B2BUA in all cases. For example, one could imagine that a large ISP
could hand out random IP addresses from a large pool, making it
essentially similar to an anonymizer service. There is no principal
difference between knowing that "user came from anonymizer service
anon.com" and "user came from ISP large-isp.com". (Well, almost: it may
be easier to switch anonymity providers than ISPs.) With VPN services
and L2 tunneling, you can probably create IP-level anonymous ISPs that
don't require B2B UAs and cover a very large geographical area.

A privacy B2BUA would break services, since it would have to strip all
headers, thus disabling any service that it doesn't happen to know
about.

B2BUAs are also, it seems, much more loop-prone than proxies. For
examples, see mailing list hosts, which are essentially SMTP B2BUAs.
(They also illustrate the service transparency issues, with endless
debates as to what fields should have which values and whether header
fields should or should not be copied.)

---

From: Michael Thomas <[email-masked]>
Date: Fri, 12 Apr 2002 12:24:59 -0700 (PDT)

Henning Schulzrinne writes:
 > essentially similar to an anonymizer service. 
  
   BTW, IPv6 already allows for private (read: formed
   dynamically and randomly by the host) IP addresses.
   The ISP doesn't even need to "allow" it or provide
   for it.

 > There is no principal
 > be easier to switch anonymity providers than ISPs.)

   This all gets down to your paranoia level. Prefixes
   do tell you something about IP topology which could
   lead to educated guesses -- which may be all that's
   necessary. Hopefully this level of paranoia will only
   be needed in the direst of cases like mob snitches, etc.

	     Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Apr 2002 16:01:51 -0400

[Trimming privacy-threatening cc lines, revealing list membership :-)]

I think part of the problem is, as I think Dean and Brian have alluded
to, is that many things that used to be tied together in one mechanism
in the PSTN are now split across several different ones:

- From display name
- From URL
- RPID
- user authentication name (Authorization)
- Organization
- Call-Info

Also, to pick up the "disable CLID and disallow anonymous calls": I
think part of this has to do with the commingling of identity and the
ability to call back. I suspect that even the Hollywood mogul wouldn't
mind if his name appeared on the starlets display screen, but wants to
maintain the "don't call us, we'll call you" attitude, i.e., avoid
revealing a callable number.

I don't think anticipating regulation is particularly helpful here.
Anybody can say anything about what some legislature somewhere may
legislate at some point in the future.

I wouldn't be too surprised if, instead of PSTN legislation, some of the
email spam legislation finds its way into SIP behavior, e.g., having to
declare a truthful return address, an indication of the call intent
(like some of the laws and bills calling for adding ADV to the subject
line) or including an opt-out link (header?). If we could make progress
there, I think we'd do more for "privacy" than hiding a user name.

Henning