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

[Nick Hilliard <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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/

Nick