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

[Nick Hilliard <[e-mail]>]

Keyur Patel wrote on 11/08/2020 19:45:
> A working group last call has been requested for 
> draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State 
> signaling”. Please reply to the list with your comments. The WGLC will end 
> on August 25, 2020.

In general, replicating validation functionality using BGP communities 
is a poor idea and from an ops point of view, it seems wiser as a long 
term objective to push vendors to support bgpsec than to implement hacks 
like this.  For this reason I don't support publication of the draft as 
an rfc.

Major issues:

1. The draft lacks a problem statement and a sunset clause.

2. Previously there's been a good deal of discussion on sidrops about 
RPKI validation state signalling.  Several problems were listed here:

> https://mailarchive.ietf.org/arch/msg/sidrops/YV1WfoxQNiwfOjtKIY1d6YJjRxM/

Most of the problems associated with validation state signalling 
identified in that email also apply to bgpsec validation state 
signalling, namely:

- crypto authentication is lost
- different and incompatible set of signalling hooks

In particular all the problems associated with RPKI validation state 
signalling over eBGP also apply to bgpsec state signalling over eBGP.

Defining this as non-transitive is a good start, but the language needs 
to change to ensure that it cannot escape an ASN.  Can I suggest the 
following text changes:

change:
>    If the router supports the extension as defined in this document, it
>    SHOULD attach the BGPsec path validation state extended community to
>    BGPsec UPDATE messages sent to BGP peers by mapping the locally
>    computed validation state into the last octet of the extended
>    community.  This SHOULD be done automatically for iBGP peers and
>    configurable for eBGP peers (see below).

to:
>    If the router supports the extension as defined in this document, it
>    SHOULD attach the BGPsec path validation state extended community to
>    BGPsec UPDATE messages sent to iBGP peers by mapping the locally
>    computed validation state into the last octet of the extended
>    community.

and change:
>    By default, routers SHOULD enable use of this
>    community on all iBGP sessions and routers SHOULD disable the use of
>    this community on all eBGP sessions.  Implementations MUST NOT send
>    more than one instance of the origin validation state extended
>    community and MUST drop (without processing) the BGPsec path
>    validation state extended community if received over an External BGP
>    (eBGP) peering session that has not be explicitly configured to
>    enable processing.

to:
>    By default, routers SHOULD enable use of this
>    community on all iBGP sessions.  Implementations MUST NOT send
>    more than one instance of the origin validation state extended
>    community, MUST NOT attach the BGPsec path validation state extended
>    community to BGPsec UPDATE messages sent to eBGP peers and MUST drop
>    (without processing) the BGPsec path validation state extended community
>    if received over an eBGP peering session.
Nick