On Tue, May 20, 2014 at 8:10 AM, Geoff Huston <gih...@gmail.com> wrote:
>
> On 20 May 2014, at 4:38 am, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
>> It's unclear to me what would happen if you split this into a
>> prefix/asn per cert and just carried more certs in your purse. Why
>> would I not just add more certs to my purse? is there a particular
>> reason to conglomerate these under the minimal number of certs? are we
>> trying to minimize space in my purse? if so the purse is large, and
>> the certs very small... I could 10x or 100x the number of certs here
>> and be ok still.
>
> For AS numbers thats an interesting approach, if you carry a single ASN per
> cert then yes, there would be a whole lot more certs around (-ve), but any
> discrepancy in AS registry records between parent and child would be limited
> to just those ASns where there are such discrepancies (+ve)
>
ok, in tim's/your(someone's) original note:
--------------------- snip ------------------------
Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509} (TA certificate)
Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511}
Certificate 3: {10.0.0.0/20, AS64501, AS64509}
Currently we reject certificate 2 and everything under it..
--------------------- end snip ------------------------
it looks to me like making this 8 ROA instead of 3 would make sense.
The 'isp'/resource-owner (I think - AS64501) would be able to announce
the /12, /22 and /20. The customer/other prefix-users:
64505 - /12 and /22
64509 - /12 and /20
64511 - /22
which seems to catch the intent of the 3 certs at least. This way if
you were to break out a new /X from the /12 for AS65534 no one is
broken and no shuffling has to happen (yet).
If the RIR would break the /12 up into 2x /13, for instance, and
transfer the top/higher /13 off to RIR#2, only the /12 needs to change
and you could do make-before-break over some period of time acceptable
to the 3+ parties involved.
Additionally, if the RIR has an oopsy on the /12 the other prefixes by
the users are ok... hopefully.
It's not clear to me that 'oopsy' will happen on only a single prefix
either? if it can happen to 1, it can happen to 20000. (maybe that's a
chat for another day in the thread though).
> However I'm unsure how you could or would apply this principle to IPv4
> addresses. And I'm even more unclear about IPv6.
>
to /32's? or something else? I suppose TODAY we only really care about
'minimum size prefix (max length) which is globally accepted'. We also
should have data on how quickly the RPKI system converges across it's
whole (perhaps to some level of 'converge') given number of objects in
the global system. (this metric discussion came up several times over
the last M meetings... sriram and tim have some data, but it's not
clear how applicable any of the study work has been)
> However, in principle, the validation algorithm proposed in this draft
> performs a validation function which is semantically equivalent to breaking
> down each certificate into a collection of certificates, each describing one
> element of the original number set, but this approach does not require one to
> define the minimal unit of addresses in IPv6, nor try to generate an
> enumeration of individual /128s (or even /64s!) in IPv6, which I guess is a
> Good Thing.
sure, but I don't know that we need to go to host-level data do we?
you can't get a host-route routed in the internet today, at least not
beyond your local ISP (save leaks/mistakes), and I think the ROA
format allows you to specify:
128.2.0.0/16-32 AS5050
right? so in v6:
2001:4860::/32-128 AS15169
Any case of splitting a prefix (2001:4860::/32 becomes 2001:4860::/33
&& 2001:4860:8000::/33) for the purposes of transfer/change-in-Origin
is going to require /make before break. I don't think that's changed
by the validation algorithm is it?
I do think that being explicit with the roa content and not cute by
chunking as much as possible into the bag is a good thing. It seems,
to me, like it makes the decision process for each ROA less complex,
and thus any further actions on that ROA (splits, joins, deletion,
etc) simpler.
-chris
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
