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

[Robert Raszuk <[e-mail]>]

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.

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 <[e-mail]> wrote:

> > From: Jakob Heitz (jheitz) <[e-mail]>
> > 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 <[e-mail]>
> > Sent: Friday, November 12, 2021 4:17 AM
> > To: DECRAENE Bruno INNOV/NET <[e-mail]>; idr@ietf. org
> > <[e-mail]>
> > Cc: Jakob Heitz (jheitz) <[e-mail]>; Robert Raszuk <
> [e-mail]>
> > 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 <[e-mail]> On Behalf Of [e-mail]
> > Sent: Friday, November 12, 2021 5:07 AM
> > To: idr@ietf. org <[e-mail]>
> > Cc: Jakob Heitz (jheitz) <jheitz=[e-mail]>; Robert
> Raszuk
> > <[e-mail]>
> > 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 <[e-mail]> On Behalf Of Jakob Heitz (jheitz)
> > > Sent: Friday, November 12, 2021 1:43 AM
> > > To: idr@ietf. org <[e-mail]>
> > > Cc: Robert Raszuk <[e-mail]>
> > > 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 <[e-mail]> On Behalf Of Enke Chen
> > > Sent: Wednesday, November 10, 2021 9:08 PM
> > > To: Robert Raszuk <[e-mail]>
> > > Cc: idr@ietf. org <[e-mail]>
> > > 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 <[e-mail]>
> 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 <[e-mail]> 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-
> > 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-
> > 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-
> > drafts/__;!!BhdT!xVSA3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-
> > Yyt0Dp5IPcAJBaeBJzQ$
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> I-D-Announce mailing list
> > > >> [e-mail]
> > > >>
> 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
> > gQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJjm-9obU$
> > > >> or https://urldefense.com/v3/__ftp://ftp.ietf.org/ietf/1shadow-
> > sites.txt__;!!BhdT!xVSA3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-
> > Yyt0Dp5IPcAJ8-8NHvY$
> > > >
> > > > _______________________________________________
> > > > Idr mailing list
> > > > [e-mail]
> > > > 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
> > > [e-mail]
> > >
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!xVS
> > A3jr29MgQ-ZiztKwbCrN3KpbqpjfaPxEeAXb-Yyt0Dp5IPcAJT-k3FIg$
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > [e-mail]
> > >
> >
> 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
> > [e-mail]
> >
> 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.
>
>