Re: [Idr] I-D Action: draft-wang-idr-bgp-error-enhance-00.txt

[Jeffrey Haas <[e-mail]>]

Haibo,

On Mon, Nov 15, 2021 at 03:47:46PM +0000, Wanghaibo (Rainsword) wrote:
> Our main purpose is to reduce the impact of error messages on the
> business, also to provide some clear descriptions of what was not clearly
> defined in the original RFCs.

Please make sure to highlight specifically which things you believe may not
be clearly defined in the RFCs.  If there is consensus about this, filing
Errata is an appropriate thing.

> At present, more discussion is about the NLRI’s parsing. Such as the scope
> of application raised by Jeff, it is true that the Internet has a wide
> range of applications, and this processing may not be appropriate.
> However, for other AFI/SAFIs, such as EVPN and MVPN, this processing can
> be considered. This also answers Jim's question. We focus on the
> MP_REACH/UNREACH attribute, which mainly refers to various service
> AFI/SAFIs and non-Internet services.

Please remember that even "simple" IPv6 Internet service is carried in
MP_REACH/UNREACH.

The characterization about the scope of the address family is really the
detail we will want to discuss here.  I tend to frame the problem in terms
of the "blast radius" - the damage caused by an explosion - that a protocol
fault may have.  While it is usually the case that mvpn and evpn are
"local", evpn type 5 routes may effectively pass through networks and
eventually interact with the Internet.  

Similarly, IPv4/IPv6 unicast may be used solely for private purposes.

> The integrity of the NLRI mentioned by Enke can be divided into two parts.
> First, the length of the NLRI in the MP_REACH is incorrect. This is
> described as a parsing error in RFC7606 section 5.3. However, the specific
> proceduring is not described.

The text in RFC 7606, section 5.3:

:   The NLRI field or Withdrawn Routes field SHALL be considered
:   "syntactically incorrect" if either of the following are true:

The procedure is understood from RFC 4271, section 6.3:

:   The NLRI field in the UPDATE message is checked for syntactic
:   validity.  If the field is syntactically incorrect, then the Error
:   Subcode MUST be set to Invalid Network Field.

>  It can be understood that the definition of
> RFC4760 is retained, that is, disable the NLRI’s AFI/SAFI or reset the
> session. It is also worth discussing whether it is appropriate to disable
> AFI/SAFI or reset session.

I am personally curious what implementations disable a given AFI/SAFI.

The challenge an implementation has if it decides NLRI is malformed is
whether it can find the next BGP message boundary safely.  This is part of
my microphone comments during the IDR presentation of your draft.

In the most optimistic case, a BGP Update contains a single NLRI.  In the
event that the Update is considered malformed because of the NLRI, it might
be possible to look at adjacent memory patterns to find the BGP Marker
field.  If so, an implementation may choose to "resync" the BGP messages and
continue.  I am unaware of whether any implementation does this.

(The BGP Marker is a somewhat vestigial protocol feature.  It was originally
there to cover a previous authentication feature that was not carried
forward in the protocol updates.)

> Currently, some AFI/SAFIs, such as EVPN,
> contain multiple routing types. Whether an error of one of them should
> affect the entire AFI/SAFI. 

This has been a conversational point before with our Area Director, Alvaro.
The typed NLRI has created an unfortunate additional place of fragility in
error handling.  This is just another example.  

> Whether a packet is parsed out of bounds depends on the length of the
> MP_REACH attribute, the total length of the attribute, and the total
> length of the packet to ensure that the packet does not across the bounds.
> According to Keyur's comments, TCP is flow-based. If the current packet is
> discarded, whether the subsequent packet can be parsed depends on the
> arrival of the next packet. However, this should not affect the processing
> of the current packet.

This again indirectly applies toward using the Marker to find the "next
packet".  The scenario I believe you're trying to highlight is if it is the
case that an implementation believes that all damage to an Update is
contained in a single BGP message that it may be one step "safer" to leave
the session up.

While this may be true, the real question is the blast radius of the damage
of the Update that contains malformed state.

RFC 7606 decided to consider malformed NLRI as toxic.  As we discussed
during the IDR session at this recent IETF, it will take significant
motivation to convince the Working Group to change this consensus.

> Finally, some mechanism optimizations, such as dynamic capability
> negotiation and multi-session, may be used to reduce the impact. However,
> we also need consider how to do better under the current BGP mechanism.

I urge you to note that multi-session and BGP QUIC address similar
considerations but by different mechanisms.  multi-session reduces the
"blast radius" to a separate session.  I commonly refer to this property as
"structural separation".

For BGP QUIC, the protocol supplies a missing OSI Layer 5 that has the
opportunity to change the per-message fault model.

-- Jeff