How does reverse path forwarding work (PIX) ?

[pmacdanel]

Hello,

I am curious as to how rpf works on the pix. I found the description in the command ref. to be somewhat vague, and am hoping someone can explain the following points on rpf Ingress filtering :

Ingress filtering checks inbound packets for source ip address integrity, it does this by looking up a reverse route in local routing table, which must exist or the packet is dropped. I don't understand what the pix is looking up in the routing table , ie how does the local routes in the table relate to telling if the SA is legitimate or spoofed ?

Scenario:

the PIX inside interface has 2 connected networks, 172.16.1.0, and 192.168.1.0

one is directly connected , the other has a route statement via inside

these networks are being address translated to the outside interface public ip 111.111.111.111

rpf is configured for the outside interface

Question 1: a legitimate packet comes in with a SA of 222.222.222.222 destined for 111.111.111.111, with a nat mapping to 172.16.1.23. What is the pix doing and comparing when checking the route table to verify this is a legitimate packet ? How does NAT figure into the picture ?

Question 2 : another packet, but this time the SA of 222.222.222.222 was spoofed in a DOS attack, destined for the outside interface, 111.111.111.111,

how is this packet compared and dropped ?

Question 3 : What is the signifigance of the default route ( in regards to rpf only) ?

I would greatly appreciate any comments on how rpf works in this example

-patrick

[gmiiller]

In a nutshell, RPF allows a router or firewall to ask itself the question "Am I receiving this packet on the same interface that I would use if I was forwarding traffic to the source of the packet" If the answer to the question is yes, the packet passes RPF, if the answer is no, the packet fails RPF. NAT becomes largely irrelevant, all that RPF is doing is ensuring that the traffic arrived from the "right direction"

With reference to the default route (and your network design) leading to the internet. What this means is that traffic arriving on your outside interface with any source address other than those connected/routed on your inside interface will pass RPF, again, the logic here is that the packet has arrived from the "right direction" based on the routing table, and in this case, the default route.

My own question here has to do with RPF on routers, and I'm wondering if there is any plan to modify the RPF/extended access-list functionality so that the RPF ACL can genuinely be used to inspect all components of a packet that has failed RPF, including source/destination/port etc. Also, I've encountered problems getting RPF access-list logging to work properly and wonder if anyone can throw some light on it.

[pmacdanel]

Thanks for the reply,

I think that gives me a better picture, it seems that the real functionality of rpf would come from a scenario where it was deployed on, say, an ISP edge router as ingess and egress filtering. It won't do a whole lot for a SOHO network other than prevent ip spoofing of their internal subnet(s) correct ?

[gmiiller]

That's about it. In most cases, what RPF does is eliminate the need for you to manually change all of your anti-spoof access-lists every time your internal network addressing/routing changes.