North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Strange things which should never happen (was Re: RFC 1918)

  • From: Josh Richards
  • Date: Sun Aug 06 18:54:22 2000

* Patrick W. Gilmore <[email protected]> [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 

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>


Josh Richards [JTR38/JR539-ARIN]
<[email protected]/>
Geek Research LLC
IP Network Engineering and Consulting

Attachment: pgp00000.pgp
Description: PGP signature