Implementing Dynamic Authentication and Authorization
| Authentication means identifying a user, and authorization involves deciding what that user can do. Both are integral parts of an overall network security policy. Network authentication and authorization are not new problems. IT departments the world over are making their users miserable by installing newer and "better" tools that make joining a network much more complicated than just plugging your laptop into the right port in a conference room. Of course, with regular security intrusions and threats, authenticated LAN access is, alas, a necessity. Virtualized Networks are no exception. In keeping with the general rule that what worked before virtualization must work after it, it must be possible to authenticate users but alsoand this is newto place them into the right network. To do this, there has to be a tie-in between the authorization and all the possible forms of tunnels being used for transport. For example, an engineering company with an on-site contractor might want to limit network access to the LAN segment where that person will work, perhaps in a laboratory, and then revoke all forms of access when the contract expires. The network must therefore be able to do the following:
In a virtualized environment, you will find the same authentication techniques as on a standard campus network, which is reassuring, because authentication needs to be based on something tangible: something you know, something you have, something you are. Authentication is an important, if difficult problem for today's administrator. It is, however, already part of to network virtualization. Thus, our interest lies in authorization. Authorization is the link between a user's identity and the user's rights on a network. More specifically, authorization policy determines a user's network membership. In a Cisco environment, authorization manifests itself as Cisco IOS (or CatOS) commands applied to a user's traffic, usually at the interface level. In Virtual Network, these instructions contain VRF or VLAN names, or ACLs that determine which hosts or subnets are reachable for a user or group. There are many different mechanisms to manage network membership. We need to pick one that allows the most flexibility and is the easiest to manage. To give away the element of surprise, the recommendation is to use 802.1x where available. But to understand the design trade-offs, it is necessary to see that network membership can be static or dynamic:
The easiest way to allow regular change is to have a central policy store that all network devices consult before they forward user traffic. This in turn has implications for which mechanisms can be used to authorize users:
You get the general idea. In each case, authorization is done using different data: service set identifier (SSID), username and password, MAC addresses, and so on. The authorization commands (such as VRF/VLAN name, ACL name) can be statically configured or downloaded dynamically. Policy can quickly become complicated, often unduly so. The next sections discuss several of the different authentication and authorization options and their integration into the virtualized enterprise network. First, here is a final word on complexity. In our experience, it is better to keep things simple. Your network will work longer that way! In a campus environment, authentication can be
We will now look at each option in turn. Clientless AuthenticationThe term clientless refers to the fact that no special software is required on host machines for them to access the network. The benefits of this are enormous: no special installation, no maintenance and upgrades, and no issues with compatibility. In LAN environments, a clientless solution involves using a network address as the user (or host) identifier. Figure 11-2 shows a topology where hosts are authorized against their MAC address. When an end station is connected the first time, it sends a DHCP or Address Resolution Protocol (ARP) packet. The wiring closet switch intercepts the first packet and checks whether the source address is allowed to connect on this port. If so, the switch places the port into a VLAN and forwards all traffic thereafter normally. Figure 11-2. MAC Authentication All the different components come together in this simple example. Hosts are authenticated with their Ethernet addresses. The authorization policy simply grants or blocks network access and places the port in the appropriate VLAN. Before looking at the implementation details, how good is this solution? The benefits include the following:
On the other hand, there are a number of obvious problems here. First, MAC addresses are not especially trustworthy because they can be changed. Malicious users can easily alter their Ethernet address. Innocent users can do the same thing when they replace a wireless adapter or change laptop. This brings us to the second problem: How does the switch know which addresses are allowed onto the network in the first place? There has to be a long list somewhere for the switch to query when an address appears on the network for the first time. Finally, static VLAN configuration is cumbersome if you expect to have a dynamic group membership environment. The next section examines two different implementation alternatives of Layer 2 clientless authentication: a distributed approach using the port security feature found on Cisco switches, and a centralized one using VLAN Membership Policy Server (VMPS). Static Clientless ImplementationPort SecurityThe port security feature configures switch ports to forward only traffic from a given MAC address. If another machine tries to use the port, all their traffic is dropped. The switch command needed to activate port security is as follows: set port security 2/1 maximum 2 This example goes one step further by limiting the number of allowed MAC addresses on port 2/1 to just two. In addition to just locking down each port with a set number of addresses, port security also lets you tell the switch to accept traffic either from only preconfigured addresses or from the first N addresses it learns. There are multiple applications of port security. It allows protection against MAC address spoofing by preventing users from changing their address. It can also be used to lock down a port that belongs to a given user. For example, if network policy states that only one user can ever use a port in dormitory, port security can limit the MAC address accepted on the port to the first address learned after the port transitions to link up. After school starts, students connect their laptops to their ports and thus "burn in" their access rights for the year. This system is not perfect, of course, but it will work in a large number of cases, freeing up the support team to fix the unusual cases or problems. What does this have to do with virtualization? Port security enables you to safely and statically bind ports to a VLAN. For example, a factory floor might have measurement and control systems running on Windows 3.1 (such scenarios exist!) that must be part of a virtual network used to manage production systems. Because of security risks, no unauthorized user can connect to the production network. The most pragmatic way to authorize such old software is to statically configure the VLAN names on the access ports. This, of course, opens up the security risk that some other user physically might connect a different machine on one of the preconfigured ports. Port security mitigates this risk because it can be used to list the MAC addresses authorized on the ports. Note Admission control based on MAC addresses is always susceptible to spoofing. It is easy to change a MAC address on a laptop, for example. And it is common for MAC addresses to be labeled on PCs for inventory-management purposes. The static, distributed approach makes sense when only a small number of ports need to be locked down (and when all other options fail). Despite the flexibility, it would be unwise to view port security as a general-purpose network-wide mechanism to map users to VLANs, because you need to correctly configure every MAC address on every port on every switch. There are better alternatives and, quite frankly, life is too short. Instead, we need a central server where MAC addresses and VLAN mappings are configured just once and made available to all switches on the network. It so happens that there is centralized solution for MAC authentication: VMPS. Centralized Dynamic Clientless AuthenticationVMPSVMPS was created by Cisco in the late 1990s to provide a way to dynamically assign MAC addresses to VLANs. Port security statically binds a host to a port (and, optionally, a VLAN). VMPS uses MAC addresses as a proxy for user identity and dynamically binds a MAC address to a VLAN. Under such a scheme, when a user connects to any port in the network, the switch will query a central server to find out which VLAN the host belongs to. Figure 11-3 shows the main components of a VMPS solution. One of the switches in the network is the primary VMPS server that contains the canonical list of address-VLAN bindings. Figure 11-3. VMPS Solution The server downloads the list from a TFTP server when it boots up. All other switches are VMPS clients and exchange query/responses (using UDP) to validate VLAN membership, as follows (the device names refer to Figure 11-3):
VMPS has a number of features that allow a network administrator to control how the switch behaves when no match is found. The default behavior is to drop traffic from the address, but the client switch port can also be configured in secure mode, in which case it is shut down if authorization fails. VMPS also supports the concept of a "fallback" VLAN. If the server does not find a VLAN name for the requested MAC address in its database, it can return a different VLAN name. The fallback feature is a simple way to create a guest VLANall known enterprise MAC addresses are stored in the VMPS database. All visitors, who have unknown addresses by definition, can connect but are placed in a fallback VLAN, which is only allowed Internet access. It possible to further refine VMPS policy by restricting VLAN membership to a particular port on a specified switch. VMPS also supports IP phones, which require an additional VLAN per port, which must be statically configured. VMPS allocates the native VLAN name and makes sure that two different VLAN IDs are used for each VLAN. The VMPS solution also has a graphical tool, called the User Registration Tool (URT), that enables administrators to easily edit VLAN membership on a Windows server and then make the resulting file available with TFTP to the VMPS primary and backup servers. The early versions of the product did no more, but URT has since been enhanced to integrate into an Active Directory (AD) structure. Now, in addition to host-based authentication, users can perform a Windows login to be able to connect to the network. These details are beyond the scope of this book and, for our purposes, it is enough just to know that there is a way to graphically administer the VMPS solution. VMPS is a sophisticated clientless authentication and authorization system. It allows central administration, with options for different behavior when a client address is not found in the database and support for VoIP. However, the trend today is definitely toward 802.1x, and we do not recommend VMPS as a general-purpose solution. After all, VMPS is proprietary and places an additional resource load on the wiring closet switches, which have to intercept packets, query servers, and so oneven as they forward other traffic at wire speed. As you will see, 802.1x has much stronger protocol security, albeit at the cost of putting software on the clients. Before looking at 802.1x, we should point out that all the discussion so far has focused on Layer 2, but IP address-based authorization is also possible. It is not secure, but we review the pros and cons in the following section. Layer 3 Clientless AuthenticationWeb ClientsLayer 3 clientless authentication can mean one of two things:
Consider the first option. Such a scheme makes sense when you need to restrict network access to entire subnets. For example, remote employees connect to a VPN concentrator and are allocated addresses from subnet 10.0.0.0/24. Network policy prevents these users from connecting to any lab machines (these network administrators are obviously inveterate control freaks, but that issue is beyond the scope of this book), so lab routers have an ACL rule, such as access-list 1 deny 10.0.0.0. 0.0.0.255. Note Because IP addresses are almost always dynamically allocated, it makes no sense to grant or refuse access at the port level using a host's source address in the way that we did with Layer 2. Otherwise, the network would have to allocate an IP address, and then decide whether the same address is allowed on the port the user was connected to when the user asked for the address in the first place! Another example that has been deployed is to implement a simple walled garden (where users are restricted to certain content). Subscribers connect to the network and receive a 10.0.0.0 address and default gateway from DHCP. This 10.0.0.0 subnet is not routed to the rest of the network, so users can connect only to local servers. Static or policy-based routing (PBR)-based VRF allocation are other (widely deployed) tools for Layer 3-based authorization. These are basically location-based policy setting schemes. The second option listed at the start of the section is web-based authorization. This solves a different problem, where the network needs to know the identity of the user before deciding what to do with them. The web-based approach can seem appealing at first blush because the Layer 2 equivalent802.1xappears complex to deploy. The reasoning here is that every host already has a web browser, and every user knows how to enter a name and password on a web page, so there is no need to deal with supplicants. However, web-based authentication is more expensive than it first appears. Figure 11-4 shows the setup. Before the user can authenticate, she needs to have an IP address to get to the registration server. However, we do not want her to be able to access the entire network yet, so she is limited to the 10.0.0.0 subnet, which allows her to reach the web server and nothing else (all this could be in a registration VRF, of course). After she authenticates, we need to move the user into the 192.168.1.0 subnet, which allows full access to the rest of the network. Here is where things get complicated because there is no way to tell an Ethernet host to return their IP address to get a new one. Figure 11-4. Web-Based Authentication A second complication is how to get the user to the registration server in the first place. You cannot expect users to remember an IP address, or even a name. So, the network has to intercept all HTTP traffic, and redirect Domain Name System (DNS) requests so that a standard browser will display the registration page correctly. The redirection mechanism must then be removed after the user is authenticated. To summarize:
The problem with the preceding simplified list is that there is no standard way to accomplish Step 8. However, there are workarounds such as scripts that telnet to the switch to reset the port, short DHCP lease times, DHCP reconfigure (RFC 3203), proprietary control protocols running between the server and switch to trigger VLAN or VRF changes, time-based TCP redirection, and Network Address Translation (NAT). These solutions are beyond the scope of this book. Web-based authentication schemes do exist and are popular at public access points such as conferences or hotels. Cisco offers multiple implementations. Building Broadband Service Manager (BBSM) is a Windows NT server-based solution designed for hospitality environments. Cisco Internet Services Group (ISG) is a service provider class solution that is integrated into high-speed edge routers. However, to date, we believe that there is no web-based alternative for general deployment in the enterprise access layer that is as efficient as 802.1x, which is our next topic. Client-Based Layer 2Client-based access has a long history in dialup and digital subscriber line (DSL) networks, where a PPP client implements authentication and authorization and allows the service provider fine-grain control over who can access their networks, what they can do there, how long they can stay, and so on. The similarities between public-access networks and enterprise LANs is striking because the problem we are grappling with is that it is no longer possible to know a priori whether a machine that connects to a LAN port is trustworthy or even whether it should be there. Service providers have long had to deal with people who should not try to connect to their network. In the late 1990s, the choice of PPP for DSL was not automatic because it involved distribution costs. Few operating systems at the time had a PPP over Ethernet (PPPoE) client, so the service provider had to send CDs to their customers with software stacks and provide support for installation and updates. Of course, this issue tends to dissipate with time as native implementations appear on the usual suspects of residential connectivity (Microsoft, Apple, Linux, Linksys, Netgear, and so on) and as the protocol definition stabilizes enough to mitigate incompatible implementations. For this same reason, client-based software was not an obvious choice for Ethernet authentication. However, as discussed in the section that covered clientless authentication, there is not much choice. The Ethernet protocol does not have enough hooks to provide strong access control. That is what the IEEE proposes to deliver with the 802.1x standard. 802.1x provides an authentication and authorization mechanism for Ethernet networks. The switch, called the authenticator, blocks all network access until the client, called a supplicant, successfully authenticates. Figure 11-5 shows the roles played by networked devices in an 802.1x environment. Figure 11-5. 802.1x Roles A definition of each role is as follows:
The 802.1x standard defines protocol details and state changes that determine how the switch access port is allowed to move from a state where it accepts only 802.1x frames to one where the supplicant can send traffic normally. 802.1x is important to us because it allows access ports to be dynamically placed into VLANs. This single feature means that it is a key component to a virtualized network, which still run VLANs between access and distribution layers. Next, we review some of the protocol-level details and discuss the interactions between 802.1x and the rest of the access layer functionality (for example, with DHCP). 802.1. x Protocol Details802.1x has protocols nested within protocols similar to a Russian matryoshka doll. 802.1x uses a transport mechanism (encapsulation frames and so on) to carry the Extensible Authentication Protocol over LAN (EAPOL) protocol between supplicant and authenticator. EAPOL, in turn, is the EAP protocol running over LANs. EAP comes to us from PPP, where it was created as an extensibleand standardizedauthentication mechanism that did not require IP. You can think of EAP as an extension to PPP whose purpose is to avoid the spread of proprietary authentication methods above and beyond the well-known Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). EAP is defined in RFC 3748 as a framework for exchanging messages until the supplicant is either authenticated or denied access:
EAP offers a duplicate-free, reliable transmission channel. Different authentication methods (item [d] in the RFC definitions), which are often written as EAP-SOMETHING (such as EAP-TLS, EAP-TTLS, and so on), are multiplexed over EAP allowing the endpoints to choose from a list of methods. Network administrators must select the methods that are the most appropriate and choose supplicants and servers that support them. Figure 11-6 shows the list of supported authentication methods on a modern operating system. Figure 11-6. EAP Authentication Methods Because EAP was originally written with PPP in mind, an encapsulation was required to transport it over Ethernet. Figure 11-7 shows the EAPOL format (from IEEE 8021x-2001).
PAE: EtherType code for PAE Protocol Version: set to "0000 0001" for current version Type: 0 EAP-packet 1 EAPOL-Start 2 EAPOL-Logoff 3 EAPOL-Key 4 EAPOL-Encapsulated-ASF-Alert Body: Present for types 0, 3 and 4 After all that background explanation, it is time to see how a client can actually gain access to a network. Figure 11-8 shows the protocol interaction between the different 802.1x roles. Figure 11-8. 802.1x Protocol Exchange The most relevant field is the Packet Type, which can have one of the following values:
You can see from the list that EAPOL adds only four messages to EAP semantics. EAPOL frames are sent to a reserved group address, 01-80-C2-00-00-03, called the PAE group address. This address is taken from the 16 reserved bridge protocol data unit (BPDU) addresses in the 802.1D standard. No switch should forward packets with this address. After all that background explanation, it is time to see how a client can actually gain access to a network. Figure 11-8 shows the protocol interaction between the different 802.1x roles. Before the supplicant connects, the switch port is in the unauthorized state. The client sends an EAPOL-Start message, and the switch (playing its authenticator role) replies with an EAP-Request Identity message. The supplicant's reply is relayed to the RADIUS authentication server, which then issues a challenge to which the supplicant must reply correctly. The supplicant can also issue a challenge to the authentication server, in the case of the mutual authorization scheme. When all parties have been authenticated, the RADIUS server sends the ACCESS-ACCEPT packet, which is relayed by the authenticator as the EAP-Success message. 802.1x events such as logon, authentication fail, and re-authentication are logged in RADIUS accounting messages. In reality, the implementation details can vary quite a lot from the description in the previous paragraph. Cisco Technical Marketing Engineering teams have done extensive testing that characterize some of the major differences and provide detailed design recommendations. Our own 802.1x-related recommendations are based on this in-depth research and excellent documentation. dot1x ImplementationExample 11-1 shows the Cisco IOS configuration needed to run 802.1x on a Cisco switch. The configuration is simple, with a global command to enable 802.1x and per-port activation using the dot1x port-control command. CatOS syntax obviously differs, but it is equally simple to configure. Example 11-1. 802.1x Cisco IOS Port Configuration
When activated, the switch sends EAP-Failure on link up, followed by EAP-Request/Identity frames. The supplicant should send EAPOL-Start, and then authentication can start. When the 802.1x process completes successfully, the switch puts the client MAC address in the CAM table so that it can always access the network, thus overriding any port security configuration that might be present on the port. Many client protocol stack implementations do not assume that they will run in an 802.1x environment, so they send out DHCP Discover packets before sending EAPOL frames. These are discarded by the switch, and the client will have to resend them after authorization completes. Supplicants also behave differently when users log on and off. Some send EAPOL-Logoff events so that the switch can put the port into unauthorized state and send EAPOL-Start when a new user logs on. Others do not, in essence reducing 802.1x to host, not user, authentication. Of course, that is acceptable on a network where user authentication is done using other mechanisms such as Kerberos, but it has some implications for network accounting that we discuss later. The basic configuration assumes a single host per port (and the IEEE documentation reinforces this by referring to point-to-point Ethernet links). Furthermore, 802.1x is intended for access ports and cannot be configured on trunks, Remote Switched Port Analyzer (RSPAN), and so on. As a result, Ethernet frames with source MAC addresses other than that of the supplicant are discarded. Cisco does not recommend connecting hubs to a 802.1x enabled port, but does provide two methods for dealing with such a scenario:
Because of the Ethernet group addresses used by the supplicant and authenticator, it should be impossible to connect a switch between supplicant and authenticator because EAPOL frames are not forwarded. When deploying 802.1x, you must decide which policy to apply to clients that do not, or cannot, successfully authenticate. It is not safe to assume that all clients have supplicants. Even those that do might not have the authentication method being used on the network. There are two basic options to manage such cases: MAC-auth-bypass and guest VLAN. MAC-auth-bypass is a centralized approach for hosts with no supplicant (we call it centralized because the client MAC addresses can be stored in a central RADIUS server). The advantage is that the switch first attempts to use 802.1x before falling back on the less-secure method. MAC-auth-bypass is compatible with VoIP and applies only to the port VLAN ID (PVID) (the voice virtual LAN (VVLAN) is always authorized). When the client fails to authenticate using 802.1x, the switch can try another method using the MAC-auth-bypass feature, which attempts to authenticate the learned MAC address using RADIUS (in other words, the switch does almost the same thing as it would have done if had detected a 802.1x supplicant). As shown in Figure 11-9, the client MAC address is used both as the username and password credentials in the RADIUS Access-Request packet. If the authentication, authorization, and accounting (AAA) server returns an Access-Accept, the client is allowed onto the network. For those who are familiar with network access server (NAS)-port authentication for DSL or dialup connections, this is analogous. Figure 11-9. MAC auth-bypass Runs After 802.1x The guest VLAN was designed to allow graceful migration to 802.1x. The configuration of guest VLAN requires the dot1x guest vlan VLAN command on the access ports. Hosts that do not, or cannot, authenticate with 802.1x are placed in a named VLAN that the administrator can configure to have limited network access. The switch typically attempts to authenticate the supplicant three times before placing the port into the guest VLAN. Note Guest VLANs might require supplicant support to avoid a possible race condition. Recall that client protocol stacks often send DHCP requests before attempting to authorize with 802.1x. It is possible that a client is busy waiting for DHCP while the switch is waiting for EAPOL. The switch's 802.1x timers can time out, and the port can be placed in guest VLAN before client is ready to negotiate. To avoid this, the switch 802.1x implementation should be able to remove clients from the guest VLAN if they receive an 802.1x frame and begin the authorization process anew (Cisco IOS has this "second-chance" feature). The supplicant should to be able to initiate EAPOL-Start (which is in accordance with spec) without seeing any EAP frames from switch. Some do, some do not. The auth-fail VLAN is a special case of the guest VLAN where supplicants that fail to authenticate are placed. This differs from the guest VLAN, which can only contain supplicants that did not attempt to authenticate. In other words, auth-fail is for those who try, but fail; guest is for those who did not try at all. Only a single MAC address is allowed on any port in the auth-fail VLAN. The switch can be configured to put guest and auth-fail hosts into the same VLAN. Incidentally, authentication failure can be defined as follows:
The network administrator needs to decide what policy to apply to the guest or auth-fail VLAN. The hosts can be directed to a server that allows them install or upgrade supplicant software, or the VLAN can simply allow Internet access. In either case, remember to provide a DHCP and DNS service for this VLAN, too. Returning to switch setup, the other major configuration step is to enable RADIUS authentication for 802.1x supplicants, which requires the following commands: aaa authentication dot1x default group radius aaa authorization network default group radius If you have worked with remote access, this part of the setup will look familiar. The execution of the preceding commands assumes that a RADIUS server is already configured on the device. Remember that that the server must be reachable on ports that do not themselves need authentication. The aaa authentication dot1x command is the basic command to use RADIUS for port authentication, and the aaa authorization network command allows dynamic VLAN assignment. The integration with RADIUS is the enabler for dynamic network selection. The authorization server sends the VLAN name in the RADIUS Access-Accept. The entire port is placed in the VLAN. The RADIUS attributes necessary for VLAN assignment are as follows:
VLAN assignment can be combined with other per-user policies that have either dedicated RADIUS attributes or Cisco vendor-specific attribute (VSA)-pair support. For example, you can instantiate per-user access lists, or apply QoS policy using attribute 26,9,1 with a value such as ip:inacl#1 = permit ip any any. Dynamic VLAN assignment appears to be a feature that every network should use without further thought. However, host software does not expect to change subnet when a user logs in. That is exactly what per-user VLAN assignment allows, however, so use it judiciously. Some operating system stacks that do support this feature attempt to ping the known default gateway (learned through DHCP during a previous user's session) every time 802.1x successfully authenticates. If there is no reply, it tries to renew its IP address. The DHCP relay forwards the packet to the (new) DHCP server, which can inform the client of the subnet change. The client then requests a new DHCP address. If the client does not have some way to adapt to subnet changes, it is better to enforce peruser policy at a higher layer (consult Chapter 8 "Traffic Steering and Service Centralization" for more information). As usual, the following question arises: What about voice? Just as with port security and VMPS, 802.1x works transparently with VoIP configurations. In the simplest scenario, phone ports are statically configured to bypass 802.1x authentication. On a Cisco network, it is possible to do a little better. If the switch detects a Cisco IP phone with Cisco Discovery Protocol Version 2 (CDPv2), it allows the phone's MAC address to join the voice VLAN. The native VLAN port, called PVID in 802.1x jargon, is still deactivated until 802.1x successfully completes, so hosts connected behind the phone are still authenticated. Figure 11-10 shows a typical deployment. A standard IP phone contains a three-port Ethernet switch, with one port connecting to the host, one to the on-board call processing logic, and the third to the LAN switch (because it is a switch, the phone really should not forward EAPOL frames, but it does anyway). If used, the RADIUS Tunnel-Private-Group-ID RADIUS attribute sets the native VLAN identifier, as you would expect. Figure 11-10. 802.1x VoIP Scenario (No Phone on Supplicant) Note There is a security risk here because any host that can spoof CDPv2 can in theory join the voice VLAN and attack the voice infrastructure (which should be protected, so the hole is not the end of the world, even if we would like to see it closed). The long-term answer is to put supplicants on IP phones, and this has started. Cisco high-end phones already have one, for example. Until then, many networks are open to unauthorized connection to the voice VLANthe CDP solution is actually an improvement over the norm. Note that you cannot unplug an authenticated phone and connect a PC in its place. The switch will see the link state and address change and will deny access. Just as for any supplicant, the phone's authentication can be easily monitored using a simple packet-capture program, which gives an attacker the ability to mount a replay attack using the captured packets. Strong password implementation is critical with tokens or public/private keys. We have covered 802.1x in some depth and alternate Layer 2 and Layer 3 clientless schemes. 802.1x is the most complete and robust authentication and authorization solution available, irrespective of whether the rest of the network is virtualized. The next section examines a simple design and shows how to use 802.1x in support of network policy and how to tie the access and distribution layers so that users have access to the right virtual network. |
EAN: 2147483647
Pages: 128