Subject: AW: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva cy draft)

From: "Jesske, R" <[email-masked]>
Date: Wed, 10 Apr 2002 10:38:33 +0200

Dear Chris and Mark,

regarding your discussion on privacy the privacy draft I have some comments:

1. From the Service Provider Point of view the mechanisms described within the privacy draft are needed. It is important to have a statement from the caller if he wants to hide his identity by the callee. There are many call scenarios where I would like to see this kind of privacy including the case of the interworking with a PSTN network, because there it is needed to have the clear statement if the call needs privacy or not.

2. For regulation, billing and other purposes the service provider needs an indication if the address included in the Invite is trusted or untrusted (screen = Yes/No). I know Chris does not like overregulated networks, but I think we need this within the SIP domain and in the PSTN interwoking case. 

3. I don't know if a "privacy proxy" will solve all problems concerning privacy and trusted addresses/entities. I support the proposal of the privacy draft concerning the trust relations and the additional headers.

Of course the interworking with PSTN networks is not the only application (and of course not the most important) of the privacy draft. But for the Service Provider, which will have hybrid networks (e.g. SIP and PSTN), the privacy draft gives the tool to solve many problems at the network boundary.

Best Regards

Roland Jesske

Deutsche Telekom AG
Zentralbereich Netzinfrastruktur (ZB NI)
Section NI196; Signalling, Gateways and Switching Systems
Roland Jesske, NI196a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940
Fax:    +49 6151 83-4577
mailto: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: Chris Martin [ mailto:[email-masked] <mailto:[email-masked]> ]
> Gesendet am: Dienstag, 9. April 2002 00:13
> An: Mark Watson
> Cc: [email-masked]
> Betreff: Re: Private Info in To/From (was RE: FW: [Sip] Comment, SIP
> Privacy draft)
>
> > Mark Watson wrote:
> >
> > Chris,
> >
> > Regarding whether these privacy features can be provided by a proxy,
> > modification of the From/To fields cannot be done by a
> proxy according
> > to the current specification. You require a device which is more
> > clever than a proxy, as it has to maintain the link between the
> > From/To values of the incoming dialog and those of the outgoing
> > dialog, performing modification in both directions.
> >
> > Otherwise it will not work with an RFC2543 client, which matches
> > dialogs based on the whole From/To values. If you don't care about
> > RFC2543 clients, then it would work, but you would still not be a
> > proxy according to the RFC.
>
> It will be acting totally in acordance with the RFC except
> for the fact
> that it must modify the outbound packets and then maintain
> the original
> data in order to convert the responses/requests back to the original
> headers that the internal SIP UA will recognize as having sent.
>
>
> >
> > I am not foolish enough to mention the name for such devices, but I
> > expect you can guess :-)
> >
> > Regarding the To field, if A calls B and B forwards to C, then B has
> > the right to ask their Service Provider for the forwarding to be
> > carried out 'anonymously'. As well as precluding forwarding based on
> > redirection, this would imply modification of the To field, in which
> > B's identity is carried (amongst other things).
>
>
> That is an interesting scenario, I'll need to digest this one.
>
> I believe that we are seeking the same outcome here, so what
> can be done
> to make it spec, do we really need additional headers, or do we rename
> the "deveices" :^) .....create a privacy proxy....to go along with the
> others   :^)
>
> Thanks,
> Chris
>
> >
> > Regards,
> >
> > Mark
> >
> > > -----Original Message-----
> > > From: Chris Martin [ mailto:[email-masked] <mailto:[email-masked]> ]
> > > Sent: 08 April 2002 13:58
> > > To: Watson, Mark [MDN05:EP10:EXCH]
> > > Cc: [email-masked]
> > > Subject: Re: Private Info in To/From (was RE: FW: [Sip]
> Comment, SIP
> >
> > > Privacy draft)
> > >
> > >
> > > Mark,
> > > Commments inline
> > >
> > > > Mark Watson wrote:
> > > >
> > > > Chris,
> > > >
> > > > I am arguing that exactly the type of service you describe
> > > below will
> > > > be required to be implemented by providers of public
> SIP services
> > in
> > > > order to meet Data Protection requirements.
> > >
> > > The features of topology hiding, could be implemented on
> a separate
> > > element to provide for the protection of the IP addresses
> within the
> >
> > > SDP, etc., but I think that it still doesn't require any
> additional
> > > headers to provide this functionality.
> > >
> > > >
> > > > In particular, the values in the To/From fields will need to be
> > > > modified.
> > >
> > > I agree with you in respect to confidentiality and topolgy hiding
> > (IP
> > > modification) of the internal calling domain, but also
> > > believe that the
> > > privacy aspect can be performed on the SIP proxy for the From
> > > Headers. I
> > > also believe that the To headers, in relation to outbound calls
> > > originating from the calling domain of the caller, when
> they relate
> > to
> > > the called party, outside of the calling domain, doesn't
> > > really require
> > > modification, in my mind as long as the From has been modified to
> > > specify that the caller is calling from a private number.
> > >
> > > >
> > > > Others are arguing that the transport of the To/From fields
> > without
> > > > modification is a transparent service of SIP, and that the
> > > contents of
> > > > these fields are entirely the responsibility of the calling UA
> > i.e.
> > > > the Service Provider has no responsibility for the
> information in
> > > > these fields.
> > >
> > > Ya, and this is where I totally agree with you, in that it must be
> > > addressed at this level by the SIP service provider.
> > >
> > > The reason for this is that this is where the provisioning is
> > > performed
> > > for customers of SIP carriers.
> > >
> > > Individuals can place anything they want in the >From field merely
> > by
> > > configuring the SIP UA to do so. But in the case of a carrier
> > > much more
> > > control and policy is required.
> > >
> > > >
> > > > One important point about the service you describe below is that
> > it
> > > > cannot be implemented on a proxy. Something more that a proxy is
> > > > required.
> > >
> > > See my first comment on this one.
> > >
> > > I have been working with many firewall vendors to assist them in
> > their
> > > development of both SIP enabled Firewall ALG's (SFA) and
> SIP enabled
> >
> > > Firewall Proxies (SFP)(These are basically outbound proxies).
> > > There are
> > > several vendors now, which I will leave unnamed, that now support
> > SIP
> > > and other vendors still on the way, I will let them jump
> in and name
> >
> > > themselves if they so desire.  These vendors may very well provide
> > the
> > > functionality for the capabilities that you are looking for,
> > > in the very
> > > near future. They have proven to do this job very nicely so
> > > far, and in
> > > some instance provide additional security features that
> will also be
> >
> > > very beneficial in the SIP environment.
> > >
> > >
> > > Thanks,
> > > Chris
> > > >
> > > > Regards...Mark
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Martin [ mailto:[email-masked] <mailto:[email-masked]> ]
> > > > > Sent: 06 April 2002 17:57
> > > > > Cc: [email-masked]
> > > > > Subject: Re: Private Info in To/From (was RE: FW: [Sip]
> > > Comment, SIP
> > > >
> > > > > Privacy draft)
> > > > >
> > > > >
> > > > > I have a few questions here regarding what it means and what
> > > > > it is that
> > > > > is desired of privacy in the relation to SIP.
> > > > >
> > > > > Are we asking to mask the identity of the calling party or
> > provide
> > > > > confidentiality or both? I am going to stick with what
> > > > > appears to be the
> > > > > focus so far in mind, as I read the list, which is
> > > masking the true
> > > > > identity. I am still digesting SIPS.
> > > > >
> > > > > In this case my assumption is that the topic surrounds
> > > commincations
> > > >
> > > > > within a service provider environment/doamin not a private
> > > > individuals
> > > > > SIP UA and the world, and that we dont need to do anything
> > between
> > > > > service provider proxy and calling SIP UA, so why add an
> > extension
> > > > or
> > > > > additional header at all? I am also going to refer to service
> > > > provider
> > > > > customers as enterprise customers just for this exampe, they
> > > > > could just
> > > > > as easily be SOHO customers.
> > > > >
> > > > > In the case of a service provider, if we are asking
> to mask the
> > > > > identity, as in a private number/username that we dont want
> > > > > disclosed to
> > > > > the called, then it seems that it would be a bit simpler
> > > to maintain
> > > >
> > > > > that which is curently implemented in SIP, and just develop
> > > > > the privacy
> > > > > mechanism as a feature on the SIP proxy, transparently to
> > > the Caller
> > > >
> > > > > (which has been provisioned due to the desire of the
> > > Caller to be a
> > > > > private entity).
> > > > >
> > > > > For example if a SIP Proxy recieves a request from the calling
> > SIP
> > > > UA,
> > > > > it should then act normally on the request, with the
> > > > > exception that, at
> > > > > this point it must modify all SIP Headers that contain
> > > > > information such
> > > > > as IP adresses and usernames of the caller, to
> > > <[email-masked]>,
> > > >
> > > > > instead of [email-masked], and as a key to getting
> > > > > responses back to
> > > > > the SIP UA, the SIP Proxy must maintain the Call-ID with
> > modified
> > > > host
> > > > > information if there is any in the Call-ID.
> > > > >
> > > > > This leaves incoming requests to the SIP UA's, calling
> > > parties which
> > > >
> > > > > want to call this particular SIP UA, with privacy enabled,
> > > > > will have to
> > > > > be privvy to the SIP UA actual information. This implies that
> > > > > a request
> > > > > from a SIP UA within a SIP provider domain are really all
> > > that need
> > > > to
> > > > > be gaurded by the service provider.
> > > > >
> > > > > Example Request:
> > > > >
> > > > >  F1 INVITE User A -> User B
> > > > >
> > > > >    INVITE sip:[email-masked] SIP/2.0
> > > > >    Via: SIP/2.0/UDP here.com:5060
> > > > >    From: BigGuy <sip:[email-masked]>
> > > > >    To: LittleGuy <sip:[email-masked]>
> > > > >    Call-ID: [email-masked]
> > > > >    CSeq: 1 INVITE
> > > > >    Contact: <sip:[email-masked]>
> > > > >    Content-Type: application/sdp
> > > > >    Content-Length: 147
> > > > >
> > > > >    v=0
> > > > >    o=UserA 2890844526 2890844526 IN IP4 here.com
> > > > >    s=Session SDP
> > > > >    c=IN IP4 100.101.102.103
> > > > >    t=0 0
> > > > >    m=audio 49172 RTP/AVP 0
> > > > >    a=rtpmap:0 PCMU/8000
> > > > >
> > > > >
> > > > >  F1 SIP Proxy -> User B
> > > > >
> > > > >    INVITE sip:[email-masked] SIP/2.0
> > > > >    Via: SIP/2.0/UDP here.com:5060
> > > > >    From: BigGuy <sip:[email-masked]>
> > > > >    To: LittleGuy <sip:[email-masked]>
> > > > >    Call-ID: [email-masked]       /*SIP Proxies
> > > > > public address
> > > > >    CSeq: 1 INVITE
> > > > >    Contact: <sip:[email-masked]>
> > > > >    Content-Type: application/sdp
> > > > >    Content-Length: 147
> > > > >
> > > > >    v=0
> > > > >    o=UserA 2890844526 2890844526 IN IP4 here.com
> > > > >    s=Session SDP
> > > > >    c=IN IP4 100.101.102.103   /*may be actual SIP UA or B2BUA
> > > > > ip address
> > > > >    t=0 0
> > > > >    m=audio 49172 RTP/AVP 0
> > > > >    a=rtpmap:0 PCMU/8000
> > > > >
> > > > > The only shady area here is the SDP portion which depending on
> > the
> > > > > environment it is assumed may or may not be a bad thing,
> > > since this
> > > > > really depends on the enterprise policies at that point, and
> > > > > since DHCP
> > > > > or a B2BUA may be implemented in many enterprise scenarios.
> > > > >
> > > > > This sounds too simple to me but I wanted to know to
> what degree
> > I
> > > > am
> > > > > wrong here, if I am at all.
> > > > >
> > > > > As for SMIME content, if this information is provided by the
> > > > > user it is
> > > > > then the users problem, as is the case of enterprise security,
> > and
> > > > SIP
> > > > > UA mis-configuration, which is easily detectable
> within the SIP
> > > > > messages. This actually could be an value added service,
> > > > > detecting these
> > > > > mis-configurations.  :^)
> > > > >
> > > > >
> > > > >
> > > > > Chris
> > > > >
> > > > > _______________________________________________
> > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip <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 <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: Chris Martin <[email-masked]>
Date: Wed, 10 Apr 2002 07:34:50 -0500

> 1. From the Service Provider Point of view the mechanisms described within the privacy draft are needed. It is important to have a statement from the caller if he wants to hide his identity by the…

Actually I do believe that the mechanisms are required and fully support
the direction of the privacy draft. I guess what I am looking for is a
method to reduce the number of mechanisms within the protocol. Right now
I am focusing on the mechanism that basically conveys the identity of
the caller to the remote party as "private".  In the case of a service
provider or even a SIP UA for that matter, I dont see the need to place
the mechanism in the protocol, when it seems that all we need is a local
mechanism on the SIP UA itself or a provisioning option on the SIP UAS
to modify the From to "private". I am just wondering if every aspect of
SIP communications needs to be conveyed by a SIP message.

> 2. For regulation, billing and other purposes the service provider needs an indication if the address included in the Invite is trusted or untrusted (screen = Yes/No). I know Chris does not like ov…

I never said that I was against unregulated networks, they are and will
be a reality. I actually have been concerned that the regulation aspect
is being ignored, by the very fact that everyone looks at firewalls as
an evil in an IP network. It may be firewalls, SIP enabled, that provide
portions fo calling confidentiality, topology hiding, etc., and I
believe that these will aid in meeting future regulations.

> 3. I don't know if a "privacy proxy" will solve all problems concerning privacy and trusted addresses/entities. I support the proposal of the privacy draft concerning the trust relations and the ad…

Was just kidding about privacy proxy. 

Would just like to look into the need of additional headers. As for
trust relations in a carrier network...this may be a matter of
provisioning on SIP UAS.

> Of course the interworking with PSTN networks is not the only application (and of course not the most important) of the privacy draft. But for the Service Provider, which will have hybrid networks…

Totally agree. This is a tool not only addressing future reguations at
the carrier level, but also at the enterprise boundaries.

Thanks for the excellent feedback, 
Chris

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip