deploying RPKI based Origin Validation
morrowc.lists at gmail.com
Fri Jul 13 17:28:01 UTC 2018
On Fri, Jul 13, 2018 at 12:41 PM Grant Taylor via NANOG <nanog at nanog.org>
> 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'.
> 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)
(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
> > prefix(es) and hope that you follow another / proper path.
> 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;
> > 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?
> > 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
More information about the NANOG