Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020

Nick Hilliard <nick@foobar.org> Mon, 21 September 2020 20:42 UTC

Return-Path: <nick@foobar.org>
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 A20023A09A8 for <sidrops@ietfa.amsl.com>; Mon, 21 Sep 2020 13:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TVoTDbBwSmuh for <sidrops@ietfa.amsl.com>; Mon, 21 Sep 2020 13:42:46 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F353A09A4 for <sidrops@ietf.org>; Mon, 21 Sep 2020 13:42:45 -0700 (PDT)
X-Envelope-To: sidrops@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 08LKgdjA068415 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2020 21:42:39 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
To: "sidrops@ietf.org" <sidrops@ietf.org>
Cc: Keyur Patel <keyur@arrcus.com>
References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <b5038fc3-a25c-5b7a-63ff-c57c05355098@foobar.org>
Date: Mon, 21 Sep 2020 21:42:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.30
MIME-Version: 1.0
In-Reply-To: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/StCv4dpbLcery7jvRpwaSr-5BZg>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020
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: Mon, 21 Sep 2020 20:42:48 -0000

Keyur Patel wrote on 10/09/2020 18:27:
> The wg chairs extended the call for a week in hopes that we would have a 
> consensus. Seems like more discussion is needed and so we plan extend 
> the call for 1 more week. TheWGLCwill now end on September 17, 2020

this comment is coming a bit late in the day, but I think it would be an 
idea to clarify the behaviour of the receiving bgp side a little better.

>    A receiving BGPsec enabled router SHOULD use the received BGPsec path
>    validation state in situations where a locally computed BGPsec
>    validation result is not currently available.  In the absence of the
>    extended community, the receiving BGPsec enabled router MUST NOT make
>    any assumption about the validation sate of the UPDATE.

The second sentence is a no-op, so it would probably be better to remove it.

The draft intends that the bgp receiver treats routes with this extcomm 
as if they were locally validated by bgpsec.  The simplified state 
outcome is:

1. the receiving bgp implementation has bgpsec enabled, and has computed 
a local validation result for the incoming prefix

2. the receiving bgp implementation supports bgpsec, but has not 
computed a local validation result for the incoming prefix

3. the receiving bgp implementation does not support bgpsec.

At the moment, the text deals with case #2.  Probably what you want to 
do here is state that local validation takes preference over the 
community value.

Here's some suggested text as a replacement for the paragraph above, 
which deals with #1 and #2:

>    A receiving BGPsec enabled router SHOULD use the received BGPsec path
>    validation state in situations where a locally computed BGPsec
>    validation result is not currently available.  If a locally computed BGPsec
>    validation result is available, then the received BGPsec path validation
>    state MUST be ignored.
I'm not sure what you intend with state #3. The choices here are: SHOULD 
implement alternative policy handling mechanism, SHOULD NOT implement 
alternative policy handling mechanism, or no advice.

Some of this behaviour could be synthesised using normal policy hooks in 
the bgp stack's configuration grammar, but that would need coding and 
could be messy if there were ever future plans to support bgpsec because 
then there would be two frameworks, probably incompatible with each 
other.  It would certainly be easier for implementers to state that the 
draft is not intended for bgp stacks which don't already implement 
bgpsec.  Do the authors have any thoughts on this one?

Nick