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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 02:02:51 -0600

A note on the paragraph below.

First, I don't think that the applicability statement in sip-privacy is
intended to be an exhaustive list of requirements for the mechanism - quite
the opposite, it's a set of restrictions on the use of the mechanism. The
need for these restrictions arose from the (concrete) ways in which the
mechanism was being applied.

I don't actually believe that call trace, as I understand it, requires RPID
or any comparable apparatus in SIP signaling. No new protocol mechanism is
required for a proxy server to record the results of an authentication
(indexed perhaps by Call-ID) so that administrative requests for the
identity of the originator of a call can be satisfied. I think RPID actually
attempts something a little more ambitious; sharing this identity
information in a putatively secure fashion within a community of 'trusted'
servers, so that this private identity information is immediately available
to any 'trusted' element that inspects the signaling, although it is still
concealed from end users. How the applicability statement hinders even this
goal, though, is unclear to me. All that the applicability statement
restricts is the insertion or receipt of RPID by untrusted elements. Surely
this is unrelated to call trace? In short, I doubt that the AS has made call
trace an impossible goal for the RPID header.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 5:49 AM
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] Comment, SIP Privacy draft
> 
[snip]
> 
> If the AS is trying to be a complete listing of requirements then it is
> clearly deficient. Moreover, if this is indeed the intention with an
> applicability statement, then it is very concerning, that we have this
> applicability statement being forced into the document by our "spirit
> guides" at the last minute without any discussion about the actual
> requirements. As I mentioned before, call trace completely  fell through
the
> cracks here essentially rendering the draft useless for what it was
supposed
> to do. As this discussion shows, there is disagreement on other points as
> well.
> 
> 
[snip]
> 
> 
> -- Flemming
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 
> _______________________________________________
> 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: Fri, 29 Mar 2002 08:08:27 -0500

"Peterson, Jon" wrote:

> the opposite, it's a set of restrictions on the use of the mechanism.

Our AD doesn't seem to agree with this.

> The
> identity of the originator of a call can be satisfied.

The philosophy behind all the DCS extensions and hence the privacy draft was to
get state out of the network and into the endpoints. The way it's done in this
case is by encrypting a private Remote-Party-Id before passing it to an
untrusted entity. However, it is true that there are, as always, many different
ways of solving a given problem, and if you are content with recording state in
the network, then you are of course correct. But, I have a very big problem with
having an applicability statement thrown in at the last minute that all of a
sudden starts changing my design philosophy and goals and hence requires me to
change the mechanism.

> I think RPID actually
> concealed from end users.

The problem occurs when you want to forward the message to an untrusted entity,
whether an end user or something else (e.g. another provider).

> How the applicability statement hinders even this

See above.

-- Flemming

--
Flemming Andreasen
Cisco Systems