[33167] in North American Network Operators' Group
Re: RFC1918 addresses to permit in for VPN?
daemon@ATHENA.MIT.EDU (mdevney@teamsphere.com)
Mon Jan 1 04:50:18 2001
Date: Mon, 1 Jan 2001 01:46:55 -0800 (PST)
From: <mdevney@teamsphere.com>
To: Stephen Stuart <stuart@mfnx.net>
Cc: jlewis@jasonlewis.net, nanog@merit.edu
In-Reply-To: <200012312215.eBVMFxV02157@hi.tech.org>
Message-ID: <Pine.LNX.4.21.0101010143500.10993-100000@core.teamplay.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Sun, 31 Dec 2000, Stephen Stuart wrote:
> Date: Sun, 31 Dec 2000 14:15:59 -0800
> From: Stephen Stuart <stuart@mfnx.net>
> To: jlewis@jasonlewis.net
> Cc: nanog@merit.edu
> Subject: Re: RFC1918 addresses to permit in for VPN?
>
>
> Only that private addressing helps ensure that your machines don't
> have access to the Internet. If you've set up a network where there is
> truly no packet path to the Internet such that it wouldn't matter if
> your back-end network was numbered in RFC1918 space or not, then it
> becomes unlikely that the network in question will be compromised *by
> an attacker arriving via the Internet*, and your security does not
> depend on RFC1918 addressing. You will have someone walking up to a
> switch and plugging in to consider (but that's more a facility
> security issue). RFC1918 gives you a place to number hosts without
> conflicting with "public" address space, that's all.
>
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.
Assuming various things that should be standard procedure -- dynamic NAT
as opposed to static, blocking source routing, etc.
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.
>
