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 14:56:53 +0100

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.

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).

Regards,

Mark

> -----Original Message-----
> From: Chris Martin [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]]
> > > 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 17:12:48 -0500

> 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

> > Individuals can place anything they want in the >From field merely
> by

Use [email-masked] for new developments on the application of sip