From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Peterson, Jon" <jon.peterson@neustar.biz>, Paul Kyzivat
 <pkyzivat@alum.mit.edu>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] stir-06: Reality check on numbers (6.1.1)
Thread-Index: AQHRNCzE6AHd4lmGNku6EHrqWfhAdp7GgauQgAXSrACAAAXxAIAABKMAgAAX85A=
Date: Tue, 15 Dec 2015 19:45:00 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE24A61@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <9C95CF4B-88BD-4EFF-9076-E59CF165E22D@standardstrack.com>
 <566AF294.6090001@alum.mit.edu>
 <949EF20990823C4C85C18D59AA11AD8BADE23BB6@FR712WXCHMBA11.zeu.alcatel-lucent.com>
 <D29595DF.17587A%jon.peterson@neustar.biz> <56706158.3080905@alum.mit.edu>
 <D295A284.1758E9%jon.peterson@neustar.biz>
In-Reply-To: <D295A284.1758E9%jon.peterson@neustar.biz>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/dR92QKz9knvV2ytRLPIEDsyzdvI>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)
Precedence: list

I'm lost.

sip:611@foo.com, before conversion to canonical form, is a SIP URI belongin=
g to foo.com. It is not a telephone number or a dial string. Depending on h=
ow foo.com assigns its SIP URIs it might relate to a dialstring 611 in foo.=
com land, but that is an entirely arbitrary decision of foo.com, and nothin=
g that should be verified anywhere as a telephone number.

This might be a string that exists after conversion of a tel-URI or dialstr=
ing 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:jon.peterson@neustar.biz]=20
Sent: 15 December 2015 19:09
To: Paul Kyzivat; DRAGE, Keith (Keith); stir@ietf.org
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 necessar=
ily speculative. This gets into territory where it's unclear that we even w=
ant the verification to work. If a callee in, say, Austria receives a call =
from sip:611@foo.com (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 sto=
ry about them. There is some use in signing the To field for service number=
s to prevent cut-and-paste attacks. On balance, I don't see any decisive re=
ason to forbid it. Again, the worst thing that can happen is verification w=
ill fail, and if the number is weird, or has leaked into a place where it s=
houldn't be, failure is probably the right thing.

Jon Peterson
Neustar, Inc.

On 12/15/15, 10:52 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 12/15/15 1:30 PM, Peterson, Jon wrote:
>>
>> The canonicalization rules are not designed with the assumption that=20
>>the  string inputted to the algorithm is an E.164 number. They are=20
>>designed to  be as flexible as possible given the presence of a dial=20
>>string -  remembering that we canonicalize To as well as From.=20
>>Ideally, everything  we deal with would follow the dictates of=20
>>RFC3966, sure. We just proceed  with an abundance of caution.
>
>So, do you assume that a uri of sip:611@foo.com will be canonicalized=20
>the same way by everybody?
>
>I suppose everyone in the NANP might do so. But what about a recipient=20
>in some other locale?
>
>I guess the theory is that at the borders between domains numbers will=20
>be rewritten to be understandable in the receiving domain. If the=20
>number doesn't contain its country code then it presumably needs to be=20
>added at a country boundary to be understood. That works for numbers=20
>that correspond to E.164 numbers. But what about 611? There is no=20
>standard way to put a country code on it.
>
>	Thanks,
>	Paul
>
>> I would be happy to add some text saying that escaped characters=20
>>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)"
>> <stir-bounces@ietf.org on behalf of keith.drage@alcatel-lucent.com>
>>wrote:
>>
>>> The international E.164 number can only be decimal digits.
>>>
>>> That therefore means that the country code, the national destination=20
>>> code, and the subscriber number, all of which are component parts of=20
>>> an international E.164 number, can only be decimal digits.
>>>
>>> That would imply that the only part that could contain such a=20
>>>character  is a prefix to an E.164 number, or if the number is not an=20
>>>E.164 number,  such as a private dial plan.
>>>
>>> I'd note that RFC 3966 states: "All phone numbers MUST use the=20
>>> global form unless they cannot be represented as such."
>>>
>>> I suspect that "*", "#", etc have more usage in numbers that are=20
>>> dialstrings rather than telephone numbers.
>>>
>>> Regards
>>>
>>> Keith
>>>
>>> -----Original Message-----
>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat
>>> Sent: 11 December 2015 15:58
>>> To: stir@ietf.org
>>> 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,=20
>>>>it must
>>>>         construct a number string.  Implementations MUST drop any=20
>>>>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=20
>>>>only  in
>>>>         the To header field value).  This MUST result in an ASCII=20
>>>>string
>>>>         limited to "#", "*" and digits without whitespace or visual
>>>>         separators.
>>>>
>>>> Survey time: does pound or star  EVER appear in a From field? E.164=20
>>>> 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=20
>>>there is  the possibility of pound coming through then that is=20
>>>needed.
>>>
>>> Also, * and # (as well as A-D) are never valid in global numbers,=20
>>>but are  valid within local numbers not just first, but anywhere in=20
>>>the number.
>>>So
>>> why is there special treatment for a *leading* star or pound?
>>>
>>> ISTM that canonicalization of dialstrings that represent local=20
>>> rather than global numbers is fraught with difficulty.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>
>>>
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stir
>>
>>
>