Network Segmentation Approaches

Keith Medcalf kmedcalf at
Tue May 5 13:01:11 UTC 2015

It is called the Purdue Enterprise Reference Architecture ...

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at] On Behalf Of
> nanog1 at
> Sent: Monday, 4 May, 2015 20:56
> To: nanog at
> Subject: Network Segmentation Approaches
> Possibly a bit off-topic, but curious how all of you out there segment
> your networks.  Corporate/business users, dependent services, etc. from
> critical data and/or processes with remote locations thrown in the mix
> which could be mini-versions of your primary network.
> There's quite a bit of literature out there on this, so have been
> considering an approach with zones based on the types of data or
> processes within them.  General thoughts:
> - "Business Zone" - This would be where workstations live,
>   web browsing occurs, VoIP and authentication services live too.
>   Probably consider this a somewhat "dirty" zone, but I should
>   generally be OK letting anything in this zone talk fairly unfettered
>   to anything else in this zone (for example a business network at my
>   HQ location should be able to talk unfettered to an equivalent
>   network at a remote site).
>   I'd probably have VoIP media servers in this zone, AD, DNS, etc.
> - Some sort of management zone(z) - Maybe accessible only via jump host
>   -- this zone gives "control" access into key resources (most likely
>   IT resouces like network devices, storage devices, etc.).  Should
>   have sound logging/auditing here to establish access patterns outsid
>   the norm and perhaps multi-factor authentication (and of course
>   FW's).
> - Secure Zone(s) - Important data sets or services can be isolated from
>   untrusted zones here.  May need separate services (DNS, AD, etc.)
> - I should think carefully about where I stick stateful FW's --
>   especially on my internal networks.  Risk of DoS'ing myself is high.
> Presumably I should never allow *outbound* connectivity from a more
> secure zone to a less secure zone, and inbound connectivity should be
> carefully monitored for unusual access patterns.
> Perhaps some of you have some fairly simple rules of thumb that could
> be built off of?  I'm especially interested to hear how VoIP/RTP
> traffic is handled between subnets/remote sites within a "Business
> Zone".  I'm loathe to put a FW between these segments as it will
> put VoIP performance at risk (maybe QoS on FW's can be pretty good),
> but maybe some sort of passive monitoring would make sense.
> (Yes, I've also read the famous thread on stateful firewalls[1]).
> Thanks!
> [1]
> fuu2+state:results

More information about the NANOG mailing list