Subject: Re: [stir] Validating TN authority together with number portability

From: Julio Martinez-Minguito <[email-masked]>
Date: Tue, 26 Sep 2017 11:09:46 +0000

As you mentioned, SHAKEN does not care about for which TNs a certificate has authority. It is trusted that the TN belongs to the certificate, and if not, measures are taken later and the reputation of the operator/certificate will be affected.

But back to the IETF draft for certificates and TN authority declaration, the current method to specify the authority can get difficult to implement. If number is ported out we split a range in 2 ranges. And we'll keep splitting the ranges as more numbers are being ported out.
Using different certificates for different ranges would result on a high number of certificates. Specifying all the ranges within 1 certificate will result also in a complex specification.

The specification should be extended to simplify the way to indicate the authority over telephone numbers, specially when numbers are ported out from ranges.

>Brian Rosen <[email-masked]> Wed, 23 August 2017 14:32 UTCShow header<https://mailarchive.ietf.org/arch/search/?email_list=stir>
>Resellers complicate it.
>> On Aug 23, 2017, at 10:01 AM, Eric Burger <[email-masked]><mailto:[email-masked]&gt>; wrote:
>>
>> For that matter, in North America the NPAC already has which operator is supposed to manage a given ported TN. I'm not sure I see the issue here. I suppose one could cross check to make sure the right operator is signing, or is the root of distribution, for a given number.
>>
>>> On Aug 16, 2017, at 8:27 AM, Chris Wendt <[email-masked]><mailto:[email-masked]&gt>; wrote:
>>>
>>> I think you would just cover this scenario with two different certificates with the two smaller ranges.
>>>
>>> That said, for North America the SHAKEN approach is not to use certificates for number blocks, so not sure if you looking at a generic solution or not.
>>>
>>>> On Aug 16, 2017, at 5:21 AM, Julio Martinez-Minguito <[email-masked]><mailto:[email-masked]&gt>; wrote:
>>>> Hi,
>>>> The current drafts for RFC4474bis and certificates describe how to validate that a telephone number is owned by the operator signing the calling Identity. A TNAuthorizationList may be included in the certificate listing the numbers the operator is authoritative for.
>>>>
>>>> However, I see some issues handling this together with number portability which need to be clarified.
>>>> Subscribers will be ported in and out quite frequently, making the information in the certificates obsolete. To keep up the pace with the number portability, the operators certificates would have to be updated frequently. Should the certificates have short validity times? E.g. 1 week, or even shorter?
>>>>
>>>> Instead of having the TN information in the certificate and need to update it constantly, it would be more appropriate to have a trusted server connected to the national Number Portability DB (to update the information) to which the verifiers can connect and retrieve the authority information. Each verifier could retrieve the TN lists for operators and refresh the list daily, without needing to re-issue operator certificates, so it would be updated with the latest portability.
>>>>
>>>> About how to represent the TN lists, e.g. if an operator owns the range 555-xxxx, with the current definitions it will be easy to describe:
>>>> TelephoneNumberRange ::= SEQUENCE {
>>>>      start TelephoneNumber = 5550000,
>>>>      count INTEGER (2..MAX) = 10000
>>>>      }
>>>>
>>>> Now, if number 555-6789 moves to another operator we have to represent with:
>>>> ({start = 5550000, count = 6789}, {start = 5556790, count = 3210})
>>>>
>>>> As more numbers are moved out from the range, this representation format will get messy and difficult to manage.
>>>>
>>>> To handle NP it would be easier to keep the original range, and include a list of excluded numbers which have been ported out, e.g.:
>>>>
>>>> TelephoneNumberRange ::= SEQUENCE {
>>>>      start TelephoneNumber,
>>>>      count INTEGER (2..MAX),
>>>>      excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry
>>>>      }
>>>>
>>>>
>>>> Is this a feasible solution? Is it too late to handle now due to the current state?
>>>> _______________________________________________
>>>> stir mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>> _______________________________________________
>>> stir mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/stir
>>
>> _______________________________________________
>> stir mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Tue, 26 Sep 2017 08:11:39 -0500

I get your point but I’d be curious to hear a good proposal on how to do this simpler than the specs already provide.

This is an information theory problem, it’s hard to represent a disparate set/grouping of numbers no matter how you attack it.

> On Sep 26, 2017, at 6:09 AM, Julio Martinez-Minguito <[email-masked]> wrote:
> 
> But back to the IETF draft for certificates and TN authority declaration, the current method to specify the authority can get difficult to implement. If number is ported out we split a range in 2 ranges. And we’ll keep splitting the ranges as more numbers are being ported out.
> >Brian Rosen <[email-masked] <mailto:[email-masked]>> Wed, 23 August 2017 14:32 UTCShow header <https://mailarchive.ietf.org/arch/search/?email_list=stir>
> >Resellers complicate it.
> 
> >> On Aug 23, 2017, at 10:01 AM, Eric Burger <[email-masked]> <mailto:[email-masked]&gt>; wrote:
> 
> >>
> 
> >> For that matter, in North America the NPAC already has which operator is supposed to manage a given ported TN. I’m not sure I see the issue here. I suppose one could cross check to make sure the right operator is signing, or is the root of distribution, for a given number.
> 
> >>
> 
> >>> On Aug 16, 2017, at 8:27 AM, Chris Wendt <[email-masked]> <mailto:[email-masked]&gt>; wrote:
> 
> >>>
> 
> >>>> On Aug 16, 2017, at 5:21 AM, Julio Martinez-Minguito <[email-masked]> <mailto:[email-masked]&gt>; wrote:
> 
> >>>> Hi,
> 
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
> >>>
> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
> >>
> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 26 Sep 2017 09:21:58 -0400

One idea we tossed around was to extend an OCSP check to include a check of whether the TN in question was still in the range.

Brian

> On Sep 26, 2017, at 9:11 AM, Chris Wendt <[email-masked]> wrote:
> 
>> On Sep 26, 2017, at 6:09 AM, Julio Martinez-Minguito <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked]

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 26 Sep 2017 06:43:59 -0700

Or include references to authorized certs in a registry such as one used for routing.

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, September 26, 2017 6:22 AM
To: Chris Wendt <[email-masked]>
Cc: Julio Martinez-Minguito <[email-masked]>; [email-masked]
Subject: Re: [stir] Validating TN authority together with number portability

Brian

On Sep 26, 2017, at 9:11 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 26, 2017, at 6:09 AM, Julio Martinez-Minguito <[email-masked]<mailto:[email-masked]>> wrote:

>Brian Rosen <[email-masked]<mailto:[email-masked]>> Wed, 23 August 2017 14:32 UTCShow header<https://mailarchive.ietf.org/arch/search/?email_list=stir>
>Resellers complicate it.

---

From: Julio Martinez-Minguito <[email-masked]>
Date: Tue, 26 Sep 2017 15:05:14 +0000

A proposal to handle the numbers ported out is to explicitly indicate them, while keeping the original range. Thus the ranges do not need to be split several times. 
 TelephoneNumberRange ::= SEQUENCE {
      start TelephoneNumber,
      count INTEGER (2..MAX),
     excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry
     }

A possible issue is that the list of excludedNumbers (numbers ported out) could get long as numbers are being ported out,  and the list of excluded numbers might even include  more than the 50% of the numbers in the range. In those cases 'cleanups' could be done to change how the numbers the operator is authoritative are represented, e.g. list of numbers instead of using ranges. 

About doing queries to external systems (OCSP or others protocols) to check if numbers are still in the range for the operator, it would require making queries for every call, and that would impact latency and capacity.

To avoid updating certificates everytime numbers are ported, there can be a query to an external trusted server to download the list of numbers an operator is authoritative. This list could  be updated and downloaded everyday, without having to update the certificates. The format to represent the list can be according to the format described in the draft (maybe with the inclusion of "excludedNumbers".

From: Alex Bobotek [mailto:[email-masked]] 
Sent: den 26 september 2017 15:44
To: 'Brian Rosen' <[email-masked]>; Chris Wendt <[email-masked]>
Cc: Julio Martinez-Minguito <[email-masked]>; [email-masked]
Subject: RE: [stir] Validating TN authority together with number portability

Brian

On Sep 26, 2017, at 9:11 AM, Chris Wendt <mailto:[email-masked]> wrote:

On Sep 26, 2017, at 6:09 AM, Julio Martinez-Minguito <mailto:[email-masked]> wrote:

 
 
>Brian Rosen <mailto:[email-masked]> Wed, 23 August 2017 14:32 UTChttps://mailarchive.ietf.org/arch/search/?email_list=stir
>Resellers complicate it.
>> On Aug 23, 2017, at 10:01 AM, Eric Burger <mailto:[email-masked]&gt; wrote:
>>
>>> On Aug 16, 2017, at 8:27 AM, Chris Wendt <mailto:[email-masked]&gt; wrote:
>>>
>>>> On Aug 16, 2017, at 5:21 AM, Julio Martinez-Minguito <mailto:[email-masked]&gt; wrote:
>>>> Hi,
>>>> mailto:[email-masked]
>>> mailto:[email-masked]
>> mailto:[email-masked]
 
mailto:[email-masked]

mailto:[email-masked]

---

From: Chris Wendt <[email-masked]>
Date: Wed, 27 Sep 2017 11:32:39 -0500

Regarding your last comment, you should pay attention to the discussions in modern working group :)

> On Sep 26, 2017, at 10:05 AM, Julio Martinez-Minguito <[email-masked]> wrote:
>