Deploying a virtual network function over a software defined network infrastructure: experiences deploying an access control VNF in the University of Basque Country’s OpenFlow enabled facility Eduardo Jacob, Jon Matias, Alaitz Mendiola, Victor Fuentes, Jokin Garay, Christian Pinedo University of the Basque Country (UPV/EHU) e-mails: {eduardo.jacob, jon.matias, alaitz.mendiola, victor.fuentes, jokin.garay, christian.pinedo}@ehu.es Paper type Technical paper. Abstract Network Function Virtualisation is one of the last buzzwords in the networking scenario. Although this functionality is many times related with Software Defined Networks this is not compulsory. For some, NFV can be seen as a new name for an assembly of known technologies, but substituting hardware boxes by Virtual Machines in the dynamic scenario of the slice creation in SDN based infrastructure is quite novel. In this article we will present our experience deploying a Virtualised Network Function to offer access control services (as an output of an AuthN/AuthZ process) on our OpenFlow Enabled Facility (EHU-OEF).

Keywords OpenFlow, Network Function Virtualisation, Virtualised Network Function, Network Virtualisation, IEEE 802.1X, Authentication and Authorization. 1. Introduction We have deployed our own experimental facility at the University of the Basque Country (UPV/EHU), the EHU OpenFlow Enabled Facility (EHU-OEF) (I2T Research Group, 2014). This facility is based on Software Defined Networking (SDN) technology (Kreutz, et al., 2014), OpenFlow in particular (McKeown, et al., 2008), and delegates the control plane of the slice to the controller defined and administered by the owner of the slice. EHU-OEF provides a virtualised infrastructure based on Layer 2 prefixes, i.e. MAC address prefixes. It is a novel approach to network virtualisation, which allows us to provide full VLAN capacity to the experiments running on top of our infrastructure. The only requirement is the need to configure the MAC addresses of end host accessing the infrastructure (as simple as configuring the IP address and even more simple when using virtual machines). A very detailed explanation of this infrastructure can be found at (Matias, et al., 2013). The shared infrastructure imposes some challenges when trying to assure the isolation between slices and controlling who has access to each slice. In this context, we have designed a mechanism to authenticate and authorize each user before accessing the resources available at each slice. This procedure must be enforced by each slice owner. Moreover, the resources and services provided (i.e. multiple services, not just access to the slice) by each slice can be defined by the owner of the slice and be controlled independently by a different security procedure. In a nutshell, the EHU-OEF provides a virtualised infrastructure which exposes the OpenFlow control plane to the experimenters. A mechanism to control the access to each slice is provided, but it is delegated to the experimenters and must be managed by them. This network functionality, i.e. the access control to the slice, is provided as a virtual machine that could be instantiated at slice creation process and implements FlowNAC, (Matias, et al., 2014) a modified version of IEEE 802.1X with a novel EAPoL-in-EAPoL (Extensible Authentication Protocol over LAN) encapsulation to authenticate the users without the need of a captive portal and provide service level access control. However, some interaction is needed between the SDN (i.e. OpenFlow controller) and the Network Functions Virtualisation (NFV) resources (i.e. Access Control Virtual Network

Function, AC-VNF) in order to implement such access control to the slice. The rest of the paper is structured as follows; in section 2 we will present the problem statement, in section 3 the EHU-OEF platform and its second release that allows conducting experiments in NFV, in section 4 the interaction between SDN and NFV and implementation details of the Access Control Virtual Network Function, in section 5 the operative of the EHU-OEF management framework and finally, in section 6 the conclusions will be drawn. 2. Problem statement One of the limitations of SDN while trying to implement a network functionality is the lack of state supported at the networking elements. SDN architecture components (switches) are essentially stateless. The state is maintained at the controller by means of SDN applications. But, it’s important to highlight that implementing a stateful application implies redirecting all the traffic to the OpenFlow controller by encapsulating it in the OpenFlow protocol. Network Function Virtualisation (Chiosi, et al., 2013) is the ideal complement for SDN in order to implement stateful solutions, since the SDN interfaces can be used to redirect the specific traffic (i.e. identified by flow entries at data plane) to the Virtual Network Function (VNF) box, where the state is maintained. No encapsulation is needed and it can be located at any place in the infrastructure by using the IT virtual resources (i.e. computation and storage). The traffic can be processed by distributed VNF boxes (at data plane) without needing to redirect all the traffic to the (logically) centralized OpenFlow Controller (although it can be physically distributed). As previously mentioned, some kind of interaction is needed between NFV and SDN in order to assign each traffic to the corresponding VNF box. 3. EHU-OEF platform Back in 2010, the I2T Research Group started the deployment of an OpenFlow testbed to conduct networking related research, the EHU-OEF, in the first campus-wide experience with OpenFlow at the University of the Basque Country. The first release of the platform consisted solely of networking resources as the platform was oriented to SDN research. Afterwards, the offerings of the infrastructure were augmented to include virtualised computational resources, allowing the experimenters to deploy a complete testbed attaching virtual machines (VMs) associated to their network slices and thus enabling research and experimentation in NFV following the ideas behind the ETSI NFV Proof of Concepts (ETSI Industry Specification Group for NFV, 2013). The complete infrastructure of the EHU-OEF is shown in Figure 1.

Figure 1: EHU-OEF experimental facility

Building upon this, recently a second release of EHU-OEF has been deployed with a management framework to ease the use by the experimenters automatizing the provisioning and deployment of the slices and the associated resources and also allowing the enrichment of the slices with NFV based services. The management framework is displayed in Figure 2 and is composed of the following elements: - Management: built with Tomcat and MySQL, hosts the management website described in section 5 and

interacts with the rest of the elements of the framework. - Monitoring: gathers the monitoring information from the infrastructure using SNMP and MRTG and

provides the information to the management server. - Slicing: built with a modified version of FlowVisor that implements L2PNV and manages the slicing. - Xen hosts: built with Xen and libvirt, they host the computing resources and are deployed at different points

in the network. Communication with the management server is done using TLS and certificates issued by a locally managed certification authority.

- Gateway: provides DHCP, DNS and internet access (NAT/FW) to the VMs and VNFs deployed in EHU-OEF through the management network.

Figure 2: EHU-OEF Management framework

As this release is currently stable and used in the experiments of the research group, currently a new release is being planned that includes extending the available VNFs to offer basic services in the experimenter slices (such as DHCP, DNS, firewall, etc.) and implementing software switches in the Xen servers to extend the scope and variety of the networking resources available in the EHU-OEF platform. 4. Approach for implementing a Virtualised Network Function over a SDN infrastructure. 4.1 SDN and NFV interactions According to the ETSI NFV architecture (ETSI NFV ISG, 2013) there are some assumptions that must be considered regarding the implementation of a VNF: - The VNF is built on top of a NFV Infrastructure (NFVI), which provides a set of virtual resources (i.e.

Virtual Computing, Virtual Storage and Virtual Network) over a virtualised layer. - The VNF implements all the logic in a single box and has two reference points (northbound and

southbound). - The actual management of the VNF is out of the scope of this NFV architecture. - There is no explicit relation with SDN and how both technologies could be related in a real deployment. What we have tried to solve with this experience in deploying a VNF over EHU-OEF infrastructure (based on SDN) is how the SDN and NFV can fit together and to identify how each technology could be beneficial for each other. Moreover, when actually deploying the VNF to become operational, the management of the VNF needs to be covered by the implementation.

Regarding the SDN and NFV interaction, first of all some basic concepts need to be clarified. At this point, the the state (stateless vs stateful) must be analyzed. In SDN the data plane and control plane are separated and implemented on different (at least logical) entities: the Data Path and Controller, respectively. On the one hand, the Data Path is stateless by definition, since the flow entries that can be matched do not maintain any state from previous packets. On the other hand, the Controller is a software application which can easily maintain the state of previous interactions. In a nutshell, to implement a stateful solution in SDN all the packets (involved in the stateful support) must be redirected to the Controller. From the NFV perspective, there is no restriction to implement both a stateless and stateful VNF and it is up to the logic of the VNF to support one or another. One interesting aspect is how this state-related issue can be addressed when combining the SDN and NFV technologies. Following the same split between stateless (data) and stateful (control), the VNF could also have some benefits from as similar approach (depending of the actual network function). In this approach the stateless part of the VNF could even rely on SDN to implement this functionality, whereas the stateful part could remain in a VM somewhere in the network. If any interaction is needed between both stateless and stateful parts of the VNF, the SDN could eventually be used to steer the packets from the stateless data path to the VM in order to be processed. The main difference between SDN and NFV split (data vs. control or stateless vs. stateful) is the following: On the SDN approach the packets from the Data Path to the Controller are encapsulated in OpenFlow protocol and the logic to process this packets must be adapted to run as an OpenFlow application on top of the Controller. A specific implementation is needed for each Controller to be used. As opposite, on the NFV approach the packets can be redirected to the VM without any encapsulation (less overhead and processing time) and even more, the packets can be processed by legacy deployments (e.g. Linux x86 applications). In a mixed SDN and NFV scenario, we foresee two main beneficial interactions between both technologies. On the one hand, the SDN can be a tool for steering the traffic to the adequate VNF VM by just setting the proper flow entries matching the packets (e.g. specific protocol) to be redirected to this VM. Moreover, the redirected packets are not encapsulated in OpenFlow messages and can be processed by legacy applications deployed on top of any OS. Typically, these packets will be related to a specific legacy protocol that allows interaction between end hosts (e.g. a client and a server). On the other hand, the VNF can rely on SDN to implement some (stateless) flow level process (i.e. basically match and action) as an output from the process (stateful or stateless) previously described, i.e. the exchange between end hosts by means of a specific protocol. To achieve this interaction the VNF must be connected to the SDN controller by any northbound interface exposed upwards. This interface allows the VNF to apply and enforce some actions on the Data Path, which could improve the overall performance of packet processing. Finally, there is an important interface, which is out of the scope of the NFV standard, which is the VNF management interface. The main challenge of this interface is its dependence with the application logic implemented on the VM. This means that it is really challenging to define a common interface for any type of application that could be implemented by the VNF. However, this management interface is key for a real deployment and must be defined when implementing the VNF. This interface should be also made available, through some kind of connectivity, to the actual user who requests the VNF. The SDN could be also the tool for providing such connectivity. To conclude the security is a topic to be further study for all the interfaces described above, both for the SDN-NFV and VNF management interface. 4.2 The Access Control Virtualised Network Function (AC-VNF) The objective of the Access Control Virtualised Network Function is the provisioning of security services, more concretely, access control to the slice (or services behind the slice resources) and policy enforcement. The solution is based on IEEE 802.1X standard (and a modified version of the standard to implement the access control per service (Jacob & Matias, 2012), instead of per port). Basically, the VNF is built on a VM with a Linux distribution and HostAP (http://hostap.epitest.fi/hostapd/) software (authenticator) running on it. To implement the service based access control, both modified versions of HostAP and wpa_supplicant (http://hostap.epitest.fi/wpa_supplicant/) are used (already developed). In addition to this, a RADIUS server (authentication server, http://freeradius.org/) infrastructure must be also provided in conjunction with the HostAP VM (this can be provided as a joint VNF box or with a standard interface to legacy resources). The user identifiers and credentials must be also managed by the slice’s owner (in our case a LDAP infrastructure). An interface between the RADIUS server and the SDN controller (OpenFlow

controller) has been also implemented by means of REST-JSON in order to properly enforce the policy (access to a service). This interface defines the flow entries and the specific DPID (Data Path Identifier, which identifies the switch), which must be activated/released on successful/failed ending of authentication and authorization (AA) procedure. This approach effectively implements the separation of the state associated to the AA procedure, which is maintained in the VNF box, from the actual enforcement of the policy, which is assured by the SDN flow entries. Thus, the functions associated to the whole AA procedure are distributed between SDN and NFV. The cooperation between SDN and NFV is fundamental. Our implementation in fact, provides an example on how this could be implemented: the definition of this type of interfaces (probably per VNF) is basic. Regarding our implementation, we mentioned that the associated traffic to the VNF, must be redirected to the VNF box. In our case, the VNF traffic (IEEE 802.1x) can be easily distinguished by it’s EtherType (0x888E) or it’s MAC destination address (a reserved multicast address: 01:80:C2:00:00:03). In our platform, we have also implemented a module for the slice controller (currently, we have a module for NOX and FloodLight controllers) in order to redirect all the IEEE 802.1X traffic (i.e. EAPoL frames) to the appropriate VM, the VNF box, where the HostAP is located. To obtain a more general solution and the possibility to deploy multiple HostAP VMs in the same slice (e.g. for load balancing between several VNF boxes), we have designed a procedure to redirect the EAPoL frames by rewriting the multicast MAC destination address with the unicast MAC address of the HostAP VM. The rewriting is enforced at the edge switch directly connected to the end user and reverted before accessing the HostAP VM (i.e. rewrite the unicast by multicast address). The end user can be both a VM from another virtual server or a physical PC directly connected to one of the physical ports of any of the OpenFlow switches. One important issue related to NFV is the need of some virtual machine provisioning mechanism and management, including some automated configuration mechanism to adapt the dummy configuration of the VM on the repository to the specific values needed in each slice. For instance, the HostAP VM (i.e. authenticator) needs some information about the RADIUS server (e.g. the pre-shared key, the IP address, port...). This VM provisioning mechanism and its automated configuration functionality represents an additional set of features for our infrastructure and is also available to users for generic purposes, as previously explained in section 3.

Figure 3: AC-VNF process

Once the slice is deployed and properly configured, no traffic is allowed at the slice except the EAPoL frames, which are redirected properly (by unicast rewriting) to the VNF box. An IEEE 802.1X authentication and authorization procedure must be successfully completed before accessing any resource/service available at the slice. This AA procedure can be associated to specific services (instead of full access to the network as defined at the IEEE 802.1X standard) defined at SDN by a set of flow entries. Once the AA procedure succeeds, flow entries are deployed by the SDN controller enabling the access to the service, thus, enforcing the policy. The

same end user can also request additional services by using the modified HostAP wpa_supplicant software. This is shown in Figure 3. 5. Operations overview An experimenter who wants to use EHU-OEF facility must contact the administrator of the platform and request access. Once request is approved by the administrator, access credentials -username and password- are given to the experimenter. In order to use of the facility, experimenters must also provide the public key which will be used to grant access to the resources instantiated by the experimenter. Management of the platform is entirely performed from the web portal shown in Figure 4, where the experimenter, after the authentication procedure, can manage the slices, including operations such as creation of new resources over the slice, deploying, enabling or disabling Virtual Network Functions, etc.

Figure 4: EHU-OEF Management server, home

The rest of the section describes the available operations related to slices in section 4.1, resources in section 4.2 and monitoring in section 4.3. 5.1 Slices Under the Slices Tab shown in Figure 5, the experimenter can get a list of running slices assigned, and access the detailed configuration for each one. The website also allows creating new slices and to do so the experimenter must set a name for the slice and configure the controller.

Figure 5: EHU-OEF Management server, slices view

The platform provides the option to automatically add a controller from a set of templates – POX, RYU... – which are dynamically configured for the slice and ready-to-work. Also, the experimenter can use his own controller setting up the corresponding URL and OpenFlow Port. Once the creation of the slice is started some process are activated internally. First of all, it is required to create a slice into Flowvisor and corresponding rules to enforce flowspace policy to guarantee isolation between slices. EHU-OEFs runs a modified version of Flowvisor-1.4 which is able to support MAC prefixes for flow characterizations using OpenFlow 1.0. After this process, if the automatic controller option is selected, a virtual resource running the selected controller type is provided and attached to the slice, including the public key of the experimenter to grant access to the resource. After the creation of the slice, the experimenter can continue managing the slice selecting “View Resources” for a certain slice. 5.2. Resources As previously stated, the EHU-OEF offers both network and computational resources to experimenters. In the first release of the platform, slices were considered as a subset of the network resources, composed of hardware and software switches, that experimenters were able to control through OpenFlow. Since the appearance of NFV, with the VMs assuming some networking functionalities, the slice definition has become richer. As a consequence, in order to provide the best possible service to the experimenters of the facility, the EHU-OEF platform provides the means to provision and deploy generic purpose VMs and also more specific purpose resources for NFV related research and experiments as shown in Figure 6.

Figure 6: EHU-OEF Management server, resources view

First of all, at the resources section, experimenters can visualize the resources associated with their slice. They can see information about the resource types, their location inside the facility or the VM template that has been used for their creation. Second, experimenters are able to add new resources to their slice anytime. Besides the template that they want to use for the creation of the VM, researchers are also able to select the location where that VM will be deployed. Thus, they will know exactly the composition of their slice, making possible for them to control the network in a proactive way. All VMs run on Xen Server. For that matter, when a new resource is added from the EHU-OEF management server, the corresponding Xen Server is instructed to create a new VM using the specified template. Besides, in order to keep a record of everything that has been provisioned for users, all the relevant information such as the VM type, etc. is stored in a MySQL database. Starting from a basic set, the available VM templates is continuously expanded as experiments are conducted in the platform and those specific VMs used that are considered to be useful for further experiments are modified and include in the list. At the time of writing this document, several different VM templates are available for users:

- OF Controllers POX and Ryu: Linux VM templates with the POX or Ryu OpenFlow controller already installed (each template has one of them)

- Standard Lightweight Linux VM: A Linux lightweight VM template of generic purpose. The template contains a pre-installed set of common tools very useful for networking research, e.g., tcpdump, vim, compilers, etc.

- Demo Client and Demo Server: Linux VM templates prepared to run iperf as client and server respectively.

- HostAP (Access VNF): A Linux VM template that contains everything necessary to implement the Access Control Virtual Network Function as explained in section 4.

5.2.1 VNF Configuration The EHU-OEF management framework can also be used to manage the VNFs of the slices. For instance, in the the Access Control VNF, it is possible to activate or deactivate the Access Control VNF without disrupting the service. Furthermore, it provides the necessary tools to configure the allowed services inside the slice and the users with permission to access it as shown in Figure 7 and Figure 8.

Figure 7: EHU-OEF Management server, VNF configuration of services

Figure 8: EHU-OEF Management server, VNF configuration of users

5.3. Monitoring Aware of the importance of monitoring in networking experiments, the EHU-OEF management framework includes a monitoring tool available for experimenters. The framework monitors the bandwidth of a set of ports within the EHU-OEF OpenFlow switches. In order to obtain the bandwidth, SNMP and MRTG are used as can be seen in Figure 9. As a consequence, the information obtained is port-based and not flow-based. In order to improve the monitoring system, the I2T Research group is currently working on alternative ways to monitor an OpenFlow network.

Figure 9: EHU-OEF Management server, monitoring

6. Conclusions and future work The paper has presented the automated deployment of a Virtualised Network Function over the slices created in our SDN based infrastructure. This approach is particularly well suited to a stateless SDN based infrastructure as the VNF is able to store the data needed to main the AA state. As additional conclusions, we have found that our MAC prefix based virtualisation has proved to be very effective to deal with layer 2 traffic involved in the 802.1x procedure. Finally, it’s worth to mention that the design needs to carefully address the configuration not only of the VM employed in the VNF but also of the underlying communication substrate to maintain the proper isolation and these involves the creation of some specific pieces of software. Starting with this first implementation our goal is to continue developing more VNFs. Acknowledgments This work has been partially funded by the Spanish MICINN project A3RAM-NG (TIN2010-21719-C02-01) and the Basque Government Strategic Research Project Future Internet II (IE11-316). It is also supported by the University of the Basque Country’s Training and Research Unit for Telecommunications and Electronics (UFI11/16). References Chiosi, M., Wright, S. & et al., 2013. Network Functions Virtualisation (NFV). [Online] Available at: http://portal.etsi.org/NFV/NFV_White_Paper2.pdf [Accessed 14 April 2014]. ETSI Industry Specification Group for NFV, 2013. ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework". [Online] Available at: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf [Accessed 14 April 2014]. ETSI Industry Specification Group for NFV, 2013. ETSI GS NFV-PER 002: "Network Functions Virtualisation (NFV); Proof of Concepts; Framework". [Online] Available at: http://www.etsi.org/deliver/etsi_gs/NFV-PER/001_099/002/01.01.01_60/gs_NFV-PER002v010101p.pdf [Accessed 12 June 2014]. I2T Research Group, 2014. The University of the Basque Country’s OpenFlow Enabled Facility (EHU-OEF).

[Online] Available at: http://i2t.ehu.es/resources/ehu-oef [Accessed 14 April 2014]. Jacob, E. & Matias, J., 2012. Deploying OpenFlow in production at the University of the Basque Country: Identity based network infrastructure configuration. s.l., s.n. Kreutz, D. et al., 2014. Software-Defined Networking: A Comprehensive Survey. arXiv: 1406.0440. Matias, J. et al., 2014. FlowNAC: Flow-based Network Access Control. Budapest, EWSDN14 (accepted paper). Matias, J. et al., 2013. The EHU-OEF: An OpenFlow-based Layer-2 experimental facility. Computer Networks, Special Issue: Future Internet Testbeds. McKeown, N. et al., 2008. OpenFlow: Enabling Innovation in Campus Networks. ACM SIGCOMM Computer Communication Review, II(38), pp. 69-74.

Vitae

Eduardo Jacob got in 1991 a BSc in Industrial Engineering and a MSc. in Industrial Communications and Electronics from the University of the Basque Country (UPV/EHU). He spent 5 years in a public R&D institution and as IT director in the private. He got his PhD in ICT in 2001. He is assistant professor and actually acting as Head of the Communications Engineering Department. He is the promoter of the EHU OpenFlow Enabled Facility. His interests are related to application of the Software Defined Networks to support advanced applications, ITS and privacy by design sensors. Jon Matias received his BS and MS degree in Electrical Engineering from the University of the Basque Country (UPV/EHU, Spain) in 2003. He currently works as a lecturer and researcher in the Electronics and Telecommunications Department at the Faculty of Engineering of Bilbao (UPV/EHU). He is also pursuing the PhD degree in electrical engineering at the same University focused on access networks and security. His research interests include Computer Networks, Broadband Access Networks, OpenFlow, Services Provisioning and Security. Alaitz Mendiola received her BSc and MSc degrees in telecommunication engineering in 2012 from the University of the Basque Country (UPV/EHU). Her research interests include Software Defined Networking, Network Virtualisation and DOCSIS Access networks. Victor Fuentes received his BSc and MSc degrees in Telecommunication engineering in 2013 at the University of the Basque Country (UPV/EHU). He has experience with integration of GPON access networks into Openflow sceneries and Openflow proxy-based platforms. He has been actively involved in the deployment of EHU-OEF. Jokin Garay received his BSc and MSc degrees in telecommunication engineering in 2003 from the University of the Basque Country (UPV/EHU). After a period in the private sector he came back to the University. His research interests include Software Defined Networking, Network Functions Virtualisation and Cloud Computing. Christian Pinedo received his BSc and MSc degrees in Telecommunication Engineering in 2004 from the University of the Basque Country (UPV/EHU). He was researcher at the I2T research lab until he got in 2007 another MSc in Information and Communication Systems in Wireless Networks from the UPV/EHU. In September 2007 he left the university and was employed in the private sector. Since August 2012 he returned to I2T research lab focusing his research on network virtualisation technologies and railway communications.