[lacnog] RPKI ROAs - Blackhole - Maximum prefix length

[Job Snijders]

On Fri, May 17, 2019 at 20:26 Douglas Fischer <fischerdouglas en gmail.com>
wrote:

> Hello Job and everyone else!
>
> After a night with that suggestions in mind, I was thinking on some
> alternatives...
>
>
> About de Orign-Validation of /32 or /128
> ----------------------------------------
> Couldn't be possible a "partial" RPKI validation on prefixes that comes
> with the community of black-hole?
>
> When i say "partial", I mean disregard LE of the mask, and only look to
> ASN<-> prefix authorization made by the owner of the prefix.
> P.S.: I remember to read something like this with IRR announces.
>
> A Simple(stupid) example:
> "If community==blackhole and prefix-mask=32 (or 128) and\
> origin-validation=conteined_inside_the_mask_announced_in_RPKI then\
> accept the prefix and put it on Blackhole action"
>
>
> Could it be considered an acceptable solution?
>


I’d say this is not a complete or acceptable solution. What happens here is
that the RPKI ROAs I publishes, are modified without my permission.

Anyone can add my ASN to their AS-SET. Now if the route server also ignores
parts of my ROA publication (by pretending maxlength is set to 32), anyone
can attempt to blackhole my IP space.

In addition to the above trivial workaround, the surrogate blackholing
method still has issues:

- for 100% effectiveness, 100% of IX participants must apply custom
configuration to that specific IX.

- a misconfiguration in one ASN can still negatively impact lots of other
ASNs (think blackholing of 8.8.8.8)

- IX participants expect blackholing to work when the service is advertised
as “blackholing”, but since you never achieve 100% cooperation, the service
will never be effective, which is somewhat misleading.

The technique you describe was first thought up in a marketing department
because they wanted to tick the boxes “rpki” and “blackholing”, and ended
up doing neither properly. They are mangling rpki based VRPs, and the
blackholing only works if all traffic sources participate in the insecure
scheme.

I maintain that in this situation it is better to do it correctly, or not
do it at all. With “in-fabric” blackholing there is no need for validation,
rpki checks, and the participant can only impact their own network, they
have no influence over other people’s blackhole routes.

Kind regards,

Job
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190517/c052b3a3/attachment-0001.html>