On 12/3/12 9:04 AM, "Danny McPherson" <[email protected]> wrote:
> >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. Sure. But my point was typically today we don't do general filtering of unauthorized originations. If we were to accept that as a goal, then the only difference in the emergency DDoS mitigation origination and a hijack is a phone call. How to represent that phone call in the system at the speed of BGP update propagations is the point. > >> 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. Address allocation is strictly hierarchical and distributed in the Internet today. It seems that any resource certification system would have to reflect that fact. > >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. I was trying to talk about the suggested requirement of near real-time authorization of route updates, divorced from any specific mechanisms. OK, I know I suggested a mechanism. But all I really meant was the observation that the only real way to get authorization to move at the speed of updates, is to carry the auth data in the update. If we want to relax that a bit ... But still be more responsive than existing proposed mechanisms, we would need modified/different distributions mechanisms for authorization data. > >Of course, > > >-danny Obviously, Dougm _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
