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

[Warren Kumari <[e-mail]>]

On Sat, Sep 09, 2023 at 6:53 PM, Job Snijders <[e-mail]> wrote:

> 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? :-)
>


How about, at the end of "5.  ROA Validation", at the end of:
"Before a relying party can use a ROA to validate a routing announcement,
the relying party MUST first validate the ROA.  To  validate a ROA, the
relying party MUST perform all the validation checks specified in [RFC6488]
as well as the following additional ROA-specific validation steps."
you add: "If any of these constraints fail, the profile is deemed corrupt,
and the entire ROA should be discarded (probably after reporting an
error)." or similar.

You said: "For example, this following code is equivalent of what **all
sane validators** do:" (emphasis mine); we are trying to protect against
people who haven't thought though all of the implications. E.g:
You know that if we don't specify the above, someone will e.g accept the
first ROAIPAddressFamily and ignore additional ones ("There MUST be only
one instance of ROAIPAddressFamily per unique AFI", so if I see more, I can
just ignore them, right?!)


W

>
> 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….
>>
>