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
