Subject: [Idr] Discarding the UPDATE MSGs

From: Robert Raszuk <[email-masked]>
Date: Sun, 27 Mar 2022 18:43:21 +0200

Authors,

While exchanging some emails with Kaliraj I noticed something which I
believe needs to be clarified.

Your draft says:

   While
   [RFC4271] described methods to tear down BGP sessions or discard
   UPDATES after certain thresholds are exceeded, some nuances in this
   specification were missing resulting in inconsistencies between BGP
   implementations.

While in RFC427 I was only able to find text in BGP state machine stating
that when max prefix is reached peer get's disconnected.

      One reason for an AutomaticStop event is: A BGP receives an UPDATE
      messages with a number of prefixes for a given peer such that the
      total prefixes received exceeds the maximum number of prefixes
      configured.  The local system automatically disconnects the peer.

So while I am full aware on what the implementations allow you to setup as
actions when max prefix is reached I think either some other reference
needs to be provided with normative text or this draft needs to define the
exact handling of subsequent UPDATE MSGs once max prefix has been reached
while session to a peer stays up.

Thx,
Robert.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 28 Mar 2022 01:18:52 -0400

Hi Robert

I believe Section 2 provides the verbiage you are looking for

Kind Regards

Gyan

On Sun, Mar 27, 2022 at 12:43 PM Robert Raszuk <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2022 10:13:24 +0200

No it does not.

Thx,
R.

On Mon, Mar 28, 2022 at 7:19 AM Gyan Mishra <[email-masked]> wrote:

>> So while I am full aware on what the implementations allow you to
>> setup as actions when max prefix is reached I think either some other
>> reference needs to be provided with normative text or this draft needs to
>> define the exact handling of subsequent UPDATE MSGs once max prefix has
>> been reached while session to a peer stays up.
>>
>> Thx,
>> Robert.
>>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Mar 2022 10:20:24 -0400

Robert,

> while session to a peer stays up.

True to the style of RFC 4271, it's hard to find some events.  From section 6.7:

:    A BGP speaker MAY support the ability to impose a locally-configured,
:    upper bound on the number of address prefixes the speaker is willing
:    to accept from a neighbor.  When the upper bound is reached, the
:    speaker, under control of local configuration, either (a) discards
:    new address prefixes from the neighbor (while maintaining the BGP
:    connection with the neighbor), or (b) terminates the BGP connection
:    with the neighbor.  If the BGP speaker decides to terminate its BGP
:    connection with a neighbor because the number of address prefixes
:    received from the neighbor exceeds the locally-configured, upper
:    bound, then the speaker MUST send the neighbor a NOTIFICATION message
:    with the Error Code Cease.  The speaker MAY also log this locally.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2022 17:26:02 +0200

Hi Jeff,

Ok this clearly says "discards *new* address prefixes" which means MUST
parse the UPDATE MESSAGES even after max prefix is reach to check if what
is arriving is new or already accepted.

That was my understanding and Kaliraj was of the opposite opinion.

This at least to me proves that the new max inbound prefix limit draft
should spell out much more clearly what implementation MUST do as far as
handling of UPDATE MSGs from a given peer after max prefix limit is
reached.

Many thx,
Robert.

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Mon, 28 Mar 2022 18:23:15 +0000

> That was my understanding and Kaliraj was of the opposite opinion.

I was not. I replied in the other thread clarifying that I was considering ‘post-parse and pre-import policy’ only.

The opinion I was trying to state was that: because per-prefix syslog will not scale well, I did not consider it a deployable option to enhance debugging. That could be used as an attack vector itself to overwhelm the logging infra.

Reading sec 6.7 quoted below also, I don’t get the idea of ‘discarding Update msg’, as it talks about new prefixes. Though I agree - it doesn’t hurt to make the text clearer in the new draft.

Thanks
Kaliraj
From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, March 28, 2022 at 8:25 AM
To: Jeffrey Haas <[email-masked]>
Cc: Melchior Aelmans <[email-masked]>, idr@ietf. org <[email-masked]>
Subject: Re: [Idr] Discarding the UPDATE MSGs
[External Email. Be cautious of content]

Hi Jeff,

Ok this clearly says "discards new address prefixes" which means MUST parse the UPDATE MESSAGES even after max prefix is reach to check if what is arriving is new or already accepted.

This at least to me proves that the new max inbound prefix limit draft should spell out much more clearly what implementation MUST do as far as handling of UPDATE MSGs from a given peer after max prefix limit is reached.

Many thx,
Robert.

On Mon, Mar 28, 2022 at 4:20 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

-- Jeff

Juniper Business Use Only

---

From: heasley <[email-masked]>
Date: Tue, 29 Mar 2022 17:00:15 +0000

> The opinion I was trying to state was that: because per-prefix syslog will not scale well, I did not consider it a deployable option to enhance debugging. That could be used as an attack vector its…

Does it need to define what is overwhelming to syslog?  Or can it even
do so?  That is installation-specific.  Syslog is free to discard messages
that exceed its rate of logging or whatever other policy.  The security
section should mention the possibility.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Mar 2022 13:08:03 -0400

> On Mar 29, 2022, at 1:00 PM, heasley <[email-masked]> wrote:
> 

I think it's more of an operational consideration than a security consideration.

My personal distaste for features that drop routes like this is that the feature's behavior is often indistinguishable from the terrifying class of BGP bugs where routes are lost or stuck.

The best we can do in many such circumstances is for the system to keep state that it has started dropping things.  That state (perhaps in something like a yang module) may also want to have a clear command to flush the sense that things were last discarded.  Or perhaps that system simply keeps a time for last dropped.

The authors and Working Group are highly encouraged to think about what sort of management infrastructure belongs alongside codifying this long-existing feature.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Tue, 29 Mar 2022 19:30:49 +0200

Dear Jeff, WG,

On Tue, 29 Mar 2022 at 19:09, Jeffrey Haas <[email-masked]> wrote:

> >> The opinion I was trying to state was that: because per-prefix syslog
> will not scale well, I did not consider it a deployable option to enhance
> debugging. That could be used as an attack vector itself to overwhelm the
> logging infra.
> >
> My personal distaste for features that drop routes like this is that the
> feature's behavior is often indistinguishable from the terrifying class of
> BGP bugs where routes are lost or stuck.
>
> The best we can do in many such circumstances is for the system to keep
> state that it has started dropping things.  That state (perhaps in
> something like a yang module) may also want to have a clear command to
> flush the sense that things were last discarded.  Or perhaps that system
> simply keeps a time for last dropped.
>
> The authors and Working Group are highly encouraged to think about what
> sort of management infrastructure belongs alongside codifying this
> long-existing feature.

I share your concerns - I think that in the global Internet routing system
use case, often times it is best for all parties involved to have the
session reset:

- the session tear down is logged (on both sides),
- the increase in latency/throughout might alert end users who in turn
might alert one of the ISPs,
- and finally, the disappearance of traffic across the affected link in and
of itself is perhaps an event that is monitored for on either one of the
two sides; prompting the operators to remedy the route leak or config error.

Of course different operators have different perspectives on this type of
inter-business failure situation and disagree with my take.

Some might argue that “keeping as many bits flowing as possible” (at the
cost of no longer, installing new entries) is desirable. However aside from
likeliness to staleness bugs, I think it’s a can of worms when you consider
that more/less specific announcements might get lost in the “soft landing”
approach, resulting in hard to troubleshoot issues.

Capturing these trade-offs in a spec is hard.

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 29 Mar 2022 18:58:03 +0000

I agree with Job.

This is "limp along" thinking.
The world is moving to highly redundant networks.
Highly redundant networks work well only when faulty nodes die quickly and completely.
"limp alongs" or "near death, refusing to die" nodes in a highly redundant network
can attract traffic incorrectly and cause outages, thus reducing the availablity
of the entire system.

When there are multiple nodes in a network that hit max-prefix, but drop
different routes, all manner of strife can occur, including routing loops
if some of the routes are aggregates of others.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Job Snijders
Sent: Tuesday, March 29, 2022 10:31 AM
To: Jeffrey Haas <[email-masked]>
Cc: John Heasley <[email-masked]>; Melchior Ælmans <[email-masked]>; Kaliraj Vairavakkalai <kaliraj=[email-masked]>; Robert Raszuk <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] Discarding the UPDATE MSGs

Dear Jeff, WG,

On Tue, 29 Mar 2022 at 19:09, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
> On Mar 29, 2022, at 1:00 PM, heasley <[email-masked]<mailto:[email-masked]>> wrote:
>

I share your concerns - I think that in the global Internet routing system use case, often times it is best for all parties involved to have the session reset:

- the session tear down is logged (on both sides),
- the increase in latency/throughout might alert end users who in turn might alert one of the ISPs,
- and finally, the disappearance of traffic across the affected link in and of itself is perhaps an event that is monitored for on either one of the two sides; prompting the operators to remedy the route leak or config error.

Of course different operators have different perspectives on this type of inter-business failure situation and disagree with my take.

Some might argue that “keeping as many bits flowing as possible” (at the cost of no longer, installing new entries) is desirable. However aside from likeliness to staleness bugs, I think it’s a can of worms when you consider that more/less specific announcements might get lost in the “soft landing” approach, resulting in hard to troubleshoot issues.

Kind regards,

Job

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 30 Mar 2022 02:19:29 -0400

This issue reminds me of the TCP stuck 0 receive window issue where it’s
better to kill the session immediately then limp along in a half baked
state and cause a major internet outage.

Troubleshooting of course would be a nightmare for the NOC within
inconsistent clipped BGP RIB.

Kind Regards

Gyan

On Tue, Mar 29, 2022 at 2:59 PM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Job Snijders
> *Sent:* Tuesday, March 29, 2022 10:31 AM
> *To:* Jeffrey Haas <[email-masked]>
> *Cc:* John Heasley <[email-masked]>; Melchior Ælmans <
> [email-masked]>; Kaliraj Vairavakkalai <kaliraj=
> [email-masked]>; Robert Raszuk <[email-masked]>;
> idr@ietf. org <[email-masked]>
> *Subject:* Re: [Idr] Discarding the UPDATE MSGs
>
>
>
> Dear Jeff, WG,
>
>
>
> - and finally, the disappearance of traffic across the affected link in
> and of itself is perhaps an event that is monitored for on either one of
> the two sides; prompting the operators to remedy the route leak or config
> error.
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*