* Patrick W. Gilmore <patrick@ianai.net> [20000716 09:06]:
I think Sean is worried about the response to that packet. The host might send the reply/ACK/return/whatever packet out the second interface. If the e1 is addressed with RFC1918 space, and the packet were sourced from an RFC1918 address in another network, the reply would obviously go to the wrong location. If someone knew your internal network well enough, this might even be used as a form of DoS attack.
For example, say the source address of the inbound RFC1918 packet just happened to be the same as your own (the e1 address)... Actually that may be an answer right there (to the earlier discussion): For the same reason it is Good Practice(tm) to filter inbound packets at your borders that have source addresses in your IP ranges to prevent outside originated spoofing, if you use *any* RFC1918 space internally you shoulder filter RFC1918 space inbound at the border since, effectively, that RFC1918 space you are using is part of your IP ranges (read: just as exploitable from outside originated spoofing as your global IP blocks). So those that use RFC1918 addresses internally for inter-mediate routers that argue that other providers should not filter RFC1918 _source_ addressed packets should consider that they themselves may be open to spoofing attacks. As long as you allow RFC1918 into your _own_ networks, regardless of any other a anti-spoofing protection you may have in place (i.e. for your global public IP blocks). If a provider uses RFC1918 addresses internally and practices what I've heard some say, allowing RFC1918 source addressed packets into their AS, that _is_ a provable security hole--it's open to basic IP spoofing just as things were before you had your global IP blocks anti-spoof access-lists in place. Just because you use private IP addresses inside doesn't mean I can't exploit them from the outside. "I" is *not* meant in a literal sense above. :-) Also I may be stating the obvious, I don't know. <shrug> -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard@cubicle.net/fix.net/freedom.gen.ca.us/geekresearch.com> Geek Research LLC IP Network Engineering and Consulting