en

Methods for flexible and intelligent network services

The focus of this work package are methods for flexible and intelligent network operation. The following three use cases in the BelWü/campus context are considered.

Innovations based on the SDN technologies OpenFlow and P4 are proposed, realized as prototypes, and partly deployed in operational networks.

Integration of High-Performance Zones (HPZs) in campus networks and in the BelWü-Network

SDN-NeIF, Demo-SDN-NeIF

Science DMZ, SciPass or CampusBypass have already proposed an integration of high-performance infrastructure in campus networks. In this project, High-Performance Zones (HPZs) equipped with high-performance servers and networks were set up in campus networks at different locations. The HPZs of different locations were connected via the optical high-performance network „Netzwerk für Innovation und Forschung“ (NeIF) and also integrated into the BelWü network and the campus networks. An OpenFlow-based approach was proposed which was first implemented in Mininet, then in a local testbed, and finally trialed on real hardware over the NeIF. For the latter, critical infrastructure was emulated to avoid issues with the operational network. A particular challenge were the responsibilities of the components. The campus networks and the HPZs are operated by the universities while the network between the campus networks and the forwarding within the NeIF between the HPZs are controlled by BelWü.

SDN-NeIF architecture

The proposed SDN architecture is illustrated in the figure. Each university location consists of a campus network and an HPZ. The campus network is connected via a campus router (CR) with a border router (BR) and a border switch (BS). The BR provides the uplink to the BelWü core network and to the Internet. The BS is an OpenFlow switch which is controlled by a central SDN controller (BSC) in the BelWü network and interconnects several university locations over the NeIF. It is also connected to the CR and the BR to interconnect the HPZ with the campus and the Internet.

Firewall offloading in campus networks through a firewall bypass for trustworthy traffic

Offwall, FWCongOff

Firewalls are often a bottleneck in the campus context if their capacity is lower than the network bandwidth. Their upgrade may be technically feasible, but it is very expensive. A typical use case is illustrated in the figure. Some traffic traversing a department firewall is trustworthy and does not need to be controlled by the firewall. Examples are flows between a department and the datacenter or other departments. Deviating such traffic around the firewall may be a cost-efficient way to mitigate the bottleneck.

Netzwork topology for the firewall bypass

Several options were considered to deviate trustworthy thraffic around a firewall.

  • Access control lists (ACLs) on a switch provide the possibility to configure explicit forwarding entries so that defined traffic may be deviated around a firewall. A market research turned out that switches supporting ACLs are very expensive so that ACLs cannot provide cost-efficient firewall offloading.

An OpenFlow controller can configure forwarding rules on an OpenFlow switch. This may be leveraged to deviate defined traffic around a firewall. Both a dynamic and a static bypass were proposed and investigated.

  • With a dynamic bypass, new flows are first forwarded via the firewall. The sampling feature sFlow is used to sample packets at the outgoing interfaces of the firewall. The controller is informed about sampled packets and installs bypass rules for the corresponding flows on the OpenFlow switch. However, experimental performance studies based on a prototype and theoretical projections revealed that cost-efficient OpenFlow switches do not support sufficient rules to effectively offload a firewall in case of congestion.
  • With a static bypass, a whitelist in a database is updated via a web application. The OpenFlow controller communicates with the database and translates the whitelist into rules on the OpenFlow switch. This deviates corresponding traffic around the firewall. This concept was tested as a local prototype and adapted to the challenges of the specific use case. The developed solution was adopted by the Institute of Computer Science of the University of Tübingen at the locations Sand and the TTR2 building at the Obere Viehweide. Further applications will follow.

Flexible application of the security protocols 802.1X, MACsec, and IPsec in campus networks

The protocols 802.1X, MACsec, and IPsec are used to improve security in campus networks. 802.1X is utilized to authenticate and authorize users: only users who can prove their identity obtain access to the network. MACsec encrypts the entire traffic on a link between two switches. If MACsec is applied for all links of a network, it becomes very difficult for an attacker to intercept, modify, or inject traffic. With VPN solutions and IPsec, an encrypted virtual connection can be established between a host in the Internet and a VPN concentrator in a network. The objective of the following work is to apply these protocols in an innovative way using SDN, and to simplify and improve their deployment compared to current best practices.

IEEE 802.1X based authentication and authorization with SDN

AAM, xRAC

The standard IEEE 802.1X describes protocols and procedures to secure LAN infrastructures using authentication and authorization. The principle is illustrated in the figure. Initially, a client can communicate only EAP with its access switch. Then, the client is authenticated by the authenticator on the access switch using the protocols EAP and RADIUS. With RADIUS, the authenticator requests remote authentication servers for authentication and authorization data. After successful authentication, the client is authorized. That means the switch grants the client access to the network, and the client’s traffic is possibly assigned to a specific VLAN.

VLAN assignmnent based on 802.1X and SDN

802.1X is a widely deployed concept, and it is also applied in eduroam. However, it has some shortcomings. 802.1X requires manual configuration of authenticators on switches. The authorization is stateless, i.e., access to the network cannot be denied to the client after authorization even if its authorization data has changed in the meantime. RADIUS or DIAMETER are required as backend authentication servers which are difficult to maintain while simple databases would suffice for local application. A new concept for SDN-based IEEE 802.1X integration was developed. The authenticator is implemented as controller application which can communicate with both RADIUS servers or some other backend, e.g., a database. Thereby, manual configuration of the access node is no longer needed, which facilitates deployment. Clients still communicate via EAP with the switch so that clients can continue utilizing existing 802.1X software. However, the switch does not locally process the EAP messages but forwards them to its controller which configures the switch appropriately after successful authorization. A prototype has been implemented with software and hardware switches. The work was extended so that not only users but also applications can be authenticated and authorized. To that end, applications need to be encapsulated in restricted application containers (RACs). A prototype has been realized with Docker containers. After successful authentication of a RAC image and the user, the RAC is authorized. Only then it can be executed on its server. In addition, the RAC’s access to the network can be limited and controlled in a fine-granular way.

MACsec based protection of campus networks using P4

P4-MACsec

MACsec can be manually configured on interfaces of appropriate switches to encrypt the entire traffic on a link. The manual configuration is cumbersome and error-prone. An automation of this process including automatic topology detection with LLDP and software-defined key distribution is desirable. However, today’s topology detection with LLDP is not encrypted, which makes it vulnerable so that the resulting topology is not trustworthy. We consider a network consisting of programmable P4 switches. Each P4 switch has its own local controller which performs local and encrypted topology detection with an adapted LLDP. Received LLDP packets are relayed to a central controller which has an overall view of the topology, generates keys, and configures MACsec on all links via the local controllers. Automatic rekeying is also forseen. This concept has been implemented on P4 software and hardware switches. P4-MACsec applies the concept of local controllers which has been developed and implemented in bwnet for OpenFlow switches before LoCoSDN

IPsec-based remote access in campus networks using P4

P4-IPsec

With VPNs, a so-called roadwarrier, e.g., the computer of a teleworker, can log into a remote network. To that end, the user configures an encrypted IPsec tunnel between its VPN client on the roadwarrier and a VPN concentrator in the remote network. The roadwarrier obtains an IP address from the remote network and may use all services of the network afterwards. The VPN concentrator is an expensive specialized hardware. We propose to substitute it by several P4-based VPN gateways in the network. When a particular service is requested, a suitable signaling method supported by the DNS and a central controller automatically establishes an encrypted IPsec tunnel between the VPN client and the VPN gateway nearest to the targeted server. The scalability of the VPN improves by substituting the VPN concentrator through several VPN gateways. In addition, the traffic is carried encrypted in the target network as long as possible, which improves security. Finally, usability gains through the automated tunnel setup upon service request.

en/networks.txt · Last modified: 2019/10/09 14:34 by Mark Schmidt