Re: [sidr] [Sidrops] [Technical Errata Reported] RFC8416 (7080)

Di Ma <madi@rpstir.net> Tue, 23 August 2022 02:58 UTC

Return-Path: <madi@rpstir.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52925C14CE33; Mon, 22 Aug 2022 19:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTF2aH6SEdiZ; Mon, 22 Aug 2022 19:58:13 -0700 (PDT)
Received: from out20-38.mail.aliyun.com (out20-38.mail.aliyun.com [115.124.20.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F56C14CE42; Mon, 22 Aug 2022 19:58:11 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06823001|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0426703-0.00627277-0.951057; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047212; MF=madi@rpstir.net; NM=1; PH=DS; RN=11; RT=11; SR=0; TI=SMTPD_---.OzXn0f3_1661223486;
Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.OzXn0f3_1661223486) by smtp.aliyun-inc.com; Tue, 23 Aug 2022 10:58:07 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <63DB38A9-D503-4566-92F3-21D8A3FA3D68@ripe.net>
Date: Tue, 23 Aug 2022 10:58:06 +0800
Cc: Tim Bruijnzeels <tim@nlnetlabs.nl>, Warren Kumari <warren@kumari.net>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, sidr@ietf.org, SIDR Operations WG <sidrops@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, andrew-ietf@liquid.tech, jgs@juniper.net, david@mandelberg.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1251E19B-AAAA-48BB-9C76-F76E0AA7176C@rpstir.net>
References: <20220810210643.1A9504C29D@rfcpa.amsl.com> <20220810212520.ateioe73xzawcldf@benm-laptop> <CAHw9_i+5Sy1A5Hi7NHcoQctLDBbsorPCz3y0ctDs3K7vL1j-Jw@mail.gmail.com> <6E03D553-6499-403E-B38A-6233A9DF6A9F@nlnetlabs.nl> <63DB38A9-D503-4566-92F3-21D8A3FA3D68@ripe.net>
To: Ties de Kock <tdekock@ripe.net>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/dAuGsVfz0jljoxGQ1W-xZyAQex8>
Subject: Re: [sidr] [Sidrops] [Technical Errata Reported] RFC8416 (7080)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2022 02:58:17 -0000

I have got no objection to this erratum as the co author of RFC8416. Thanks go to Ben for catching this. 

And this update will not affect RPSTIR2 as we check it.

Anyway, I think this discussion will help to update SLURM in support of ASPA in next version as Tim mentioned.

Di

> 2022年8月22日 16:47,Ties de Kock <tdekock@ripe.net> 写道:
> 
> Hi Tim, all,
> 
>> On 22 Aug 2022, at 10:29, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
>> 
>> Hi Warren, all,
>> 
>> I (co-author) agree that this was an oversight. I have no objections to the change.
>> 
>> However.. I haven't checked, but beware that current implementations might fail to parse the file if a "comment" member is added here, if they are (overly) strict. I expect that most will simply ignore this member. Perhaps it's wise that this is verified before finalising the errata.
> 
> I checked two implementations. The (archived) RIPE NCC validator accepts a
> comment field in bgpsecAssertions. StayRTR does not parse the bgpsecAssertions
> structure and I expect it to ignore additional attributes.
> 
> However, if there are any compliant implementations, following section 3.1,
> they would not accept a file that incorporates that follows the change proposed
> in this erratum:
> 
> > ... An RP MUST consider any deviations from the specifications to
> > be errors.
> 
> I think we need to keep this in mind when discussing this erratum.
> 
> Kind regards,
> Ties
>> 
>> Tim
>> 
>>> On 21 Aug 2022, at 17:57, Warren Kumari <warren@kumari.net> wrote:
>>> 
>>> 
>>> Dear SIDROPS, at al,
>>> 
>>> I believe that this Errata is correct, and I intends to mark it Verified unless I hear a clear objection by this Friday (August 26th).
>>> 
>>> W
>>> 
>>> 
>>> 
>>> On Wed, Aug 10, 2022 at 5:25 PM, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org> wrote:
>>> Adding sidrops@
>>> 
>>> On 08/10, RFC Errata System wrote:
>>> 
>>> The following errata report has been submitted for RFC8416, 
>>> "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
>>> 
>>> -------------------------------------- 
>>> You may review the report below and at: 
>>> https://www.rfc-editor.org/errata/eid7080
>>> 
>>> -------------------------------------- 
>>> Type: Technical 
>>> Reported by: Ben Maddison <benm@workonline.africa>
>>> 
>>> Section: 3.4.2
>>> 
>>> Original Text 
>>> ------------- 
>>> The above is expressed as a value of the "bgpsecAssertions" member, as an array of zero or more objects. Each object MUST contain one each of all of the following members:
>>> 
>>> o An "asn" member, whose value is a number.
>>> 
>>> o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
>>> 
>>> o A "routerPublicKey" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the equivalent to the subjectPublicKeyInfo value of the router certificate's public key, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
>>> 
>>> Corrected Text 
>>> -------------- 
>>> The above is expressed as a value of the "bgpsecAssertions" member, as an array of zero or more objects. Each object MUST contain one each of all of the following members:
>>> 
>>> o An "asn" member, whose value is a number.
>>> 
>>> o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
>>> 
>>> o A "routerPublicKey" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the equivalent to the subjectPublicKeyInfo value of the router certificate's public key, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
>>> 
>>> In addition, each object MAY contain one optional "comment" member, whose value is a string.
>>> 
>>> Notes 
>>> ----- 
>>> The "comment" member is allowed to appear in every other structure defined by the document, and was clearly intended to be allowed here too, since it appears in the examples presented in sections 3.4.2 and 3.5
>>> 
>>> Instructions: 
>>> ------------- 
>>> This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary.
>>> 
>>> -------------------------------------- 
>>> RFC8416 (draft-ietf-sidr-slurm-08) 
>>> -------------------------------------- 
>>> Title : Simplified Local Internet Number Resource Management with the RPKI (SLURM) Publication Date : August 2018 
>>> Author(s) : D. Ma, D. Mandelberg, T. Bruijnzeels Category : PROPOSED STANDARD 
>>> Source : Secure Inter-Domain Routing 
>>> Area : Routing 
>>> Stream : IETF 
>>> Verifying Party : IESG
>>> 
>>> _______________________________________________ 
>>> sidr mailing list 
>>> sidr@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops