idnits 2.17.1 draft-wang-idr-bgp-error-enhance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 October 2021) is 909 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4760' is mentioned on line 182, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group H. Wang 3 Internet-Draft M. Shen 4 Intended status: Standards Track J. Dong 5 Expires: 27 April 2022 Huawei Technologies 6 24 October 2021 8 Revised Error Handling for BGP Messages 9 draft-wang-idr-bgp-error-enhance-00 11 Abstract 13 This document supplements and revises RFC7606. According to RFC 14 7606, when an UPDATE packet received from a neighbor contains an 15 attribute of incorrect format, the BGP session cannot be reset 16 directly. Instead, the BGP session must be reset based on the 17 specific problem. Error packets must minimize the impact on routes 18 and do not affect the correctness of the protocol. Different error 19 handling methods are used. The error handling methods include 20 discarding attributes, withdrawing routes, disabling the address 21 family, and resetting sessions. 23 RFC 7606 specifies the error handling methods of some existing 24 attributes and provides guidance for error handling of new 25 attributes. 27 This document supplements the error handling methods for common 28 attributes that are not specified in RFC7606, and provides 29 suggestions for revising the error handling methods for some 30 attributes. The general principle remains unchanged: Maintain 31 established BGP sessions and keep valid routes updated. However, 32 discard or delete incorrect attributes or packets to minimize the 33 impact on the current session. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 27 April 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. Error-Handling Procedures Update for NLRI . . . . . . . . . . 4 77 3.1. Prefix Length Error . . . . . . . . . . . . . . . . . . . 4 78 3.2. Appears More Than Once . . . . . . . . . . . . . . . . . 4 79 4. Error-Handling Procedures Update for Existing Attributes . . 5 80 4.1. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4.2. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 5 82 4.3. Prefix SID . . . . . . . . . . . . . . . . . . . . . . . 6 83 4.4. AGGREGATE and AS4_AGGREGATOR . . . . . . . . . . . . . . 6 84 4.5. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 6 85 4.6. Cluster-List . . . . . . . . . . . . . . . . . . . . . . 6 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 90 7.2. Informative References . . . . . . . . . . . . . . . . . 7 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 93 1. Introduction 95 According to RFC 4271, a BGP session that receives an UPDATE message 96 containing a malformed attribute needs to reset the session that 97 receives the malformed attribute. 99 According to our experience during maintenance, malformed packets may 100 be incorrectly encapsulated due to software bugs or mis-understanding 101 of standards in software development. Interrupting a neighbor causes 102 neighbor flapping, which does not help solve the problem. The 103 malformed packets may not be recognized by intermediate routers and 104 cannot be incorrectly checked and propagated to other routers that 105 establish sessions. When they reach the router that recognizes and 106 checks the attribute, the neighbor flapping may also occured. Even 107 because routes are propagated multiple times, a route containing 108 malformed packets may be received from multiple sessions at a 109 checkpoint, causing multiple sessions to be reset, and the harm is 110 multiplied. 112 For the preceding reasons, RFC 7606 defines a new method for 113 processing incorrect UPDATE packets. If the Update packet received 114 from a neighbor contains incorrect attributes, the BGP session cannot 115 be reset directly. Instead, the BGP session needs to be handled in a 116 specific manner based on the principle that incorrect packets affect 117 routes as little as possible and do not affect protocol correctness. 118 The error handling methods include discarding attributes, withdrawing 119 routes, disabling the address family, and resetting sessions. 121 However, the error handling methods of some common attributes are not 122 provided in RFC7606 or are different from those of vendors. This 123 document supplements the error handling methods of some common 124 attributes and provides suggestions for modifying the error handling 125 methods of some attributes. 127 2. Scenarios 129 +-----+ +-----+ +-----+ 130 | RT1 |----| RR |---| RT2 | 131 +-----+ +-.---+ +-----+ 132 | 133 \ 134 +-----+ 135 | RT3 | 136 +-----+ 137 Figure 1 A simple network 139 Figure 1 shows a simple network. When RT3 has some software bugs or 140 misunderstands the RFC, it may send a malformed packet. The RR 141 receives the packet and considers it a malformed packet according to 142 the error handling rules and resets the session. Later the session 143 between RT3 and RR is re-established. RT3 will resend the packet to 144 RR, and RR continues to repeat the previous action. This will happen 145 continuously until the operator modifies the configuration, such as 146 deleting the configuration about that new feature of the property, 147 and sometimes they don't know how to correct the problem. During 148 this process, RT3 services are unavailable. Frequent neighbor 149 reestablishment and route updating also consumes more RR's system 150 resources. 152 If the RR does not understand the attribute, the RR sends packets to 153 RT1 and RT2. RT1 and RT2 may perform the same operation as RR. As a 154 result, services between RT1 and RT2 are interrupted. 156 3. Error-Handling Procedures Update for NLRI 158 3.1. Prefix Length Error 160 According to [RFC7606], when a NLRI/UNLRI or MP_REACH_NLRI/ 161 MP_REACH_UNLRI with invalid length, eg, IPv4 Prefix length is more 162 than 32, we must drop this Prefix and ignore the following Prefixes. 163 We may keep the prefixes we have parsed correctly before. 165 Then we may also try to continue parse the next update packet if we 166 can correctly find it. 168 The NLRI/UNLRI or MP_REACH_NLRI/MP_REACH_UNLRI with invalid length is 169 malformed. 171 3.2. Appears More Than Once 173 [RFC7606] described like this: 175 If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760] 176 attribute appears more than once in the UPDATE message, then a 177 NOTIFICATION message MUST be sent with the Error Subcode "Malformed 178 Attribute List". 180 Revised suggestion: 182 If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760] 183 attribute appears more than once in the UPDATE message, only the last 184 MP_REACH_NLRI/MP_UNREACH_NLRI SHOULD be processed, the others would 185 be ignore. 187 4. Error-Handling Procedures Update for Existing Attributes 189 4.1. Nexthop 191 [RFC4271] define the IP address in the NEXT_HOP meet the following 192 criteria to be considered semantically incorrect: 194 a) It is the IP address of receiving speaker. 196 b) The IP address is not EBGP directly neighbor's address or not 197 share a common subnet with the receiving BGP speaker. 199 An update message with the case a) MAY be install to the RIB but 200 treat as invalid. 202 Whether an update message with the case b) SHOULD be considered 203 semantically incoorect depends on the user's configuration. 205 The following criteria also must to be considered semantically 206 incorrect: 208 c) The IP address is all zero. 210 d) The IP address is all one. 212 e) The IP address is multicast address(Class D) or reserved address 213 (Class E). 215 f) The IP address is not a invalid ip address. 217 An update message with the case c) to f) SHOULD be logged, and the 218 route will be treat-as-withdraw. 220 4.2. MP_REACH_NLRI 222 [RFC7606] suggest to do "session reset" or "AFI/SAFI disable" 223 approach. But this approach is too strict. 225 If the Length of Next Hop Network Address field of the MP_REACH 226 attribute is inconsistent with that which was expected, the attribute 227 is considered malformed. The whole MP_REACH attribute will be ignore 228 and try to parse the next update packet. When it cannot correctly 229 locate the next update packet, it will do the procedure suggested 230 according to [RFC7606] . Otherwise, only the error SHOULD be logged 231 and continued to do packet parsing. 233 An update message may both contained MP_REACH_NLRI and 234 MP_REACH_UNLRI. If there are same Prefixes in both MP_REACH_NLRI and 235 MP_REACH_UNLRI, the message SHOULD NOT be consider malformed. In 236 this case, it should be firstly process the Prefixes in the 237 MP_REACH_NLRI then process the Prefixes in the MP_REACH_UNLRI. 239 4.3. Prefix SID 241 According to [RFC8669], an update message containing a malformed or 242 invalid BGP Prefix-SID attribute will be ignore and not advertise it 243 to other BGP peers. But this procedure may lead to unexpected 244 results. 246 The error handling is revised to be treat-as-withdraw. 248 4.4. AGGREGATE and AS4_AGGREGATOR 250 When the router-id in AGGREGATE or AS4_AGGREGATE attibute is zero, 251 the attribute SHOULD be consider semantically incorrect, and the 252 attribute SHOULD be logged and discard. 254 4.5. ORIGINATOR_ID 256 The error handling of [RFC4456] and [RFC7606] is revised as follows. 258 When the BGP Identifier in ORIGINATOR_ID attibute is zero, the 259 attribute SHOULD be consider semantically incorrect, and the 260 attribute SHOULD be logged and the UPDATE message SHALL be handled 261 using the approach of "treat-as- withdraw". 263 4.6. Cluster-List 265 The error handling of [RFC4456] and [RFC7606] is revised as follows. 267 When the CLUSTER_ID value in ORIGINATOR_ID attibute is zero, the 268 attribute SHOULD be consider semantically incorrect, and the 269 attribute SHOULD be logged and the UPDATE message SHALL be handled 270 using the approach of "treat-as- withdraw". 272 5. IANA Considerations 274 This document makes no request of IANA. 276 6. Security Considerations 278 This document helps reduce the impact of malformed packets on the 279 network and devices. 281 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 7.2. Informative References 292 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 293 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 294 DOI 10.17487/RFC4271, January 2006, 295 . 297 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 298 Reflection: An Alternative to Full Mesh Internal BGP 299 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 300 . 302 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 303 Patel, "Revised Error Handling for BGP UPDATE Messages", 304 RFC 7606, DOI 10.17487/RFC7606, August 2015, 305 . 307 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 308 A., and H. Gredler, "Segment Routing Prefix Segment 309 Identifier Extensions for BGP", RFC 8669, 310 DOI 10.17487/RFC8669, December 2019, 311 . 313 Authors' Addresses 315 Haibo Wang 316 Huawei Technologies 317 Huawei Campus, No. 156 Beiqing Road 318 Beijing 319 100095 320 China 322 Email: rainsword.wang@huawei.com 324 Ming Shen 325 Huawei Technologies 326 Huawei Campus, No. 156 Beiqing Road 327 Beijing 328 100095 329 China 331 Email: shenming2@huawei.com 333 Jie Dong 334 Huawei Technologies 335 Huawei Campus, No. 156 Beiqing Road 336 Beijing 337 100095 338 China 340 Email: jie.dong@huawei.com