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

[Paul Kyzivat <[e-mail]>]

On 12/16/15 11:01 AM, DRAGE, Keith (Keith) wrote:

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

As Eric noted, it reduces the potential for cut/paste attacks.

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

The mechanisms for canonicalizing are the same for From and To. But the 
use cases are different.

I think this is much more about To than From. I suspect it is much more 
common to see a service number in To than in From. And we aren't trying 
to prove anything about who the To is.

I'm not sure, but I have the impression that there *might* be use cases 
for putting a service number in From. (E.g., getting a callback from a 
PSAP.) Can somebody who knows comment on this? Authorization to sign a 
call from a service number might be challenging.

	Thanks,
	Paul

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