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

From: "Mark Watson"<[email-masked]>
Date: Mon, 8 Apr 2002 11:13:06 +0100

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.

In particular, the values in the To/From fields will need to be modified.

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.

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.

Regards...Mark

> -----Original Message-----
> From: Chris Martin [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
> 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: Mon, 08 Apr 2002 07:58:20 -0500

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

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. 

> 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