Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

[Brian Dickson <[e-mail]>]

On Wed, Dec 16, 2020 at 1:43 PM Jeffrey Haas <[e-mail]> wrote:

> Brian,
>
> On Wed, Dec 16, 2020 at 11:17:37AM -0800, Brian Dickson wrote:
>
> > While this is my opinion on the best way to handle it, the underlying
> facts
> > aren't arguable.
> > An AS-wide situation (stuck receivers with no TCP progress) would never
> > result in the AS sending withdrawals.
>
> For the incident in question, it's not possible for a single BGP
> implementation to decide that something AS-wide is happening.  And even so,
> auto-mitigation of this triggered by a single session on a single device
> would be unwise.
>
>
Fair enough.

Thinking a bit bigger-picture, who could or should be able to (a) detect,
and (b) respond to, a situation like this in future?
What are the pros/cons of different approaches, in terms of risk (of
accidental or malicious outages induced), or effectiveness?

I'll start:
A large network peering with another large network, is likely to have more
visibility.
If all of the sessions are stuck (but still up), that's a much stronger
indicator, and maybe that'd be a good situation when auto-reaction would be
appropriate.
Assuming the auto-reaction was limited to large peers of a large network, I
think this is less risky, and still very effective.
(There would still be a challenge of how to share this state discovery
across an ASN, but that's a more constrained problem to solve, IMHO.)




> > It has occured and can occur, ergo it needs to be handled outside of the
> > state machine proper.
>
> For the demonstrated case, a coordinated response was needed.  To some
> extent, the argument is for tooling to permit easy shutdown of sessions.
>
> Operators have plenty of provisioning machinery.  Writing up the use case
> and motivations for encouraging such a thing seems like something
> appropriate to an operational forum.
>
>
A large ASN may want a reliable, secure method of shutting down peers for
some modest duration. Is that also something to consider developing a
solution for?
Basically, a "Shoot me now, shoot me now." kind of thing.
I don't see that possible without signatures a la RPKI, but don't know if
it's something anyone would really want to have available.
The conceptual model would be that of a rapid administrative shutdown of
peering sessions, possibly with a pre-configured timer to re-enable
sessions and/or a start time?
Maybe signed with both a personal PGP key and an RPKI key, so as to have a
great deal of control over its use and trustworthiness.

Brian