RFC1918 addresses to permit in for VPN?

Tue Jan 2 16:00:28 UTC 2001

2001-01-02-09:02:37 Deron J. Ringen:
> > > That makes perfect sense to me...there is not a better way to
> > > protect a box from a DOS/hack than to only give it a private
> > > address.
>
> > this is a common fantasy. changing the its license place does
> > not change the vulnerability of your car to an accident.
>
> True...but parking your car in a garage as opposed to on the
> street does make it less vulnerable to theft.

I think, based on other comments Randy made, that the real root of
this particular disagreement is just terminology.

Randy made other followups on this thread. One, in response to a
remark similar to yours, is quite suggestive:

2000-12-31-15:40:50 Randy Bush:
> that's called a firewall, or in the extreme a disconnected
> network, not nat.

and then a little later, in a thread on Loose Source Routing (lsr):

2000-12-31-17:02:24 Randy Bush:
> lsr is not required to get through a nat. the nat presents an
> outer address that maps directly to the inner address. attack the
> outer address directly and you have attacked the inner address.

So the picture that emerges is that Randy is very definitely
speaking of NAT as Bi-directional or Two-Way NAT (in the terminology
of RFC 2663), where no address conservation is practiced, and
machines with private addresses are directly reachable via public
addresses, through a fixed incoming mapping applied by the NAT
device. I'd expect that many participants in this discussion ---
possibly including most of those thinking that NAT adds security
--- are automatically thinking about the varient of NAT named in
that RFC as Network Address Port Translation (NAPT) --- where
connections can be established from private->public only, and the
NAT device dynamically remaps the private [srcaddr,srcport] onto
per-connection-assigned public addr/port pairs, using one (it's
own) or a small number of public addresses as the target of its
mapping; this is the mode that can conserve public addresses, and
also provides stateful packet filtering allowing outbound-only
connections.

As if this weren't messy enough already, an additional complication
arises because at least one NAT implementation is part of a tool
frequently used as a firewall (ipchains), does NAPT only, and when
doing NAPT turns from a stateless simple packet filter into a
stateful packet filter, with an increase in practical security.

Especially with his remark "that's called a firewall, not nat",
I think it's clear that Randy sharply separates things that are
doing routing functions (including NAT) from things that are
enforcing security policy constraints at network traffic choke
points (firewalls). And there's jargon usage to support his view,
ipchains itself doesn't call it's NAPT implementation NAT, but
rather Masquerading. Sadly, others of us muddy the water by using
the term firewall to designate a function --- policy control and
enforcement --- which can sometimes, depending on details of the
desired policy and the available functionality, be actually
implemented partly or even entirely by a router.

Looking past the variations in usage, Randy's remarks stand very
plainly and indisputably: Network Address Translation, as a routing
function, implies nothing about security; and the use of private
addrs which it permits would clearly add no security to the mix
given Bi-directional NAT. Packet filtering, as a firewall function,
can add security.

The fact that one popular style of NAT pretty consistently implies a
variety of packet filtering would seem to be the source of the
unfortunate confusion.

Now all this discussion brings to my mind a fascinating possibility.

In the big recurring battle on NANOG, the topic of RFC 1918 addrs
comes up because some people like using them for endpoints of
point-to-point links between routers within their transit networks,
and others condemn that practice, citing the urgent operational
necessity to run traceroute, which requires "seeing" each interface
on the path through the transit network, and the recommendation in
RFC 1918 itself to filter RFC 1918 addrs at the border.

The juxtaposition of these two threads, RFC1918+NAT for security and
RFC 1918 link addrs, brought to my mind an interesting question.
Since some folks get so outspokenly upset if they see RFC 1918
addrs in a traceroute, I wonder if it'd be possible to configure
a border router to NAT those RFC 1918 addrs. Obviously this would
be something you'd want to be able to switch on and off on a
per-customer basis; folks who'd rather see the real assigned addrs
in their traceroute output would ask for this to be left off, those
who cannot abide the sight of those addrs could have it turned on,
and so would see repetitions of the NAT-ting border router addr with
the increasing hop count until the far edge of the net was reached.

Hmm. If that NAT trick would work, it might also deal with another
downside to RFC 1918 link addrs, that limits their usefulness; if
a router has interfaces onto nets with different MTUs, assigning
any of its interfaces an RFC 1918 addr is liable to be bad, since
the RFC 1918 addr is likely to be blocked at someone's border, and
that combination would cause the ICMP dest unreachable fragmentation
needed packet, required by Path MTU Detection, to be dropped, making
TCP connection setup fail. Perhaps NATting those RFC 1918 addrs at
the border would address that problem, and so allow more extensive
use of RFC 1918 addrs for router interfaces. Hmm.

I doubt the brawl over RFC 1918 link addrs will ever really get
settled; but at least there will be a possibility for peace soon;
network operators will be able to decide whether their internal
routers are in fact public servers, and if they decide they aren't,
they will be able to run MPLS or something like it, something that
propogates transit traffic in tunnels right across their net,
and so prevents the existence of the intermediate routers from
being visible even to people using custom-forged short TTLs (i.e.
traceroute) to try and detect them.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20010102/b8b98e22/attachment.sig>