[RPKI] IETF draft - The Use of Maxlength in the RPKI

[Ben Maddison]

Hi Douglas,

On 02/23, Douglas Fischer via RPKI wrote:
> I don't know if this is the best forum to discuss this ...
> If not, I apologize.
> 
The SIDROPS WG list would probably be a better bet, but we can start
here!

> So far I was not aware of this draft, which already has 6 versions, and is
> heading towards the final version.
> 
> https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06
> 
> As far as I could understand, the main reason for proposing this draft is
> to enable a safe and fast way to make the security of the RPKI origin
> validation also include the cases of RTBH ads that are generally of unique
> IPs (/ 32 or / 128 ).
> 
I think that you have misunderstood the intention of the draft, and in
particular the latest version (which made substantial changes to the
section that deals with RTBH).

The point of the draft is to call attention to that fact that creating
ROAs which permit the origination of more-specific prefixes than are
usually present in the DFZ creates an attack vector that can be
exploited by hijackers.

E.g. if I create a ROA:
    41.78.188.0/22, maxLength: 24, asID: 37271
But then only originate:
    41.78.188.0/22, AS_PATH 37271

Then an attacker can announce:
    41.78.191.0/24, AS_PATH 666_37271

And will likely succeed in becoming the best path.

It was observed that this issue is particularly present in ROAs where
the issuer had made use of the maxLength field - hence the title of the
draft.

The draft also points out that because RTBH routes are typically for
much longer prefixes, operators might be tempted to use maxLength to
allow those routes to be ROV valid, and that doing so is a bad idea,
because it creates the above attack vector.

It doesn't try to propose any solution to the real issue of how ROV/RTBH
should co-exist beyond that.

If you think that any of the above could be made clearer in the current
text, please feel free to propose changes.

> Honestly, so far I am undecided as to whether this is the best methodology
> for such a solution.
> 
> Until now I was adopting (especially for route-servers) the methodology of
> further analyzing the possible status of RPKI.
> - Valid -> complements do not fit
> - Unknown -> complements do not fit
> - Invalid -> by previous ROA Date
> - Invalid -> by Later ROA Date
> - Invalid -> by ASN of Origin
> - Invalid -> for less specific mask
> - Invalid -> by more specific mask
> 
> Thus, in the route filtering tests received against Blackhole I was using
> the following logic:
> 
> If (is into AS-SET My-Customer) and \
>    (has Black-Hole-Community) and \
>    ((is IPv4 and is /32) or (is IPv6 and is /128)) and \
>    ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more
> specific)) then \
>    accept as Blackhole...
> 
> P.S.: This is a very summarized way to express the logic... I had to do
> some gymnastics to implement it... Converting RPKI JSONs belonging to each
> AS-SET to Prefix-lists.
> 
That algorithm looks mostly sensible, and roughly similar to how we
(AS37271) are planning to implement this in the next couple of months.

However, I'd like to stress that is *not* proposed in
draft-ietf-sidrops-rpkimaxlen.
Doing that would require an update to RFC6811, and I would argue
strongly against it!

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20210223/c597cfff/attachment.bin>