[ale] HELP, need to setup wireless access point!

[Michael B. Trausch]

On Fri, 2011-02-04 at 14:35 -0500, David Tomaschik wrote:
> I only wish NAT had never been invented.

Amen to that.  NAT isn't completely and utterly useless.  But IMHO, it
would've been better to have run out of address space five or ten years
ago and have a forced migration at that time, as opposed to drawing it
out like NAT did.  NAT has done far more harm than good in the years
since it was invented and implemented.

Perhaps the biggest disservice it has done for us has been to enable
people to buy in to its perceived security advantages.  I can't even
tell you how many people I have talked to in the past five years that
truly believe that NAT is the one true method of network security
(nevermind the fact that security of a network is a multilayered and
decently complex thing).  There have been so many.

The introduction of NAT has given people a false sense of security, as
well as a false sense of certainty.

One of the things that Michael Warfield said at the IPv6 talk in January
was (loosely quoted): "If you want IPv6 on your network, you have to
support it.  If you don't want IPv6 on your network, you have to support
it."  And that is the way it is with so many things, but people fail to
realize this because they do not even give consideration to the idea
that something could happen behind their NAT.  Their NAT is supposed to
be the super-deee-duper firewall and network security solution.  It's
like it's the second coming of the diety of security or something.  But
it's not.

> NAT has caused me more headaches that I can imagine, and here at work,
> we have them doing some things that I'm pretty sure is never supposed
> to happen.  Some of the workstations here at work are on one of a few
> dozen 10.x networks, but they're only NATted leaving campus.

So far, that sounds correct.

> They're routed throughout the campus.

There's nothing wrong with routed networks using RFC 1918 space.  I have
a virtual network infrastructure run that way.

> So if someone on campus accesses a server on campus, the request comes
> in directly from their 10.x.x.x IP.  This gets real dicey for trying
> to implement SSO solutions that use the source IP as part of the
> session when the SSO system has to talk to off-campus systems.

This sounds more like a problem inherent to whatever is being used to
provide SSO capability throughout the network.  I have never really
understood the use of an IP address as part of either authentication or
authorization; IP addresses can be easily spoofed, and they're not
secure things for either authentication or authorization purposes.  In
the 1980s, the networks were probably safe enough to use an IP address
as a factor in either/or, but today it's pretty much useless.

I wrote a post to the list some time back (don't have the link handy)
where I talked about what I have for authentication.  It starts with the
user providing authentication information, which is then (through both
encryption and use of message digests) used to generate an
authentication token that is updated at every request to the server (to
avoid replay-style attacks and reduce [but not eliminate] the chance of
a successful session hijacking).  It's not perfect, but I'm not entirely
certain that there _can_ be an entirely perfect system for
authentication: you have to trust _something_, _somewhere_ for it to
work.

Authorization, OTOH is more-or-less simple: it relies on the strength of
authentication, and authorization only answers the question "Can
(assumed authenticated) user X perform action Y?"---that's all.  So, the
"perfection" has to be in the authentication.

I use an encrypted token (with a key that is derived from details of a
session and the user account in question, so that all keys for all
sessions are different) because the possession of the token is used as
proof that authentication has taken place at some point in the past.
That only works if not all of the information used to derive the key is
public (and indeed, some secret sauce is used as input to the KDF).  But
that way, I can account for systems that might relocate, such as
laptops, which might bounce from one network to the next (or, heck, from
an IPv6 network to an IPv4 one if the IPv6 link goes down for some
strange reason), or even from a desktop that has to move to dialup or a
backup connection and thus changes source addresses.  Done this way, a
session is bound more-or-less precisely to the user-agent (software)
that initiated the session.

I believe, if my understanding is correct, that Kerberos works much in
the same way.

> So the SSO server sees 10.x.x.x, but the off-campus computer sees
> AAA.BBB.x.x from the NAT gateway.  Now, I'm just a sysadmin, not a
> networking guy, but something seems very wrong about having traffic
> from both RFC 1918 address space and world-routable address space on
> the same interface.

There's nothing wrong with multiple logical networks sharing the same
physical link.  I have 2 on my home IPv4 network, mostly for convenience
reasons.  As long as the default gateway knows what's going on, it's all
good; it will send ICMP redirects when necessary.  One step better than
that, the routing tables can all have entries added to them to inform
the system what IP networks are available on the same physical link.

It certainly isn't the most elegant solution in the world, but it works
very nicely when it is setup correctly.  But that is the key: it has to
be set up correctly!

And it doesn't hurt to really understand the whole OSI model, either.
Then you get a much better view of how the whole networking stack works,
from top to bottom (or bottom to top, however you want to look at it)
and you can better understand how things actually travel on-link when
looked at from the IP layer.

Just wait and see what happens if SCTP ever makes it into widespread use
on the Internet... that'll really confuse a lot of people! :)

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110204/813d9ee3/attachment-0001.bin