Re: deploying RPKI based Origin Validation

[Christopher Morrow <morrowc.lists () gmail com>]

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