Questions: BGP Route Filtering and Hijacking Prevention

Question 1

A legitimate network operator owns the prefix 203.0.113.0/24 and announces it to their BGP peers. A malicious AS begins announcing 203.0.113.0/25 and 203.0.113.128/25. Even if neighboring ASes have a prefix list allowing 203.0.113.0/24, what happens to traffic destined for addresses in that block?

• A. Traffic is unaffected because the prefix list blocks the more-specific announcements from propagating
• B. Traffic follows the hijacker's more-specific /25 routes because routers prefer the longest matching prefix
• C. Traffic is dropped because the conflicting announcements trigger BGP loop detection
• D. Traffic splits evenly between the legitimate owner and the hijacker using ECMP load balancing

Answer: (B)

BGP routers always prefer the most specific (longest prefix) matching route. A /25 prefix is more specific than a /24 for addresses in the same range, so any router that has both routes in its table will forward traffic toward the /25 — the hijacker. A prefix list that explicitly permits 203.0.113.0/24 will block those exact routes from neighbors, but it does NOT automatically block the more-specific /25 sub-prefixes unless the filter is written to cover them. This is why more-specific prefix hijacking is so effective: it exploits the fundamental routing preference without requiring any forgery of the legitimate route itself.

Question 2

What does RPKI (Resource Public Key Infrastructure) validate when a BGP router checks an incoming route announcement, and what form of hijacking does it NOT prevent?

• A. RPKI validates the entire AS-PATH of an announcement and prevents all forms of route hijacking
• B. RPKI validates that the origin AS is authorized to announce the prefix, but does not verify the intermediate AS-PATH
• C. RPKI validates the BGP community attributes attached to a route, preventing traffic engineering manipulation
• D. RPKI validates that the announced prefix exists in the global routing table at the time of announcement

Answer: (B)

RPKI uses Route Origin Authorizations (ROAs) — cryptographic certificates issued by Regional Internet Registries — to verify that the origin AS (the AS that first announces a prefix) is legitimately authorized to do so. This closes the most common gap: an AS announcing a prefix it doesn't own. However, RPKI says nothing about the intermediate ASes in the path. Path manipulation attacks — where an AS fabricates or prepends ASes in the AS-PATH — are not addressed by RPKI alone. Additional mechanisms like BGPsec are needed for full path validation.

Question 3

RPKI validates that a BGP announcement's origin AS matches a signed authorization, which means RPKI alone is sufficient to prevent most BGP route hijacking attacks.

• T. True
• F. False

Answer: False

RPKI validates origin AS only, not the full AS path. A hijacker who announces a prefix from an authorized origin AS (e.g., by forging or prepending the real origin AS at the start of a fabricated path) would pass RPKI validation. Path manipulation attacks, where an attacker manipulates the AS-PATH to redirect traffic while still showing a valid origin, require BGPsec for full cryptographic path validation. RPKI is a significant improvement over unverified BGP, but it is not a complete solution.

Question 4

A BGP router that is configured with a 'default-deny' inbound filter will reject any prefix announcement not explicitly included in its prefix list, even from trusted peers.

• T. True
• F. False

Answer: True

Default-deny is the correct and security-critical posture for BGP filtering. Without it, a misconfiguration or malicious announcement from any peer — including a trusted one — can propagate through your router to the broader internet. Many of the most damaging real-world BGP incidents have involved routers that accepted all routes by default and then accidentally propagated a hijacked or leaked route to thousands of downstream networks. Explicit permit lists ensure that only authorized prefixes, in expected size ranges, from authorized peers, are accepted and re-advertised.

Question 5

BGP has no built-in mechanism to verify that an AS owns the prefix it is announcing. What are the two main layers of defense against prefix hijacking, and what does each one address?

Model answer: The first layer is route filtering — prefix lists and AS-PATH filters configured on each BGP session that explicitly allow only expected prefixes from each peer. This prevents unauthorized prefixes from propagating and enforces a default-deny posture. The second layer is RPKI, which adds cryptographic verification by allowing routers to check announced prefixes against signed Route Origin Authorizations (ROAs). RPKI addresses the root problem — that BGP trusts all announcements equally — by binding prefixes to authorized origin ASes with cryptographic proof. Together, filtering handles what is expected while RPKI provides cryptographic verification of what is legitimate.

Neither layer alone is sufficient. Filtering without RPKI still relies on operators manually maintaining accurate prefix lists — error-prone at internet scale. RPKI without filtering still requires router operators to act on invalid-marked routes (many currently only flag rather than reject them). The combination, along with BGP monitoring services and community coordination, forms the practical defense in depth used by security-conscious network operators.