On Fri, Jul 13, 2018 at 12:41 PM Grant Taylor via NANOG <nanog@nanog.org> wrote:
> On 07/13/2018 10:25 AM, Christopher Morrow wrote: > > > but given: > > 192.168.0.0/16 - valid > > 192.168.0.0/17 - unknown > > 192.168.0.0/24 - invalid > > > > your routing system will still forward toward the 192.168.0.0/24 prefix > > because 'longest prefix match'. > > *facePALM* > > Thank you. > > So the information would be carried across the network, but it still > suffers from the same problem. > > well, consider the situation where Mark's mythical customer(s) are: custA: dual-homed + accept default (from both providers) custB: dual-homed (and live in the 'total sekure world' TSW (tm)) CustA may not see the invalid /24 (nor the /17) but have no other path and "randomly" choose Mark and his /17 + /24 world :( CustB simply drops packets (aka: what Job wants - again, I think) So... if we had more CustB and less CustA ... maybe everywhere it's OK for 'Large Mark Providers' - LMP (tm) to provide such services? I've not looked in a 'long time', but when I worked at a large ISP ~30-35% of our customers did BGP with us, of that ~70+% just did it with us (dual / redundant links to us). I think 'almost all' took a default from us too.. whether they used that default I can't say. I think getting to Job's world is a goal, I think living in Mark's is a reality for a bit still. (yes, you could ALSO do some game playing where the customer ports for TSW were in a VRF with no 'bad' routes, but.. complexity) > > Job's plan, I think, is that you reject/drop/do-not-accept the > 'invalid' > > prefix(es) and hope that you follow another / proper path. > > Yep. > > You would almost need separate logical networks / VRF to be able to > prevent the longest prefix match winning issue that you reminded me of. > > yup, yea... complexity though :( > > Perhaps Mark could send along ONLY the valid/unknown routes to his > > customer, or some mix of the set based on what type of customer: > > > > super-sekure-customer - valid only > > sorta-sekure-customer - valid/unknown > > wild-wild-west-customer - all > > Yep. That's what I was thinking of. > > > it sounded like Mark didn't want to deal with that complexity in his > > network, until more deployment and more requests from customers like; > > Fair. > > > Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com > > yesterday?" > > Mark: "because you didn't ask for 'super-sekure-customer config? > sorry?" > > > > I could have misunderstood either mark or job or you.. of course. > > You understood me correctly. > > Thank you for explaining what I was missing. > > > sure thing! (err, this rpki/secure-routing business isn't really super intuitive :( ) > > -- > Grant. . . . > unix || die > >
