Hi, On Wed, 29 Sept 2021 at 17:27, George Tasioulis <[email protected]> wrote: > Shouldn’t blackholing precede RPKI validation so that the “invalid” /32 > announcement doesn’t matter?
If the upstream does RTBH somewhat reasonably, they will accept your BH announcements and not propagate them outside their own network (other than to select partners (e.g. IXP's) for which they have agreements in place to permit the redistribution of RTBH prefix announcements) RPKI validation SHOULD NOT be performed against RTBH announcements from your network to your upstream. The existing ROAs COULD be used to create a prefix list to validate your RTBH announcements against. (e.g. use IRRd as the backend database that combines ROA and IRR data into a combined dataset that can be used to generate prefix-lists) > What do you think about their suggestion to add a second ROA with maxLength > value of /32 – what are the implications? IMHO, the suggestion SHOULD be avoided. Adding a ROA with maxLength (v4) /32 and "only" (regularly) announcing with a length between (e.g.) /16 - /24 is against current BCP. Creating specific ROAs with MaxLength /32 - /32 is infeasible, too, and needlessly is unnecessary data added into the ROA database. As per the comment in [0] "According to RFC 7115, operators should be conservative in use of maxLength in ROAs. For example, if a prefix will have only a few sub-prefixes announced, multiple ROAs for the specific announcements should be used as opposed to one ROA with a long maxLength. Liberal usage of maxLength opens up the network to a forged origin attack. ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP." Forging an AS-path is sadly very easy, if you can find an upstream that allows this. Resulting in following the advice from your upstream _potentially_ opens up for your ip space to be the victim of as-path forgery from a malicious actor down the road (future). On the other hand, creating one /32 ROA certificate per IPv4 address you "own" the rights to is needlessly tedious and IMO unnecessary data that does not add "value" for you. Other that having that much ROA certificates (aka. data) to maintain. In short, I would strongly recommend *against* following this advice of creating 'secondary ROAs' with maxLength (IPv4) /32. [0]: https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html [1]: https://www.rfc-editor.org/rfc/rfc7115.html (aka. BCP 185) -- Chriztoffer
