Bird-users

Download

bird-users@network.cz

July 2026

20 participants
22 discussions

[Bug]: AS_PATH containing AS 0 is accepted, missing RFC 7607 validation
by xinzhe liu 05 Jul '26

05 Jul '26

Hello BIRD maintainers, I would like to report a possible RFC 7607 compliance issue in BIRD's BGP UPDATE validation: routes whose AS_PATH contains AS number 0 appear to be accepted into the BGP table instead of being treated as malformed. Summary BIRD appears not to reject AS 0 when it appears inside the AS_PATH path attribute. I tested this with an eBGP session where the peer sent a valid UPDATE whose AS_PATH was: 65002 0 BIRD accepted the route and displayed the AS_PATH with the reserved AS 0 still present. RFC 7607 Section 2 states that a BGP speaker must not originate or propagate a route with AS number 0 in AS_PATH, and that an UPDATE containing AS number 0 in AS_PATH must be considered malformed and handled according to RFC 7606. For a malformed AS_PATH attribute with parseable NLRI, RFC 7606 handling should be treat-as-withdraw: the route should not be installed, while the BGP session should remain established. Affected Version I reproduced this on: BIRD version 2.19.0+branch.master.880200b1f94c commit 880200b1 Observed Behavior After establishing an eBGP session, the peer sent an UPDATE for 192.0.2.0/24 with: ORIGIN: IGP AS_PATH: 65002 0 NEXT_HOP: 10.0.0.2 NLRI: 192.0.2.0/24 BIRD accepted the UPDATE. birdc show route 192.0.2.0/24 all showed: Table master4:192.0.2.0/24 unreachable [as0_test ... from 10.100.0.2] * (100) [AS0i] Type: BGP univ BGP.origin: IGP BGP.as_path: 65002 0 BGP.next_hop: 10.0.0.2 BGP.local_pref: 100 The route was marked unreachable because of next-hop resolution in the local test setup, but the important point is that the route was accepted into the BGP table with: BGP.as_path: 65002 0 I did not observe an error, warning, or treat-as-withdraw behavior for the reserved AS 0. The BIRD log showed the UPDATE being accepted: as0_test: BGP session established as0_test: Got UPDATE as0_test.ipv4 > added [best] 192.0.2.0/24 ... Expected Behavior BIRD should detect AS 0 in AS_PATH and treat the UPDATE as malformed. Since the UPDATE contains reachable NLRI and the NLRI is parseable, the expected behavior is: - do not install the route, - keep the BGP session established, - handle the route using treat-as-withdraw, consistent with RFC 7606 error handling for malformed AS_PATH attributes. Source-Level Analysis The AS_PATH decoder validates AS_PATH structure but does not appear to validate individual AS numbers against the reserved AS 0 value. In proto/bgp/attrs.c, bgp_decode_as_path() calls as_path_valid() and then stores the attribute: if (!as_path_valid(data, len, as_length, as_sets, as_confed, err, sizeof(err))) WITHDRAW("Malformed AS_PATH attribute - %s", err); ... bgp_set_attr_data(to, s->pool, BA_AS_PATH, flags, data, len); The later post-decode checks in bgp_decode_attrs() cover mandatory attribute presence, local-AS loop detection, confederation loop detection, ORIGINATOR_ID loop detection, and CLUSTER_LIST loop detection, but I could not find a check for AS 0: if (bgp_as_path_loopy(p, attrs, p->local_as)) goto loop; if ((p->public_as != p->local_as) && bgp_as_path_loopy(p, attrs, p->public_as)) goto loop; In nest/a-path.c, as_path_valid() checks segment framing, segment type, whether AS_SET / AS_CONFED_* are allowed, and zero-length segments: switch (type) { case AS_PATH_SET: if (!sets) BAD("AS_SET segment", type); break; case AS_PATH_SEQUENCE: break; case AS_PATH_CONFED_SEQUENCE: if (!confed) BAD("AS_CONFED_SEQUENCE segment", type); break; case AS_PATH_CONFED_SET: if (!sets || !confed) BAD("AS_CONFED_SET segment", type); break; default: BAD("unknown segment", type); } if (pos[1] == 0) BAD("zero-length segment", type); I did not find an equivalent validation pass that iterates through the AS numbers in the path and rejects asn == 0. Suggested Fix Add AS 0 validation during AS_PATH parsing or immediately after AS_PATH decoding. Conceptually: /* RFC 7607: AS 0 is reserved and must not appear in AS_PATH */ if (as_path_contains_as_zero(...)) WITHDRAW("Malformed AS_PATH attribute - AS 0 is reserved"); A similar validation may also be relevant for AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR, since RFC 7607 also covers those attributes. However, this report only describes the AS_PATH case that I reproduced dynamically. Impact Accepting AS 0 in AS_PATH can cause interoperability and policy issues: - routes accepted by BIRD may later be rejected by stricter BGP speakers, - AS_PATH-based filters may behave unexpectedly, - reserved-AS input is allowed into routing policy and best-path processing, - this appears inconsistent with RFC 7607's reserved-AS handling. This does not require tearing down the BGP session. Treat-as-withdraw should be sufficient and would match the usual RFC 7606 approach for malformed AS_PATH attributes. Please let me know if you would like a minimal reproducer or packet capture. Best regards, Xinzhe Liu

2 1

[Bug]: BGP: OPEN with peer AS 0 may be accepted in external accept-any mode, missing RFC 7607 validation
by xinzhe liu 05 Jul '26

05 Jul '26

Hello BIRD maintainers, ### Summary BIRD appears to miss the mandatory RFC 7607 validation for AS 0 in received BGP OPEN messages when the peer is configured in accept-any external-AS mode, including dynamic BGP peers created from a `neighbor range ... external` configuration. RFC 7607 Section 2 says that AS 0 is reserved, must not be used by a BGP speaker, and must not be accepted in a BGP OPEN message. When a BGP speaker receives an OPEN whose peer AS is 0, it must abort the connection and send an OPEN Message Error with subcode Bad Peer AS. In the tested BIRD configuration, a dynamic external peer was able to complete session establishment while claiming peer AS 0. ### Affected Configuration This issue is relevant when BIRD is configured to accept any external AS, for example: ```bird protocol bgp as0_open_test { local as 65001; neighbor 10.0.0.2 external; ipv4 { import all; export none; }; } ``` or with dynamic BGP peers: ```bird protocol bgp dyn_as0_test { local as 65001; neighbor range 10.100.0.0/24 external; ipv4 { import all; export none; }; } ``` The dynamic-peer case was tested locally. ### Expected Behavior If a peer sends a BGP OPEN with My Autonomous System set to 0, BIRD should reject the OPEN, abort the connection, and send: ```text Error Code: OPEN Message Error Error Subcode: Bad Peer AS ``` That is, BIRD should send NOTIFICATION 2/2 rather than allowing the BGP FSM to reach Established. ### Actual Behavior With a dynamic external peer configuration, BIRD accepted an incoming OPEN with peer AS 0 and established the session. `birdc show protocols all` showed the spawned dynamic BGP instance in Established state: ```text as0_dyn_1 BGP --- up ... Established BGP state: Established Neighbor address: 10.100.0.2 Neighbor AS: 0 Local AS: 65001 Neighbor ID: 10.0.0.2 ``` The BIRD log also showed the AS 0 OPEN being accepted and the session becoming established: ```text as0_dyn_1: Got OPEN(as=0,hold=180,id=10.0.0.2) as0_dyn_1: Sending OPEN(ver=4,as=65001,hold=240,id=0a000001) as0_dyn_1: Sending KEEPALIVE as0_dyn_1: Got KEEPALIVE as0_dyn_1: BGP session established ``` For comparison, FRR rejects the same OPEN with NOTIFICATION 2/2. ### Root Cause The relevant validation is in `bgp_rx_open()` in `proto/bgp/packets.c`. For accept-any external-AS mode, where the configured remote AS is unspecified, the current check rejects a peer only when the effective peer AS equals the local AS. There does not appear to be a separate check for the reserved value 0. The effective logic is: ```c if (caps->as4_support) { u32 as4 = caps->as4_number; if (p->remote_as ? (as4 != p->remote_as) : (as4 == p->local_as)) bgp_error(conn, 2, 2, ...); conn->received_as = as4; } else { if (p->remote_as ? (asn != p->remote_as) : (asn == p->local_as)) bgp_error(conn, 2, 2, ...); conn->received_as = asn; } ``` In accept-any external mode, `asn == 0` is not equal to the non-zero local AS, so it can pass this validation and become `conn->received_as`. ### AS4 Capability Case The AS4 Capability path should also be considered. If the OPEN carries AS4 Capability and the AS4 number is 0, that effective peer AS should also be rejected. A fix should therefore reject both cases: ```c if (asn == 0) reject with OPEN Message Error / Bad Peer AS; if (caps->as4_support && caps->as4_number == 0) reject with OPEN Message Error / Bad Peer AS; ``` ### Impact This is best described as an RFC 7607 compliance bug in BGP OPEN validation for accept-any external and dynamic peers. Practical impact depends on deployments using accept-any external-AS or dynamic BGP peering, but the observed behavior can: 1. Allow an external peer to establish a session while claiming the reserved AS number 0. 2. Violate RFC 7607's mandatory OPEN handling. 3. Create inconsistent peer-AS state for logging, policy, and later route processing. 4. Cause interoperability issues with implementations that correctly reject AS 0. The issue does not require a configured neighbor AS of 0. It occurs in accept-any external-AS mode, where BIRD accepts an external peer AS dynamically. ### Version Tested This was reproduced against: ```text BIRD version 2.19.0+branch.master.880200b1f94c ``` Best regards, Xinzhe Liu

1 0