IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 22 February 2022 11:51 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 D17D13A0E77 for <sidrops@ietfa.amsl.com>; Tue, 22 Feb 2022 03:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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_LOW=-0.7, 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 RlakCc33VkSp for <sidrops@ietfa.amsl.com>; Tue, 22 Feb 2022 03:51:36 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8: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 62CD93A0E78 for <sidrops@ietf.org>; Tue, 22 Feb 2022 03:51:36 -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 A2D6851; Tue, 22 Feb 2022 11:51: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=1645530688; bh=WkLG2H4Ho3JmNvxgonnBfoApOdJ8724NFdG9A5xyIRY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mQ2+kqteT6P5YLIr+81TuDNDnr3O6Vz3ddZg2t6PdHjB+zbqcgP/rAyNHk07bytZ/ mPC5MDm+uX0ioLJ4y389VFu5PlPoPs+H84eC4F+30LEzQnE4QsRm410kTp6zgN8IlC 8hfRf1WVR9q7WpbP6TBZaVyNE1ql3BM/HoYlRwo6ed1kM+IrrAb/SLtOs86+cBla6Z dZperQjrIEzBkl6zsXJ7Q0Tl9pD48DDi67cXNaUTN27JnOlYh3RhhPT6lsAN8PdZbT /LyvkaSpARYypFkOk/WxfQvEj2bQvo62O4+EbTkSmNQeu6ZZwlqgLEHa36sn/UdrBB VwubyDzZH6gSw==
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: <YhTMeqPkBEXzo0bg@snel>
Date: Tue, 22 Feb 2022 12:51:26 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <873DCF3D-F635-402B-8CE6-F9B78C62D7E0@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> <DF148DA2-C94D-42BF-A37F-668D9B37860B@nlnetlabs.nl> <YhS/WR3czIP3jNLF@snel> <ABE3FA29-6C9D-492B-A72A-68C20176E76D@nlnetlabs.nl> <YhTMeqPkBEXzo0bg@snel>
To: Job Snijders <job@fastly.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/shD2HMkgDrXSf7dLI6GAkOuaoKg>
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 11:51:42 -0000


> On 22 Feb 2022, at 12:43, Job Snijders <job@fastly.com> wrote:
> 
> On Tue, Feb 22, 2022 at 12:38:59PM +0100, Tim Bruijnzeels wrote:
>> Currently you need to accept BGPSec invalid path on any path where at
>> least one ASN does NOT participate in BGPSec. Applying BGPSec path
>> validation is only safe when you know that ALL ASNs on the path
>> participate.
> 
> Are you perhaps confusing 'unsigned' and 'invalid' paths?

Perhaps. It was my understanding that an 'unsigned' path should be
considered 'invalid' because otherwise one can simply strip signatures
on an 'invalid' path to do a downgrade attack.

It would help a lot of that were detectable.

My RFC-searching-fu is abandoning me at the moment but any pointers
would be welcome.

> 
> Regards,
> 
> Job

v2.8.7 | Report a Bug | By Email