10.4. Network Infrastructure

The network switch infrastructure allows you to closely control access to the network.

When you want to control users and devices that get on the network, the closer you position the policies to the user, the more control you can have. In the case of network infrastructure, you can directly control whether the user can even get on the network, as well as what network he or she can access.

In an effort to make the network as secure as possible, move to a closed access network. The more closed, the better. By using NAC, you can control the actual ports on switches, which means that you no longer need a network drop that's open to the network, available for anyone to plug into. For example, say that a stranger walks into your building and sits down at a network computer that has an open network drop. What would he or she be able to access? If you have NAC, you don't have to worry about that scenario because you know that the NAC solution controls what he or she can see.

It can control and enforce policy in your network infrastructure in several different ways. Virtual local area networks (VLANs) often segregate traffic and users. We take a deeper look at VLANs in the following section.

Two main technologies control the actual switch port:

• 802.1X

• SNMP

10.4.1. VLANs

In your typical Layer 2 switched environment, all user traffic happens on the same network. So, both compliant users and out-of-compliance machines use the same network.

Over the last several years, you may have noticed some trends in the security and resilience of networks. While vulnerabilities increase, they directly affect the resilience of networks. Simply said, while more malicious applications (such as worms, viruses, and spyware) have emerged, networks have experienced more downtime.

NAC has the goal of minimizing potential problems. For example, take viruses. If you know that a machine poses a potential virus risk, you don't want to put that machine on the network, where it can affect other machines and potentially put your network at risk. VLANs let you separate the two types of machines — compliant and non-compliant.

VLANs segment switches into multiple Layer 3 or IP networks. In a typical unmanaged switch that has no VLANs, the entire switch is one broadcast domain. When a broadcast happens, it's forwarded across all ports on the switch. VLANs allow you to segment ports virtually into multiple broadcast domains or virtual networks. If you have a 24-port switch, you can configure ports 1 through 12 as VLAN 1 and ports 13 through 24 as VLAN 2. This configuration, in essence, creates two networks on the switch. All devices in ports 1 through 12 see only each other. Devices in ports 13 through 24 see only their own broadcast traffic. You create two different IP networks, one on each VLAN:

• Original unmanaged switch: An unmanaged switch that has no VLANs behaves like this:

  • VLANs: None

  • Ports membership: Ports 1 through 24 (the default network)

  • Layer 3 IP network: 192.168.1.100

  • Broadcast network: The default network (ports 1–24)

  • Switch configuration: One IP network, one broadcast domain

  An unmanaged switch is the most basic of all switching configurations. It includes one network and one broadcast domain. Every device on every port has the ability to communicate with every other device on the switch. Broadcasts pass over the entire switch.

• Managed switch with static VLANs: A managed switch that has static VLANs behaves like this:

  • VLANs: Two (VLAN 1 — Corp, VLAN 2 — Finance)

  • VLAN 1 ports membership: Ports 1 through 12

  • VLAN 2 ports membership: Ports 13 through 24

  • VLAN 1 Layer 3 IP network: 192.168.0.0/24

  • VLAN 2 Layer 3 IP network: 172.16.0.0/24

  • VLAN 1 broadcast network: Corp network (ports 1–12)

  • VLAN 2 broadcast network: Finance network (ports 13–24)

  • Switch configuration: Two IP networks, two broadcast domains

  This switch configuration behaves like two different physical switches, even though you really just virtually separate one physical switch. You can use this configuration to manually and statically segregate different ports into different networks.

• Managed switch with VLANs that dynamically uses it for NAC: A managed switch with VLANs behaves like this if the switch dynamically uses it for network access control:

  • VLANs: Three (VLAN 1 — Corp, VLAN 2 — Quarantine, VLAN 3 — Guest)

  • Ports membership: Ports 1 through 24 (VLAN 3 — Guest)

  • VLAN 1 Layer 3 IP network: 192.168.0.0/24

  • VLAN 2 Layer 3 IP network: 172.16.0.0/24

  • VLAN 3 Layer 3 IP network: 10.0.0.0/24

  • VLAN 1 broadcast network: Corp network (no ports)

  • VLAN 2 broadcast network: Quarantine network (no ports)

  • VLAN 3 broadcast network: Guest network (ports 1–24)

  • Switch configuration: Three IP networks, three broadcast domains (the Corp network and Quarantine network are closed by default)

You can use VLAN tagging to share VLANs across multiple switches:

You can choose from several standards when you configure VLANs. The most common standard used in enterprise networks is the IEEE standard 802.1Q. 802.1Q is an open standard that defines how it tags traffic with VLAN identifiers so that when that traffic passes between switches, it transfers the VLAN information.

Ports configured for normal access that have a VLAN configured for them are called untagged ports. These ports send out packets to the host that doesn't have an association with the VLAN, but the ports are configured as members of the VLAN to which the network assigns them. When the network dynamically uses NAC with managed VLAN switches, like in the list earlier in this section, the network statically configures the ports for VLAN 3 (the Guest VLAN). All devices that connect to that port join the Guest VLAN by default. By using NAC, you can also dynamically change which VLAN assigns to a particular port, in essence, moving the endpoint that's connecting to the network between different networks (in the form of VLANs).

The network can use two main methods of dynamically changing the port VLAN membership: 802.1X and SNMP.

10.4.2. 802.1X

802.1X is a standard that provides port-based authentication for switches and access points. You need several components to make 802.1X work (as shown in Figure 10-1):

• Supplicant (endpoint agent)

• Authenticator (switch or access point)

• Authentication server (RADIUS server)

Figure 10.1. The components of 802.1X.

10.4.2.1. Supplicant

The supplicant is generally a part of the endpoint agent. The supplicant communicates authentication information and, in some cases, endpoint integrity information across a network at Layer 2 to authenticate the user, all before the endpoint even has an IP address. This transport is called Extensible Authentication Protocol over LAN (EAPoL). This adds to NAC because you can pass authentication and endpoint integrity information across a Layer 2-only network before the endpoint receives an IP address.

A supplicant makes the most sense for managed corporate machine access to the network. In some situations, you may be able to leverage other supplicants, such as supplicants built into the operating system. Look for a NAC solution that allows you the flexibility of doing both.

10.4.2.2. Authenticator

The authenticator is the switch or access point that you leverage for 802.1X. The authenticator is a dumb device in the 802.1X world of authentication — put very simply, the switch (authenticator) needs only to collect authentication information sent from the endpoint (EAPoL data), and then send that information to the authentication server over RADIUS. It collects the Layer 2 EAPoL auth data, takes the EAP payload out, and puts it in Layer 3 IP RADIUS transaction (EAPoRADIUS). The authenticator acts as a go-between, moving EAP between the Layer 2 transaction and the Layer 3 IP transaction. The traffic across this 802.1X authentication transaction is encrypted and not in the clear.

The authenticator also has to satisfy several other jobs:

• When a client connects to the network, it sends an authentication request to the authenticator so that it can start the 802.1X auth process.

• If the endpoint authenticates successfully, the authenticator needs to open up access for that endpoint.

• If the endpoint doesn't have a supplicant, the authenticator doesn't get a response to the start of 802.1X, so it needs to time the port and perform an action. It might perform an action as simple as continuing to block the endpoint, or it may move the port to an unauthenticated VLAN.

The switch can open up access for an endpoint by performing one of several actions. When you use 802.1X, the port is closed (unauthenticated) if it doesn't have an endpoint connected to it. When an endpoint plugs into the port and authentication happens, the system can take many possible actions. In the simplest form, it can change the port from closed (blocking and unauthenticated) to open (forwarding and authenticated). In this case, the switch just starts forwarding traffic to whatever VLAN the system has statically configured the port.

IETF Request for Comment (RFC) 3580 allows the switch to also consume a set of RADIUS attributes that contain actions the system can perform on the switch port. The most common of these actions is to return a VLAN number to the switch. With this functionality, the switch can open the port and then change the VLAN to which the system is connected. This feature gives you the most control over network segmentation and access control when the system uses 802.1X.

A switch that supports VLANs, 802.1X, and RFC 3580 combine to create a powerful tool for switch-based enforcement. Find out whether your switches support these protocols. If they do (and most switches do), you can use them as a part of your NAC solution. If you already own them, you don't even have to buy them and can use them as enforcement points!

10.4.2.3. Authentication server

The authentication server is the brains behind the whole 802.1X operation. An 802.1X uses a RADIUS server as the authentication server. In most NAC solutions, RADIUS service is built into the policy engine, and you need to configure this RADIUS server on the switch. To configure your switch to use this server, you usually need the IP address of the authentication server and a shared key that you use as a part of the authentication process.

10.4.3. MAC authentication

Not every endpoint or device that connects to your switched network can run a supplicant and authenticate over 802.1X. These endpoints need to use MAC address-based authentication.

10.4.3.1. Switch dependence

MAC address authentication is a switch-dependent feature. When a device connects to the network, the switch asks it for credentials by using a Layer 2 802.1X request. If the device doesn't have a supplicant, it doesn't respond to the authentication request. The switch then waits, based on a configured timeout value. It then takes the MAC address provided by the device that's trying to connect and sends that address to the RADIUS server as the user name and password in an attempt to authenticate the device. If the RADIUS server has the MAC address in its database, it can pass the authentication and return an accept to the switch, which then opens up access. It can also return any RFC 3580-based attributes at the same time, in the same way that it can for a regular 802.1X transaction.

The difference between MAC-based authentication and 802.1X authentication is that the switch acts as both the supplicant and the authenticator in a MACbased authentication. You can use this functionality with any unmanaged devices, such as printers, fax machines, badge readers, and any other device that can't run an agent or supplicant.

10.4.3.2. Unauthenticated VLANs

You can use unauthenticated, or guest, VLANs when using 802.1X. If a device doesn't have an agent or supplicant, you may choose to connect that device to the network and then provide a capture portal or Web page for authentication by using an unauthenticated VLAN. This feature, which depends heavily on a switch, is unfortunately called a different name by each switch vendor.

When a device plugs into the network, the switch asks for the endpoint to authenticate over Layer 2. The device doesn't respond, either because it doesn't have a supplicant or the supplicant isn't correctly configured. The switch then automatically opens up the switch port in an unauthenticated VLAN after a configured period of time. After an endpoint gains access to this network, it can authenticate to a Web portal or even have the supplicant installed.

10.4.4. SNMP and CLI

SNMP (Simple Network Management Protocol)- or CLI (command line interface)-based control of the switch can control access. Instead of using an open standard for control of the switch, several vendors have cobbled together control mechanisms for switches that are based on management technologies.

In this scenario, the switch is configured in the SNMP control-based policy engine, with the policy engine as a SNMP trap server. When an endpoint connects to the network, the switch sends a SNMP trap to the policy engine that says the port on the switch came up. The policy engine connects back to the switch to get the MAC address of the device connecting to the switch. If the policy engine determines that the device should have access to it allows the device to have access, the policy engine then does a SNMP write or runs a CLI command on the switch to change the configuration of the port, usually changing the VLAN configuration. The policy engine changes the static configuration of the switch, and the device can now get access to the new VLAN.

SNMP and CLI NAC approach has some downsides:

• Inconsistency: SNMP or CLI is based on changing static switch configuration, and it lacks the security-based approach of 802.1X. Because of the static configuration, the actual switch configuration and what the policy engine thinks the switch configuration can be vastly different. This can allow open or mis-configured ports to bypass the security of your NAC solution. Because policy engines also modifies configuration on the switch all the time, you can't enable switch configuration change control on your network. A lot of inconsistency can show up down the road. You think your network is configured one way, but it's actually running a whole different way.

• Dependency: CLI and SNMP device control depends very highly on the device or switch involved. Different versions of software on the switch can make or break SNMP- or CLI-based control of the device. Version monitoring becomes very important in these types of NAC solutions.