Re: Large edu's doing NAT campus wide?

[Jeff Kell <jeff-kell () UTC EDU>]

After viewing some of the other responses to this query, I'm going to
sound like the fringe Looney Tunes Admin(tm), but for sake of
completeness, here we go.

UTC was forced into NAT over ten years ago.  We had a legacy /22 and two
/21s from SURAnet jerked out from under us on short notice after the
SURA -> BBN -> Genuity -> Level3 transition and left with a new but
non-portable /22 to "make do".  There weren't enough IPs left to go
around, and no time to renumber them if there were enough.  Renumbering
into a non-portable block [again] didn't sound very attractive.  As
Kenneth Arnold noted:

> The main reason that we switched was because our ISP was changing its
> ISP and all of our IP addresses would have to change as a result.
> Since then we have changed ISPs at least one more time.  Using NAT
> makes us independent of the IP addresses of our ISP so we can easily
> change ISPs in order to get a better deal.

Since Joe was initially asking the question with respect to
security/privacy/anonymity, you certainly get "a lot of it" with
overloaded NAT (or port address translation).  If you need
accountability, you have to do a lot of logging; and even with logging
you can't make any inferences about a particular flow unless you have
the complete specification of source IP/port and destination IP/port
with a good timestamp.  It was incredibly difficult to respond to
incident reports whether they be abuse, spam, security, DMCA, or
anything else if reported from the outside world.  It can also cause
internal grief if you don't monitor from the right perspective, as
Russell Fulton noted:

> We are using NAT for our resnet and this drove me nuts until I moved sensors into the network itseslf

Once we *did* get a reasonable allocation of public addresses, we had
the option of renumbering (barely); but by this time we had started
using RFC1918 space internally and rather liked the possibilities (more
on that in a minute).  We changed our NAT from overload (PAT) to a
one-to-one dynamic pool.  The pool kept our address requirements
minimized to the number of active IPs, while the one-to-one NAT made
tracking much easier with much less logging.  Tracking your NAT address
mapping becomes a similar issue to tracking dynamic DHCP - you only need
to record the setup and teardown - and you can tune your "idle timeouts"
on the NAT assignments to cut down on the noise level.

If you accept RFC1918 and NAT as fact of life, (at least) three very
interesting possibilities open up:

First, you can subnet your network almost at will (plenty of RFC1918
space to go around), and do it with a "human readable" scheme that you
don't need a subnet calculator and cheat sheet to comprehend.  Separate
your application servers into their own subnets, separate your user
groups into their own subnets, isolate your buildings into layer-3
distributions, just to name a few.  Routing, firewalls, access lists,
etc are greatly simplified.

Second, you need static translations for your servers, but your
"internal subnets" don't have to match your "external subnets".  Assign
an external subnet for "mail servers" and apply all of your mail-related
access lists, firewall rules, IDS rules, etc to that *external* subnet.
You can map that subnet to your mail servers on campus regardless of
their location.  You can repeat this for web servers or any other group
of inside hosts with common outside access and security requirements,
regardless of their physical location in your network.

Third, need to move a server?  No problem, change the static translation
to the new inside address.  Need to pool, cluster, or load share your
DNS or mail services?  Use a NAT "rotary group" (at least that is the
Cisco terminology) to associate one external IP with a group of internal
servers.

NAT can be a royal pleasure, it doesn't have to be a royal pain.

Jeff Kell
University of Tennessee at Chattanooga