Re: Who does source address validation? (was Re: what's that smell?)
install this on all your internal, upstream, downstream interfaces (cisco router) [cef required]:
"ip verify unicast source reachable-via any"
This will drop all packets on the interface that do not have a way to return them in your routing table.
Of course, this is the IP RIB and may not include all the potential paths in the BGP Adj-RIBs-In, right? As such, you've still got the potential for asymmetric routing to break things.
Juniper has a somewhat viable solution to the 100% source validation for bgp customers. they will consider non-best paths in their unicast-rpf check on the customer interface. This means that even if 35.0.0.0/8 is best returned via your peer instead of via the provider the packet came in, but they are advertizing the prefix to you, you will not drop the packet.
What's a "bgp customer"? Can they support 500K+ uRPF entries here? -danny
On Tue, Oct 08, 2002 at 09:34:19AM -0600, Danny McPherson wrote:
install this on all your internal, upstream, downstream interfaces (cisco router) [cef required]:
"ip verify unicast source reachable-via any"
This will drop all packets on the interface that do not have a way to return them in your routing table.
Of course, this is the IP RIB and may not include all the potential paths in the BGP Adj-RIBs-In, right? As such, you've still got the potential for asymmetric routing to break things.
No, this is "if i have a path in fib" back to this source, transmit else drop; It does not validate that it is reachable via that interface, just reachable at all. so as long as you aren't null routing 1918 space in your network to drop packets destined for 1918 space, it will determine there is no route (back) and drop it.
Juniper has a somewhat viable solution to the 100% source validation for bgp customers. they will consider non-best paths in their unicast-rpf check on the customer interface. This means that even if 35.0.0.0/8 is best returned via your peer instead of via the provider the packet came in, but they are advertizing the prefix to you, you will not drop the packet.
What's a "bgp customer"? Can they support 500K+ uRPF entries here?
I'm not sure what the hardware limitations on the Juniper router are with this unicast rpf. It was introduced recently (I think in 5.3?) and i personally have not done a significant amount of testing with it. I'm just offering it as general knowledge for those that aren't aware that Juniper has unicast rpf, and that it is somewhat different from the cisco per-interface model as well as offering a different type of check that may address some peoples design issues. (this uses the bgp adj-rib-in info), not the cisco check i describe above. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Tue, Oct 08, 2002 at 11:49:41AM -0400, Jared Mauch wrote:
Of course, this is the IP RIB and may not include all the potential paths in the BGP Adj-RIBs-In, right? As such, you've still got the potential for asymmetric routing to break things.
No, this is "if i have a path in fib" back to this source, transmit else drop;
Unless I'm missing something, that's what he said; fib == loc-rib for the purposes of this discussion, and loc-rib is built from the various adj-ribs-in. That said, I'm curious to know how asymmetric routing can break this. As long as someone is sending (and you are installing) a prefix that includes the source address this check will pass. If you don't have a route back to the source at all, that isn't asymmetric routing, it's network partitioning, assuming the source is legitimate. --Jeff
On Tue, Oct 08, 2002 at 12:09:56PM -0400, Jeff Aitken wrote:
On Tue, Oct 08, 2002 at 11:49:41AM -0400, Jared Mauch wrote:
Of course, this is the IP RIB and may not include all the potential paths in the BGP Adj-RIBs-In, right? As such, you've still got the potential for asymmetric routing to break things.
No, this is "if i have a path in fib" back to this source, transmit else drop;
Unless I'm missing something, that's what he said; fib == loc-rib for the purposes of this discussion, and loc-rib is built from the various adj-ribs-in.
Correct, but it is not doing a check to see if it's returnable via the interface it came in, just if it's returnable at all. As the fib/rib is built off of the adj-rib-in (minus filtering and local policy), and the check on the cisco validates against the CEF (fib) table on the Linecard (or centralized CPU in the case of non-[fully-]distributed platforms) i wanted to clarify the check that is performed.
That said, I'm curious to know how asymmetric routing can break this. As long as someone is sending (and you are installing) a prefix that includes the source address this check will pass. If you don't have a route back to the source at all, that isn't asymmetric routing, it's network partitioning, assuming the source is legitimate.
Exactly. If I can't reach you, I don't want to have my hosts or routers spend more time than is necessary dealing with your requests. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Tue, 08 Oct 2002 09:34:19 MDT, Danny McPherson <danny@tcb.net> said:
"ip verify unicast source reachable-via any"
Of course, this is the IP RIB and may not include all the potential paths in the BGP Adj-RIBs-In, right? As such, you've still got the potential for asymmetric routing to break things.
"reachable-via any" means you're only going to drop the packet if you don't have *ANY* route back to them. I think that if you're in a situation where you have asymmetric routing, and have a packet coming in on one path that you theoretically COULD send to the destination, and the destination has an alternate-path route back to the source, *but you don't have ANY route*, then you're already in a "broken" state anyhow. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
participants (4)
-
Danny McPherson -
Jared Mauch -
Jeff Aitken -
Valdis.Kletnieks＠vt.edu