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

Job Snijders <job@fastly.com> Thu, 21 September 2023 13:51 UTC

Return-Path: <job@fastly.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1DC151540 for <sidrops@ietfa.amsl.com>; Thu, 21 Sep 2023 06:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
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 4RXHw9nWcjKr for <sidrops@ietfa.amsl.com>; Thu, 21 Sep 2023 06:51:44 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 47DDBC151539 for <sidrops@ietf.org>; Thu, 21 Sep 2023 06:51:44 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-530e180ffcbso1089336a12.1 for <sidrops@ietf.org>; Thu, 21 Sep 2023 06:51:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1695304302; x=1695909102; darn=ietf.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=UXP6D17sYOY9cFqPwsQSFBmUu7z0Tq9GcplFkR/SbJc=; b=I/TjWQREdDcbb6BbAPdXFUhfnc6Hhe76dHyAAXrct+85SFJdU2hDC9mTTt4dVJJrP1 5sxoW6JWE0TfhmEGjLUqUx3t4HHRRcETMnyChkA5CChjyRul8jFi7i8MnCrQP+GMzu6H cCt6CfG2D1bzXl8Nbtx22/pQHQCk0bZzFIcsw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695304302; x=1695909102; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UXP6D17sYOY9cFqPwsQSFBmUu7z0Tq9GcplFkR/SbJc=; b=Hm1nNdPlCltDwnPkgHfET3Q0qa03DjLSjQR7y/Z/hBgKkqiHORY+TGQOuzoCUT2ymH XJmS7wV1CljxjRoIwKc8x6PIeSXKuE7phtKUKLwevDSkFpSRCA2DzMjv/1tbEfbgQgB2 btDoGQPSTmXzSfafl9Ly0rBEo1zKN2n2PowDMOpzE6g9ehuVzXTGRZXpfoPa24Ttx5a2 gAQwel66SKUzQIOPAgRG/2OQfVg2xU+q1Pd6NUWC9RVOkVMEZeni5glKr/vdUxmQP9yS foy1IwuOpCBSFeWU0W7XdTUzfDCyh54LnO3f+JPti3AwI2DuDhCe4E6X7+7h4/HVRkat 9cyQ==
X-Gm-Message-State: AOJu0YzBAAGKdsYgiPlgaj5wnKTFAKfD8Aa1UTN89ejys0WnSuQtJZsG ajUu7gkl4sPsaeb5O5yTrLePMg==
X-Google-Smtp-Source: AGHT+IHhxx1BpvfgCGeLZwy3dGj2h6yz4hE4KHv2b3nG6KNwIa2hrsVjwV5As1+itbbpElP92/jmHw==
X-Received: by 2002:a05:6402:8d2:b0:522:6e3f:b65 with SMTP id d18-20020a05640208d200b005226e3f0b65mr4503026edz.33.1695304301902; Thu, 21 Sep 2023 06:51:41 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id b10-20020aa7df8a000000b0052284228e3bsm878001edy.8.2023.09.21.06.51.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 06:51:41 -0700 (PDT)
Date: Thu, 21 Sep 2023 15:51:39 +0200
From: Job Snijders <job@fastly.com>
To: Martin Hoffmann <martin@nlnetlabs.nl>
Cc: Warren Kumari <warren@kumari.net>, SIDR Operations WG <sidrops@ietf.org>, draft-ietf-sidrops-rfc6482bis@ietf.org
Message-ID: <ZQxKa6CfbgSzpW2t@snel>
References: <CAHw9_iKi5FLrrPW2GX0SJLgWq2g802r0JcsFsbgeYnYxfOigVg@mail.gmail.com> <CAMFGGcALstVA=04kZqoVAZanAKDa0rke=QYOyv2LNsWevLWgqg@mail.gmail.com> <CAHw9_iJJwx3R9AiBcmnST7qtdmSM_WMAtVur2RXH=dsZkFscOg@mail.gmail.com> <ZQrNn4mgpA9vJijj@snel> <20230920131316.080d60b0@glaurung.nlnetlabs.nl> <ZQr5X9B3VdoZVsdf@snel> <20230921154000.52e6edd6@glaurung.nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20230921154000.52e6edd6@glaurung.nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/JVBTaOBUir2TcRjw087PXrL4e3E>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-rfc6482bis - "A Profile for Route Origin Authorizations (ROAs)"
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2023 13:51:48 -0000

On Thu, Sep 21, 2023 at 03:40:00PM +0200, Martin Hoffmann wrote:
> Job Snijders wrote:
> > On Wed, Sep 20, 2023 at 01:13:16PM +0200, Martin Hoffmann wrote:
> > > 
> > > I think it still needs to be specified in the validation section
> > > (because that section claims to exhaustively list all condition for
> > > a valid ROA) that if any of the requirements given in the Content
> > > Type section is not met, validation fails.
> > > 
> > > This is not obvious to someone with a background in IETF protocols,
> > > who would rather be inclined to salvage what’s usable.  
> > 
> > Did you mean the sentence should be at the bottom of the validation
> > section?
> 
> Not quite. I think there should be a separate bullet point a la
> 
> |  o  The ROA content fully conforms with all requirements laid out in
> |     section 4.

I see. I added another sentence:

    https://github.com/job/draft-rfc6482bis/commit/6f3073615c754fe7dab089e5e9b321ddb78bd19c

In summary: it's now been clarified that if any check fails - the entire
ROA is invalid; and that to establish whether ROA is valid or not, the
checks in section 3, section 4, the signed object template, and other
applicable RFCs must be implemented.

Kind regards,

Job