nanog mailing list archives
Re: RFC1918 addresses to permit in for VPN?
From: Josh Richards <jrichard () cubicle net>
Date: Tue, 9 Jan 2001 15:58:34 -0800
* mdevney () teamsphere com <mdevney () teamsphere com> [20010101 01:51]: [..]
Using RFC1918 space also gets you an IP range where the outside world has no route to it -- Sorry, but no packets are not getting there, ergo no way to hack.
Wanna bet? Just because you are not announcing your 10/8 usage doesn't mean I can't send packets your direction... *I* control where I send packets regardless of whether you are announcing the space or not... Think static routes on my side and several (not uncommon) network topologies where I control enough of the layer-3 network infrastructure between me and you to get the packets to your border (say, I'm your customer, transit provider, or peer..)
Assuming various things that should be standard procedure -- dynamic NAT as opposed to static, blocking source routing, etc.
Dynamic translations (and NAPT even more than Basic NAT) make things a bit more inconvienent for me but overall don't make things that much more difficult than a static translation would be. All I need to know is what the translated address is that my target is using *now* (as in when I'm making my move). I don't care what is was before; I don't care what it is after. And finding out what it is now I'd venture is not going to be very hard with some simple cross-referencing against HTTP, SMTP, POP3, and the like logfiles.
At that point, just by use of simple routing, you've effectively eliminated 100% of attacks from the outside, and you only have to worry about inside. The front door is secure, now work on the back door.
Some "routing" (use of RFC1918 space) and some access-lists. I'd argue that the RFC1918 space has nothing to do with it since you could just as well assign public IPs to the to-be-protected-hosts and combine them with similar access-lists for the same effect. Heck, you can still run NAT in that scenario if you like. The RFC1918 (or just unannounced space of any origin) does not keep me from sending things your way, even if you aren't telling your BGP neighbors about it.. (damn I really need to catch up on my list reading, this is a week old thread...*sigh*) -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard () geekresearch com/cubicle.net/fix.net/freedom.gen.ca.us> Geek Research LLC - <URL:http://www.geekresearch.com/> IP Network Engineering and Consulting
Attachment:
_bin
Description:
Current thread:
- RE: RFC1918 addresses to permit in for VPN?, (continued)
- RE: RFC1918 addresses to permit in for VPN? John Fraizer (Feb 24)
- RE: RFC1918 addresses to permit in for VPN? Richard A. Steenbergen (Feb 24)
- RE: RFC1918 addresses to permit in for VPN? John Fraizer (Feb 24)
- RE: RFC1918 addresses to permit in for VPN? John Fraizer (Feb 24)
- RE: RFC1918 addresses to permit in for VPN? John Fraizer (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? mdevney (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? Stephen Stuart (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? Stephen Sprunk (Feb 24)
- RE: RFC1918 addresses to permit in for VPN? Deron J. Ringen (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? Stephen Griffin (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? mdevney (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? Josh Richards (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? Bennett Todd (Feb 24)
- Re: RFC1918 addresses to permit in for VPN? Andrew Brown (Feb 24)