Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Job Snijders <[e-mail]>]

On Mon, Mar 06, 2023 at 11:53:11AM -0800, Randy Bush wrote:
> > But technically what is in this draft and apparently prototyped in
> > one open source implementation has a very limited (read narrow)
> > applicability.

Worth pointing out: two widely used open-source implementations and one
closed-source implementation already exist. All three interopable and
independently authored, see Appendix A of the draft.

> adding complexity and significan new code to bgp when, as you and enke
> point out, the vendors can merely flush out their tcp implementation
> where the solution is already specified.

'adding complexity' is a highly subjective assessment.

The changeset to introduce sendholdtimer in OpenBGPD's FSM is very
readable and concise: https://marc.info/?l=openbsd-tech&m=160820754925261&w=2
The above changeset has been tested against exploit code we developed,
it works.

On the other hand, the solution Raszuk and Enke advocate was broken from
the 90s until Linux Kernel 5.11 arrived, requiring a bugfix [1] that
seems of similar 'complexity' as the OpenBGPD approach.

So yes, new code somewhere in the stack will need to be added to deal
with broken remote peers that are stuck in this particular problematic
state.

Using a recently fixed Linux-specific feature certainly is one way of
doing it, but certainly not the only way.

Kind regards,

Job

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac