speaking as regular ol' member: On Apr 28, 2015, at 3:21 PM, Iljitsch van Beijnum <iljit...@muada.com> wrote:
> On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) <rogag...@cisco.com> > wrote: > >> It is not an implementation choice, it is by design. If a signed object does >> not validate (based on whatever reason not just expiration), it is like if >> did not existed. > > No... > > Suppose: > > ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 > > BGP table 29 april: > > 193.0.0.0/21 3333 -> valid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown > > But, two days later, after the ROA expires, do we have this: > > 193.0.0.0/21 3333 -> unknown > 193.0.0.0/21 4444 -> unknown > 193.0.7.0/24 3333 -> unknown > 192.0.0.0/16 5555 -> unknown > > or this: > > 193.0.0.0/21 3333 -> invalid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown > > ? > > You seem to be saying the second, but that wouldn't work, as a simple mistake > would make AS 3333 unreachable. And since you need to connect to the internet > in order to get a new certificate/ROA so you can connect to the internet… I think Roque was saying that the first outcome would be the case, not the second: >> If a signed object does not validate (based on whatever reason not just >> expiration), it is like if did not existed. If the ROA's EE certificate expires, then the ROA does not validate, it is like if the ROA did not exist. Which makes the first outcome, not the second. I'm not sure where you see text that implies that the second outcome would happen. We have left the idea of how fast expiration takes effect up to implementation. If the implementation immediately trashes an expired EE cert, then you lose the ROA, and the 3333 route would be "unknown". If the implementation keeps the EE cert around (until next clock chime? next sync interval? until it sees a reissue or a CRL?), then you keep the ROA, and the 3333 route would be "valid". In neither case does the 3333 route become "invalid". To get a result of "invalid" for 3333 for the /21 requires that you found a ROA that authorizes some other AS for the /21 and no ROA that authorizes 3333 for the /21. > > The NANOG link I posted says it's the first case, which would be much more > workable in practice: in that case, if a certificate expires before a new one > is installed, you lose security but not connectivity. Since that's what I think happens and what you think should happen, we're good! > > Note also that the approach suggested in RFC 6483 and Cisco and Juniper > documentation, where valid > unknown > invalid is not workable because then > can still have traffic flow towards more specific prefixes even though > they're invalid and have a very low local preference. The nice thing about > RPKI is that you can deploy it TODAY if you filter invalids with the huge > upside that you get rid of unauthorized more specifics, incurring only the > very small risk that someone creates ROAs that conflict with their > advertisements. Some people think depref-ing invalids is a safer alternative than outright dropping them. There's evidence that people are creating ROAs for their own announcement but forgetting the more specific prefixes they've sub allocated to customers, where the customer are announcing from their own AS but not doing ROAs. The ROA for the aggregate makes the customer's announcement look invalid. Or maybe that's what you mean by "get rid of unauthorized more specifics" and you think that's a good outcome. > As we've successfully run BGP for 25 years without security, that's bad, but > preferable to being unreachable. I'm not sure you'd be unreachable. In this day and age, if there's an aggregate prefix that includes yours, then you got your prefix from the holder of the aggregate. And in (most?) cases, you have connectivity to the holder of the aggregate. So you are reachable through them. (Since IAmNotAnOperator (IANAO), any remark I make about operations should be checked with someone who is.) Not reachable through your backup provider, but that's maybe not so bad. If you took their/your more specific prefix and walked and no longer have connectivity thru the aggregate holder, well, … just deserts? Speculation on my part. > > But the real issue is that this isn't written down anywhere as far as I can > tell, so we're dependent on implementers all independently coming up with the > preferred way to handle this. That's never good business for a standards > organization. I don't agree that it is not written down anywhere. I think the certificate checking and the BGP route checking are both clear in the cases you lay out. --Sandy, speaking as regular ol' member
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
