Subject: RE: [Sip] sip-identity-05: display-name woes

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 8 Apr 2005 15:53:50 -0400

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, April 07, 2005 7:33 AM
> To: Brian Rosen
> Cc: Peterson, Jon; [email-masked]
> Subject: Re: [Sip] sip-identity-05: display-name woes
> 
[snip]
> 
> The most immediate problem I can see comes when your call lands on a 
> gateway to the PSTN. At that point the identification conventions of the 
> SIP network must be interworked with those of the public telephone 
> network. The gateway must decide whether to populate the calling name 
> and number fields on the PSTN side. If it has no authentication that the 
> information is correct, should it populate it? 

Let's be careful, though. If I'm calling from sip:[email-masked], what exactly does the gateway put in the ISUP CgPN field, let alone what might it share as a textual string in the GNP? That sort of SIP-ISUP mapping has bigger problems than just how to deal with display-name. Clearly, if the gateway is going to just make up a telephone number to represent the calling party, all bets are off about how to understand the GNP.

Of course, the From header field of a SIP request might contain a tel URI, or a SIP URI with a tel URI user portion. But in that instance, provided it is a valid telephone number, there is most likely a CNAM record associated with it in the PSTN. Gateways or subsequent PSTN signaling elements can always do CNAM queries to recover the associated appropriate calling name to populate the GNP. But clearly there's no point in even getting the CNAM if the telephone number itself can just trivially be forged in SIP From header fields. This gets into the whole question of why a gateway would ever trust an Identity header that asserts a telephone number. As sip-identity-04 suggests, that has to be a subject for future work, but the only plausible lines of thought we have on this today are ENUM architectures.

By launching an ENUM query, the story might go, the gateway could learn who the number owner is, and thus who should provide the signature over the Identity information, and conceivably the gateway could also learn info like CNAM at the time. This would be tantamount to just reinventing CNAM in an IP context - something that is probably inevitable if telephone numbers are to be used extensively in SIP, something that people are no doubt noodling in various shops around the world today, and something that probably wouldn't necessarily require signing the display-name in order for it to work.

But until we boil that particular ocean, I feel that PSTN interworking might not the best case on which to argue the display-name issue one way or another. 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Apr 2005 16:42:51 -0400

OK. I forgot that phone numbers were out of scope for this discussion.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Apr 2005 10:37:38 -0400

inline.

> OK. I forgot that phone numbers were out of scope for this discussion.

Yes and no. Identifiers that lack a domain structure are out of scope. 
That means tel URI won't work. But, a SIP URL with the user part as a 
phone number seems perfectly fine to me. There is the authorization 
issue, of whether you choose to trust that the domain asserting 
ownership of a phone number really does in fact own it. Thats hard, and 
not really clear to me that it needs to be solved for sip identity to be 
useful with phone numbers. The domain signature prevents the 
impersonation attacks we are primarliy concerned about.

Jon wrote:
>>> gateway to the PSTN. At that point the identification conventions of 
>>> the SIP network must be interworked with those of the public 
>>> telephone network. The gateway must decide whether to populate the 
>>> calling name and number fields on the PSTN side. If it has no 
>>> authentication that the information is correct, should it populate it? 
>>
>>
>>
>> Let's be careful, though. If I'm calling from sip:[email-masked], 
>> what exactly does the gateway put in the ISUP CgPN field, let alone 
>> what might it share as a textual string in the GNP? That sort of 
>> SIP-ISUP mapping has bigger problems than just how to deal with 
>> display-name. Clearly, if the gateway is going to just make up a 
>> telephone number to represent the calling party, all bets are off 
>> about how to understand the GNP.

Ahh. This is a good point. Clearly, it makes little sense at a gateway 
if the From field is sip:[email-masked]. It is for this reason I 
believe that P-Asserted-ID allowed for multiple values, one SIP and one 
tel. More abstractly, the problem is that I may in fact have MANY 
identities, each within different namespaces. Which one of those 
identities are meaningful to the recipient depends on who the recipient 
is. Its nearly impossible for me to know ahead of time what is 
meaningful to them, so P-A-ID allows me to include multiples.

A similar problem arises in enterprise systems, whereby there is an 
internal numbering plan which is effectively a different namespace from 
e.164. One would ideally like to supply a caller ID in both namespaces, 
so that internal phones can use the one from the private numbering plan, 
and phones outside the enterprise can use the public one.

Unfortunately, RFC 3261 allows only a single value for the From header 
field, and so this capability in P-A-ID cannot be readily extended to 
sip-identity. That is the real problem, I think.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Apr 2005 18:22:33 -0400

> impersonation attacks we are primarliy concerned about.

Well, that is a partial solution, which is better than none. But it 
presents the caller with a dilemma:

- using the sip form in From allows identity to work. But using the sip 
form also has the implied semantic that the caller can only be called 
using SIP.

- using the tel form in From has no implied semantic about how the 
caller may be called. Could be via SIP, but could be via PSTN, H.323, 
whatever. But this form won't work with identity.

For instance, I can imagine a dual mode phone - SIP over WiFi plus 
conventional cellular. I receive a call using SIP, and the phone 
captures the from address URI in a directory. Later, when I only have 
cellular coverage, I try to make a call using that directory entry. If 
it is a SIP URI it works. If it is a TEL URI it doesn't.

Of course the phone could go ahead and parse the sip uri for a phone 
number and make a pstn call with it. But it isn't *supposed* to parse 
the user part. If we want devices doing that, we should change the rule 
about interpretting the user part in the case when user=phone.

	Paul