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

Nick Hilliard <> Fri, 25 September 2020 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFCC83A13BC for <>; Fri, 25 Sep 2020 05:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sZvf-Msspl9T for <>; Fri, 25 Sep 2020 05:06:51 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0723A3A0997 for <>; Fri, 25 Sep 2020 05:06:50 -0700 (PDT)
Received: from crumpet.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 08PC6dYW032220 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Sep 2020 13:06:39 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] claimed to be crumpet.local
To: "Borchert, Oliver (Fed)" <>
Cc: "" <>, Keyur Patel <>, "Montgomery, Douglas C. (Fed)" <>
References: <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Fri, 25 Sep 2020 13:06:41 +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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Sep 2020 12:06:53 -0000

Borchert, Oliver (Fed) wrote on 21/09/2020 22:51:
> Hi Nick,
> Please see inline, I added an [ob] in front of my answers.
> On 9/21/20, 4:43 PM, "Sidrops on behalf of Nick Hilliard" < on behalf of> wrote:
>      >    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.
> [ob] We added that exact wording because during 108, concerns were voiced that
> [ob] implementations could interpret the absence of the community string as a
> [ob] particular validation result. To prevent this from happening this addition
> [ob] was specifically requested.

right, noted.  I missed the discussion about this in the ietf 108 
sidrops session.

> [ob] RFC 8205 clearly states that a router can differ local validation. A good
> [ob] reason for that could be a temporary resource shortage. In both cases #1 and
> [ob] #2, I would assume that the implementation follows RFC 8205.
> [ob] My understanding was always that local validation takes precedence over
> [ob] the community value.

Ben Maddison brought up implementation differences at the ietf108 
session. You're right that it's probably obvious to anyone on the 
SIDROPS WG that native BGPsec evaluation should take precedence, but 
developers or other people reading the specs may make different 
decisions because they're going to approach the document from a 
different point of view.  It would be clearer to make this explicit, 
e.g. to add a single sentence in the Deployment Considerations section 
to say:

"If the received validation state of a route differs from a BGPsec 
validation state locally computed according to [RFC8205], then the 
locally computed BGPsec validation state MUST be used and the received 
validation state MUST be ignored".

On a separate thing, getting back to ebgp stuff, the Deployment 
Considerations section says:

>    Furthermore, one can envision that the operator of a BGPsec router
>    decides to defer local BGPsec validation when a validation state
>    value is learned via iBGP or a trusted eBGP peer.

This needs to be reworded because there is no concept of "trusted eBGP" 
in rfc4360.  Maybe reword as "... when a validation state value is 
learned via BGP", and just revert to the default behaviour from 4360?

also nit:

>    Implementations MUST drop (without processing) the BGPsec path
>    validation state extended community if received over a peering
>    session where either the usage is not enabled or it is not part of a
>    BGPsec UPDATE.

s/peering session/BGP session/