On 14/11/2012 22:18, Christopher Morrow wrote: > 1) What is a 'route leak' (perhaps the above draft identifies one > examplar to be used in that definition)
dunno really. Some foo which involves prefixes being sent to places where they oughtn't have been sent to. This is possibly more of a legal / wordsmithing problem than anything else. > 2) Are 'route leaks' a problem that Operations folks care about speaking with my IXP operator hat on, hell yeah. INEX operates a route server cluster which provides service to ~70% of our members. If we were to operate an unprotected system and had a prefix leak from a client, it would destroy confidence in the system and people would depeer. Connectivity would be directly harmed. In my experience, it takes very little for people to lose trust in a system like this. We use strict prefix filtering based on IRRDB data with a vengeance, but ended up also having to implement maxprefixes after someone attached the INEX route server as-set macro to their own as set macro (mistake #1), then announced all the prefixes they received back to INEX (mistake #2). As it happened, their prefixes were depreferred because of the asn path length, but if they hadn't been depreferred, it could have taken down the entire system. Ouch. Anyway, point being: yes: route leaks matter, yes: at least some operations people care, and belt + braces is sensible. > 3) Should IDR (or the IETF proper) address 'route leaks' with some > form(s) of fix action. mmmm, difficult one. So the current thinking seems to be heading in the direction of RPKI which has a lot of interesting technical characteristics, probably the most interesting of which is the max prefix length. One interesting characteristic of RPKI is that in order for it to have any real function on a live network, it will be necessary to completely drop rpki-invalid prefixes. Merely depreferring them is a bit useless. Problem is, the current implementations of rpki only deal with origin validation, and not as path validation. Work on this has begun in terms of a list of specifications (draft-ietf-sidr-bgpsec-reqs), but hasn't progressed much beyond that as far as I can tell. I wonder if some of the sine-qua-nons in this document are mutually exclusive. RPKI will only be fully functional from the point of view of preventing leaks (whatever leaks are) when we have full as path validation. Being honest, RPKI concerns me from two points of view. From a technical point of view, BGP is a fully distributed system which forms the basis of global network reachability, yet RPKI seeks to impose a top-down control / validation mechanism for it, albeit based on many potential roots. I cannot seem to stop being concerned that this is an architecturally bad idea from a technical point of view, even though there are many safeguards, including: - recommendations for using local caches - lazy validation - recommendations for validation only at ASN boundaries - recommendations in draft-ietf-sidr-origin-ops ... even still, there is a double architectural inversion going on here, where a full-distributed, very low level protocol is being made to depend on a top-down, much higher level protocol. >From a non-technical point of view I also have serious concerns about RPKI in terms of it being used as a hammer that politicians / bureaucrats / LEAs / judges / etc are (and that's "are" as in present tense) extremely interested in as a potential future means of blocking content / services which they happen not to like. Although GROW is not the place for this particular discussion, this aspect of RPKI concerns me to the extent that I am disturbed about the wisdom of developing the technology in the first place: we're building an on/off button for prefixes throughout the Internet. We need to be careful what we wish for because one day, we might get it. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
