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

Warren Kumari <> Sun, 17 September 2023 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30402C14CE5F for <>; Sun, 17 Sep 2023 10:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JxWxeetnECn7 for <>; Sun, 17 Sep 2023 10:10:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 25184C14F6EC for <>; Sun, 17 Sep 2023 10:10:24 -0700 (PDT)
Received: by with SMTP id 006d021491bc7-5734f54dc44so2281571eaf.2 for <>; Sun, 17 Sep 2023 10:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1694970624; x=1695575424;; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zcaslD6Yl9Wddz1B0LFGorxJJn4Q2jimV7zcLUlDHsE=; b=PlAvCWkQmhi0uZ2FesAdCOMUeFx0axrl3JxHWFvgZn7Wn2x4dFpQkSRZ1SIF6sEhaU Whb4/zQ+IcAYKXknWnAr0kZTvyloGvd4DMmjTFRTr7MIEtr4iGyryADAseSeGLfCxsXR IL35e+Tb/IyBU1mTdz3httyw3ViNoyYeR/1wb4QzKwGk4Ha0rohaKeW3Ee3OgoJf0nnq dLlU4SFV6M/AmmBGx2p/p59egndc2nrX7VHxHL+MSayxXPXL094kpJlr3u3F3F0sry6s Zo5jgcLb3AZsclJG8GF9Bs1RazW+JvFzxAVQIv3qcafi9L+PKpdqufsrvsGNLzsFM/fM I//w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1694970624; x=1695575424; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zcaslD6Yl9Wddz1B0LFGorxJJn4Q2jimV7zcLUlDHsE=; b=rxNALcL6RHJjiJmNY0PIMY8wiPXYzuY2KIDgEZRWpWcBgwhNzrKbMvDMIzaT0kmbU9 XPFfI/S6G/4uu2sEZykI1wshKRlredk4x1rSxMW1GyWrNoh3uCqDkfhOQ3TStsN3Ej7J xe0EeY4U97A31PaoOLKO/Q1S1FGGhCsmBiA4IngcOm0hBoaPCpoCgbrjaZ+2TNQ/u9A2 f++N+TWxunu8EW6GjFaSoXntnymjmAvYDtWgBK4/BiKhSzI3sYnZJlrgQznELlAJCXJj vjHBN0jK0Wzffot4qQ61p0QqxVqylf69sB/r9ajkg2OkWIsR8Gn5sbw65Hj2+Ad8dtge HCRw==
X-Gm-Message-State: AOJu0YzK4VBJcrHx5ibRy4KK7ur67qbCLMb8ENqjhDFtlBc5Hi0xoo9L LR7iubvw//611RDHeFbnjImuvglR7jFzgFJy+4Z8cp6FfCMoxX2l
X-Google-Smtp-Source: AGHT+IFz3YtlJV/1jnb1Z5M7ZqaARklWXG3yfbRfmehv5FMpvTMQlheSd8HDE9ze2aBo/wx5dZC798ONOY9fI43kBco=
X-Received: by 2002:a05:6358:5284:b0:13c:dc2e:3548 with SMTP id g4-20020a056358528400b0013cdc2e3548mr7661653rwa.28.1694970623517; Sun, 17 Sep 2023 10:10:23 -0700 (PDT)
Received: from 649336022844 named unknown by with HTTPREST; Sun, 17 Sep 2023 10:10:22 -0700
Mime-Version: 1.0
X-Superhuman-ID: lmnpqeim.3bf325f4-dab8-4ea6-8ad1-0946b490ba00
X-Superhuman-Draft-ID: draft000fe71989ee7844
X-Mailer: Superhuman Desktop (2023-09-15T19:29:18Z)
In-Reply-To: <>
References: <> <>
From: Warren Kumari <>
Date: Sun, 17 Sep 2023 10:10:22 -0700
Message-ID: <>
To: Job Snijders <>
Cc: SIDR Operations WG <>,
Content-Type: multipart/alternative; boundary="000000000000eb7d1c0605911976"
Archived-At: <>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-rfc6482bis - "A Profile for Route Origin Authorizations (ROAs)"
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Sep 2023 17:10:34 -0000

On Sat, Sep 09, 2023 at 6:53 PM, Job Snijders <> 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:
> 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?!)


> Kind regards,
> Job
> On Sun, 10 Sep 2023 at 07:25, Warren Kumari <> wrote:
>> Dear authors and WG,
>> Thank you for this document.
>> I only have a single comment — throughout, the document says things like:
>> S  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….