I measured the responsiveness of the RPKI system in the transitions of good to bad and bad to good a few years ago.
See https://www.potaroo.net/presentations/2020-06-24-rpki.pdf tldr; - invalid to valid takes about 5 minutes to propagate but valid to invalid takes around 30 minutes. Which as a DDOS mitigation tool is a pretty crap response! Geoff > On 23 May 2024, at 4:18 PM, Lincoln Dale <[email protected]> wrote: > > You can look up any entries. So maybe go look at what others do. > > For example, we do use maxlength 24 even on 3.0.0.0/10. > https://rpki-validator.ripe.net/ui/3.0.0.0%2F10/16509 > We do have automated things that will announce more specifics if there is a > hijack, so we do want that in place. That may not be what everyone does, but > is e.g. a counterpoint to how it can be done. > > > > On Thu, May 23, 2024 at 4:09 PM Joseph Goldman <[email protected]> wrote: > Hi Phil, > > Thanks - I 100% understand the point of best practice of not using maxLength > and the potential for hijacking, what im most worried about is the statement > i've been told about 'unused' ROAs affecting used ROAs, which just seems > counter-intuitive to me, in terms of (as per the example given) having ROAs > ready for failover or TE purposes. > > This is the RFC im referring to: > > https://datatracker.ietf.org/doc/html/rfc9319 > > Specifically 5.1 which indicates having dormant ROAs available for use, but I > am being told having any dormant ROAs is grounds for all routes to be marked > invalid based on stricter validators, which is the answer im trying to > ascertain right now. > > In a failover sense, say for example I am advertising /22 out of my Brisbane > POP and some /24's out of my Sydney POP, my Sydney POP goes down and im no > longer originating those /24's, by what i've been told my /22 would now > become invalid on next check as my /24's are not being advertised, even > though I have ROAs for the /22 and /24's. > > I believe i've been given somewhat wrong information but they were basing it > off experiences with other APNIC members, I just dont want to end up in a > position where our routes are dropped after implementing our ROAs, and > maintain flexibility to not wait multiple hours before we can advertise a new > prefix if required. > > Thanks, > Joe > > ------ Original Message ------ > From: "Phil Mawson" <[email protected]> > To: "Joseph Goldman" <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: 23/05/2024 3:52:54 PM > Subject: Re: [AusNOG] Experiences with RPKI > >> Hi Joe, >> >> First up, well done on working on your RPKI roll out. Signing your own >> routes is the most important step you can take to protect your own network. >> >> In regards to using max length, I do advise against that as what it means >> someone can still hijack one of your un-advertised routes and it would be >> treated as real. >> >> IE: If you advertise and sign a /19, but have a ROA created for each route >> up to a /24. If you are not advertising all of those, a third party could >> advertise one of our /24s and spoof your ASN and it would be treated as >> valid on the internet. >> >> APNIC portal make it very easy to create ROAs for your own routes as it has >> the route table view so it can see what is already publicly advertise. I >> recommend looking at that and then signing routes based on that. >> >> DDoS mitigation providers and ROAs is an interesting topic and not sure the >> community can agree on what is the best technical solution for that. >> >> Regards, >> Phil >> >> >>> On 23 May 2024, at 3:46 PM, Joseph Goldman <[email protected]> wrote: >>> >>> G'day list, >>> >>> In the process of rolling out RPKI - and while I thought I had a good >>> grasp on everything, there is one niggling piece of information that I've >>> come against and can't verify. Was hoping people can share their >>> experiences. >>> >>> We are only doing our ROA's to begin with and not implementing validation >>> until later, the initial thought was to create an ROA for all our >>> 'supernets' and use maxLength to 24 to help cover any prefix we may want to >>> advertise. We are a much simpler setup, single AS only and we do advertise >>> many of our ranges down to /24 but not all of them. I do know of the best >>> practices of not using maxLength based on a draft rfc doc, but I am >>> personally not super concerned for our relatively small use-case to the >>> issues brought up in that doc. >>> >>> Where I have come into trouble is a source (APNIC helpdesk) indicating >>> that if we have any ROAs that exist for prefixes we are not directly >>> advertising - it may lend some validators to mark all our routes as invalid? >>> >>> i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently >>> advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' >>> in that we are not advertising those specific resources - would that cause >>> issues with strict validators out in the wild? >>> >>> My understanding reading through the RFC's is this should not be the case. >>> If any ROA that matches the prefix for the origin AS exists it should be >>> valid, regardless of other ROAs signed by the same resource holder etc. >>> >>> Matching ROAs to exact advertisements is great, but it seems to lend >>> itself to much less flexibility in traffic engineering and failover >>> scenarios - a good scenario is having dormant /24 ROAs for say a DDoS >>> mitigation service to use when needed, so you dont have to wait for RPKI >>> propagation before scrubbing kicks in. >>> >>> Based on your experience, is having all-encompassing (using maxLength), or >>> unused ROAs an acceptable way to use RPKI or will we run into issues? >>> >>> All help appreciated :) >>> >>> Thanks, >>> Joe >>> _______________________________________________ >>> AusNOG mailing list >>> [email protected] >>> https://lists.ausnog.net/mailman/listinfo/ausnog >> >> > _______________________________________________ > AusNOG mailing list > [email protected] > https://lists.ausnog.net/mailman/listinfo/ausnog > _______________________________________________ > AusNOG mailing list > [email protected] > https://lists.ausnog.net/mailman/listinfo/ausnog _______________________________________________ AusNOG mailing list [email protected] https://lists.ausnog.net/mailman/listinfo/ausnog
