How can RPKI, IRR data, and prefix-lists be combined to create robust inbound filtering?

• A. Use IRR for origin validation, RPKI for policy constraints, and prefix-lists to enforce explicit allow/deny rules.
• B. Use RPKI for origin validation, IRR for policy constraints, and prefix-lists to enforce explicit allow/deny rules.
• C. RPKI is only for encryption; IRR used for route leaking.
• D. Prefix-lists are unnecessary if RPKI is used.

Answer: (B)

Inbound filtering is strongest when you combine cryptographic validation, policy data, and concrete enforcement rules. RPKI gives cryptographic proof that a prefix is legitimately originated by the listed AS, so you can classify routes as valid, unknown, or invalid and typically drop the invalid ones. But origin validation alone doesn’t express what you should accept from a neighbor or how to handle borderline cases, so you need policy guidance as well. IRR data provides documented routing policies and allocations from registries, helping you define which prefixes and AS paths are allowed from each peer. That policy information is what you translate into concrete rules your router can enforce. Prefix-lists are the practical mechanism to implement these decisions at the edge, turning the policy and validation outcomes into explicit allow/deny statements that the device applies to inbound traffic.

So, using RPKI to validate origins, IRR data to shape acceptable prefixes and paths, and prefix-lists to enforce explicit allow/deny rules gives you cryptographic assurance, policy-aware filtering, and precise, enforceable control at the router.