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
