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

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> 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://datatracker.ietf.org/doc/draft-wang-idr-bgp-error-enhance/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-wang-idr-bgp-error-enhance-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>