Re: [stir] stir-06: Reality check on numbers (6.1.1)

["DRAGE, Keith (Keith)" <[e-mail]>]

Apart from the issues of uniqueness of canonical form, one aspect of this that I do not understand how works, is that many of these numbers do not relate to a single user or a single organization, and that applies for many of these local service numbers.

This gets even worse with emergency numbers.

112 is mean to work for roaming users. So depending on whether I am in country A or country B, I will get the emergency service organization in country A or country B respectively. These are different users and should sign differently. Further depending on where I am in that country or the category or URN subtype I use, I may get an entirely different emergency organization, presumably with its own signing. Depending on PSAP load conditions, there may be overflow arrangements that take you to an entirely different organization.

So using this with a non-unique local service number to identify somehow the called party would seem to achieve little – at least tell me what it achieves.

I’d note in your mail you also seem to switch between calling and called direction. Are you trying to ensure that the calling user knows they have reached an emergency number, or that the calling user is known to the call taker (presumably not a service number problem). I think it is your last paragraph that is confusing me.

Keith

From: stir [mailto:[e-mail]] On Behalf Of Brian Rosen
Sent: 16 December 2015 14:34
To: Paul Kyzivat
Cc: [e-mail]
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

Please don’t do that.

It would be extremely valuable for calls to any of the n-1-1 numbers to be signed, and especially 9-1-1.

Read 1-1-2 for EU.

“Swatting” is a very serious problem, which can only reasonably be stopped by having some assurances of the callers identity.  It works today because the caller’s identity can be spoofed.

In fact, just because the called party can’t be canonicalized shouldn’t make the entire mechanism fail.  I think we should have canonicalization rules for service numbers, but even in the absence of canonicalization of the “To:”, the mechanism should still work as long as the To is not mangled by downstream elements.

It doesn’t have to be foolproof, it just has to work most of the time.  The call takers will take extra precautions if the mechanism fails occasionally, but if it rarely works, then it’s useless.

Brian

On Dec 16, 2015, at 12:50 AM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>> wrote:

On 12/15/15 8:34 PM, Eric Burger wrote:

And local arrangements are… local… out of scope. The PBX/AS/SBC will have to make To/From into something sensible. At that point, it is an E.164 number that STIR can deal with.

There is no point worrying about my phone saying “From: x74107”. You cannot get there from here unless you are inside my enterprise already, at which point you are not STIRing anyway.

Since you don't live in the US you may not know what 611 is. It is not a local number, like an internal extension on a PBX. It is a service number. It is among the family of N11 numbers, of which 911 is best known.

This discussion is, loosely, about most/all of the service numbers. 911 is extra special, and has customized treatments, so we should probably exclude it from this particular discussion.

There is in general no E.164 number that the service numbers can be transformed to for purposes of canonicalization.

The answer may be that these numbers can't be canonicalized, and calls to/from them cannot be signed.

                Thanks,
                Paul


On Dec 15, 2015, at 6:48 PM, DRAGE, Keith (Keith) <[e-mail]<mailto:[e-mail]>> wrote:

I am aware that for example, some PBX deployments do this.

But my understanding is that this is an entirely local arrangement within the PBX domain that such an arrangement applies, i.e. that a set of local numbers within the PBX map to a set of SIP URIs, and that that mapping is in this particular form, rather than to any other string of digits or alphanumeric characters.

No RFC defines such a mapping, and I would not expect that any other domain would be expected to be aware of this local arrangement, anymore than it might be expected to know the relationship between the PBX numbering plan and E.164 numbers.

I guess any such expectation is the crux of the matter, unless we are talking only about such a knowledge being critical for usage within the local domain, and that was not expressed within the mails.

Regards

Keith

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]]
Sent: 15 December 2015 23:04
To: DRAGE, Keith (Keith); Peterson, Jon; [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

On 12/15/15 5:31 PM, DRAGE, Keith (Keith) wrote:

Well what was confusing was that the only way of reading the text in both your messages was that the example URI was prior to conversion to canonical form, i.e. if there were any URI parameters, they were still present. As none were specified, there could be none, and therefore the URI was a SIP URI pure and simple.

Yes, the intent was that these were prior to canonicalization. (After all, the results of canonicalization for the bis are not put into the URI.)

The simple fact is that URIs of the form sip:nnn@domain are very commonly used to represent phone numbers. And servers are very happy to conclude that they are numbers solely because the user part is all numeric, without the presence of user=phone.

I expect that a domain that wants to use all numeric user parts that are
*not* phone numbers might have great difficulty interoperating with other domains. Probably this isn't a problem in practice because:
- it just isn't done
- domains that handle phone numbers don't peer with domains that
  use non-phone-number URIs.

                Thanks,
                Paul


Keith

-----Original Message-----
From: Peterson, Jon [mailto:[e-mail]]
Sent: 15 December 2015 19:57
To: DRAGE, Keith (Keith); Paul Kyzivat; [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)


Sorry if that was baffling, I thought we were entertaining a case
where
611 was intended to be a telephone number: say that instead of "foo", that URI contained a carrier's domain, and this happened to be the unhelpful way the carrier in question stored all telephone numbers in SIP URIs. In the case where "611" is instead in a tel URL, or there is a clear user=phone parameter to the SIP URI, it is a bit more obvious - but no less clear how to canonicalize it for international transport or something.

Jon Peterson
Neustar, Inc.

On 12/15/15, 11:45 AM, "DRAGE, Keith (Keith)"
<[e-mail]<mailto:[e-mail]>> wrote:


I'm lost.

sip:[e-mail], before conversion to canonical form, is a SIP URI
belonging to foo.com<http://foo.com>. It is not a telephone number or a dial string.
Depending on how foo.com<http://foo.com> assigns its SIP URIs it might relate to a
dialstring 611 in foo.com<http://foo.com> land, but that is an entirely arbitrary
decision of foo.com<http://foo.com>, and nothing that should be verified anywhere as
a telephone number.

This might be a string that exists after conversion of a tel-URI or
dialstring to canonical form, but that is not what is being stated below.

As such it is outside the scope of STIR.

Keith




-----Original Message-----
From: Peterson, Jon [mailto:[e-mail]]
Sent: 15 December 2015 19:09
To: Paul Kyzivat; DRAGE, Keith (Keith); [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)



The use of service numbers in the From is a case where our text is
necessarily speculative. This gets into territory where it's unclear
that we even want the verification to work. If a callee in, say,
Austria receives a call from sip:[e-mail] (presumably they
wouldn't see a service number in the To), is it useful for the callee
to know that the call came from "611"? One can argue it isn't even
particularly useful for callees in America.


Does that mean we shouldn't allow service numbers in these fields? If
they are permitted in To and From in baseline SIP, we should at least
have a story about them. There is some use in signing the To field
for service numbers to prevent cut-and-paste attacks. On balance, I
don't see any decisive reason to forbid it. Again, the worst thing
that can happen is verification will fail, and if the number is
weird, or has leaked into a place where it shouldn't be, failure is probably the right thing.

Jon Peterson
Neustar, Inc.

On 12/15/15, 10:52 AM, "Paul Kyzivat" <[e-mail]<mailto:[e-mail]>> wrote:


On 12/15/15 1:30 PM, Peterson, Jon wrote:


The canonicalization rules are not designed with the assumption
that the  string inputted to the algorithm is an E.164 number. They
are designed to  be as flexible as possible given the presence of a
dial string -  remembering that we canonicalize To as well as From.
Ideally, everything  we deal with would follow the dictates of
RFC3966, sure. We just proceed  with an abundance of caution.

So, do you assume that a uri of sip:[e-mail] will be
canonicalized the same way by everybody?

I suppose everyone in the NANP might do so. But what about a
recipient in some other locale?

I guess the theory is that at the borders between domains numbers
will be rewritten to be understandable in the receiving domain. If
the number doesn't contain its country code then it presumably needs
to be added at a country boundary to be understood. That works for
numbers that correspond to E.164 numbers. But what about 611? There
is no standard way to put a country code on it.

                Thanks,
                Paul


I would be happy to add some text saying that escaped characters
should be  removed as part of the canonicalization process.

Jon Peterson
Neustar, Inc.

On 12/13/15, 9:34 AM, "stir on behalf of DRAGE, Keith (Keith)"
<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>>
wrote:


The international E.164 number can only be decimal digits.

That therefore means that the country code, the national
destination code, and the subscriber number, all of which are
component parts of an international E.164 number, can only be decimal digits.

That would imply that the only part that could contain such a
character  is a prefix to an E.164 number, or if the number is not
an
E.164 number,  such as a private dial plan.

I'd note that RFC 3966 states: "All phone numbers MUST use the
global form unless they cannot be represented as such."

I suspect that "*", "#", etc have more usage in numbers that are
dialstrings rather than telephone numbers.

Regards

Keith

-----Original Message-----
From: stir [mailto:[e-mail]] On Behalf Of Paul
Kyzivat
Sent: 11 December 2015 15:58
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

On 12/10/15 9:15 PM, Eric Burger wrote:

Section 6.1.1 on Canonicalization states:
        Once an implementation has identified a telephone
number, it must
        construct a number string.  Implementations MUST drop
any leading
        +'s, any internal dashes, parentheses or other non-numeric
        characters, excepting only the leading "#" or "*" keys
used in
        some special service numbers (typically, these will
appear only  in
        the To header field value).  This MUST result in an
ASCII string
        limited to "#", "*" and digits without whitespace or visual
        separators.

Survey time: does pound or star  EVER appear in a From field?
E.164 does not allow it.

pound isn't allowed at all in a sip uri, except via escaping.

There is no mention of escaping (or unescaping) in the text. If
there is  the possibility of pound coming through then that is
needed.

Also, * and # (as well as A-D) are never valid in global numbers,
but are  valid within local numbers not just first, but anywhere
in the number.
So
why is there special treatment for a *leading* star or pound?

ISTM that canonicalization of dialstrings that represent local
rather than global numbers is fraught with difficulty.

                Thanks,
                Paul



_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir





_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir