Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418F91A000A for ; Wed, 16 Dec 2015 06:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-jqEXMUhF6K for ; Wed, 16 Dec 2015 06:48:19 -0800 (PST) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54241A002F for ; Wed, 16 Dec 2015 06:48:10 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 3F03CC051F; Wed, 16 Dec 2015 15:48:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 0E1011A0081; Wed, 16 Dec 2015 15:48:09 +0100 (CET) Received: from OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0248.002; Wed, 16 Dec 2015 15:48:08 +0100 From: To: Paul Kyzivat Thread-Topic: [stir] stir-06: Reality check on numbers (6.1.1) Thread-Index: AQHRM+LGwWY7rnzsPE6IKcT2IKupYp7F4PAAgAM/lACAAzRnAIAABfEAgAAEowCAAAoiAIAAA3aAgAAq+YCAAAk7AIAADE2AgAAURwCAAO9sQA== Date: Wed, 16 Dec 2015 14:48:08 +0000 Message-ID: <21929_1450277289_567179A9_21929_4_1_B5939C6860701C49AA39C5DA5189448B15651F48@OPEXCLILMA2.corporate.adroot.infra.ftgroup> References: <9C95CF4B-88BD-4EFF-9076-E59CF165E22D@standardstrack.com> <566AF294.6090001@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADE23BB6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56706158.3080905@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADE24A61@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADE24B19@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56709C6E.4070901@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADE24C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5670B7C2.1030805@alum.mit.edu> In-Reply-To: <5670B7C2.1030805@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "stir@ietf.org" , "DRAGE, Keith \(Keith\)" , "Peterson, Jon" Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 14:48:22 -0000 > But E.164 isn't an option for a service number like 611. So what are thin= gs like that to be converted to? > >The draft assumes that it will be converted into something consisting sole= ly of digits, with possible leading * or #. > > If it is canonicalized as 611, then it will be ambiguous with a number in= CC +61. (I guess there is no number "1" within +61, but it may take awhile= to figure that out.) Not necessarily (there's a couple of 1x in Australia) but clearly this does= not scale, I agree. Access codes such as your x11 exist in most national d= ialling plans and "hacking a country code" to sign them with a risk of over= lap is indeed not a good idea. (Interestingly enough, Europe even has 11xy= yy codes...... :) The problem is that as calling party numbers (leaving stir aside) they're n= ot converted. So either the NANP /(national dialing plans) set(s) aside a n= umber subspace to map these access codes into some +1xxxxx611 E.164 +1 rang= e to avoid that (it's quite ugly but I guess it would work if it can be rev= ersed on the other side) or sign a RFC 3966 local number with +1. Any foolp= roof solution (and just noting Brian's previous post that it's not necessa= rily a "must have", agreed) would probably have to be something like this.= =20=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Message d'origine----- De=A0: stir [mailto:stir-bounces@ietf.org] De la part de Paul Kyzivat Envoy=E9=A0: mercredi 16 d=E9cembre 2015 02:01 =C0=A0: DRAGE, Keith (Keith); Peterson, Jon; stir@ietf.org Objet=A0: Re: [stir] stir-06: Reality check on numbers (6.1.1) On 12/15/15 6:48 PM, DRAGE, Keith (Keith) 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 i= n this particular form, rather than to any other string of digits or alphan= umeric characters. > > No RFC defines such a mapping, and I would not expect that any other doma= in 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 tal= king only about such a knowledge being critical for usage within the local = domain, and that was not expressed within the mails. This is all fixed by SBCs. But I don't think they all convert to E.164.=20 They might convert to something else based on bilateral agreements between = domains. But E.164 isn't an option for a service number like 611. So what are things= like that to be converted to? The draft assumes that it will be converted into something consisting solel= y of digits, with possible leading * or #. If it is canonicalized as 611, then it will be ambiguous with a number in C= C +61. (I guess there is no number "1" within +61, but it may take awhile t= o figure that out.) Thanks, Paul > Regards > > Keith > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 15 December 2015 23:04 > To: DRAGE, Keith (Keith); Peterson, Jon; stir@ietf.org > 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 bot= h your messages was that the example URI was prior to conversion to canonic= al 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=20 > all, the results of canonicalization for the bis are not put into the=20 > 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 th= at they are numbers solely because the user part is all numeric, without th= e presence of user=3Dphone. > > I expect that a domain that wants to use all numeric user parts that=20 > 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:jon.peterson@neustar.biz] >> Sent: 15 December 2015 19:57 >> To: DRAGE, Keith (Keith); Paul Kyzivat; stir@ietf.org >> Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1) >> >> >> Sorry if that was baffling, I thought we were entertaining a case=20 >> where >> 611 was intended to be a telephone number: say that instead of "foo", th= at 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 th= e case where "611" is instead in a tel URL, or there is a clear user=3Dphon= e parameter to the SIP URI, it is a bit more obvious - but no less clear ho= w to canonicalize it for international transport or something. >> >> Jon Peterson >> Neustar, Inc. >> >> On 12/15/15, 11:45 AM, "DRAGE, Keith (Keith)" >> wrote: >> >>> I'm lost. >>> >>> sip:611@foo.com, before conversion to canonical form, is a SIP URI=20 >>> belonging to foo.com. It is not a telephone number or a dial string. >>> Depending on how foo.com assigns its SIP URIs it might relate to a=20 >>> dialstring 611 in foo.com land, but that is an entirely arbitrary=20 >>> decision of foo.com, and nothing that should be verified anywhere as=20 >>> a telephone number. >>> >>> This might be a string that exists after conversion of a tel-URI or=20 >>> dialstring to canonical form, but that is not what is being stated belo= w. >>> >>> As such it is outside the scope of STIR. >>> >>> Keith >>> >>> >>> >>> >>> -----Original Message----- >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> 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=20 >>> necessarily speculative. This gets into territory where it's unclear=20 >>> that we even want the verification to work. If a callee in, say,=20 >>> Austria receives a call from sip:611@foo.com (presumably they=20 >>> wouldn't see a service number in the To), is it useful for the=20 >>> callee to know that the call came from "611"? One can argue it isn't=20 >>> even particularly useful for callees in America. >>> >>> >>> Does that mean we shouldn't allow service numbers in these fields?=20 >>> If they are permitted in To and From in baseline SIP, we should at=20 >>> least have a story about them. There is some use in signing the To=20 >>> field for service numbers to prevent cut-and-paste attacks. On=20 >>> balance, I don't see any decisive reason to forbid it. Again, the=20 >>> worst thing that can happen is verification will fail, and if the=20 >>> number is weird, or has leaked into a place where it shouldn't be, fail= ure is probably the right thing. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 12/15/15, 10:52 AM, "Paul Kyzivat" wrote: >>> >>>> On 12/15/15 1:30 PM, Peterson, Jon wrote: >>>>> >>>>> The canonicalization rules are not designed with the assumption=20 >>>>> that the string inputted to the algorithm is an E.164 number.=20 >>>>> They are designed to be as flexible as possible given the=20 >>>>> presence of a dial string - remembering that we canonicalize To as w= ell as From. >>>>> 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=20 >>>> canonicalized the same way by everybody? >>>> >>>> I suppose everyone in the NANP might do so. But what about a=20 >>>> recipient in some other locale? >>>> >>>> I guess the theory is that at the borders between domains numbers=20 >>>> will be rewritten to be understandable in the receiving domain. If=20 >>>> the number doesn't contain its country code then it presumably=20 >>>> needs to be added at a country boundary to be understood. That=20 >>>> works for numbers that correspond to E.164 numbers. But what about=20 >>>> 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=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)" >>>>> >>>> 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=20 >>>>>> destination code, and the subscriber number, all of which are=20 >>>>>> component parts of an international E.164 number, can only be decima= l 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=20 >>>>>> not an >>>>>> 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=20 >>>>>> 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=20 >>>>>>> number, it must >>>>>>> construct a number string. Implementations MUST drop=20 >>>>>>> any leading >>>>>>> +'s, any internal dashes, parentheses or other non-numeric >>>>>>> characters, excepting only the leading "#" or "*" keys=20 >>>>>>> used in >>>>>>> some special service numbers (typically, these will=20 >>>>>>> appear only in >>>>>>> the To header field value). This MUST result in an=20 >>>>>>> ASCII string >>>>>>> limited to "#", "*" and digits without whitespace or visu= al >>>>>>> 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=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=20 >>>>>> in 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 >>>>> >>>>> >>>> >>> >> >> > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you.