Steve,
Thanks for your response. Please see below.
On Apr 2, 2013, at 12:08 PM, Stephen Kent <k...@bbn.com> wrote:
> Shane,
>> As one operator whose worldwide routing/operations could be negatively
>> impacted by the above, it would be nice to have a concise statement about
>> what is/was the original intent of the design of the RPKI with respect to
>> the above. In addition, it would be useful to see if any potential
>> remedies/solutions may be employed (and, any associated
>> overhead/delays/*costs*/etc. they incur) that may be used to mitigate them
>> /before/ they manifest themself in the network, at which point operators
>> will be obligated to stop using those 'trusted information repositories' to
>> directly inform routing.
> The intent of the RPKI has always been to create a PKI that parallels the
> allocation hierarchy. The downside of
> this is that errors, or malicious actions, by orgs at higher tiers have the
> potential to adversely impact
> resource holders at lower tiers. At certain tiers in the allocation hierarchy
> this is true irrespective of the
> use of the RPKI. For example, if a targeted entity receives an PA allocation
> from an ISP and that ISP is forced
> by a LEO to suspend service for that entity, but to still advertise the
> sub-allocated prefix, the target has
> a problem.
That is true. However, I feel the need to point a subtle, yet important
difference from today's environment.
First, today, the ISP has direct knowledge prior to this 'event' occurring and
given the direct contractual relationship they have with the customer the ISP
would (IMO) be more likely to have a significant business interest (i.e.: get
paid) to ensure the order was valid, applicable, etc. /before/ it was carried
out. IOW, if the ISP is not providing service to the customer, then the ISP
may be unable to bill for all or part of that service provided, (one, simple
example: usage-based billing). OTOH, if a third-party (RIR?) higher up the
allocation hierarchy were to "whack" a cert, thus making a cert for a resource
invalid can the same be said?
Second, consider the 'scope' of where such a change will be propagated and a
time-to-restore back to "normalcy" after the matter is rectified. Today -- for
better or worse -- it's the immediate upstream ISP(s) of the targeted entity
that, in your example, would be curtailing the propagation of routes and/or
forwarding to the 'targeted entity' to/from the rest of the Internet. IOW, if
(or, when) the matter is appropriately resolved, then (I suspect) the
restoration times to get the customer back online are minimal today given we
are largely talking about BGP propagation times, i.e.: likely minutes.
Ultimately, it's just those immediate upstream ISP's that need to 'act' in
order to propagate that route to the entire Internet. OTOH, in a fully
RPKI-enabled world, SP's the world over are performing origin filtering using
information from the RPKI at all of their customer and peering interconnections
... this could make for some rather long 'restoration' times for the 'targeted
entity' based on several of the models I've seen tossed around in SIDR. And,
the longer the restoration times, again, the more noticeable the impact it
could have on the ISP's who provide service to/from the 'targeted entity',
(again: usage-based billing).
Nonetheless, I will be interested to see if the paper you are writing will
include these types of detail.
> if an RIR accidentally allocated the same prefix to two different entities,
> there would be a problem
> for one or both of them when they tried to advertise the twice-allocated
> space.
While theoretically a possibility, I'd be curious to know if the above is a
common occurrence? If the RIR were concerned about this, one quick way to
ensure this did not happen would be for the RIR to consult a "live" routing
table to see if the space they are (re-)allocating is already being announced
somewhere. In fact, I'd be surprised if they did not do this already.
(Granted, this does not prevent the same space from ever being twice allocated,
because the first allocation was sitting dormant/not-announced at that moment).
> I am working on a doc, to which
> I alluded in my reply to Sharon last week, that examines a wide range of
> cases in which an organization
> in the allocation hierarchy makes an error, or is forced to whack an
> allocation. The doc describes ways
> that such activity can be detected, and remediation options.
I look forward to reading that document when it's published.
-shane
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
