Greetings,
* On Wed, 14 Nov 2012 23:52:53 +0000 * Nick Hilliard <[email protected]> wrote: > 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. I agree. Max-prefix-limits feature is one of the operative tools for mitigating route leaks. However in case of operating the route servers in IXP, threshold of limit also is a important consideration. Sometimes new members advertise the full routes into route servers, so IXP operators would like to prevent that. Combination of route filter and max-prefix-limit is reasonable. Kind Regards, Masataka MAWATARI > > 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
