John, See below.
On Apr 2, 2013, at 8:26 AM, John Curran <[email protected]> wrote: > On Apr 2, 2013, at 9:53 AM, Danny McPherson <[email protected]> wrote: [--snip--] >> Yeah, they were nonsensical in the past and present role of ARIN, not in an >> RPKI-enabled world where revocation or transfer or inaccessibility will have >> some impacted on the routability of the address block in question. > > You keep repeating that assertion, but note that even in today's world > we could be ordered to reclaim and reassign a block with similar effect. > It may not be "real time" but there are plenty of folks who follow both > the daily issued files as well as derivative filter lists. It is also > true of various routing registries. Even after deployment of RPKI, there > will be some fairly long period where loss of the covering ROA _alone_ is > likely to have little impact since the routing is still there, and we don't > seem to have any documentation suggesting to _only_ listen to routes that > are known valid. Loss of ROA coverage exposes one to further exploits, > but per existing guidance it should not result in connectivity impacts > (just as leaving one's seatbelt off doesn't generate an auto accident...) Personally, I think there's a significant difference in "today's world" vs. a "RPKI-enabled world". Specifically, in today's world, it's typically only upstream SP's that are using such information as a means to apply prefix+Origin_AS filters against their directly attached customers (and, customers of customers). In my understanding of the future promise-land that is the RPKI, ROA information will *not only* be used by SP's to filter against directly attached customers (and, customers of customers) like it is today ... but *also* on all interconnect (peering) circuits and even by third-party SP's who have no direct and, likely, no indirect relationship with the resource-holder in the first place. Thus, what Danny speaks of (and, I share a similar concern) is that either an operational mistake/bug in the RPKI and/or law-enforcement action against the RPKI /will/ result in a much, much larger denial-of-service, perhaps denying that resource holder an ability to receive pack ets on the Internet for a substantial portion of time. That's a /substantially/ different operating model from today's world where, more often than not, it's typically only the customer's upstream SP's to modify/update a filter-list, which can be done in *minutes* vs. how long in the RPKI ... including time for third-parties to fetch and update and make state changes in the network? -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
