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

Comments In-Line.

Thanks,
              Jim Uttaro

From: Robert Raszuk <robert@raszuk.net>
Sent: Monday, November 15, 2021 4:18 AM
To: idr@ietf. org <idr@ietf.org>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com>; UTTARO, JAMES <ju1738@att.com>; Bruno Decraene <bruno.decraene@orange.com>
Subject: Re: [Idr] I-D Action: draft-wang-idr-bgp-error-enhance-00.txt

All,

Question and two observations.

Q: What's better - swiss cheese reachability or no reachability ? There seems to be a group of folks who think that partial reachability is better then no reachability. Well as I mentioned earlier I am not one of them.
[Jim U>] It is not about partial reachability but the possible change in reachability over some given time period. An AFI/SAFI that may be frequently exchanging state that changes the “correctness” of a given VPN/GRT i.e IPV4, IPV6 are not candidates for LLGR ( My Opinion ). Kompella VPLS VPN that relies on BGP to exchange VE-IDs ( Anchor Points ) for Data Plane learning or Flowspec are candidates for maintaining forwarding state in the event of a control plane failure as the reachability is relatively static thus the “correctness” is also static and controlled by the operator.

Some AFI/SAFIs are clearly not i.e IPV4, IPV6, and then there are those that an operator has to make a judgement call on what is most important to their customers i.e EVPN, VPNV4 etc.. EVPN introduces additional considerations.

My question to the authors is which FOUs does this draft apply to? Do they believe that different AFI/SAFIs should be treated differently? BGP is a general purpose routing protocol and any draft that proposes a blanket approach is not in sync with how BGP is used today.

O1: The fundamental issue with the proposed text is the attempt to ignore malformed NLRI in the MP_REACH/MP_UNREACH and still keep the TCP session up. IMO that's not acceptable as we do not even know if we can parse anything else in a given UPDATE msg or even subsequent UPDATE messages. BGP sends incremental updates. Maybe we could force full refresh to check if the issue repeats itself upon such an event and only then send NOTIFICATION ?

O2: The root cause here seems to be running BGP on a TCP session. Imagine if each UPDATE message came on it's own independent session (TCP or UDP) we would not have this issue at all. I think if we are to improve BGP resilience we should be heading that way. And yes this would be a major change to how BGP operates. It's almost at the BGP session layer comparable to shift from circuit switching to packet switching in the transport.

Thx,
Robert.

On Mon, Nov 15, 2021 at 10:02 AM <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
> From: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
> Sent: Saturday, November 13, 2021 2:04 AM
>
> On the DDOS thing, it's when the malformed update keeps coming each time
> the session restarts. up, down, up, down.....
> How about a shutdown-and-stay-down option?

If you are referring to my email, same comment: may work, or may not work so well. E.g.
- when the malformed BGP update is received from all redundant BGP sessions and the BGP sessions carry important prefixes you ends up removing all paths for many NLRIs. Possibly a larger DOS.
- when the DOS source has equal capability to send the error over the alternate/backup BGP sessions

Again, I'm not trying to say that nothing can be done. I'm trying to say that this may be more complex than saying "my peer is too buggy to be allowed to (have its BGP session) live". At minimum, there is a large chance (50% at first order) that the bug is on the receiver's/your side.

If you are referring to Jim's email, yes LLGR has an opportunity to shutdown-and-stay-down while keeping the routes before the error. It's also not free but at least it tries to mitigate the consequences of its decision to close the session (keep the route and de-preference them).

Regards,
--Bruno

> Regards,
> Jakob.
>

Orange Restricted

> -----Original Message-----
> From: UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>>
> Sent: Friday, November 12, 2021 4:17 AM
> To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>; idr@ietf. org
> <idr@ietf.org<mailto:idr@ietf.org>>
> Cc: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> Subject: RE: [Idr] I-D Action: draft-wang-idr-bgp-error-enhance-00.txt
>
> Could the authors articulate the higher level goals of this draft?  LLGR covers the
> goal of maintaining state when there are failures in the BGP control plane. Each
> operator can determine which services are candidates. My approach is to use this
> functionality for AFI/SAFIs that convey "state" that is static and internal to my
> network. Examples include Kompella and FlowSpec. VPNV4 is being considered
> as maintaining a customers VPN outweighs an incorrect specification that may
> occur while the control plane is down..
>
> Could you describe the FOUs for this proposal. Is it all AFI/SAFIs?
>
> Thanks,
>       Jim Uttaro
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
> Sent: Friday, November 12, 2021 5:07 AM
> To: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>
> Cc: Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>; Robert Raszuk
> <robert@raszuk.net<mailto:robert@raszuk.net>>
> Subject: Re: [Idr] I-D Action: draft-wang-idr-bgp-error-enhance-00.txt
>
> Not speaking about this draft. Not disagreeing with Jakob, but providing another
> consideration.
>
> Jakob's point is valid _assuming_ that the alternate path is not experiencing
> exactly the same situation (same perceived BGP error).
>
> We had multiple cases where such assumptions is wrong:
> - unrecognized transitive attributes: error are discovered on all downstream nodes
> - interop issues including squatting on code points, including different draft/WG
> squatting on the same code point: the route is propagated while crossing a single
> vendor and hence all downstream reacts to the same (perceived) error and each
> downstream see the same error on all redundant paths
> - plain bug on a implementation: all nodes of this implementation will see the error,
> while obviously all upstream nodes saw no error and propagated the route.
>
> So not disagree with Jakob, I also believe that deciding to make the problem
> bigger (e.g. shutting down the whole BGP session for a single attribute/NLRI) is to
> be seriously considered. And in addition to plain error/bugs, this can also be used
> as a DOS attack.
>
> On a side note, the implementer/implementation not been happy with a received
> route/attribute is quasi always assuming that the error is on the sender side and
> then he/it is right to take a decision. Well eventually, it's the receiver/you which/who
> is wrong. So in addition to been cautious (above point) I would also call for been
> humble.
>
> So thanks again for RFC 7606.
>
> Regards,
> --Bruno
>
>
> Orange Restricted
>
> > -----Original Message-----
> > From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Jakob Heitz (jheitz)
> > Sent: Friday, November 12, 2021 1:43 AM
> > To: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>
> > Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> > Subject: Re: [Idr] I-D Action: draft-wang-idr-bgp-error-enhance-00.txt
> >
> > There is another consideration.
> > Black holes.
> > A router that incorrectly withdraws can be mitigated by redundant routes.
> > A router that incorrectly advertises cannot be mitigated against.
> > It will spread a corrupted route around the network and cause black holes.
> > Redundancy is ineffective against black holes.
> > This is especially disruptive in a Clos network, because of the dense
> connectivity.
> > A rogue route from just one router can disrupt the whole fabric.
> >
> > For this reason, I say, if you cannot be sure of the prefix, then kill the session.
> > It is a fallacy to try to keep faulty equipment partially working at all costs.
> > If in doubt, kill it.
> >
> > Specifically:
> > ---
> > 3.1.  Prefix Length Error
> >
> > If the length is wrong, it may be a previous length that was wrong
> > and the bytes being interpreted as a length field are actually
> > something else. Bottom line, the whole NLRI field cannot be trusted.
> >
> > ---
> > 3.2.  Appears More Than Once
> >
> > How do you know which one is wrong?
> > I could accept treating all of them as withdraw assuming they
> > can be parsed correctly.
> >
> > ---
> > 4.2.  MP_REACH_NLRI
> >
> > If the nexthop length is wrong, I could accept to parse the prefixes
> > and if the MP_REACH_NLRI is otherwise not in error, threat all
> > the prefixes as withdraw. To ignore would risk advertising incorrect routes.
> >
> > Regards,
> > Jakob.
> >
> >
> > -----Original Message-----
> > From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Enke Chen
> > Sent: Wednesday, November 10, 2021 9:08 PM
> > To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> > Cc: idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>
> > Subject: Re: [Idr] I-D Action: draft-wang-idr-bgp-error-enhance-00.txt
> >
> > Hi, Folks:
> >
> > I have several comments on the draft, and some of them are similar to
> > Robert's.  More specifically,
> >
> > ---
> > On 3.1: Prefix Length Error:
> >
> > >>
> >    According to [RFC7606], when a NLRI/UNLRI or MP_REACH_NLRI/
> >    MP_REACH_UNLRI with invalid length, eg, IPv4 Prefix length is more
> >    than 32, we must drop this Prefix and ignore the following Prefixes.
> >    We may keep the prefixes we have parsed correctly before.
> > >>
> >
> > This is not correct.  Regarding NLRI parsing, RFC 7606 does not relax the
> > error handling specified in RFC 4271:
> >
> >    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.
> >
> > In RFC 7606, we have clarified the "Syntactic Correctness of NLRI Fields"
> > in Sect. 5.3, and also emphasized the fundamental requirement or using
> > "treat-as-withdraw":
> >
> >     o j. Finally, we observe that in order to use the approach of "treat-
> >        as-withdraw", the entire NLRI field and/or the MP_REACH_NLRI and
> >        MP_UNREACH_NLRI attributes need to be successfully parsed -- what
> >        this entails is discussed in more detail in Section 5.  If this
> >        is not possible, the procedures of [RFC4271] and/or [RFC4760]
> >        continue to apply, meaning that the "session reset" approach (or
> >        the "AFI/SAFI disable" approach) MUST be followed.
> >
> > ---
> > On 3.2 Appears More Than Once
> >
> >     Again we want to make sure NLRIs are parsed correctly and fully.  It's
> >     difficult to know for sure when there are multiple MP_REACH_NLRI
> >     attributes or the MP_UNREACH_NLRI in one UPDATE message.
> >
> > ---
> > On 4.1 Nexthop
> >
> >     As currently defined in RFC 4271, the procedure does not allow for graceful
> >     recovery from the error conditions, e.g,, after the duplicate
> > address is removed
> >     from an interface. There seems to be room for improvement, perhaps in a
> >     separate document.
> >
> > ---
> > On 4.2 MP_REACH_NLRI:
> >
> >     Again, we must make sure the NLRIs are parsed correctly and fully. That
> >     is fundamental to the error handling specified in RFC 7606.
> >
> > ---
> > On 4.3 Prefix SID
> >
> >     *If* there is an issue with the error handling in RFC 8669, then rfc8669bis
> >      would be more appropriate for making the correction, IMO.
> >
> > ---
> > On 4.4 Aggregator, AS4_Aggregator:
> >
> >       Why does it matter?
> >
> > ---
> > On 4.5 ORIGINATOR_ID
> >
> >      "Treat-as-withdraw" would be more disruptive, isn't it? That would contrary
> >       to the goal of the draft. I don't see a need for the change.
> >
> > ---
> > On 4.6 Cluster-list
> >
> >      Did we ever define zero as an invalid CLUSER_ID? I do not recall
> > we did that,
> >      and I don't see a need for doing so now.
> > -----
> >
> > Thanks.  -- Enke
> >
> > On Sun, Oct 24, 2021 at 6:47 AM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
> > >
> > > Dear Authors,
> > >
> > > Below are my comments after review of your proposal.
> > >
> > > 1) There is no such thing as "MP_REACH_UNLRI" ... Please swap all
> occurances
> > to "MP_UNREACH_NLRI". Likewise please adjust all "UNLRI" or define a priori
> what
> > you mean by this abbreviation.
> > >
> > > 2)  Section 3.1 -
> > >
> > > You say:
> > >
> > > "Then we may also try to continue parse the next update packet if we can
> > correctly find it."
> > >
> > > I don't think this is a good suggestion for the Standards track document.
> > >
> > > 3)  Section 3.2 -
> > >
> > > I disagree with the suggestion. If a speaker is sending more than one
> > MP_REACH_NLRI or MP_UNREACH_NLRI it should be cut out as soon as
> > possible from causing more damage.
> > >
> > > 4) Section 4.1 -
> > >
> > > I am not sure why there is any need to enumerate the same specific special IP
> > addresses and not to list others. For example if I receive IPv4 next hop as
> > 127.0.0.1 is this cool ?
> > >
> > > I recommend editing this:  "f) The IP address is not a invalid ip address." I
> think
> > you mean to say:  "f) The IP address is not a valid ip address."
> > >
> > > 5) Section 4.2 -
> > >
> > > I don't think this is a good suggestion.  Likewise in the case  of same prefix
> > being present in both MP_REACH_NLRI and MP_UNREACH_NRLI suggestion to
> > "firstly process the Prefixes in the MP_REACH_NLRI then process the Prefixes
> in
> > the MP_REACH_UNLRI" is not good.
> > >
> > > 6) Section 4.3 -
> > >
> > > How can you treat it as withdraw something which is part of the "malformed
> > prefix-SID attribute" ?
> > >
> > > 7) Sections 4.4 & 4.5 & 4.6 -
> > >
> > > Why are you suggesting again to check and detect special cases of *only* all
> > zero addresses ? There are lot's of special IPv4 or even more IPv6 addresses to
> > detect. I am not sure if we need to educate implementers about those in the BGP
> > spec.
> > >
> > > Conclusion:
> > >
> > > If WG agrees that there are some valid suggestions in your proposal we
> should
> > issue a RFC7606bis and not separate draft updating it like you are suggesting.
> So
> > far to me like there is no substance to even go for -bis version of 7606.
> > >
> > > Yes, the BGP-4 protocol running on TCP is not bullet proof when it comes to
> > handling bad implementations or malicious protocol attacks. Your figure 1
> > illustrates this well. But even with all suggestions listed there still remains lot's of
> > attack vectors if someone has access to inject bad BGP packets to your
> network.
> > >
> > > I think we should consider using new transport which no longer runs on TCP
> and
> > essentially not only treats all SAFIs as fully independent streams but also cut's
> > interdependencies between all NLRI even with given SAFI.
> > >
> > > Good news is that some proposals in this direction are starting to pop-up in
> this
> > WG, IMO already opening new doors for the new (hopefully much more robust)
> > BGP version.
> > >
> > > Many thx,
> > > Robert
> > >
> > >
> > >
> > > On Sun, Oct 24, 2021 at 2:06 PM <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:
> > >>
> > >>
> > >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > >>
> > >>
> > >>         Title           : Revised Error Handling for BGP Messages
> > >>         Authors         : Haibo Wang
> > >>                           Ming Shen
> > >>                           Jie Dong
> > >>         Filename        : draft-wang-idr-bgp-error-enhance-00.txt
> > >>         Pages           : 8
> > >>         Date            : 2021-10-24
> > >>
> > >> Abstract:
> > >>    This document supplements and revises RFC7606.  According to RFC
> > >>    7606, when an UPDATE packet received from a neighbor contains an
> > >>    attribute of incorrect format, the BGP session cannot be reset
> > >>    directly.  Instead, the BGP session must be reset based on the
> > >>    specific problem.  Error packets must minimize the impact on routes
> > >>    and do not affect the correctness of the protocol.  Different error
> > >>    handling methods are used.  The error handling methods include
> > >>    discarding attributes, withdrawing routes, disabling the address
> > >>    family, and resetting sessions.
> > >>
> > >>    RFC 7606 specifies the error handling methods of some existing
> > >>    attributes and provides guidance for error handling of new
> > >>    attributes.
> > >>
> > >>    This document supplements the error handling methods for common
> > >>    attributes that are not specified in RFC7606, and provides
> > >>    suggestions for revising the error handling methods for some
> > >>    attributes.  The general principle remains unchanged: Maintain
> > >>    established BGP sessions and keep valid routes updated.  However,
> > >>    discard or delete incorrect attributes or packets to minimize the
> > >>    impact on the current session.
> > >>
> > >>
> > >>
> > >> The IETF datatracker status page for this draft is:
> > >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-idr-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-wang-idr->
> bgp-error-enhance/__;!!BhdT!xVSA3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-
> Yyt0Dp5IPcAJNIDCK3A$
> > >>
> > >> There is also an htmlized version available at:
> > >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-wang-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-wang->
> idr-bgp-error-enhance-00__;!!BhdT!xVSA3jr29MgQ-
> ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJOGmWECE$
> > >>
> > >>
> > >> Internet-Drafts are also available by anonymous FTP at:
> > >> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-<https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet->
> drafts/__;!!BhdT!xVSA3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-
> Yyt0Dp5IPcAJBaeBJzQ$
> > >>
> > >>
> > >> _______________________________________________
> > >> I-D-Announce mailing list
> > >> I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
> > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i-d-<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d->
> announce__;!!BhdT!xVSA3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-
> Yyt0Dp5IPcAJxaUUpHE$
> > >> Internet-Draft directories:
> https://urldefense.com/v3/__http://www.ietf.org/shadow.html__;!!BhdT!xVSA3jr29M<https://urldefense.com/v3/__http:/www.ietf.org/shadow.html__;!!BhdT!xVSA3jr29M>
> gQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJjm-9obU$
> > >> or https://urldefense.com/v3/__ftp://ftp.ietf.org/ietf/1shadow-<https://urldefense.com/v3/__ftp:/ftp.ietf.org/ietf/1shadow->
> sites.txt__;!!BhdT!xVSA3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-
> Yyt0Dp5IPcAJ8-8NHvY$
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.org<mailto:Idr@ietf.org>
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> 3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVS
> > oW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-
> >
> QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=SI6tanfZVs9gnmPKxxAheSBJdycZtcV
> >
> WA5R6ub0TPz0&s=Kx7piVPCBN7qQf0IR_Ue8GQC2a_BNjdKR_7ybyNWWBc&e=
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org<mailto:Idr@ietf.org>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS>
> A3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJT-k3FIg$
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org<mailto:Idr@ietf.org>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS>
> A3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJT-k3FIg$
>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org<mailto:Idr@ietf.org>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS>
> A3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJT-k3FIg$

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.