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

From: Julio Martinez-Minguito <[email-masked]>
Date: Wed, 16 Aug 2017 09:21:28 +0000

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?

---

From: Chris Wendt <[email-masked]>
Date: Wed, 16 Aug 2017 08:27:35 -0400

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]> wrote:
> 
> Hi,
>  
> _______________________________________________
> stir mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Eric Burger <[email-masked]>
Date: Wed, 23 Aug 2017 10:01:22 -0400

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]> wrote:
> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/stir
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Wed, 23 Aug 2017 10:32:16 -0400

Resellers complicate it.

> On Aug 23, 2017, at 10:01 AM, Eric Burger <[email-masked]> wrote:
>