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

From: Gyan Mishra <[email-masked]>
Date: Thu, 2 Dec 2021 18:24:38 -0500

Robert

I agree that is a good idea to look at other transport mechanisms other
then TCP.

Especially from the issue brought up by Job and others related to the TCP
stuck state that resulted in a major Internet outage.

I think separation of BGP from TCP as TCP is part of the management plane
is a good well worthwhile effort if it can be made feasible such as over
QUIC or other transports.

Kind Regards

Gyan

On Sun, Oct 24, 2021 at 9:47 AM Robert Raszuk <[email-masked]> 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 <[email-masked]> 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
>> [email-masked]
>> 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
>>
> _______________________________________________
> 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*