BGP Routing-Security RPKI ISP Networks Protocols

After RFC 7454: what’s changing in BGP security and how to prepare your network

Ariel S. Weher
After RFC 7454: what’s changing in BGP security and how to prepare your network

Introduction: a policy that aged badly

In 2015, RFC 7454 / BCP 194 became the gospel of BGP security. It pushed aggressive filtering: nothing more specific than a /24 in IPv4, nothing longer than a /48 in IPv6, static prefix-lists, and a long list of rules that today cause more pain than they fix.

Reality in the field is different. Filtering every /25 or more specific shuts out legit customers with PI who need to announce small blocks. A static prefix-list with 50,000 entries does not scale. And the worst part: length-based filtering does not protect you from hijacking a valid /20.

On April 7, 2026, the IETF GROW working group published revision 15 of draft-ietf-grow-bgpopsecupd—the document that will replace RFC 7454 once it finishes its path as a BCP. As of this article it is in WG Last Call—not an RFC yet, but the direction is clear and the content has stabilized. The real shift: stop obsessing over prefix size and focus on origin validation.

If you run an ISP in LatAm, this forces a hard look at your inbound and outbound filters. It is not optional.

What the draft proposes

The document’s philosophy moves from defense by filtering to defense by validation. The draft is deliberately abstract—it states properties an operator MUST meet without mandating specific technologies—but the operational direction is clear. Putting the draft together with what we consider good practice today, the comparison looks like this (rows marked † are our operational recommendation, not draft requirements):

Aspect RFC 7454 (2015) Post-bgpopsecupd operational stance
Length filter Block ≥/25 IPv4, ≥/49 IPv6 The draft drops length-based guidance; length does not imply legitimacy
Origin validation Mentions IRR as optional The draft requires the origin be “globally authorized”; in practice that means RPKI + ROA with IRR as a complement
Transitive attributes Light detail The draft strongly recommends against changing immutable transit attributes (SHOULD NOT) and forbids carrying RPKI state in transitive attributes (MUST NOT)
BGP roles † Not a thing RFC 9234 defines roles (Provider, Customer, Peer) and the OTC attribute for route-leak prevention
ASPA † Not a thing ASPA drafts (draft-ietf-sidrops-aspa-verification) add AS-PATH validation by provider relationship
Communities † Light detail Operational recommendation: document which communities you accept, do not strip them blindly
Monitoring † Basic SNMP, syslog BMP (RFC 7854) as a tool for anomaly detection

The key point: prefix length is not a signal of attack. A hijacked /24 is as dangerous as a legit /25. The new focus is validating who is allowed to announce that prefix, not how many bits it has.

What it looks like in practice

Scenario 1: your session with an upstream

You probably have something like this today:

ip prefix-list UPSTREAM-IN deny 0.0.0.0/0 ge 25
ip prefix-list UPSTREAM-IN permit 0.0.0.0/0 le 24

That blocks /25s from PI customers that ride that upstream. Under the new recommendation, the length filter goes away and RPKI validation takes its place:

! FRRouting
route-map UPSTREAM-IN permit 10
 match rpki valid
 set local-preference 200
!
route-map UPSTREAM-IN permit 20
 match rpki notfound
 set local-preference 100
!
route-map UPSTREAM-IN deny 30
 match rpki invalid

Scenario 2: your session with a single-homed customer

The draft adds explicit guidance for multi-homed customers, but single-homed is still ~90% of cases in LatAm. The new line: do not filter on length if the customer has a valid ROA.

! Juniper JunOS
policy-statement CUSTOMER-IN {
    term VALID-ROA {
        from {
            protocol bgp;
            validation-database valid;
        }
        then {
            local-preference 200;
            accept;
        }
    }
    term INVALID-ROA {
        from validation-database invalid;
        then reject;
    }
    term NO-ROA {
        from validation-database unknown;
        then {
            local-preference 100;
            accept;
        }
    }
}

Note the order: valid is accepted with high local-preference, invalid is rejected, unknown is accepted with low local-preference. That lets you roll out RPKI without breaking customers who still have no ROA.

Scenario 3: communities and security

RFC 7454 did not dig into the role of communities in operational security. By strongly recommending against changes to transit attributes without a solid reason (SHOULD NOT), bgpopsecupd indirectly reinforces that stripping all communities on peering sessions is a mistake: there are well-known communities used for mitigation (RTBH, RFC 7999) and for signaling origin.

The operational play is to document which communities you accept and from whom, instead of stripping everything blindly. We cover that in detail in the post on BGP communities for ISPs.

Configuration: moving on from RFC 7454

Note: The configuration snippets below are reference examples. Exact syntax can differ by platform OS version (FRRouting, JunOS, Huawei VRP). Always verify against the official docs for the version you run.

You do not have to change everything overnight. A phased migration is the sane path:

Stage Action Impact
1 Turn on RPKI-RTR with your RIR (LACNIC) Validation without changing routes
2 Apply route-maps with rpki notfound allowed See what share of your routes have no ROA
3 Reach out to customers without a ROA and help them create one Cuts not-found traffic
4 Drop length-based prefix-lists Simplifies operations
5 Enable BMP toward your monitoring stack Real-time anomaly detection

FRRouting: full example config

! RPKI-RTR (requires bgpd compiled with -M rpki)
! Standard RTR port is TCP 323 (RFC 8210); 8323 is used when unprivileged
rpki
 rpki cache tcp rpki.ejemplo.ayuda.la 8323 preference 1
 exit
!

! BLACKHOLE before RPKI: accept RTBH routes even if RPKI invalid
route-map UPSTREAM-IN permit 5
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!

! Route-maps with RPKI validation
route-map UPSTREAM-IN permit 10
 match rpki valid
 set local-preference 200
!
route-map UPSTREAM-IN permit 20
 match rpki notfound
 set local-preference 100
!
route-map UPSTREAM-IN deny 30
 match rpki invalid
!

! BGP neighbor with policy
router bgp 65001
 neighbor 198.51.100.1 remote-as 65002
 neighbor 198.51.100.1 route-map UPSTREAM-IN in

Huawei VRP: example with route-policy

# Configure RPKI validation
rpki
  rpki cache rpki.ejemplo.ayuda.la port 8323 preference 1
#

# Create route-policy with validation
route-policy UPSTREAM-IN permit node 10
  if-match rpki origin-as-validation valid
  apply local-preference 200
#

route-policy UPSTREAM-IN permit node 20
  if-match rpki origin-as-validation not-found
  apply local-preference 100
#

route-policy UPSTREAM-IN deny node 30
  if-match rpki origin-as-validation invalid
#

# Apply to peer inside address-family
bgp 65001
  peer 198.51.100.1 as-number 65002
  ipv4-family unicast
    peer 198.51.100.1 enable
    peer 198.51.100.1 route-policy UPSTREAM-IN import
    prefix origin-validation enable

Huawei VRP: equivalent XPL example

On NE40E / NetEngine 8000 boxes with VRP V8R16+ you can use XPL (eXtensible Policy Language) instead of route-policy. The upside is the logic lives in one if/elseif/endif block, without the numbered node fragmentation:

# Create route-filter with RPKI validation
xpl route-filter UPSTREAM-IN
  if rpki-validation == valid then
    apply local-preference 200
    approve
  elseif rpki-validation == not-found then
    apply local-preference 100
    approve
  elseif rpki-validation == invalid then
    refuse
  endif
end-filter

# Apply to peer inside address-family
bgp 65001
  peer 198.51.100.1 as-number 65002
  ipv4-family unicast
    peer 198.51.100.1 enable
    peer 198.51.100.1 route-filter UPSTREAM-IN import
    prefix origin-validation enable

Operationally, versus route-policy: XPL evaluates conditions as one sequential, short-circuiting block, which makes the flow easier to read when you have several chained conditions. It also supports parameterized variables ($var) that make it easier to reuse filters across peers with similar policy.

Common mistakes we see in audits

1. Filtering on length and calling it security

A prefix-list with ge 25 gives you a false sense of safety. An attacker with a valid /20 walks right in. The only real defense is validating who is announcing.

2. Not telling RPKI invalid from not-found

Invalid means a ROA says that AS must not announce that prefix. You drop that.

Not-found means there is no ROA. That is a different thing. Dropping it breaks legit reachability. The recommended practice is unambiguous: accept not-found at lower preference, do not reject it. Rejecting it today would cut off a big chunk of the internet.

3. Stripping communities you do not understand

Stripping all communities on peering sessions kills useful tools like RTBH. If your upstream sends 65535:666 for blackholing and you strip everything, you cannot mitigate a DDoS without waiting on them to act.

4. Not monitoring BGP with BMP

Without BMP, a subtle change in a peer’s Adj-RIB-In goes unnoticed until it hits forwarding. BMP lets you spot new routes, changed communities, or mass withdraws in seconds, not hours.

How this ties to other topics

This does not sit in a vacuum. It plugs straight into:

  • RPKI and ROAs: without published ROAs, validation does nothing. If you are an LIR at LACNIC, publishing your ROAs is an operational requirement now, not a nice-to-have.
  • BGP communities: the new draft doubles down on not messing with transit attributes; communities are part of the security model, not noise to strip.
  • BGP roles and ASPA: RFC 9234 defines peering roles and the OTC attribute to stop route leaks. ASPA adds AS-PATH validation by provider relationship as the next layer after ROV.
  • DDoS and RTBH: well-known communities like 65535:666 (RFC 7999) become operational tools, not “risky” knobs.

What we are seeing in the field

In 40+ ISP audits across Argentina, Brazil, Chile, and Mexico between 2025 and 2026, the pattern repeats:

  • 80% have length-based prefix-lists that block legit /25s and /26s from PI customers
  • 40% have RPKI on but not wired into route-maps (look-only, no policy)
  • 90% strip all communities, no exceptions
  • Under 10% use BMP for BGP monitoring

Moving to the bgpopsecupd-15 posture takes work, but it cuts long-term operational load. A three-term RPKI route-map is easier to maintain than a 500-line prefix-list you have to update every time a customer gets new PI.

Need a hand?

Reviewing routing policy for an ISP with 50 BGP sessions is not trivial. If you want an audit of your current filters, a guided migration to RPKI-based validation, or someone to sanity-check your config before a customer complains their /26 is invisible, we should talk.

See our network engineering services →

Contact the team →

References

Have you looked at your prefix-lists today? How many legit prefixes are you killing on length without knowing? If you found one, write us at [email protected].