On Dec 1, 2012, at 10:17 AM, Montgomery, Douglas wrote: > It is kind of interesting to think about this requirement - the ability to > need to announce a prefix from a new, previously unseen origin, driven by > a previously non-existant business relationship, anywhere in the world > with a moments notice ... This will be a challenge to any system that > where the users of resource certification information caches data from its > authoritative sources. > > It is also interesting to consider that these requirements are basically > the requirements of a hijack, with the exception that some-where, at the > speed of light, some-one declared this one is "OK".
It's a route announcement in the system Doug, just like any other today. > Not trying to be provocative (dialing that down in general would be a good > thing) ... Just actually trying to think about this as a serious system > requirement. > > Maybe we should have just put the ROA in the BGPSEC update! Call up your > DDOS mitigation provider, give them the private key for your Address > Allocation .. And your done! The new BGP update, contains the ROA. That > is the authorization of the new origin moves at the same speed of the > updates that need it. See, again, we're trying to start with solutions and deal with the imposition of an architectures reeking of 80s and early 90s baggage (i.e., PKI & SBGP-esque) and all their constraints, without recognizing why those systems are no longer favorable or why they weren't adopted in the first place! Adding all this rigidity and ignoring systemic complexities you're introducing, while not address some pretty fundamental concerns (e.g., use of "expired data in RPKI", "lack of robustness in today's nation-state/cyber security landscape", doesn't deal with "leaks", downgrade attacks from algorithms, expired certificates, or unprotected attributes, latency in RPs being aware of new information", etc... Slamming a hierarchical PKI into a distributed routing system is what didn't work in the 90s, agreed. I still contend that work in SIDR would be more effective if we'd focus on a general Internet number resource certification system and decouple precisely how it's employed in the routing system (or other applications, e.g. SAVI, SEND, whatever..). Here, we're focusing on routed resource certification to control what's routed on the Internet, not how or if it's "secure", or the lack of responsiveness of the system. At least employing some pub/sub models for new object availability, rather than requiring CAs and RPs to discover all new information about objects in the system, would be useful in this decade. Of course, -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
