Re: [Sidrops] [routing-wg] misconceptions about ROV

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 22 February 2022 09:19 UTC

Return-Path: <tim@nlnetlabs.nl>
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 C5A153A0A7D for <sidrops@ietfa.amsl.com>; Tue, 22 Feb 2022 01:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXwaVKNQVYem for <sidrops@ietfa.amsl.com>; Tue, 22 Feb 2022 01:19:35 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA28C3A0A8E for <sidrops@ietf.org>; Tue, 22 Feb 2022 01:19:34 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 2458566; Tue, 22 Feb 2022 09:19:29 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net []) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1645521568; bh=+otGNZAS2EJgJFzzI0PAUNP6KJhNz8kJ1nL/QU9KBEw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JOs32H4Ew2lulY/jE76F5Q4CZ4Ra0XS3Liy7tgOOIsaIGdWt5Yl3bULRC5Dj5+DDn Oy3NqggTMjsHGhMPFhCeQTd0RPw508DebLvMM5p/Kzz+LB5Z8zrZ8MXWTzg7CefLMe kZTy76Ji50+HdbpYoROob/I+E5QVf6IP12AWwZgB9AwN9ChQruiRaYU+qydJ0V9Rw0 yRrkYs3GjCKrJTjy+RmqAtzaSECczf8tkjolaB4pAdxffxh/uQpr/AWiF3/m+LYA+B vK59a+RQDGsqlwx7MT3/qiCnl56I9GvdS/5hq+gAsVC6MGehpT6TzmUBaPySxP+yG+ B5LJv/i4eX5Bw==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <015C9C28-4230-40D8-A9F2-7420B726C00F@juicybun.cn>
Date: Tue, 22 Feb 2022 10:19:23 +0100
Cc: Randy Bush <randy@psg.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF148DA2-C94D-42BF-A37F-668D9B37860B@nlnetlabs.nl>
References: <m2h78roqbp.wl-randy@psg.com> <7FBC2063-2404-4BF9-836E-210629C4BA63@juicybun.cn> <m28ru3ofyq.wl-randy@psg.com> <3C18BA8C-FA34-4D24-96E4-F85644089513@nlnetlabs.nl> <015C9C28-4230-40D8-A9F2-7420B726C00F@juicybun.cn>
To: Di Ma <madi@juicybun.cn>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sPxfOF2ZZLStNHA3wM55rEqWMhM>
Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 22 Feb 2022 09:19:40 -0000


> On 22 Feb 2022, at 09:51, Di Ma <madi@juicybun.cn> wrote:
> 
> Tim,
> 
> It seems to be a good idea to do signaling and have a sort of signed object for policy indicator :-)

I think we need a model where we can have valid/invalid/not-found (or equivalent) for paths.

Then we people can turn validation on with much less risk, and people can start implementing
BGPSec on their routers independently with more immediate (albeit initially small) benefit.

If and how we can get there is another matter. Perhaps a signed policy indicator (presence of
router certs?) will help, but it may not be enough.

Note that all this is orthogonal to ASPA. ASPA essentially says whether paths are plausible,
and BGPSec (valid path) says what actually happened. Though if ASPA informs that an adjacency
is invalid then this could perhaps be valuable input to BGPSec path validation with regards
to downgrade detection.

Tim


> 
> Di
> 
>> 
>> All that said, if we could have a constructive discussion about solving
>> the BGPSec deployment challenges then I would welcome it very much. Perhaps,
>> it would be possible to signal (with signed objects in the RPKI) when
>> BGPSec is applicable - and when a downgrade has happened.. somehow? No, I
>> don't have the answer but we may want to put our minds together.
>> 
>> Tim
>> 
>>> 
>>> randy
>>> 
>>> _______________________________________________
>>> Sidrops mailing list
>>> Sidrops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops