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