bgpd: outbound route-map can make locally originated route violate RFC 4271 NEXT_HOP peer-address rule

[xinzheliu2000]

Summary

FRR bgpd appears to allow an outbound route-map to make a locally originated
IPv4 route violate the RFC 4271 Section 5.1.3 rule that such a route must not
be advertised to a peer using that peer's own address as NEXT_HOP.

I am reporting this as an RFC 4271 conformance / route-policy safety issue,
not as a remotely exploitable security vulnerability.

RFC Context

RFC 4271 Section 5.1.3 says:

A route originated by a BGP speaker SHALL NOT be advertised to a peer
using an address of that peer as NEXT_HOP.

The reproduced route is locally originated by FRR via a network statement,
which is the case covered by the RFC text above.

Test Configuration

route-map SET_NH permit 10
 set ip next-hop 10.100.0.2
!
router bgp 65001
 bgp router-id 10.100.0.1
 no bgp ebgp-requires-policy
 no bgp network import-check
 neighbor 10.100.0.2 remote-as 65002
 neighbor 10.100.0.2 passive
 !
 address-family ipv4 unicast
  network 198.51.100.0/24
  neighbor 10.100.0.2 activate
  neighbor 10.100.0.2 route-map SET_NH out
 exit-address-family

Expected Behavior

Before UPDATE encoding, if the final NEXT_HOP for a locally originated route
equals the receiving peer's address, FRR should suppress the advertisement or
replace NEXT_HOP with the normal local next-hop, and log a warning.

I understand that route-maps are policy tools and that the operator explicitly
configured set ip next-hop 10.100.0.2 in this test. The concern is that the
route-map is allowed to override the outbound NEXT_HOP after route origination,
and there appears to be no final RFC 4271 Section 5.1.3 safety check before
UPDATE encoding.

Actual Behavior

FRR advertised the locally originated route with the receiving peer address as
NEXT_HOP:

NLRI:     198.51.100.0/24
NEXT_HOP: 10.100.0.2

The parsed UPDATE from the PoC:

{
  "attrs": [
    {"code": 1, "flags": 64, "len": 1, "value_hex": "00"},
    {"code": 2, "flags": 80, "len": 4, "value_hex": "0201fde9"},
    {
      "code": 3,
      "flags": 64,
      "len": 4,
      "nexthop": "10.100.0.2",
      "value_hex": "0a640002"
    },
    {"code": 4, "flags": 128, "len": 4, "value_hex": "00000000"}
  ],
  "nexthop": "10.100.0.2",
  "nlri": ["198.51.100.0/24"],
  "withdraw_len": 0
}

The corresponding vty output also showed the peer-specific advertised route
with that next hop:

Network          Next Hop
198.51.100.0/24  10.100.0.2

Dynamic Verification

This was reproduced against:

FRR bgpd 10.6.1

The PoC starts a temporary bgpd instance and connects as a synthetic eBGP
peer from 10.100.0.2. It then parses the UPDATE sent by FRR.

PoC verdict:

VERDICT: REPRODUCED_PEER_ADDRESS_NEXTHOP

I also tested a nearby control case:

route-map SET_NH permit 10
 set ip next-hop peer-address

In this setup, that did not reproduce the issue. FRR sent NEXT_HOP=10.100.0.1
for the locally originated route. The reproduced issue is therefore the
explicit outbound set ip next-hop <receiving-peer-ip> case, not necessarily
the peer-address keyword case.

Impact

This requires local configuration or automation control over FRR route policy.
A remote BGP peer cannot directly trigger it with a packet.

The concern is that FRR can emit an RFC-nonconforming UPDATE for a locally
originated route when an outbound policy accidentally or intentionally sets the
next hop to the receiving peer. Depending on receiver behavior, this may cause
route rejection, blackholing, or confusing interoperability failures.

A conforming receiver may reject or refuse to install the route because the
NEXT_HOP equals its own address. RFC 4271 Section 5.1.3 also says that a BGP
speaker shall not install a route with itself as the next hop.

Suggested Fix Direction

Consider adding a final outbound NEXT_HOP safety check after route-map
modification and before UPDATE encoding for locally originated routes:

if route is locally originated and final NEXT_HOP equals receiving peer address:
  reject/suppress the advertisement, or reset NEXT_HOP to the local address

If FRR intentionally allows this for compatibility with existing deployments,
it would be helpful to document that outbound set ip next-hop can override
the RFC 4271 locally-originated route guard and may produce updates that peers
reject or cannot use.