Filtering iBGP at the Edge
The RFC discuss the concept of spoof blocking, blocking your own internal IP space from entering your network, in several places. Preventing externally sourced packets from reaching your IBGP addresses is one such case. The specific recommendation is to block your own address space from entering your network in order to protect your iBGP.
The concept is relatively easy to understand. There’s no reason why anyone on the internet should be able to send iBGP to you. It’s only use is internal. Further, you should be blocking your OWN iBGP addresses from entering your network. That would certainly be the result of spoofing. If I have a /27 that contains all of my iBGP addresses, then would I be receiving an iBGP packets from outside my network with a source address in that /27? I shouldn’t.
There are two general principles at play here. First, your control plane should have a narrow window of exposure. In this case if your iBGP is numbered out a /27 then it makes sense that only that /27 should be able to send & receive iBGP to your control plane. Second, you should, generally, have an anti-spoof filter at your edge for your own internal-use addresses. Your control plane filters can only do so much. They are crafted to allow your own legitimate protocols & traffic through them. But any packet can be spoofed with one of your own addresses as source. If a packet were spoofed such that its source address was one of your own iBGP /27 addresses then it would get passed successfully through your control plane filters. The answer is to filter at your edge as well. If there’s no reason to receive a packet with a source-address in that /27 on your customer facing interfaces then you should be filtering that out. That prevents those spoofed packets from entering your network.
There are, of course, caveats. This presumes that you are using different addresses for your iBGP and eBGP connections. You can’t very well deny connections to your iBGP /27 if those same addresses are used by customers to establish their eBGP connections. Strategies could vary. You could have secondary loopbacks or /32 addresses used just for iBGP, or you could have a sophisticated filter on your edge interfaces, allowing BGP from the customers peering address to your loopback but allowing no other BGP traffic to your loopback. You'll want to be careful, also, if you have multiple internal users and/or off-net or multi-hop connections. In other words, if you have a complex internal BGP environment you want to think hard about this and perhaps rely on other mechanisms more.
The below examples reference IPv4. Don’t forget your IPv6 filters as well!
[I’m fairly certain you can’t just filter iBGP. I’ve spent time digging through the three vendors docs for special hooks and don’t see any.]
Juniper Example
In this Juniper example we’re going to assume that all of our iBGP addresses are in the 10.10.10.0/27 range and that range is ONLY used for iBGP. Our filter blocks any TCP/BGP packet coming FROM one of those addresses; if we receive one from an external-facing interface then it’s a spoofed source address. We’re using the GROUPS command to create a generic “macro” to apply to interfaces and then applying the group on ethernet interface et1/0/0.
prefix-list iBGP-RANGE {
10.10.10.0/27; }
Groups {
INTERFACE-CUSTOMER {
Interfaces <*> {
unit <*> {
family inet {
filter {
input-list customer-in;
}
}
family inet6 {
filter {
input-list customer-in;
}
}
}
}}}
Et-1/0/0 {
unit 109 {
apply-groups INTERFACE-CUSTOMER;
filter customer-in {
term allow-bgp {
from {
source-prefix-list {
iBGP-RANGE;
}
protocol tcp;
port bgp;
}
then deny;
}
<additional terms>
You can find additional information about Juniper configuration groups, as well as links to further configuration group documentation, at:
Cisco XR Example
Our Cisco example is a little simpler. Note that we’ve defined an ACL that we intend to apply to every external facing interface. We’re filtering out packets FROM our own internal iBGP range to ANY destination.
ipv4 access-list input-strict-in
remark Deny internal iBGP spoofed sources
deny ip 10.10.10.0/27 any
…
permit any any
interface type hundredgige 0/1/0/0
ipv4 access-group input-strict-in ingress
Brocade Example