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 protected]> 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 >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 > > > > >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
