[ednog] Techniques for overlays and walled gardens

[Frank Sweetser]

On Tue, Apr 05, 2005 at 04:08:21PM -0500, John Kristoff wrote:
> I'm most interested in how other institutions are dealing with
> 'overlay', but also in some forms known commonly as walled garden
> networks.
> 
> We have a number of applications for separating certain groups of hosts
> from other groups of host on our IP network both on a temporary basis
> and permanently.  The temporary case is the now somewhat classic walled
> garden method a lot of educational institutions are using for hosts that
> are inflicted with some type of security problem (e.g. worm, any number
> of the IRC-based bots).  On a permanent basis there are a number of
> systems that are increasingly using TCP/IP such as those from an
> institution's facilities or police departments where you do not need,
> nor would you often want them, to be accessible from other systems
> (e.g. temperature controls, video surveillance).
> 
> In the former case there is the DHCP/DNS switching techniques used by
> something like NetReg or in our case Netpass, which switches a port's
> VLAN membership to to one that forces all traffic through a set of
> boxes.  Scaling Netpass across a campus with a number of routers in
> the path and where these networks span many geographic areas scales as
> poorly as layer 2 and VLAN trunking scales.

We play DHCP/DNS games here, but avoid VLAN switching tricks.

> In the latter case, physical separation might often be ideal, but not
> always practical nor cost effective.  Even then in some cases a very
> small set of outside hosts may need to 'manage' these otherwise private
> systems.  Here again, there is potential scaling and management problems
> with layer 2 solutions, private addressing, filters and other layer 3
> tricks.

Here, for the important stuff (security cameras, environmental controls, etc)
we put them in an application specific VLAN with an RFC1918 addressing scheme.
The subnets have no router interfaces defined on them, locking them down
further than just firewalling rules.  Any machines that must be on both the
private and public networks are dual homed, and watched carefully by central IT
staff.

For less critical, more transient issues such as virus infection, we currently
just pull them out of DNS/DHCP and fire off an email.  We're not too large, and
have a strongly centralized IT, so this may not be practical for everyone.  We
are also planning on extending the incoming freshman registration system to
virus infections.

Basically, for such subnets, we have a second shared network that unregistered
systems get dropped into.  This other subnet goes to a different router (a
linux box this in place) and DNS server that redirects all traffic to our
netreg server.  Netreg recognizes that the system is coming from one of the
unregistered subnets, and automatically redirects to a quickreg page with info
such as subnet and mac pre-filled.  It's turned handling our incoming class of
700+ freshmen from 3+ days of moderate insanity into an exercise in waiting
around for someone with problems.

The next step is to expand netreg to recognize when a system is coming from a
secondary network address not because it is unregistered, but has a hold, and
then give the user directions and software to help them help themselves.  If we
get *really* ambitious, we may even plug it into our snort network for
automatic holds for known really bad signatures.

> We've also had some discussion about separating classes of users,
> such as delineating between faculty, staff and students.  Perhaps
> all three of these general scenarios has a common theme?

We've had discussions about this (mostly with regard to our wireless subnet),
and couldn't figure out any good way to clearly define a mapping between a
given machine and a given class of user, especially given that we don't have
a PKI.  For example, how do you handle loaner machines that may be used by
anyone?

> So we've begun investigating an MPLS deployment for at least the
> first two general classes of problems described above.  I don't want
> to turn this into a MPLS is [great|evil] thread, I am just interested
> what others are doing and how they are doing it.

I'd definately be curious in hearing how this turns ouf if you go that route.

-- 
Frank Sweetser fs at wpi.edu
WPI Network Engineer
GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC