Re: [Sidrops] AD Review of: draft-ietf-sidrops-rfc6482bis - "A Profile for Route Origin Authorizations (ROAs)"

[Job Snijders <[e-mail]>]

Hi Warren,

In the RPKI world when it’s detected a “MUST” is violated, the profile at
hand is deemed corrupted, and thus validators will end up reporting errors
and ignore the entire ROA. (With “ignore” I mean, for example, no attempt
will be made to extract data from the ROA’s eContent to transform into RTR
PDUs).

For example, this following code is equivalent of what all sane validators
do:
https://github.com/openbsd/src/blob/ef485fbb74ef0027e2f1148eae1325267d3d44cf/usr.sbin/rpki-client/roa.c#L170-L190
- each “MUST” is checked, and if there is a problem of any kind the code
jumps to the error path.

The internet-draft/RFC document style so far has been to document exactly
what’s valid; and not point out at each instance that if the object data at
hand doesn’t comply with the stated conformity requirement at hand it
thusly is invalid. And indeed, the “cop-out” route is quite unattractive.

I don’t see much value in rewording each “MUST” requirement as a “TRULY
MUST”, so do you have some suggestion in mind? :-)

Kind regards,

Job

On Sun, 10 Sep 2023 at 07:25, Warren Kumari <[e-mail]> wrote:

> Dear authors and WG,
>
> Thank you for this document.
>
> I only have a single comment — throughout, the document says things like:
>
> S 4.3.2.2.  Element maxLength
> "If present, the maxLength MUST be:
>
>    *  an integer greater than or equal to the length of the accompanying
>       prefix, and
>    *  less than or equal to the maximum length (in bits) of an IP
>       address in the applicable address family: 32 in case of IPv4 and
>       128 in case of IPv6."
>
> Oh, fine. But, what happens if the maxLength is **less** than length of
> the prefix? Should implementations simply ignore this prefix? Should they
> view the ROA as invalid? Should they call the police and report it? This is
> just one example of this sort of concern, there are a bunch of similars
> ones too.
>
> I guess that the argument could be made that this document only specifies
> a profile, and that it is the responsibility of other documents to handle
> this (and other violations), but that feels like somewhat of a cop out…
>
> W
>
> P.S: I had a quick look at RFC6488, RFC9319, and a few others, and didn't
> see that particular issue handled, so I don't really know if other
> documents are addressing all of the errors….
>
>
>