Subject: [sidr] RPKI utility vs fragility

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 25 Jul 2014 16:00:40 +0000

… To follow up on the last couple of comments of the session … the large
resource bundles also contain AS numbers … while we can claim NOTFOUND
might help routing robustness in RPKI malfunctions … there is no such 3rd
state in path validation.   The path becomes INVALID in such cases.

Of course this might be the answer to John’s earlier question of when one
would keep a route with INVALID path but Valid/NOTFOUND origin. :)

I have participated in several public/private working groups where
operators often express concern about the RPKI fragility vs utility
question.  Anything we can do to reduce the fact or FUD about the
fragility concerns, would help in these discussions.

dougm
— 
Doug Montgomery, Mgr Internet & Scalable Systems Research NIST/ITL/ANTD

---

From: Terry Manderson <[email-masked]>
Date: Fri, 25 Jul 2014 18:04:43 +0000

Hi Doug,

Yes, it is true that BGPSEC only has two states (valid/not valid) and
there is also a raft of hand-waving around the implementation of those
states, eg the draft cites local policy, for whatever that is worth.

Taking a step back, this might well go further than just the
Valid/NotFound state of the originating AS. Thus the question regarding
what happens to the route path validation that contains a set of RPKI
objects (Step I, section 5 in bgpsec-protocol) along the path is raised.
My presumption to date (perhaps horrendously wrong) is that it would not
be terminal, eg NOT invalidate the routes of all affected parties in
BGPSEC enabled islands. If it is the case that it will suffer the same
fate related to the 3779 validation question Geoff poses, and I've held
off commenting on bgpsec protocol for other-worldly reasons, maybe 2
states is not sufficient? Perhaps a 3rd 'Incomplete' state might be of use
for both robustness and detectability? - since after all, a router cert
will also invalidate in the case where a RIR/NIR/LIR "screws-up", to use
another WG member term.

The heretic in me (insert profuse apologies) would also take a further
step (nay leap) back from the coal face and proffer the idea that while
being stuck between a rock and a hard place the use of RPKI validation and
thus the tight binding of RPKI and Path Validation is a step too far
architecturally. 

For many long years I've liked the mantra that the administrative function
maintains an arms-length distance to the 'fit for use' of a prefix in
routing terms. Case in point, we see this now being raised in such works
as SLURM and Suspenders for those non-accidental situations people fear,
and the agreement ARIN asks to implement for preservation which Wes also
can't engage for near the same reasons. Perhaps the transfer of resources
in RPKI is also bound there as well.

So sitting there as an operator known to have influence over some
infrastructure that helps in the (DNS) stability of the global (big "G")
internet I find myself questioning the overall architecture, and wonder if
I could actually sleep at night should I implement origination and path
validation for that little piece of DNS infrastructure. Especially if some
BGPSEC enabled transit provider has all route paths broken (mine and all
'clients') due to a 'higher tree' CA issue. I like the statement of valid
resource entitlement, I like the statement about path validation. I'm not
comfortable with rpki+bgpsec where they are so married, and divorce
appears not to be an option. Ever.

As such I, similarly, don't prescribe to the (flippant) statement from
Geoff that a 'one RIR' RFC might be written in this context. :) (Although
I have associates that will certainly line up for the author queue on
that!)

As I said, I live in world of double-edged swords. Each decision has a
consequence here. And so far I do see a problem. I don't yet know if this
validation shift opens up other attack vectors combined with, say, a MiTM
of the BGPSEC update.

I am much in favour of increasing the fact levels. Happy to contribute
where needed.

That said there are also many other problems. We have no option for key
roll yet, we haven't come out the other side of the TAL and publication
points draft, and I'm sure this list is incomplete.

Terry

On 26/07/2014 2:00 am, "Montgomery, Douglas" <[email-masked]> wrote:

>Š To follow up on the last couple of comments of the session Š the large
>resource bundles also contain AS numbers Š while we can claim NOTFOUND
>might help routing robustness in RPKI malfunctions Š there is no such 3rd
>Of course this might be the answer to John¹s earlier question of when one
>‹ 
>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr