Re: [stir] Ranges or individual numbers

[Brian Rosen <[e-mail]>]

If we allowed ranges, I would NOT invalidate a cert when a number ported out (or back in) to a range.  I would have an OCSP-like query that was queried with cert and TN and responded with valid-for-that-TN or not.  Since CRLs don’t work, you need something like OCSP.  Since you are querying for validity, extending to say “valid for this TN” is a small change.

Numbers in use are growing, but somewhat slower than before.  Some of the growth is in devices that are not phones, but they would need certs.  Inventory changes all the time, especially since we hand out numbers in blocks of 1000, rather than the 10K we used to do it in.  That’s US experience, not necessarily the same in countries like India.

I don’t think push notification would work particularly well, but it’s possible as long as the notification expired reasonably promptly.  I think OCSP is the right model.

Brian

On Jul 29, 2014, at 3:03 PM, Henning Schulzrinne <[e-mail]> wrote:

> I’m not sure that the OCSP will differ all that much in practice, given the large number of ranges (i.e., a single SBC will see the same range only somewhat more likely than the same number within the caching interval).
>  
> Given the relatively low growth of voice services, my guess is that almost all new (to-a-provider) customers are either ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the ported “singleton” number (which may become, by chance, part of an existing block on the winning side at some point, but initially won’t, by definition) and the range above. Managing all of these splits and merges doesn’t sound all that much easier than individual numbers and seems harder to implement. Since we don’t want porting to fail validation (I’m less worried that the losing provider can still sign for a while), we probably need a push notification.
>  
> I’m not against ranges, but I’m trying to make sure we consider all the complexities involved before early “optimization” of one facet.
>  
> From: stir [mailto:[e-mail]] On Behalf Of Brian Rosen
> Sent: Monday, July 28, 2014 12:49 PM
> To: Richard Shockey
> Cc: [e-mail]
> Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates
>  
> US NPAC does about 1.5M transactions a day.  Not all of those would invalidate a cert, but I lot would either create one or invalidate one.  I believe you have to keep the cert in the CRL at least until it expires.  How long we’re you thinking the expiration time was?  A typical year?   More?   You fetch an entire CRL.   It’s just not a practical answer.  And we have OCSP.  A much more practical answer, even with an extension if we support ranges.
>  
> 
> 
>  
> In any event is should be clear that I agree with Henning that a cert per TN system is preferable and our guidelines should reflect that. Why are you even suggesting number block ranges?  You are the last person I would have thought would be fond of the LERG. [That’s the North American Local Exchange Routing Guide for you non NA centric folks]
> Because most delegations to SPs are in a range.  It may be that eventually, SPs won’t keep number inventory, but they do for most SPs in effectively all countries.  
>  
>  
>  
> In addition I certainly agree that we cannot boil the ocean here with a requirement for some global system. Nothing will ever get deployed… I still have the 6116 arrows sticking out my back.
> No one is arguing, but the details have to be worked out.
>  
> 
> 
>  
>  
> Brian
>  
> On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <[e-mail]> wrote:
> 
> 
> 
> My suggestion would be conceptual simplicity. My hunch is that the fraction of numbers that are assigned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have “holes”.) The only ranges likely to be left are large-scale businesses. Thus, if we can devise a mechanism that’s a bit less efficient, but avoids dealing with prefixes, this might be a good trade-off.
>  
> As long as there’s a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-less static table of national prefixes, the national aspect doesn’t seem to be too hard – even if there’s more than one way to retrieve a cert or public key. (I realize +1 poses somewhat unique challenges, but treating it as a list of mini-countries for each area code, where the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)
>  
> From: stir [mailto:[e-mail]] On Behalf Of Brian Rosen
> Sent: Monday, July 28, 2014 9:06 AM
> To: Richard Shockey
> Cc: FOUQUART Philippe IMT/OLN; [e-mail]
> Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates
>  
> I think we do it in STIR.  Not only do we have Russ, but we have Sean, and we have EKR, and we have other folks well versed in certs.
>  
> I agree than distribution will vary some by country, but I think it would be worth our time to write up some guidelines at least.
>  
> One part I know we have to do is to do something OCSP-like that verifies the validity of a cert for a particular TN (that is, get a cert for a range, port a number out of the range, the cert is still valid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we need that query.  It’s not a bad thing to have a CRL, but you need the other bit anyway.
>  
> And I agree, we are making very good progress.
>  
> Brian
>  
> On Jul 27, 2014, at 5:20 PM, Richard Shockey <[e-mail]> wrote:
> 
> 
> 
> 
> OK .. The real question.  How are the gory details going to be worked out?  
>  
> In STIR or where?
>  
> If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem.  We can recommend that the relevant National Numbering Authority do FOO but I’m not sure how much else is possible.
>  
> Is that in RAI or ?   This is actually something the AD’s and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined.
>  
> Well?
>  
> I would suggest that we do consult with our SIDR friends here.  Having personally spoken to many of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicate to our current work plan.
>  
> BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like.  Don’t worry be happy!
>  
>  
> From: stir [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Sunday, July 27, 2014 12:08 PM
> To: [e-mail]
> Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates
>  
> I support this becoming a WG work item.
>  
> Philippe Fouquart
> Orange Labs Networks
> [phone]
> 
> 
> 
> -------- Message d'origine --------
> De : Robert Sparks <[e-mail]> 
> Date : 25/07/2014 19:43 (GMT+01:00) 
> A : [e-mail] 
> Objet : [stir] Call for adoption of draft-peterson-stir-certificates 
> 
> 
> 
> 
> 
> There was very strong consensus in the Toronto STIR meeting to adopt 
> draft-peterson-stir-certificates as a STIR WG document.
> This message is to confirm that consensus on-list.
> Please comment before 8-Aug-2014.
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> _________________________________________________________________________________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>  
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir