Subject: RE: [Sip] z9hG4bK forever ???

From: "David R. Oran" <[email-masked]>
Date: Sun, 5 May 2002 10:03:02 -0400

A light bulb went on...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Drage, Keith (Keith)
> Sent: Monday, April 29, 2002 5:26 AM
> To: 'Mark Watson'; 'Dean Willis'; 'William Marshall'; [email-masked]'
> Subject: RE: [Sip] z9hG4bK forever ???
> 
> 
> The special arragement option depends on how the network 
> operator deals with providing it.
>  
> If the network operator gives it to all and everyone, then it 
> is as you say. Essentially as the From field. This requires 
> no further consideration.
>  
> When it was specified however, one major use was identified 
> as being from enterprise networks, in fact they were the main 
> proponents of such a usage. If one follows the private 
> network ISDN signalling specifications (ISO PSS1 and ECMA 
> QSIG) then enterprise delivered values are screened in the 
> enterprise network, thus as far as the enterprise network is 
> concerned, they are regarded as network asserted rather than 
> as user asserted. The only reason for the special arrangement 
> coding (user provided unscreened) in this case is that the 
> public network operators wanted a distinction between public 
> network asserted identities and private network asserted identities. 
>  
> So far the point is therefore that while enterprise networks 
> can and do assert identities, they may not be fully trusted. 
> In the ISDN, it is trusted sufficiently in order to deliver 
> the CLIP service to the remote user, but is not trusted 
> sufficiently for malicious call identification. If we are to 
> achieve 100% mapping to the ISDN/PSTN, then we may need to 
> reflect this distinction.
>  
Yes, but the ISDN is missing what I believe is a crucial distinction -
whether the NAI was asserted by you (the carrier looking at the SIP
message), or another carrier. The tacit assumption is that the "pubic
networks" comprise a single homogenous trust domain, and everything else
is a "private network" and hence in a different trust domain. There is
no capability for finer granularity nor control of transitivity.

If we simply provide the ability to authenticate the source domain of
the NAI, and to scrub NAI at any boundary between domains, we can
duplicate, as well as improve on the ISDN functionality. If one maps to
ISDN itself, there is clearly some loss of information, as there is with
any mapping function, but this loss is no worse than connecting anything
different to ISDN in the first place.

> I certainly do not believe that we should treat the 
> unscreened coding in all cases as mapping to the From header, 
> as this will not give a 100% mapping in the reverse 
> direction. However, in the longer term, providing some values 
> indicating who provided the assertion may resolve this 
> problem. 
I do not believe anything less than a digitally signed authenticator is
of much use in the world of IP. The attacks are mountable in just about
any envrironment that is not encased in bulletproof walls.

> In this case dummy values such as "non-public 
> network operator" could be used as the asserting identity 
> when such values are mapped.
> 
I am more than a little nervous about introducing native identifiers to
SIP which state nothing meaningful globally from a policy standpoint. I
certainly trust a non-public network operator in the UK to preserve my
privacy more than a pubic network in North Korea. Telling me that an
identity was asserted by a "public network operator" without a digital
signature proving which one it is, does me absolutely no good at all. I
might as well ask for code points like "carrier not cited in last year's
Amnesty International human rights report".

> In the short term, as a large number of public network 
> operators do not allow the special arrangement to exist, it 
> may be best to ignore the special arrangement, or at least 
> the finer details of the mapping.
>  
> Keith
>  
>  
> 
> 	-----Original Message-----
> 	From: Mark Watson [mailto:[email-masked]]
> 	Sent: 18 April 2002 12:00
> 	To: 'Dean Willis'; William Marshall; [email-masked]
> 	Subject: RE: [Sip] z9hG4bK forever ???
> 	
> 	
> 
> 	I think we're about at the end of this one. 
> 
> 	Two final points from me: 
> 	1) Dean's desire to avoid having the From: field 
> mangled unless he has specifically requested it is 
> reasonable. I still think  that the subscriber's wishes could 
> overrule this though.
> 
> 	This is no different from the ISDN 'Special 
> Arrangement' where the user inserts any number they like in 
> the Calling Party Number field. The network passes it though 
> with no checking, changing, nothing - I think this is 
> analogous to what Dean wants for the From field.
> 
> 	But the network still removes this information if the 
> subscriber wants anonymity. The stated purpose of the field 
> is user identity, which implies Personal Data of the 
> subscriber. This is enough to argue that the network must 
> remove it if privacy is required, and this is certainly the 
> application of current legislation to ISDN.
> 
> 	What is the stated purpose of the From field - I do not 
> think it is sufficiently different for us to be _sure_ that 
> we can avoid the requirement.
> 
> 	So, the munging may still be required, but I certainly 
> agree it should be avoided wherever possible. 
> 
> 	2) In formal terms, 'B2BUA == NOT Proxy'. We all know 
> there will be/are devices which behave very much like a 
> proxy, but perform some additional functions, such as these 
> privacy services. This is fine. Everyone should be aware that 
> with only two terms defined 'B2BUA' and 'Proxy', such devices 
> fall into the B2BUA category.
> 
> 	...Mark 
> 
> 	> -----Original Message----- 
> 	> From: Dean Willis [mailto:[email-masked]] 
> 	> Sent: 17 April 2002 17:36 
> 	> To: William Marshall; [email-masked] 
> 	> Subject: Re: [Sip] z9hG4bK forever ??? 
> 	> 
> 	> 
> 	> Baill said: 
> 	> > All this discussion of proxy modification of the From and 
> 	> To headers, 
> 	> > and the need for a B2BUA, seems to me to be a short-term 
> 	> problem only. 
> 	> > 
> 	> > RFC3261 (2543bis-09) specifies matching of 
> dialog-ids based only 
> 	> > on Call-ID and tags, not on display-name or on 
> addr-spec.  So 
> 	> > when all endpoints are compliant with RFC3261, 
> there will be no 
> 	> > problem with a proxy modifying the display-name or 
> addr-spec in 
> 	> > the From header. 
> 	> 
> 	> I disagree. I don't want the network mangling my 
> user-to-user headers 
> 	> unless I've specifically requested it to do so. 
> Specifically, the 
> 	> non-authenticated, non-mangled, non-protected From: field 
> 	> offers utility 
> 	> which is DIFFERENT than that provided by network 
> authenticated calling 
> 	> party ID, and I don't want to sacrifice that utility 
> just because this 
> 	> is a capability the widely-deployed PSTN (as opposed 
> to say Q.SIG) 
> 	> didn't have . . . 
> 	> 
> 	> -- 
> 	> Dean 
> 	> 
> 	> 
> 	> 
> 	> 
> 	> _______________________________________________ 
> 	> 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