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

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 1 Apr 2002 08:53:26 -0500

You raise a reasonable point on how a malicious call trace would be
triggered.  In the PSTN, one dials a service code and the network does the
rest.  "The rest" consists of a printout of the call trace on a teletype in
a telco office, or the more modern equivalent -- the called party gets no
access to its contents.  Thinking in SIP terms, the called party would
presumably also do an INVITE to a service code and include the encrypted
token which encapsulates the necessary trace information.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, April 01, 2002 7:59 AM
To: 'William Marshall'
Cc: [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft

[snip]

So, then, you mean that I'm supposed to send an INVITE to the hostname and
port identified in the encrypted URI when I want that URI translated? I had
gotten the impression from the text that I could use the hostname and port
to query for a translation of the encrypted URI to its original form. I
guess I got that impression from the line in 6.1:

   ... whereas the "hostport" 
   identifies the entity that can decrypt the information

But now I can see how this admits of either reading. However, I'm a little
confused about how this is then supplying a valuable privacy service. When I
request privacy for a call, I don't exactly expect that the person I'm
calling will be able to call me back. But 7.2 suggests that encrypting the
URI in this way makes it suitable for transmission to untrusted entities. Is
this the desired behavior? Or does the server decrypting the URI make some
further decision to disallow certain requests to that URI? If so, this
should at least be mentioned.

As a means of malicious call trace (which I assume is the motivating
requirement) this also seem a little counterintuitive, especially if, as the
tracing network, I don't intend to start a session with the entity
identified by the URI. Is there some other request (maybe part of the
'certain call control functions') you mention above that I can send that
will just result in the decrypting of the URI? Or should the tracing network
requests a translation out-of-band somehow?

I must also point out that the other concerns I raised in my previous mail
are quite material to whether or not this is encryption mechanism is
genuinely implementable. There really are a lot of points that would need to
be resolved.

> > 		....  whereas the Call-Info means "this is
> > unimportant information that the end user should display if they can,
> > otherwise, don't worry about it."
> 
> My old rotary phone does exactly this with the Caller-ID 
> info.  Perhaps I need to upgrade my UA.

When I read things like this I'm really not sure if you're being serious.
Are you honestly suggesting that it doesn't matter whether or not the
network-verified identity for a request is presented to the UAS and end
user? That it doesn't matter if trusted network elements communicate such
identities to untrusted elements? I'd like to think it is clear from my
wording above that Call-Info is 'optional' in the sense that users can
display it if they like, whereas RPID has strict rules concerning whether or
not a UA is eligible to receive the network-verified identity - this is
unrelated to whether or not the UA can display it. Hence the distinction I
attempted to draw between selectively rendering the content (RPID) and
rendering optional content (Call-Info). There are restrictions on where RPID
is passed that do not currently exist for Call-Info.

> Bill Marshall
> [email-masked]

_______________________________________________
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

_______________________________________________
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: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Apr 2002 08:55:57 -0500

> > Just because your network cannot verify the authenticity of the
> > information does not mean the information is useless. With the present
> > semantics, some people (I'm one of them) still find it useful from a pure
> > caller-id service perspective to have a clear-text caller-id being
> presented
> > although it was untrusted as opposed to having nothing at all, as long as
> I know
> > it's untrusted.
>
> This is the issue that I was trying to zoom in on. Who generates that
> caller-id that will be displayed to the UAS in your Iraqi case? The UAC?

No - the Iraqi network.

> My
> point is that the From header already provides a clear-text caller-id that
> was generated by the originating user but not necessarily verified by any
> intermediary, right? With or without sip-privacy-04, the From header already
> provides an (untrusted) means for an end-user to assert an identity that
> could be displayed by the destination endpoint, which the destination
> endpoint does not know to be verified by the network. So what does untrusted
> RPID add to this?

It allows for a network-asserted identity provided by network A to be delivered
via network B, even though network B does not trust A.

>
> > The longer term problem with your statement is that it assumes
> > that the "screen" mechanism is the only authenticity mechanism forever. As
> I
> > have stated many times, we expect a generic security solution that can
> > authenticate various headers in the future. Once we get that, you can now
> have a
> > Remote-Party-Id signed, sealed and delivered from an "untrusted" network
> and
> > actually still be able to verify it even though your network provider
> can't
> > vouch for it. Pretty useful - no ?
> >
>
> Since I am (at the moment) only arguing for the removal of 'screen', I have
> a hard time seeing how I would have a problem with assuming that 'screen'
> goes away. Moreover I've argued that we can dispense with the 'screen'
> mechanism without solving the more difficult problem of signing RPIDs.

Yes you have, and you have also said that we must remove any untrusted
Remote-Party-Ids. Well, if there in the future is a signature covering the
Remote-Party-Id (among other things), the end-user can now actually see who is
vouching for the Remote-Party-Id, regardless of whether any intermediary proxies
trust the previous hop and/or verifies the signature. This makes the
Remote-Party-Id more generally usable in the future as well, which seems to be
something you want to prevent.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Apr 2002 09:03:42 -0500

Henning Schulzrinne wrote:

> I think we should be careful of trying to over-engineer what's primarily
> a social or legal problem.
>

I agree completely.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Apr 2002 09:25:56 -0500

"Peterson, Jon" wrote:

> Specifically, I am concerned with RPID usage as a replacement for the To and
> >From headers, in architectures which have proposed that To and From should
> always contain random/anonymous information for all calls (not just when
> privacy is needed) and RPID alone should be used to assert originating and
> destination identities. I feel that these architectures pose tangible
> threats to interoperability.

Well the draft doesn't say this (except for From in the anonymous case which I
have already agreed to change to "anonymous@localhost" instead), so this is
completely bogus.

> Were the SIP WG to pass sip-privacy-04
> as it stands it would be unnecessarily open to these sorts of abuses (though
> I would be the first to note that it is better than -03, which had no
> applicability statement and did not require IANA registration for
> extensions). If the remaining loopholes were closed, I would go back to
> ignoring sip-privacy-* as I have in the past; it certainly was not until I
> heard about the RPID To/From replacement architectures that I became, as I
> am now, interested is seeing changes to the draft.

Well, this is big part of the problem. The draft has been in the works for three
years and there has been plenty of opportunity for you to participate and shape
the draft. What is in the privacy-04 draft is the result of the discussions and
consensus that have formed among the active participants in this process.
However, as you admit, you have not been interested in contributing to this
draft but instead chose to ignore it until the very last minute, where you then
show up with a laundry list of items you want changed, and in most cases not
because there is anything technically wrong, but simply because you personally
disagree with them and fear that some people may use them in ways you do not
like. You claim to not be interested in killing the privacy draft, but your
timing could hardly have been more obstructive. I will furthermore also note,
that you have not managed to produce a lot of support for your positions. I
think this goes a long way towards deciding what to do with some of your
comments.

> If you would like to see
> the changes I suggested, they are available in the ML archives here:
>
> http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04258.html
>

To which I responded, but you didn't follow up (in fact I will note that WG Last
Call for this draft ended before you decided to revive just one of your
objections).

>
> This is not to say that all SIP headers must be overspecified to prevent
> such abuses. Again, this happened to come up for RPID and not for anything

> else, and the squeaky wheel gets the grease.

Can it get any more hypocritical than this ? It's OK for a bunch of headers to
be underspecified and open to abuse, but it's not OK for Remote-Party-Id to be
open to abuse, even though there are explicit statements in there saying what it
is *not* intended for and furthermore extensibility is under the control of
designated expert review (all of which were added in an attempt to accommodaty
you and address your concerns, but it is still not good enough for you). I'm
becoming less and less convinced that you are interested in anything but killing
this draft.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 2 Apr 2002 15:04:24 +0100

Christian wrote:
> 
> > The reference to "Public telephony server" above is very misplaced.
> 3GPP &
> > DCS SIP networks are not telephony networks. We need less of this 
> > invective and more focus on the real problems.
> 
> The reference was not an invective, but rather an acknowledgement of
> legal implications of providing a "public service". The 
> requirements to
> be able to provide call tracing applies to public services, and result
> in a requirement to have something like the remote party ID. 

Apologies - the term 'public telephony' often has rather loaded meaning
round here and I mis-interpreted your comment. If you mean 'public service
provider' then I understand the distinction your are making.

> It is quite
> unclear that such a requirement applies to a private service, e.g.
> direct calls over the Internet between two corporations. 

What makes you think this ? At present a user receiving malicious calls at
work (from the PSTN) can ask for these to be traced. Why should they lose
this ability if their employer switches to a SIP-based telecommunications
service using the Internet ? (as well as getting worse QoS :-)

I think if it became widespread that corporations used Internet-based
telecommunications which did not support malicious call trace, then
regulators, not to say consumer groups and groups representing employees
might become concerned.

I would think we could make the SIP-based service at least as good as the
PSTN in this regard.

The 'trusted third party' in the form of the public service provider
performs a valuable service in mediating between the legitimate desire or
the caller to remain anonymous, and the equally legitimate desire for called
parties to be protected from malicious calls. A third party of some kind is
required to guard the privacy of the caller, whilst ensuring the tracebility
of the call.

Now there is no reason why this 'third party' needs to be a public service
provider. The same 'third party' function could be provided by proxies owned
by the corporations between which calls are being made.

We should be clear that if users choose to receive calls directly, without
such a 'trusted third party', then they will not receive the protection from
malicious calls that they are used to on the PSTN. It may be fine for
individual users to make this choice, but it is not something that anyone
providing service to many users (be that a commercial service, or an
employer providing telecommunications to their employees) could choose to
do.

So, we need mechanisms to enable this in as many scenarios as possible.

...Mark

OTOH, the
> existence of technologies such as remote-party ID have to be 
> taken into
> account when devising a privacy solution: we must assume that whatever
> information is given to the network will be disclosed.
> 
> -- Christian Huitema 
>

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 2 Apr 2002 15:06:26 +0100

Jon Peterson wrote:
> 
> 
> A few more things about this Call-Info business.
<snip> 
> Call-Info
> clearly exists for a purpose unrelated to privacy/identity management,
> although I concede that its intended use may have its own privacy
> implications. But do your concerns about the legality of publically
> available services extend to instant messaging, Internet 
> gaming, and the
> like?

My concerns would extend to any service which inserted the real identity of
the user on their behalf, and did not provide a way for the user to turn
this off on a session by session basis.

I think in most (if not all) services on the Internet today, any identities
inserted by the network are user provided names which may or may not be
related to the users real identity.

Also, in practice, if a service always inserts the users real identity, this
is not mitigated by arguments along the lines of 'The header's semantics
mean that you should not always trust this identity' - the user may still
feel their privacy is compromised if their identity is given out without
their control, even if the header it is sent in is somehow marked as
'unreliable'.

So, if you wanted to build a service where an outbound home proxy inserted,
say, the user's photo for them, I think you would need a mechanism for the
user to prevent this happening on a per-session basis before the service
would be acceptable to the users, never mind the regulators. I guess you
could give the user a separate (virtual) outbound home proxy which did not
do this.

Anyway, your other comments suggested you did not see the need to proxies to
insert Call-Info at all, and if this were the case the problem goes away.

...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 2 Apr 2002 18:42:57 +0100

Flemming wrote:

> > Jon wrote:
> > > ... I say, "But it isn't 'untrusted' anymore if it has a
> > > signature; the
> > > concept of being intrinsically 'untrusted' is no longer
> > > meaningful." The end
> > > result is the same - we agree that if an RPID is signed, it
> > > shouldn't be
> > > removed.
> > >
> >
> > I think if I sign an RPID with a signature that noone 
> recognises, then
> > this is semantically equivalent to 'screen=no'.
> >
> 
> Good point (self-signed certificates come to mind as well). However,
> let's not turn this into a crypto-discussion. We already have 
> consensus
> that this is not a requirement for the privacy draft.

Actually, I thought I was just restating a point you made in an earlier
mail: If we're fine with proxies passing on signed RPIDs where they don't
recognise the signature, we should also be fine with proxies passing on
untrustworthy RPIDs i.e. those with 'screen=no', because the two are
equivalent.

The important point, then, is what we expect *UAs* to do with such things.
Jon's contention was, I think, that (effectively) that UAs should discard
them. Your contention was that the (human) user should decide what meaning
if any to attach to the information. If we're being consistent we should
have the same answer for 'screen=no' RPIDs as we have for signed RPIDs where
we don't recognise the signature.

...Mark

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Apr 2002 11:17:46 +0100

I am less than interested in the screen parameter. It has never, even in the
PSTN, managed to convey information in the absence of the special
arrangement.

However I do want to see RPID (or identity in some form) from untrusted UAs.
Rather than the trusted entity performing verification in this case, I see
the functionality of this as allowing the real trusted entity to select from
a number of valid identities that it might otherwise insert. The fact that
it the identity inserted may appear identical to the received value does not
mean that it has been passed on transparently. All we need to do is clearly
indicate that this guidance was provided by an untrusted entity.

The PSTN case of the special arrangement has to be considered as a trusted
entity sending the information in the first place, and therefore is outside
the scope of this discussion, and therefore we do not need a screen
parameter in the way that this discussion is interpreting it.

Keith 

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]  

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: 01 April 2002 15:47
To: Peterson, Jon
Cc: 'William Marshall'; [email-masked]
Subject: Re: [Sip] Comment, SIP Privacy draft

"Peterson, Jon" wrote:

>
> Until sip-privacy removes the 'screen=' parameter, sip-privacy still has
> sunny-day handling for the insertion of RPID headers by untrusted UAs. I'm
> not suggesting that we add text saying that untrusted UAs MUST NOT add the
> RPID. I'm suggesting that the concept of an 'untrusted' RPID be expunged
(by
> removing the 'screen' concept and the associated protocol apparatus), and
> that proxies MUST remove RPIDs they receive from untrusted sources. I
think
> would be much more effective.

You are concerned about somebody doing something the draft does not define,
and
in fact explicitly states it is not intended for. You have not provided any
technical problems with this, but are only concerned with the potential for
misuse. There is no point in either of us continuing to repeat the same
arguments on this point. If somebody else feels strongly about this point
and
has something technical to offer, they should speak up.

> calling will be able to call me back.

Bill already explained how malicious call trace works - you will not be able
to
call that party back.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: [email-masked]
Date: Thu, 4 Apr 2002 10:12:51 EST

In a message dated 4/2/02 9:06:58 AM Eastern Standard Time, 
[email-masked] writes:

> the caller to remain anonymous, and the equally legitimate desire for 
> called parties to be protected from malicious calls. A third party of some 
> kind is required to guard the privacy of the caller, whilst ensuring the 
> tracebility of the call.
> provider. The same 'third party' function could be provided by proxies 
> owned by the corporations between which calls are being made.
> such a 'trusted third party', then they will not receive the protection 
> from malicious calls that they are used to on the PSTN. It may be fine for 

Mark,

I like your synopsis above of the situation. Likewise, you could add, if 
users choose to originate their calls without such a "trusted third party", 
then they will not receive the protection from having their identity passed 
to some unknown user that they are used to on the PSTN.

There needs to be an understanding that we are addressing two different 
architectures in these discussions:

1. With a trusted third party (Read: service provider) who guarantees 
privacy/protection/etc. (usually because the law says they must)
2. Without a trusted third party (Read: Wild-wild west) in which no one using 
it is guaranteed of anything.

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Thu, 4 Apr 2002 17:33:12 +0100

...bit quiet today ... 

Mike Pierce wrote:
 
> Likewise, you could add, if users choose to originate their calls without
such a "trusted third 
> party", then they will not receive the   protection from having their
identity passed to some 
> unknown user that they are used to on the PSTN. 

If there's no "third party" then the user does not need to include any
identity information in the message at all. The end-to-end model tips the
balance completely to the side of the caller & their desire to remain
anonymous (or in the absence of a PKI, to mis-represent themselves).

> There needs to be an understanding that we are addressing two different
architectures in these
> discussions: 
privacy/protection/etc. 
> (usually because the law says they must) 
> 2. Without a trusted third party (Read: Wild-wild west) in which no one
using it is guaranteed 
> of anything. 

Absolutely, and I think our generic privacy requirements draft will need to
start with a description of the models we are addressing and an analysis of
exactly *whose* privacy we are protecting in each model.

For example, the concept of 'subscriber' only exists in a 'service provider'
model.

I wonder whether the case of enterprise networks sending calls over the
Internet is a third model - its characteristics are slightly different.
There is no 'Service Provider' as such, but the enterprise(s) are 'providing
a service' to the users.

...Mark

---

From: William Marshall <[email-masked]>
Date: Thu, 4 Apr 2002 12:25:23 -0500 (EST)

Jon Peterson wrote:
> RPID. I'm suggesting that the concept of an 'untrusted' RPID be expunged (by
> that proxies MUST remove RPIDs they receive from untrusted sources. I think

The compelling case I still see for the screen parameter is due to the
extensibility of identity types.  If an RPID header arrives at a proxy
with an unknown identity type (only because that proxy has not yet
received its upgrade), it does not seem reasonable to strip it.
Otherwise, a new identity type can't be used until _every_ proxy
in the path has been updated.

Bill Marshall
[email-masked]

---

From: "Mark Watson"<[email-masked]>
Date: Thu, 4 Apr 2002 19:02:50 +0100

Bill makes a good point. Plus it's worryingly quiet today, so let's see if I
can summarise again...

There are actually two applications for 'screen=no' RPID which we have been
discussing:
1) RPID inserted by a UA, to give a 'hint' to the outbound proxy as to which
identity it would like to be known by
2) RPID inserted by a Proxy with 'screen=yes' which is later downgraded to
'screen=no' because it passes into another trust domain

(1) is required by 3GPP - well *a* solution is required, not necessarily
RPID. Some people have suggested using unsolicited Proxy-Authorization
instead, but as this function has nothing to do with authentication, I'm not
sure this is appropriate - does anyone disagree, or have another suggestion
?

(2) is a question of whether such 'screen=no' information has any value. We
had a long thread (the Iraqi thread) about whether this would be useful for
Call Trace, which I think foundered on the inability to distinguish between
a type (2) 'screen=no' RPID and a type (1) 'screen=no' RPID which has made
its way unchanged from a UAC which is trying to mis-represent itself.

So the remaining question is whether type (2) 'screen=no' RPID is worth
displaying to the user (with appropriate health warnings) - I can't see how
it's any less valuable than the From: field, and everyone wants to display
that.

I do think that the discussion about (1) above, and the 3GPP requirement, is
really quite a distinct issue from the 'Bad Things' that are presently in
the 3GPP specifications, namely the obfuscation of the To/From fields. This
is much more related to our other thread on how to provide privacy services
and the requirement to modify To/From to provide certain privacy services.

I think that if we were agreed that modification of To/From *is* required in
order to provide (certain) privacy services (and the device that does this
thus needs to be More Than Just A Proxy), then there is no excuse for always
obfuscating To/From i.e. I don't think the 'Bad Things' and RPID are in fact
related as has been claimed.

Regards...Mark

> From: William Marshall [mailto:[email-masked]]
> Sent: 04 April 2002 18:25
> To: [email-masked]

---

From: William Marshall <[email-masked]>
Date: Thu, 4 Apr 2002 13:24:24 -0500 (EST)

> identity it would like to be known by

Regarding the issue of UA inserting RPID, versus the proxy inserting 
RPID, ---

There was a lengthy discussion around bis-WGLC about proxies
modifying the SDP (not allowed according to bis) and the fact that
firewall control proxies do.  The conclusion, IIRC, was that the
definition acording the spec would not always be consistent with
the marketing term for a product -- mainly due to the fact that
firewall control proxies did not want to be lumped in the same
category of "bad things" as B2BUAs.

I see the same thing likely here.  Whether the box that interfaces
to the user is a UA, or a "UA-with-integrated-proxy", it will certainly
be marketed as a UA.  If the market for the device requires that it 
do functions that are only allowed to be done by a proxy, it will
be done.  Perhaps the term will then be "B2BUA with Proxy".  The
point is, it shouldn't matter how the architectural elements are combined
and optimized to do the job.

Bill Marshall
[email-masked]

-----original message-----
From: "Mark Watson" <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft
Date: Thu, 4 Apr 2002 19:02:50 +0100 

Regards...Mark

---

From: [email-masked]
Date: Thu, 4 Apr 2002 15:52:18 EST

In a message dated 4/4/02 11:33:48 AM Eastern Standard Time, 
[email-masked] writes:

> (Mark answered): If there's no "third party" then the user does not need to 
> include any

But as has been noted before, the IP address itself may be enough to violate 
someone's privacy. And the end user can't leave that out. If that is to be 
hidden in certain cases, there needs to be another device in between. 
Likewise, if the calling party identity is not provided, in many networks the 
call will never be carried, due to the requirements at the terminating end.

> 
> (Mark said): For example, the concept of 'subscriber' only exists in a 
> 'service provider'
> model.

And I would argue that, without a "subscriber" or a "service provider", there 
is no concept of a service being provided. And most of what we're talking 
around are "services". So that is a real quandry. I would suggest that we 
further expand on the two situations I listed as follows:

1. With a trusted third party (Read: service provider) which provides 
services, one of those services being to guarantee privacy/protection/etc.
2. Without a trusted third party (Read: Wild-wild west) meaning that there 
are no services being provided. End users do anything they want and no one is 
guaranteed of anything (e.g., privacy, protection, or that anything they try 
to do will neccesarily function as they expect).

Maybe all discussions need to be split between these two cases, since they 
are so much different.

> 
> (Mark asked): I wonder whether the case of enterprise networks sending 
> calls over the

Yes, I would consider the enterprise network as the "service provider" even 
if distinct parts of it are interconnected by some other IP network. This 
includes two cooperating and trusting enterprise networks. 
Privacy/authentication/encryption/etc. between various parts of the 
enterprise network(s) are the responsibility of that network(s). The user 
doesn't need to deal with these issues. It only needs to worry about between 
itself and its "trusted third party" that is providing service.

Mike (again)

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 5 Apr 2002 10:32:46 -0800

> anonymous (or in the absence of a PKI, to mis-represent themselves).

Not really. The e2e model cuts both ways: the called party may decide to
refuse calls that do not carry some form of identification, or at least
some form of authorization. The real privacy issue is to devise a
structure in which the caller discloses enough to convince the called
party to pick up the call, but not so much as to compromise privacy. In
SIP, the caller has also to convince potential relays to forward the
call, and the same privacy issue arises: disclose enough to convince the
intermediate party to carry the call, but not so much as to compromise
privacy.

There is a big difference between private services and public services
subject to regulation. In the latter case, third parties mandate some
level of disclosure to the network, e.g. for law enforcement purposes. A
private service may be content to forward a call using for example a
role identifier instead of a user identifier; a public service may be
requested to actually identify the user, i.e. to request more
information than the caller is willing to disclose to the called party.
This is what drives us into a band-aid architecture, in which
information is supposedly first disclosed and then at a latter stage
withdrawn.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 5 Apr 2002 10:41:40 -0800

> But as has been noted before, the IP address itself may be enough to 
> violate someone's privacy. And the end user can't leave that out. If
that 
> is to be hidden in certain cases, there needs to be another device in 
> between. Likewise, if the calling party identity is not provided, in
many 
> networks the call will never be carried, due to the requirements at
the 
> terminating end. 

Actually, you can use the IPv6 "privacy address" for that purpose. For
example, you could build up an address that is only used for one
specific call.

-- Christian Huitema