Quite right. PSTN gateways present their own problems, but just the use of number-based SIP URIs for communications within the SIP environment also has some issues, i.e., the fact that the number has meaning without the domain part, and thus the temptation to modify the domain part. As part of the straw man proposal presented today in the meeting, it was suggested that a domain can sign a number-based SIP URI if it believes that calls to that number can reach the user via that domain. So that is all you can assume about the domain part of such a URI.
Of course, this leads to the question of when is a SIP URI number-based and when is it not. In theory, the user=phone parameter could be the criterion, so that if user=phone is absent a relying party could assume that the domain indicated in the URI is the "home" domain for that user. In practice, it appears there are implementations that modify the domain part of any URI that looks like it contains a phone number in the user part. That would appear to be broken, in that return routability would be lost. However, in practice, often a numeric user part IS a phone number, and assuming global uniqueness, return routability perhaps is achievable. So there seems to be rather a grey line between trusting or not trusting the domain part of a SIP URI as being the "home" domain of the user. We have to try to figure out how to address this and give reasonable advice to relying parties. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dwight, Timothy M (Tim) > Sent: 13 March 2008 19:28 > To: IETF SIP List > Subject: Re: [Sip] The thing we're missing in the RFC 4474 > and DTLS-SRTPdiscussion > > I don't understand the focus on PSTN gateways. Is it > believed that only > PSTN gateways ever create URIs with numeric user parts? Or that PSTN > gateways are particularly untrustworthy? Neither seems reasonable to > me. > > tim > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Dean Willis > > Sent: Thursday, March 13, 2008 12:00 PM > > To: IETF SIP List > > Subject: [Sip] The thing we're missing in the RFC 4474 and > > DTLS-SRTP discussion > > > > > > We seem to agree that RFC 4474 assertions involving things > that look > > like phone numbers can not really be trusted, and probably > therefore > > should not be sent. > > > > However, DTLS-SRTP doesn't function without RFC 4474. > > > > So, if you need to use DTLS-SRTP to protect a phone call that > > involves > > a numeric identity (and that includes E.164, private phone > numbers, > > and numeric user parts of any kind), you end up having to > > send an RFC > > 4474 Identity header that is going to mislead people. > > > > So as things are currently written, one can never use > > DTLS-SRTP with a > > numeric userpart in the identity. > > > > That's the part that we absolutely have to sort out. > > > > We could fix this by having gateways encode their identity using a > > reserved userpart. This has to have the property of saying > "Do not > > display this as caller-ID". Using "sip:domain" or > > "sip:ipaddress" does > > not work, as those might actually be valid URIs that be be > displayed > > as IDs. > > > > It might work to have the gateway use a reserved value, like > > "sip:[EMAIL PROTECTED] > > ". > > > > Or it might work to extend RFC 4474 to have a "strength of > > assertion" > > indicator. > > > > It's certainly easier to add guidance in DTLS-SRTP about what > > gateways > > should do and about how UASes should interpret various > header fields > > than it is to change RFC 4474. > > > > However, we need to note that a standards-track document > cannot say > > "Use P-Asserted-Identity". That would be an unacceptable > downref. It > > could however say "If the identity encoded in the RFC 4474 > Identity > > header has the reserved userpart "pstngateway", then the UAS > > MUST NOT > > display this to the user as the calling party identifier. > > Rather, the > > UAS should use other indicators of calling party identity > > that may be > > available to it. > > > > -- > > Dean > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
