shared workplace infrastructure in the public sector final - cisco · uk public sector shared...

© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. of 31

White Paper

UK Public Sector Shared Workplace Infrastructure

Secure connectivity for Public Sector agencies over shared wired and wireless

network infrastructures.

Summary

This whitepaper outlines solutions that can provide secure connectivity for Public Sector agencies over shared

wired and wireless network infrastructures. This guide is targeted at network professionals and other personnel

who assist in the design of Public Sector office networks and compliments the design patterns and principles

issued by GDS Common Technology Services (CTS).The solutions outlined in this guide have been developed in

response to a demand for:

location independent working to enable employees from multiple public sector agencies to work

collaboratively and without restriction from any public sector building;

extending secure connectivity beyond public sector buildings to enable efficient service delivery to the

citizen;

maximising the utilisation of public sector buildings through multi-tenancy and consolidation

reducing operating expenses through real-estate reduction.

Demand for increased flexibility, agility and automation.


Contents Requirements & Constraints ..................................................................................................................... 3

High-level Shared Workplace Infrastructure Design.................................................................................. 4

Shared Wide Area Network (WAN) Designs .............................................................................................. 5

Common Direct Network Service Provider (DNSP) ................................................................................ 5

Overlay VPN ........................................................................................................................................... 6

DMVPN ............................................................................................................................................... 8

DMVPN per-Tenant .......................................................................................................................... 10

MPLS over DMVPN ........................................................................................................................... 11

IPSec Requirements ......................................................................................................................... 13

A Hybrid WAN Architecture focused on Users Needs ..................................................................... 15

Shared Wireless SSID and Wired LAN .................................................................................................. 17

Wireless Coverage............................................................................................................................ 18

Network Separation ......................................................................................................................... 19

Network Access Control (NAC) ........................................................................................................ 20

Wired 802.1x Solution Overview ..................................................................................................... 20

Wired 802.1x Data & Voice Design Considerations ......................................................................... 21

Access by user enrolment (Guest Wireless Overlay Model) ............................................................ 22

IP Addressing .................................................................................................................................... 23

TrustSec ............................................................................................................................................ 24

Federated RADIUS Authentication Proxy Service ................................................................................ 26

Authentication Workflow ................................................................................................................ 27

Change of Authorisation (CoA) – RFC 5176 ..................................................................................... 28

Direct Internet Access (DIA) ................................................................................................................. 29

Solution Components .......................................................................................................................... 30


Requirements & Constraints

The following table lists the requirements and constraints which have been considered when designing the

services.

Table 1. Design Requirements and Constraints

Requirement / Constraint Notes

Compliance with current HMG

Information Assurance guidelines

Use of an assured transport network for unencrypted transmission of OFFICIAL data

Use of a CPA Foundation Grade IPSec or SSL VPN product (with Two-Factor Authentication)

and Walled Garden architecture for transport of OFFICIAL data over a non-assured network,

e.g. Internet

Managed End-User Devices only

Provide a “seamless” user

experience

Not IPSec or SSL VPN based

No reliance on Guest Wi-Fi access

Full access to “home” network

resources

Not relying on Citrix/Terminal Services/VDI services to access applications

Access to shared local resources,

eg. printers

Network designs should include provision for access to shared local resources

Overlapping IP schemes The majority of public sector organisations use the RFC1918 10.0.0.0/8 network for their

internal network resources


High-level Shared Workplace Infrastructure Design A shared workplace infrastructure design for a multi-tenant building includes a single wireless LAN SSID and wired

LAN switch infrastructure which all tenants share. In a shared infrastructure design, one or more VLAN’s are

created on the shared LAN for each tenant organisation and their users, both local and roaming trusted visitors, are

dynamically assigned to those VLAN’s as they are authenticated onto the network. Once connected, the user will

have secure access to:

shared network resources within the building such as printers;

their own organisation’s wider network via an Overlay VPN or Common Direct Network Service Provider

(DNSP) WAN connection.

Transport

Tenant 1 DC Tenant 2 DC

MGMT

WLC

AAA/ISE

DMVPN

Spoke

Router

T1

DMVPN

Hub

T2

DMVPN

Hub

Firewall Firewall

AAA/ISE AAA/ISE

AAA Proxy

T1

DMVPN

T2

DMVPN

MGMTAccess

Switch

T1 User

T2 User

Shared

SSIDT1 User

T2 User

Figure 1 - High-level Shared Infrastructure Design with 2 Tenants and Overlay VPN’s


Shared Wide Area Network (WAN) Designs

Common Direct Network Service Provider (DNSP)

The simplest form of multi-tenant building connectivity can be provided where all tenants have their WAN’s

provided by the same DNSP or Regional PSN provider. In this scenario, a single Ethernet WAN circuit can be

logically segmented between the tenants and the L3VPN’s of each tenant extended from the SP infrastructure to

the CPE router using VRF-lite technology. The WAN of each tenant is then presented on a separate physical LAN

interface on the CPE router and connected to each tenant’s own LAN infrastructure. Hierarchical QoS (HQoS) is

employed on the WAN circuit to dedicate portions of the available bandwidth to each of the tenants dependent on

their individual requirements.

T3 VRF

T2 VRF

T1 VRF

Tenant 1 WAN

Tenant 2 WAN

Tenant 3 WAN

Tenant 1 LAN

Tenant 2 LAN

Tenant 3 LAN

DNSP

Figure 2 – Common DNSP Design with 3 Tenants using VRF-lite

This approach benefits the tenants by reducing WAN costs to each tenant by eliminating the duplication of WAN

circuits and sharing the cost of connectivity between them.

Typically, one tenant will act as the lead-tenant and have the responsibility of:

Contracting with the WAN service provider;

Apportioning WAN costs to the other tenants and cross-charging them where appropriate;

Providing power, cooling, rack space, etc… for the NTE and CPE equipment of the provider;

Providing technical contacts, access and escort for service provider staff during commissioning and

troubleshooting of the WAN service during and outside of office hours;

Submitting change requests to the service provider on behalf of the other tenants.

A Common DNSP design is most appropriate for buildings where each tenant has a permanent presence requiring

dedicated wired and wireless LAN resources, e.g. a joint emergency services control room manned by police,

ambulance and fire & rescue staff. It is also commonly used technique at shared datacenter facilities.


Overlay VPN

In this model, all tenants share connectivity to a common transport network over which they construct overlay

VPN’s to connect their presence in the multi-tenant building to their corporate resources.

Overlay VPN’s have many advantages and solve the issues caused by:

Overlapping IP schemes within the public sector networks where all users will typically be trying to access

resources in one of many 10.0.0.0/8 networks;

The requirement for “seamless” access which prevents the use of techniques such as Network Address

Translation (NAT), Remote-Access SSL or IPSec VPN’s, Citrix, etc… that would typically be used as a

workaround for overlapping IP schemes. By using an overlay VPN for WAN connectivity, the user

experience is unaffected as the tunneling is moved from the end-user’s client to the network infrastructure.

Other advantages are:

supplier independence – two or more connectivity suppliers can be used for carrier resilience and the

ability to encrypt overlay VPN’s with IPSec allows a wider choice of suppliers;

transport independence – overlay VPN’s are not restricted to particular network connectivity, eg. the

Common DNSP model requires an Ethernet presentation with 802.1Q support. The ability to encrypt

overlay VPN’s with IPSec enables a choice of connectivity options e.g. MPLS, Internet based transport or

a hybrid of both.

security – each tenant can manage their own overlay VPN;

Internet usage policy enforcement - tunneling all traffic from the remote users will also mean Internet

access for remote users will always flow via their home organisation’s Internet connection rather than

using a local guest Internet breakout. This will ensure their Internet usage is subject to their home

organisation’s security and content controls even while working remotely;

speed to deploy – broadband Internet or wireless connectivity can be operational in days versus the

extended lead times on MPLS connectivity;

shorter contracts – broadband and wireless connectivity contracts are typically much shorter than those

of MPLS solutions providing maximum flexibility to the customer.

One disadvantage of the overlay model when compared to the Common DNSP model is the inability of each tenant

to reserve bandwidth on the shared WAN link for their own exclusive use. However, technologies such as

Adaptive QoS for DMVPN or the Intelligent Path Control capability of Intelligent WAN (IWAN) could be deployed to

alleviate application performance issues during periods of congestion.

The foundation of an overlay VPN design is a common transport network which provides connectivity to:

enable tunnel creation between the endpoints in each overlay network,

carry user and device authentication traffic between RADIUS servers, such as Cisco Identity Services

Engine (ISE), at the multi-tenant building and the user’s home network.

For the UK public sector operating at OFFICIAL level, the transport network can be:

an Assured network such as the PSN Shared Services VPN or an equivalent on a Regional PSN;

a suitably configured CPA Foundation Grade IPSec VPN over an unassured network, e.g. Internet;

or a combination of both (hybrid WAN);


The choice of transport network is likely to be decided based on the connectivity options available at the location

and the mix of tenants. However, for the majority of sites, a PSN connection into a Shared Services VPN from a

DNSP or Regional PSN is the most likely option as it provides:

assurance to permit OFFICIAL traffic to traverse in the clear;

service level guarantees;

additional security of a closed network;

less complexity compared to an Internet based VPN which requires PKI authentication

However, an Internet based VPN is a good option for:

providing additional bandwidth and/or secondary path to supplement a primary PSN connection;

extending network connectivity into non-public sector buildings to assist with the efficient delivery of

services, e.g. residential care homes where NHS and Local Authority Social Care staff attend regularly;

Providing connectivity for temporary or mobile locations, e.g. ad-hoc vaccination centres during a

pandemic.

Table 2. PSN WAN connectivity compared with Internet based Transport

PSN Shared Services VPN Internet VPN

Assurance PSN Assured None

Security

Limited to PSN members only

No internet access

Data sovereignty guaranteed

Open

Data sovereignty uncontrolled

Service Levels SLA backed Availability SLA only

Quality of Service Supported None

Connectivity Wired Wired & Wireless options

Suppliers Restricted to DNSP’s Unrestricted

As in the Common DNSP model, one tenant will act as the lead-tenant to own the relationship with the transport

connectivity provider(s).

Each tenant is likely to install their own router or firewall into the multi-tenant building to provide VPN connectivity

to their own services. However, it is possible for costs to be reduced further through sharing of VPN routers

between tenants through the use of VRF-Aware VPN technologies such as Dynamic Multipoint VPN technology

(DMVPN).*

* DMVPN is an accreditable encryption solution, as outlined within the PSN Technical Domain Description, as follows:

“An encryption architecture which utilizes mGRE NHRP (including proprietary implementations*) to form dynamic tunnels which adhere to the PSN Cryptographic Framework

(Interim or PRIME, unique key pair per end device and unique traffic encryption keys per security association)” (Cabinet Office: Technical Domain Description).


Tenant 1

Tenant 2

Common

Transport

Network

Tenant 1

Overlay VPN

Tenant 2

Overlay VPN

Tenant 1

WAN

Tenant 2

WAN

Figure 3 - Shared WAN Design with Overlay VPN's

Each tenant’s tunnel headend should be placed outside of a firewall at their DC so a security boundary can be

maintained between the remote users and their internal network and enable filtering of traffic from the remote

users.

Cisco’s DMVPN technology offers the simplest, scalable and flexible solution for overlay VPN’s and has been

deployed extensively by UK public sector agencies and suppliers.

DMVPN

Dynamic Multipoint VPN is a Cisco IOS feature that combines standards based protocols, GRE, NHRP and IPSec

together to form a solution that can deliver very large-scale overlay VPN networks with relatively simple

configuration and little operational overhead.

DMVPN is a very flexible technology which can be configured to operate:

In Hub & Spoke or Dynamic Full-Mesh modes;

With or without IPSec encryption;

With static routing, BGP, EIGRP, RIP or OSPF;

With VRF’s;

With Quality of Service (QoS);

With IPv6 as both the payload (IPv6 over IPv4) and/or the underlying transport (IPv6 over IPv6);

With MPLS.

Routers participating in a DMVPN network are classed as “Hubs” or “Spokes”. Hubs are typically placed in the

Data Centers closest to the applications. Hubs have Multipoint GRE (mGRE) interfaces through which they

maintain permanent tunnels and routing adjacencies with each of the spokes. Spokes can be added to a DMVPN

network without requiring any additional configuration on the hub.

In hub and spoke DMVPN deployments, all spoke-to-spoke traffic passes through the hub. But in dynamic full-

mesh deployments, only the first packets in a spoke-to-spoke flow are routed through the hub. The hub reacts to

the first packets in the spoke-to-spoke flow by sending NHRP indirect messages to the spokes which instruct them

to create a dynamic on-demand tunnel. Subsequent packets in the flow are then routed directly between the

spokes via the on-demand dynamic tunnel.


Figure 4 - DMVPN Static and Dynamic Tunnels

DMVPN is fully VRF-aware. This allows DMVPN tunnels to be sourced from and attached to VRF’s on a Cisco

router as well as the global/default routing table. Cisco routers can join multiple DMVPN networks with each in a

separate VRF if required. This facilitates the construction of different overlay topologies for each VRF or tenant.

DMVPN can also take advantage of Front VRF (fVRF) and Inside VRF’s (iVRF) which allow the tunnel source

interface and the tunnel interface to be in different VRF’s. The tunnel source interface is placed in the fVRF and

the GRE encapsulation/decapsulation process forms a secure “conduit” through to the tunnel interface placed in an

iVRF. This allows the internet to be used as a tunnel transport network safely as the internet connection is placed

in a separate VRF to the internal corporate networks.

The DMVPN networks for multi-tenant buildings can be deployed in one of two ways:

One DMVPN for each tenant. Each DMVPN can be on a separate router for each tenant or combined

onto a single shared router using VRF-Aware DMVPN. A DMVPN for each tenant allows different overlay

topologies to be created for each tenant and ensures maximum flexibility but increases configuration

complexity as the number of tenants rises.

A single MPLS enabled DMVPN. An MPLS enabled DMVPN reduces the overlay network to a single

DMVPN which is shared by all tenant traffic. Separation of the traffic flows is maintained by MPLS VPNv4

labels applied to the packets on ingress to the router from the iVRF’s. This model requires DMVPN hubs

to be provided centrally so is best suited to a Regional PSN service provided by a single service provider.

The choice of DMVPN per-tenant or MPLSoDMVPN will be determined by the number and type of tenants and the

configuration complexity each additional tenant introduces and the degree of flexibility required in the overlay

topologies.


DMVPN per-Tenant

PSN WWW


MGMT

WLC AAA/ISE

PSN

DMVPN

Router

WWW

DMVPN

Router

PSN

DMVPN

Hub

WWW

DMVPN

Hub

PSN

DMVPN

Hub

WWW

DMVPN

Hub

Firewall Firewall

AAA/ISE AAA/ISE

AAA Proxy

AAA ProxyT1 PSN

DMVPN

T2 PSN

DMVPNT1 WWW

DMVPN

T2 WWW

DMVPN

AAA

DMVPN

CSR1000v

T1 User T2 User T1 User

Shared

SSIDT1 User

T2 User

Figure 5 - Resilient Shared Infrastructure Design with PSN & Internet Transport – VRF-Aware DMVPN per-Tenant

In a DMVPN per-Tenant design, each tenant requires:

A DMVPN overlay. A separate DMVPN will be created for each of the participating organisations to

tunnel their traffic between their remote users and their Data Center. Dual DMVPN’s over two different

transport networks can be used for resilience

DMVPN Hub routers. Each tenant will require one or more DMVPN Hub routers to terminate their own

DMVPN’s. Dual Hubs should be used for resilience and hubs should be placed close to the applications.

One or more DMVPN Spoke routers. The DMVPN routers at the multi-tenant buildings will be spokes in

the DMVPN’s of each tenant. The spoke routers can be dedicated physical devices for each tenant or

shared between tenants with VRF-Aware DMVPN. Traffic between multi-tenant buildings will be carried

via dynamic on-demand tunnels.


Dynamic full-mesh DMVPN deployments. The DMVPN’s should be deployed in dynamic full-mesh

mode to support peer-to-peer applications between remote users at different locations on the DMVPN,

e.g. voice/video calls with Cisco Jabber

GRE encapsulation without IPSec protection on Assured transport networks. IPSec encryption of

the DMVPN networks will not be required if the transport network is an assured service appropriate for the

transport of user data classified as OFFICIAL (subject to local accreditor approval). Tunneling across

Assured networks is used as a workaround for the overlapping IP schemes rather than for security

protection purposes.

GRE encapsulation with IPSec protection on unassured transport networks. IPSec tunnel protection

must be enabled on Internet based DMVPN’s in accordance with CPA Foundation Grade IPSec Security

Gateway guidance.

Use of fVRF and iVRF’s. The DMVPN tunnels on each router will be sourced from IP addresses in an

fVRF attached to the transport network. The DMVPN tunnel interfaces will terminate in iVRF’s.

BGP. iBGP Is recommended as the dynamic routing protocol for the DMVPN overlays for its scalability,

stability and flexibility. The hubs should be configured as Route Reflectors and spokes should peer with all

hubs. iBGP is preferred for the hub-spoke peerings as it allows path manipulation easily using local-

preference and weight whereas eBGP requires AS path-prepending or MED.

MPLS over DMVPN

PSN

MPLSoDMVPN

SPOKE1

SPOKE2

SPOKE3

WLC1

WLC2

WLC3

AAA Proxy

HUB1

HUB2WWW

Tenant 1

WAN

Tenant 2

WAN

Tenant n

WAN

AAA

AAA

AAA

Multi-Tenant BuildingsTransport & Overlay

NetworksCentral DC & Authentication Departmental Networks

ASA/ASAv

ASA/ASAv

ASA/ASAv

Figure 6 - Shared Infrastructure Design with PSN & Internet Transport – MPLSoDMVPN


An MPLS over DMVPN design requires:

A single DMVPN overlay. A single DMVPN overlay will be created to tunnel the traffic for each of the

participating organisations from the multi-tenant buildings to a central datacenter. Traffic from the multi-

tenant buildings will be aggregated at the central datacenter and forwarded onto the individual tenant

networks, typically using an Option-A interconnect Dual MPLS enabled DMVPN’s over two different

transport networks can be used for resilience

Centralised DMVPN Hub routers. The MPLS enabled DMVPN will require hubs located in the central

datacenter. Dual Hubs should be used for resilience.

One or more DMVPN Spoke routers. The DMVPN routers at the multi-tenant buildings will be spokes in

the MPLS enabled DMVPN. All tenants will share the DMVPN routers and their traffic will remain

separated by VRF’s.

Dynamic full-mesh DMVPN deployments. The DMVPN should be deployed in dynamic full-mesh mode

to support peer-to-peer applications between remote users at different locations on the DMVPN, e.g.

voice/video calls with Cisco Jabber. Traffic between multi-tenant buildings will be MPLS switched over

dynamic on-demand tunnels. MPLS enabled dynamic tunnels are supported from IOS-XE 3.12S and IOS

15.4(2)T

GRE encapsulation without IPSec protection on Assured transport networks. IPSec encryption of

the DMVPN network will not be required if the transport network is an assured service appropriate for the

transport of user data classified as OFFICIAL (subject to local accreditor approval). Tunneling across

Assured networks is used as a workaround for the overlapping IP schemes rather than for security

protection purposes.

GRE encapsulation with IPSec protection on unassured transport networks. IPSec tunnel protection

must be enabled on Internet based DMVPN’s in accordance with CPA Foundation Grade IPSec Security

Gateway guidance.

Use of Global Routing Table and iVRF’s. In an MPLS enabled DMVPN, the tunnels MUST be sourced

from and terminated in the Global Routing table in order for BGP VPNv4 next-hop resolution to work

correctly. All customer facing interfaces, ie. the tenant VLAN’s are placed in iVRF’s

Multi-Protocol BGP (MP-BGP). MP-BGP with VPNv4 SAFI is the only dynamic routing protocol

permitted on the MPLS enabled DMVPN overlay although IGP’s can be run within the iVRF’s and

redistributed into MP-BGP just as in a normal MPLS L3VPN network. The hubs should be configured as

VPNv4 Route Reflectors and spokes should peer with all hubs.


IPSec Requirements

Internet Based DMVPN must use one of the following CESG approved IPSec profiles. At time of writing, the

guidance1 states:

Foundation profile is suitable for protection of OFFICIAL until 31st December 2021. This will be reviewed

on an annual basis

The use of “PSN Interim” profile is acceptable only until 31st December 2018

All VPN deployments should migrate to Foundation or End-State PRIME by 1st January 2018

Table 3. CESG Foundation and PRIME cipher suites

Algorithm Foundation End-State PRIME

Encryption ESP AES-CBC 128 AES-GCM 128

Key Exchange IKEv1 IKEv2

Hash HMAC-SHA256-128 HMAC-SHA256-128

Diffe-Hellman Group 14 Group 19

Authentication RSA X.509v3 ECDSA 256bit X.509v3

Certificate Enrollment/Re-Enrollment SCEP EST

Performance data for the ISR4000, ISR G2, ASR1000 and selected 800 series models using the Foundation profile

are available under a non-disclosure agreement (NDA). Please contact your Cisco Account Manager for further

details.

1 CESG document – Network Encryption at OFFICIAL v2.3


Software Defined-WAN (SD-WAN) – Cisco Intelligent WAN (IWAN)

Cisco’s Software Defined WAN (SD-WAN) solution is called Intelligent WAN (IWAN) and it enables customers to

augment their provider networks with alternative WAN transport services like Internet or mobile to build a hybrid

WAN architecture, and even offload public cloud traffic with Direct Internet Access.

Context-aware routing features like application visibility and intelligent path control help ensure the best user

experience. The transport path to the Data Centre via the Internet is secured using IPsec network encryption

technology – DMVPN, so the end-to-end delivery is secured. Cisco’s Access Routing platforms have been assured

via Commercial Product Assurance (CPA) Foundation Grade for IPsec VPN.

Application Visibility – includes uses a form of Stateful Deep Packet Inspection called NBAR2 to identify

and classify applications as they traverse the network and Performance Monitor which collects and

reports performance metrics of the applications

o NBAR2 is invaluable as it is no longer practical or possible to classify applications based on

Access Control Lists (ACL’s) any longer because:

the applications are moving to the cloud so the destination IP address is variable.

applications are all standardising on HTTP/S for transport. Distinguishing between

business critical applications and web browsing is no longer possible using L4 port

information alone. Application Visibility when combined with QoS mechanisms can

ensure business critical web or cloud-based applications have priority over web

browsing or guest Internet traffic across the network.

o Performance Monitor – is embedded into the router and:

collects performance metrics such as bandwidth usage, response time and latency of

TCP applications and jitter, delay, latency and loss of RTP applications such as voice

can export the performance data to external management platforms in NetFlow v9 or

IPFIX formats for use in capacity management or traffic analysis reporting

Intelligent Path Control – is based on Performance Routing v3.

o PfRv3 uses the application classification and realtime performance data provided by NBAR2 and

Performance Monitor to dynamically adjust the routing of individual applications to ensure their

performance requirements are met. This is different to standard routing based on the

reachability and metrics of destination network prefixes, e.g. with PfRv3 a voice call may be

rerouted because delay, jitter or packet loss on the primary path are causing a degradation in call

quality even though the primary network path is still available. With standard routing, as long as

the primary path was available the voice calls would continue to use it and call quality would

suffer

o PfRv3 also load-shares by default, i.e. it actively tries to maintain an equal split of traffic across

all links. So for tenants paying for resilient links into a multi-tenant building, instead of having

one link idle, both links are actively forwarding traffic.


A Hybrid WAN Architecture focused on Users Needs

A hybrid WAN architecture is a mixture of both provider services and other alternative transport methods like the

Internet or mobile networks.

Private

Cloud

Public

Cloud

Virtual

Private

Cloud

MPLS

WWW

Cisco Cloud

Web Security

Branch

Hybrid WAN

Transport

(DMVPN)

Direct Internet

Access

Figure 7 - Hybrid WAN Architecture

A hybrid approach allows:

WAN bandwidth capacity to be added at significantly lower cost than MPLS

Improved performance of business critical applications by offloading internet and non-business critical

applications from the MPLS service onto the secure Internet path

Intelligent load-sharing of traffic across the MPLS and Internet paths so both paths are utilised

Improved availability of branch sites through dual WAN links and/or dual CPE routers

Improved performance of cloud-based applications by allowing branch users to access them directly via

the local internet connection versus tromboning through a central DC

The introduction of new services such as guest or citizen internet access

It is imperative that the WAN service characteristics match the user’s needs, so the following technical

considerations should be noted when considering Internet based transport.


Table 4. Internet based Transport Considerations

Advantages of Internet Transport Technical Considerations

Lower cost compared with, for example, a Multi-Protocol Label

Switching (MPLS) IP VPN service.

Speed and quality of the Internet connection. In general, quality has

increased but there are still large discrepancies in speed and reach.

Simple to transfer Service Providers (SP). Works over an Internet

connection so not tied to a single SP and can easily roam out of

region.

Maintenance contract on Internet connections. Most private networks

have very high SLAs associated with line and equipment fix. Typically

even with business Internet connections this is lower than when using a

private network particularly on line fixes.

Availability good enough particularly for sites that need

reasonably low speed.

Service SLAs. Private networks usually offer delay and packet loss on

a per QoS basis. Internet services typically don’t offer QoS and will not

offer any on-going guarantee associated with packet loss or end to end

delay.

DIA from the branch offers optimal traffic flows for users. Cloud

Service adoption is on the increase, so many businesses are

looking at local Internet breakout at the branch office to offer

optimised on-premise and cloud hosted solutions.

Ensure that the VPN created over the Internet is encrypted to the right

level for the organisation.

How will the data-in-transit security be applied without an Assured

underlying transport? CPA Foundation Grade?

Could deploy for example, MPLS as primary and Internet as

backup to take a risk averse approach and lower costs.

Internet based threats and DoS attacks - Increased number of Internet

PoPs at the branch opens up the scale of Internet threats significantly.

Many points of control versus a smaller number of controlled and

monitored Internet Gateways.

Easy for SMEs to provide. Lose control over traffic flow and predictability - Internet connections

are often asymmetrical in nature which may impact some sites. Internet

traffic can also be asymmetrical in nature.

Cheaper services mean more sites may opt for dual-links. IWAN

may offer greater service resilience and application performance.

Limited (or no) QoS and impact on voice and video calls.

Faster provisioning from the SP’s, e.g. 10 days for Fibre to the

Cabinet (FTTC) Internet versus > 60 working days for L3VPN.

Place additional pressure on Core SP Networks - heightened during

Emergency Response Incidents.

Sites can be carrier independent. Data Sovereignty - some UK Internet traffic may route via other

countries - limited control.

Shorter contracts available vs Managed WAN. Cheap copper/fibre-based services will be delivered from the same

serving telephone exchange so true resilience/ carrier diversity requires

a circuit (e.g. fibre) to another PoP.

Protection from DDoS attacks through obscurity. On their DIA

connections, the branch sites only require a single public IP

address which would typically be supplied by DHCP from the

ISP’s address range. Providing the IP is not registered in DNS,

the identity of the branch site would be hidden from attackers.

Branches using DIA to access cloud applications could still be

working even if the organisation’s central internet connection was

experiencing an outage or DDoS attack.

Multicast and IPv6 support is lacking or non-existent on native

broadband.


Shared Workplace Network Designs

Shared Wireless SSID and Wired LAN

The shared workplace infrastructure relies on the creation of a new common SSID (e.g. GovRoam), which allows

all users in the multi-tenant buildings to connect automatically and follow the process of 802.1 x authentication

using EAP-TLS mutual authentication methods. Utilising these methods ensures that the connection is seamless to

the user, a secure connection to the wireless network is established and there is no requirement for captive portals.

Once authenticated, wireless and wired users will be dynamically placed onto a VLAN dedicated to their

organisation from where they will be able to reach shared resources and also their organisation’s wider network via

an overlay VPN or Common DNSP WAN connection.

When compared to broadcasting the SSID of each tenant’s corporate network at every site, creating a single

shared SSID has the following advantages.

Table 5. Shared SSID advantages

Shared SSID Distributed SSID’s

Manageability

Two Wi-Fi profiles to manage on End-User Device

One additional SSID to configure and advertise

One SSID per-tenant may exceed guidance of 4

SSID’s per-AP which prevents management

traffic impacting on bandwidth available for user

traffic

Scalability One SSID to configure and advertise One SSID per-tenant may exceed guidance of 4

SSID’s per-AP

Simplicity User education required No change for users

At small sites, a single VLAN per-tenant may be sufficient to accommodate wireless and wired users and each

VLAN can be trunked or bridged to the WAN router which provides L3 services. However, at large sites with

potentially hundreds of users from each tenant, a single VLAN would create a prohibitively large broadcast domain.

In this case, multiple VLAN’s should be created for each tenant in conjunction with VRF-lite on the LAN switches

and the traffic routed to the WAN router. Users can be spread over the VLAN’s based on the switch or wireless

access point to which they are connecting. This will be controlled by the user and device policy management

server (Identity Services Engine - ISE).


Wireless Coverage

If each department procured their wireless LAN infrastructure independently, there could be a number of

challenges with regards to RF coverage, interference and roaming, especially, if a common SSID is advertised at

both locations.

Consider a multi-floor building, with Tenant ‘1’ on floor 1, and Tenant ‘2’ on floor 2.

Tenant 2 – Wireless Management LAN

Tenant 2

WLC

Tenant 2 RF Roaming Domain

Tenant 1 – Wireless Management LAN

Tenant 1

WLC

Tenant 1 RF Roaming Domain

Tenant 2 Occupied Floor

Tenant 1 Occupied Floor

Shared Area /

Canteen, etc

Shared Area /

Canteen, etc

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Common

SSID

Tenant 1

User

Figure 8 – RF coverage, interference and roaming

If the same common SSID were advertised in both departments wireless architecture, a visiting trusted user

connected to the wireless within Tenant 1 on the first floor may potentially have visibility of the same SSID

advertised by Tenant 2 on the second floor.

As it is the decision of the client as to when it roams, there is always a potential for the trusted visiting client to

inadvertently roam onto the Tenant 2 advertised SSID, that will certainly impact upon the user experience. As

these two wireless implementations are discreet systems with no RF roaming capability or interaction, this would

be a hard roam for the client, resulting in a complete new 802.1x authentication, new IP address and potentially

new or different user policies, as per the local department security policy. This will cause delay, disruption and

impact upon any connections that client may have established, impacting upon the user experience.

Equally, the two systems may see each other as ‘Rogue’ networks, advertising the same SSID as their own

implementation, thus creating alarms. Also, they will both be attempting to utilise the same channel allocation,

potentially causing co-channel interference.

Therefore, strong consideration should be given in this scenario to the RF bleed between floors and the potential

for the impact to the user experience.

There are a number of features in the Cisco wireless LAN controller that may assist in mitigating this scenario,

such as turning off lower data rates, utilising Radio Resource Management (RRM) features to control the transmit

and channel allocation, optimised roaming feature, RX-SOP features, High Density Experience (HDX), clientlink

etc… but these are no substitute for an on-site RF survey, together with appropriate positioning and number of

access points.


Network Separation

Many questions arise around the connectivity of wireless LAN access points direct to the ‘OFFICIAL’ infrastructure.

It is good commercial practice to connect the wireless Access Points (AP) directly to the corporate infrastructure,

and indeed there are departments that have adopted this approach, either as a result of legacy deployments or due

to budget constraints during the design stages, avoiding separate infrastructure, but it is the most commonly

deployed method.

In evaluating your departments’ business need for wireless LAN connectivity, the risk mitigating factors should be

understood to ensure that it is acceptable for your department to attach AP’s directly to your trusted environment.

The diagram below attempts to outline some areas that could be considered in this approach. Other areas to

consider may be the type of traffic you are carrying over the wireless connections, such as corporate only, or

corporate plus trusted visitor or potentially the addition of open guest access.

WLC

Switch

Access

Point

Encrypted Control

CAPWAP tunnel

(FlexConnect or

Central Mode)

Data CAPWAP tunnel

(optional DTLS

encryption for Central

mode)

Data Traffic, local

drop off at switch

(FlexConnect)

Tunneling Options:-

CAPWAP DTLS from AP to WLC for

control traffic for both Central mode and

FlexConnect mode

CAPWAP from AP to WLC for Data

traffic – termination direct to WLC for

data traffic termination in central mode

Data traffic from AP to switch for

FlexConnect local traffic only

CAPWAP termination at directly

connected Catalyst switch for

Converged Access only

Optional DTLS for data traffic

Switchport Connectivity Options:-

Authenticate access point to

infrastructure using 802.1x for access

point to switch

Authenticate access point to wireless

controller using simple user name

password

Authenticate the access point to

controller using certificates

Options:-

Mutual Authentication

WPA2 AES encryption

EAP-TLS authentication

Backend RADIUS / PKI

(optional) Client VPN overlay – traffic

encrypted, what about management

frames?

PMF – Protected Management Frame

Wireless Risk?

Rogue Device detection

Noise source / interferer detection

Wireless Intrusion Prevention

Location tracking

Allow access from identified locations

only

Figure 9 – Network Separation Considerations


Network Access Control (NAC)

Client network access control (NAC) can be enforced on wireless and wired LAN infrastructure via 802.1x

authentication using Cisco Identity Services Engine (ISE), which will authenticate and authorise the client upon

connectivity to the network. ISE provides a granular level of control e.g. allow the client to only connect when at a

certain location, time of day, using only Apple devices and based upon being a member or an Active Directory

group. An access control list can be pushed to the edge to enforce connectivity for that client session, which will

only allow access to identified resources or internet only traffic.

The client device would utilise 802.1x mutual authentication against department RADIUS servers, utilising EAP-

TLS and department PKI digital certificates, thus ensuring confidentiality and integrity for the wireless connection.

Upon completion, the wireless session will be secured with a WPA2 AES encrypted session on a per-client/per-

session basis between client and access point. If adopting a local mode termination of data traffic, all client traffic

will be encapsulated within a CAPWAP tunnel to the controller, where this traffic will terminate. Optionally, the

CAPWAP data traffic can be enhanced with DTLS encryption, although it is assumed that this tunnel will be over a

trusted environment at this point anyway.

Wired 802.1x Solution Overview

IEEE 802.1X provides an authentication mechanism to devices wishing to attach to a wired or wireless LANs. It

involves three components: an authenticator, an authentication server and a supplicant.

Client

(Supplicant)

VoIP

(Supplicant)

Switch

(Authenticator)

Radius

(Authentication Server)

802.1X RADIUS

802.1X RADIUS

Figure 10 – Solution Components Overview

Authenticator

The authenticator is the switch that controls physical access to the network based on the authentication status of

the supplicant. The authenticator acts as an intermediary (proxy) between the supplicant and the authentication

server. The authenticator requests identity information from the supplicant via 802.1X, verifies that information with

the authentication server via RADIUS, and then relays a response to the supplicant based on the response from

the authentication server.

Authentication Server

The authentication server performs the actual authentication of the supplicant. By examining the information in the

encapsulated EAP messages relayed from the authenticator, the authentication server validates the identity of the

supplicant and notifies the switch whether or not the supplicant is authorised to access the LAN.

The user database is where user credentials used in 802.1X authentications are stored. This function can be

integrated into the authentication server or it can be an external server (i.e LDAP) to which the authentication

server has access.


Supplicant

A supplicant is an 802.1X client that runs on an edge device (workstation, laptop, phone). The job of the supplicant

is to request access to the LAN and respond to requests from the authenticator (the switch). The supplicant

communicates with the authenticator via 802.1X-encapsulated EAP packets its credential. Examples of IEEE

802.1X-compliant supplicant software include the Cisco AnyConnect Secure Mobility Client or the build-in

supplicant within Cisco IP Phones.

Wired 802.1x Data & Voice Design Considerations

Multi-Domain Authentication (MDA)

Multi-Domain Authentication (MDA) host mode is a feature that allows a Cisco switch to modify the default IEEE

802.1X requirement that only a single device can connect to a switch port while retaining the security and visibility

that IEEE 802.1X provides.

When properly enabled for MDA, the switch divides the switch port into two virtual “domains” (a domain is

equivalent to a VLAN on a wired network). The switch independently and asynchronously authenticates the phone

and the device behind the phone. When the phone authenticates successfully, it is given access to the voice

domain. When the device behind the phone is authorised, it is given access to the data domain.

Mac Authentication Bypass (MAB)

One of the challenges linked to any 802.1x implementation is related to agent less devices or devices that haven’t

been provisioned or configured with the needed credentials to authenticate to the network.

MAB initiates only after an 802.1x timeout. MAB would then require a variable amount of time to learn the MAC

address of the end station. It has to wait until the device try to send some traffic to the network in order for the

switch to learn its MAC address. Once this has occurred, a RADIUS exchange is initiated to the backend server

asking whether the MAC address should be allowed network access.

Web Authentication

WebAuth enables a Cisco Catalyst switch to check a user’s credentials submitted through a web login portal on the

switch.

Inaccessible Authentication Bypass

If an IEEE 802.1x authentication fails because the AAA server is unavailable, the switch can be configured to allow

clients access to a special VLAN (sometimes called the “Critical VLAN”) that provides configurable access to the

network. The Critical VLAN can be any VLAN except for the voice VLAN.

Inaccessible Authentication Bypass for Voice

Inaccesible Authentication Bypass for Voice feature will authorise the switch to accept tagged traffic with the voice

Vlan on the port and will place the device in the configured voice Vlan of the port in case the AAA are down.

Open Authentication (Silent Run)

By default, IEEE 802.1X drops all traffic prior to a successful IEEE 802.1X (or MAB) authentication or WebAuth

initialisation. This is sometimes referred to as closed mode (enforce mode or active mode). Cisco switches can be

configured for open-access mode, which allows all traffic (in both the data and voice VLANs) prior to successful

authentication.


Access by user enrolment (Guest Wireless Overlay Model)

In addition to the shared SSID, guest wireless LAN access will be required for visiting users who:

are trusted visitors from public sector organisations that are not participants in the shared infrastructure

service;

are untrusted users (guests).

Guest network deployments generally consist of an open network SSID, thus DNS / DHCP would need to be

controlled to allow wireless client connectivity.

Once connected the guest wireless user will be challenged via a web authentication page to control the guest

user’s access. User authentication, authorisation and network policies can be simplified by the use of Cisco Identity

Services Engine (ISE) with the controller conducting Central Web Authentication.

A tailored portal on a per-department or on a per-site location can be presented to the guest user for access into

the guest network. A series of criteria can be defined in ISE to be entered by the guest and captured within ISE, as

well as accepting the Acceptable Use Policy (AUP) before they are successfully allowed access.

ISE has the flexibility to allow users self-registration; self-registration with pin access (e.g. user creates a username

/ password, but must still obtain a pin code from reception for example); self-registration with sponsor approval and

sponsored guest access, each of which can be sent to the user via email, sms or print.

Upon completion of authentication, the authorisation profile can be used based upon client location; time of day;

how they are connecting; what type of device it is; or who they are, allowing a policy to be defined centrally in ISE

to control network access at the edge. For example, you only want apple devices, connected in the shared area

location to gain network access during 9am to 5pm weekdays, and to the Internet only.

For ensuring that the guest traffic is logically separate and non-reachable or routable from the corporate

infrastructure, the most commonly deploy architecture is to adopt a guest anchor wireless controller in an Internet

DMZ. All guest traffic in this instance will be tunnelled from the access point the central controller, then immediately

encapsulated within a tunnel from this controller to a DMZ based controller where this traffic will terminate. At no

point is the guest traffic within exposed to the corporate network, as such the point of presence from a network

perspective will be within the DMZ. This also allows additional controls to be placed upon this traffic at a single

central location, instead of many distributed touch points across the network. It also allows a single point for any

additional monitoring or logging of traffic as necessary.

To ensure your corporate traffic is not affected by bandwidth utilisation of the guest traffic on the wireless network,

there are measures that can be taken in the controller to ensure air time fairness of corporate SSID over guest

SSID, together with steps such as rate limiting and utilising application visibility and control to prioritise applications

or drop others.

For information around the different types of web authentication available via the wireless LAN controller, please

refer to the following document:

http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide-00.html

http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide-00.html


IP Addressing

As there will be no direct routing between the VLAN’s of the different tenants, the IP subnets to be used to address

the devices on each VLAN should be supplied from each tenant’s own internal addressing schemes. This avoids

the complexity of having to find an RFC1918 address range which is unique across all tenants.

DHCP & DHCP Relay

Once an authenticated user has been placed onto the appropriate VLAN, the user’s device will attempt to obtain an

IP address via DHCP.

At smaller sites, the WAN router can provide DHCP service by either:

Running a vrf-aware IOS DHCP server to offer IP configuration locally;

Running DHCP Relay on the VLAN sub-interface to unicast the DHCP request to a central DHCP server

at the user’s home network via the DMVPN.

At larger sites, DHCP can be offered by either:

Local DHCP server(s);Running IP-Helper on the SVI interfaces of the LAN switches to unicast the DHCP

request to a central DHCP server at the user’s home network via the WAN router.

IPv6

Dual-stack is the preferred, most versatile way to deploy IPv6 in existing IPv4 environments. IPv6 can be enabled

wherever IPv4 is enabled along with the associated features required to make IPv6 routable, highly available, and

secure.

The primary advantages of dual-stack are that it does not require tunneling over the IPv4 networks and offers

processing performance advantages because packets are natively forwarded without having to account for

additional encapsulation and lookup overhead.

However, there is an associated increase in overall network utilization and workload that derives from transmitting

and processing control traffic generated by the IPv4 and IPv6 protocols simultaneously. IPv6 can also increase the

memory utilization on network devices from maintaining neighbor tables if devices are using multiple IPv6

addresses on the same interface.

In a shared building, a dual-stack deployment would allow tenants to move to IPv6 at their own pace as the IPv6

features can be enabled on their LAN interfaces and WAN devices independently of the other tenants.

The most important consideration is to ensure that any devices which are deployed in the network such as

switches have support for IPv6 in hardware.

The Dual-Stack model requires IPv6 support across the entire network from end-to-end.

IPv6 is supported by DMVPN in:

IPv6 over IPv4 transport

IPv6 over native IPv6 transport

EIGRP supports IPv6 in VRF-Lite configurations in Named configurations only.

OSPFv3 supports VRF-Lite


Table 6. IPv6 supported products

Component IPv6 Support Notes

Overlay VPN - DMVPN Yes IPv6oIPv4 & IPv6oIPv6

Overlay VPN - IWAN No PfRv3 does not support IPv6 currently

Identity Services Engine Yes

Catalyst 2960-X Yes

Catalyst 3650 Yes

Catalyst 3850 Yes

Catalyst 4500E Yes With Sup7E

Catalyst 4500X Yes

Catalyst 6500 Yes

Catalyst 6800 Yes

ISR4000 Yes

ASR1000 Yes

AnyConnect Secure Mobility Client Yes SSL VPN Only currently

2500 WLC Yes

5520 WLC Yes

8540 WLC Yes

http://www.cisco.com/c/en/us/solutions/industries/government/global-government-certifications/ipv6-certified-

list.html

IPv6 address allocation to hosts on the tenant VLAN’s can be assigned via Stateless Address Autoconfiguration

(SLAAC), static assignment or DHCPv6. DHCPv6 assignment is likely to be the predominant method and just as in

the IPv4 address assignment section earlier, DHCPv6 addresses can be delivered locally by the WAN router or

from a remote DHCPv6 server using DHCPv6 Relay.

SLAAC may be preferred if the end devices (such as older Apple products) do not have support for DHCPv6.

/64—On Tenant VLAN interfaces, it is recommended to use a /64 prefix because it is easy and consistent for

address management and a /64 is assumed for correct operation of SLAAC, SEND, and privacy extension use.

Although IPv6 does not use broadcasts and a /64 can have billions of hosts attached, it is still good practice to limit

the Tenant VLAN’s in the same way as would be done for IPv4 subnets.

IPv6 should operate correctly over WLAN access points in much the same way as IPv6 operates over Layer 2

switches.

Cisco supports the use of IPv6-enabled hosts that are directly attached to Cisco IP Phone ports, which are switch

ports and operate in much the same way as plugging the host directly into a Catalyst Layer 2 switch.

TrustSec

Cisco TrustSec provides an alternative mechanism for segmenting users on a shared network and will offer greater

scalability and operational simplicity when compared to allocating VLAN’s for each tenant organisation.

With TrustSec, instead of assigning users to specific VLAN’s as they authenticate onto the network, they

http://www.cisco.com/c/en/us/solutions/industries/government/global-government-certifications/ipv6-certified-list.html

http://www.cisco.com/c/en/us/solutions/industries/government/global-government-certifications/ipv6-certified-list.html


are assigned to Security Groups. Once assigned to a Security Group, each user’s traffic is marked with a

Security Group Tag (SGT) which are then used throughout the network to enforce security using Security

Group Access Control Lists (SGACL’s). SGT’s provide segmentation on a per-user level over shared

LAN’s, WLAN’s and VPN networks and simplify the application of security by divorcing security policy

from static elements such as IP addresses, subnets and VLAN’s.

At the WAN router, if SGT’s are used instead of VLAN’s, user traffic can be mapped to the correct iVRF

and WAN using SGT Based Policy Based Routing (PBR). SGT Based PBR will route packets into VRF’s

based on their SGT marking. This simplifies the network by eliminating the need to trunk multiple VLAN’s

to the WAN router or creating a L3 interface for each tenant.

One disadvantage to using TrustSec in a multi-tenant building, is the IP addressing of the shared subnets

at the multi-tenant building would need to be unique across all the tenant’s wider networks to avoid

overlaps or clashes with the tenant’s internal subnets.

Cisco has submitted the Source-Group Exchange Protocol (SXP) to the IETF as an Internet Draft. SXP is

a control plane protocol, which carries SGT to IP address bindings throughout the network and is

fundamental to the operation of TrustSec. Cisco has also made available an open source SXP

implementation for other vendors to utilize and also submitted the data plane method of carrying Source

Group Tags on Ethernet to the IETF.

Access to Shared Resources

Two possible approaches to accessing shared resources from the VLAN’s are detailed below.

Remote User VLAN’s

DMVPN Router with IOS Firewall

PSN WWW

Shared Resources LAN

Figure 11 – IOS-XE Zone-Based Firewall for Inter-VRF Routing

PSN WWW

Shared Resources LAN

DMVPN Router

Remote User VLAN’s

Figure 12 - Dedicated Firewall for Inter-VLAN Routing

Use a dedicated firewall to provide

routing and filtering between the

Remote User VLAN’s and the Shared

Resources VLAN.

The DMVPN router can use ICMP

redirects to send traffic for shared

resources to the firewall.

Or use static NAT for shared resources

so the devices appear on the Remote

User VLAN’s.

This solution is best suited to larger

locations.

Place the shared resources into their

own iVRF.

Use the Zone-Based Firewall in the

IOS-XE router to provide routing and

filtering between the tenant iVRF’s and

the Shared Resources iVRF.

This solution is best suited to smaller

locations.


Integration & Interoperability

Federated RADIUS Authentication Proxy Service

Authentication of users onto the shared SSID and wired LAN is ultimately performed by a RADIUS server located

within the user’s “home” network. This allows each organisation to maintain control and monitoring of users

accessing their network and avoids reliance on a third-party. The WLC’s and switches providing access to the

shared infrastructure service send authentication requests to a local RADIUS server within the multi-tenant building

in the first instance. The local RADIUS server uses the domain name or realm included in the user’s credentials to

identify if the user can be authenticated locally or if the request should be forwarded to the central RADIUS proxy

servers. The central RADIUS proxy servers also use the domain name in the user’s credentials to identify the

RADIUS server to forward the request to. The internal RADIUS servers and central RADIUS proxy servers must

have connectivity over the transport network to facilitate the proxy operation.

Cisco Identity Services Engine (ISE) can support up to 50 separate Active Directory domain servers if required, or

be used as the Federated Radius server, for multiple government departments. Equally, the ISE server can forward

RADIUS request from the local department site and if required, depending upon the RADIUS method deployed,

can strip both the prefix or suffix realm from the RADIUS request and direct to a federated system to authenticate

against the home network RADIUS.

When the RADIUS Accept messages are returned to the local RADIUS server via the proxy, the local RADIUS will

perform dynamic VLAN assignments by injecting RADIUS attributes (IETF64, IETF65 and IETF81) into the

RADIUS Accept messages before forwarding them to the WLC or access switch. This ensures each tenant’s

VLAN’s are only locally significant to the shared LAN infrastructure within the multi-tenant building.

Each multi-tenant building will require a standard VLAN mapping to be created for the tenant organisations.

Table 7. Example of Tenant VLAN mapping

Organisation Tenant VLAN

Tenant 1 10

Tenant 2 20

Tenant 3 30

Tenant 4 40


Transport


MGMT

WLC

AAA/ISE

DMVPN

Spoke

Router

T1

DMVPN

Hub

T2

DMVPN

Hub

Firewall Firewall

AAA/ISE AAA/ISE

AAA Proxy

T1

DMVPN

T2

DMVPN

MGMT

Access

Switch

T1 User

T2 User

Shared

SSIDT1 User

T2 User

1

2

3

4

5

6

Radius Accept plus the following attributes:

IETF 64 (Tunnel Type) = VLAN

IETF 65 (Tunnel Medium Type) = 802

IETF 81 (Tunnel Private Group ID) = VLAN ID eg. 10 for Tenant 1 Figure 13 - Authentication Flow and Dynamic VLAN Assignment

Authentication Workflow

1) Radius authentication request message from WLC or access switch sent to local Radius server

2) Local Radius cannot authenticate user from its own local user list so forwards the authentication request

to the Federated Radius Proxy

3) Radius Proxy forwards the authentication request to the user’s home Radius server

4) User’s home Radius server authenticates the user and responds to the Proxy with Radius Accept

message

5) Proxy forwards the Radius Accept to the Radius server at the shared building

6) Local Radius server performs dynamic VLAN assignment by injecting Radius attributes into the Radius

Accept message before forwarding it onto the WLC or access switch


Change of Authorisation (CoA) – RFC 5176

The standard RADIUS authentication and authorisation process typically uses a “pull” model, in which the requests

originate from a network device and a response is sent from the queried RADIUS servers. RADIUS CoA requests

defined in RFC 5176 are used in a “push” model, in which external servers can request network devices to initiate

or re-initiate the authorisation process. This mechanism allows RADIUS servers to dynamically update the policy

applied to individual sessions after they have been authenticated, e.g. moving a user to a quarantine VLAN or

terminating their session in response to the detection of suspicious behaviour. Wired and wireless LAN equipment

with support for CoA / RFC5176 should be deployed at multi-tenant buildings.


Direct Internet Access (DIA) In some scenarios, organisations may prefer their remote users to have Internet access from a local connection at

the multi-tenant building rather than backhaul the traffic over the WAN network to their central Browser Internet

Gateway. This approach can benefit the user experience by:

providing a more efficient path for accessing public cloud-based applications;

preserving bandwidth on PSN MPLS links for the most critical centrally delivered applications.

At sites with local Internet connections, the WAN router can offer direct Internet access to these users by using the

IOS Zone-Based Firewall to:

route packets from the tenant iVRF’s to the shared Internet fVRF;

perform NAT or PAT of outbound internet traffic from the internal RFC 1918 addresses to a public

address;

provide stateful inspection of outbound traffic and enforce a policy that only allows:

o inbound traffic in response to sessions initiated by internal users;

o the protocols required for DMVPN tunnel establishment.

(optionally) provide content scanning of HTTP and secure HTTP (HTTPS) traffic and malware protection

services to web traffic by transparently redirecting HTTP and HTTPS traffic to the Cisco Web Security

cloud;

(optionally) provide caching and pre-positioning of web-based content which preserves internet bandwidth

and improves performance by serving content locally using Cisco WAAS and Akamai Connect features.

Note: – Cloud Web Security, WAAS and Akamai Connect require the addressing in each iVRF to be non-

overlapping for correct operation with VRF’s.

Tenant VLAN

DMVPN Router with

IOS Firewall

PSN WWW

Primary WAN

- to central DC -

DMVPN Backup

- to central DC -

Internet & VPN

Tunnel Traffic

Figure 14 – Direct Internet Access Schematic


Solution Components

Table 8. Available platforms for high-density, large campus2

Component Enterprise Mission Critical Best In-Class

Overlay VPN DMVPN iWAN Base

(DMVPN & PfRv3)

iWAN Advanced

(Base + AVC & WAAS/AKC)

WAN Router ISR4000 ISR4000 / ASR1000 ISR4000 / ASR1000

Wireless LAN Controller 8500 or 5500 (AireOS) 8500 or 5500 (AireOS) 8500 or 5500 (AireOS)

Access Points 1700 2700 3700

Access Switches Catalyst 2960X Catalyst 3650,3850 & 6800IA Catalyst 4500E & 6800IA

Distribution Switches Catalyst 3850 Catalyst 6880-X Catalyst 6807-XL Sup-2T

Core Switches Catalyst 6800 Catalyst 6800 Catalyst 6800

Authentication ISE ISE ISE

802.1X Supplicant AnyConnect Secure Mobility Client AnyConnect Secure Mobility Client AnyConnect Secure Mobility Client

Management Prime Infrastructure 3.0 Prime Infrastructure 3.0 Prime Infrastructure 3.0

2 From Cisco Campus LAN and Wireless LAN Design Summary, October 2015


Q&A

Q. Can the service expand to accommodate additional members?

A. Yes. Each new participant will require a new Remote User VLAN, iVRF and DMVPN overlay network in

addition to configuration required to make their internal AAA server reachable from the central AAA proxy

Q. What ISR/ASR models and software are suitable for DMVPN?

A. The ASR1000, ISR G2, ISR 4000 and selected 800 series models support DMVPN. DMVPN requires the

Security feature license

Q. What ISR/ASR models and software are suitable for MPLS over DMVPN?

A. For MPLS support on the ISR range, the AppX and Security feature licenses are required. The AX bundles

will support MPLS over DMVPN. On the ASR1000, the Security or VPN feature license is required.

For More Information

We would welcome the opportunity to discuss secure mobility solutions with you and to review the contents within

this guide. Please contact your Cisco Account Manager to discuss your requirements in more detail. Alternatively

read more about Cisco DMVPN, ISE or Mobility via www.cisco.com.

Author

This document and the solutions contained within are the work of Lee Davies, a Systems Engineer within the UK &

Ireland Public Sector team. In his role, he has worked extensively across the public sector in Wales and with UK

PSN Connectivity Service Providers. The concepts outlined in this document were initially developed with Welsh

local authorities and health boards in response to a requirement for social care employees to work jointly and

cooperatively within each other’s buildings.

Disclamier

Although the author has attempted to provide accurate information throughout this document, Cisco assumes no

responsibility for the accuracy of the information. Cisco may change the programs or products mentioned at any

time without notice. Mention of non-Cisco products or services is for information purposes only and constitutes

neither an endorsement nor a recommendation.

Printed in USA CXX-XXXXXX-XX 20/20

http://www.cisco.com/c/en/us/products/security/dynamic-multipoint-vpn-dmvpn/index.html?referring_site=bodynav

http://www.cisco.com/c/en/us/products/security/identity-services-engine/index.html

http://www.cisco.com/cisco/web/UK/solutions/trends/mobility/index.html

http://www.cisco.com/

shared workplace infrastructure in the public sector final - cisco · uk public sector shared...

Documents