FlowNAC: Flow-based Network Access Control
Jon Matias <[email protected]>
Jon Matias, Jokin Garay, Alaitz Mendiola, Nerea Toledo, Eduardo Jacob
University of the Basque Country (UPV/EHU)
Outline Introduction
Related Work
FlowNAC
Validation
Conclusions
Introduction Network Management complex task Wide range of protocols and applications Requirements from target scenario
Enterprise networks, data center, operator networks…
Network Security big impact on management Complex configuration Dynamic updates based on users’ attaching point to the
network Manual configuration is error-prone (e.g. ACL, VLANs, filter rules
or middleboxes)
Network Access Control (NAC) proposed as a solution Policy description to secure the access of network devices
to the resources available in the network
Introduction NAC solution design principles
Policy must be defined once Otherwise: collision avoidance / resolution mechanism
Policy decision must be centralized
Policy must be declared over high-level names
Network should enforce a strong binding between a packet and its origin
Introduction SDN could be useful to simplify and improve networking solutions Enterprise netwoks, data center and experimental
facilities benefit from SDN
NAC as a networking application could benefit from SDN(e.g. Ethane) Adds appropriate granularity (fine-grained or coarse-grained)
for access control to services
Flexibility to identify the services as a set of flows (with dynamic definition)
Service definition evolves to assure the same profile and level of security when the user moves to a new location
Related work Commercial products from vendors
Cisco, Juniper, Alcatel-Lucent…
Definition of policies to enforce and manage the identity of the user behind the device
Prevent non-updated systems to access the network
IEEE 802.1X standard
Port-based Network Access Control (PNAC)
Allows to identify the user (AuthN) and apply a policy (AuthZ) based on decision at the PDP Access to the network is granted based on the user’s identiy
(source MAC address)
Related Work RFC 4675 and RFC 4849 add granularity to PNAC
VLAN tag attribute (RFC 4675) (max. 4096)
Filter rule attribute (RFC 4849)
FlowNAC improvements
Target service is provided for policy evaluation
Granularity is defined at flow-level
Multiple simultaneous AuthN and AuthZ processes
Related work SDN-based proposals
Ethane Identity-based access control with a logically centralized
network architecture (binding IP, MAC and port)
Web-based authentication and reactive mode
A browser and IP connectivity is needed (DHCP, DNS)
Other similar solutions: Resonance
Dynamic access control based on monitoring and iterface-based policy control
Web-based authentication and reactive mode
Related Work SDN-based + IEEE 802.1X proposals Y. Yamasaki, et al., “Flexible Access Management System for
Campus VLAN Based on OpenFlow”, 2011
S. Kinoshita, et al., “Implementation and Evaluation of an OpenFlow-Based Access Control System for Wireless LAN Roaming”, 2012
Authentication based on IEEE 802.1X
Related to eduroam (supplicant software is needed)
Reactive mode
FlowNAC Flow-based Network Access Network Based on IEEE 802.1X to authenticate the user
EAPoL-in-EAPoL extension to allow multiple AA processes
The set of granted services can evolve in time
Interaction with user (web-portal) is not needed (e.g. servers)
Drawback: Requires additional software (supplicant)
Proactive mode The target service is requested
Service definition is provided in advance by service provider
The service can be provided before the traffic is sent (or even scheduled)
Traffic to be analysed by the controller is reduced
FlowNAC Fine-grained control of which traffic from the user is granted to access the network
Traffic flow associated with the target service Assumption: Traffic uniquely identified and statelessly
matched at data plane
Incomming frames univocally categorized in a service
Policy enforcement at flow level: allow or deny
FlowNAC vs. PNAC
Granularity: flow vs. port
Active services: N vs. 1
FlowNAC vs. PNAC Similar overarching architecture
FlowNAC extensions 1. The protocol between the supplicant and the authenticator MUST
differentiate between multiple authentication and authorization (AA) processes from the same user (i.e. the same MAC address).
2. The identifier used in the request MUST contain at least three different namespaces: username, service and domain. Network Access Identifier (RFC 2486): username or username@realm
3. The policy definition MUST be extended to include the requested service as a parameter to be evaluated.
4. The service MUST be univocally defined as a set of networking parameters.
5. The protocol between the authentication server and the authenticator MUST be extended to support the transmission of the set of authorized flows to the authenticator.
6. The authenticator MUST actually enforce the access control based on the set of flows authorized as a result of the AA process.
FlowNAC extensions
1
2
3
4
5
Target service included in policy definition
Service univocally defined in terms of networking
6
Authorized Flows
Flow-based enforcing
SDN-based authenticator
FlowNAC: SDN-based architecture
FlowNAC: SDN-based architecture
PAE
PAC
Validation over EHU-OEF
EHU-OEF Virtualization: L2PNV
Validation scenario
Results
1, 10, 50 and 100 simultaneous users requesting access to the service (30 repetitions)
Conclusions FlowNAC improvements over the IEEE 802.1X standard (PNAC) Multiple simultaneous services individually granted Granularity (fine-grained or coarse-grained)
Applying SDN principles allows the separation of the actual policy enforcement at data plane from the AA process state Proactive enforcement of services Traffic remains in data plane (performance improvement)
Service provider is responsible to uniquely define the service Avoiding possible collision or misidentification (e.g. private
addressing)
PEP decomposition (SDN datapath, Authenticator Network Function and SDN controller) enables the modular and independent scale up and down of each of these components as needed
FlowNAC: Flow-based Network Access Control
Jon Matias <[email protected]>
Jon Matias, Jokin Garay, Alaitz Mendiola, Nerea Toledo, Eduardo Jacob
University of the Basque Country (UPV/EHU)
Thank you for attending
Q&A