CHARISMA – D2.5 – v1.0 Page 1 of 37 Converged Heterogeneous Advanced 5G Cloud-RAN Architecture for Intelligent and Secure Media Access Project no. 671704 Research and Innovation Action Co-funded by the Horizon 2020 Framework Programme of the European Union Call identifier: H2020-ICT-2014-1 Topic: ICT-14-2014 - Advanced 5G Network Infrastructure for the Future Internet Start date of project: July 1 st , 2015 Deliverable D2.5 CHARISMA E2E V-Security Architecture Due date: 31/10/2017 Submission date: 31/10/2017 Deliverable leader: Fundació i2CAT, Internet i Innovació Digital a Catalunya (i2CAT) Dissemination Level PU: Public PP: Restricted to other programme participants (including the Commission Services) RE: Restricted to a group specified by the consortium (including the Commission Services) CO: Confidential, only for members of the consortium (including the Commission Services)
Transcript
CHARISMA – D2.5 – v1.0 Page 1 of 37
Converged Heterogeneous Advanced 5G Cloud-RAN Architecture for Intelligent and Secure Media Access
Project no. 671704
Research and Innovation Action
Co-funded by the Horizon 2020 Framework Programme of the European Union
Call identifier: H2020-ICT-2014-1
Topic: ICT-14-2014 - Advanced 5G Network Infrastructure for the Future Internet
Start date of project: July 1st, 2015
Deliverable D2.5
CHARISMA E2E V-Security Architecture
Due date: 31/10/2017
Submission date: 31/10/2017
Deliverable leader: Fundació i2CAT, Internet i Innovació Digital a Catalunya (i2CAT)
Dissemination Level
PU: Public
PP: Restricted to other programme participants (including the Commission Services)
RE: Restricted to a group specified by the consortium (including the Commission Services)
CO: Confidential, only for members of the consortium (including the Commission Services)
Figure 1: End-to-end security, and the different possible endpoints ............................................................... 8 Figure 2: Encryption and Decryption (source:[3]) ............................................................................................. 9 Figure 3: LTE trust model ................................................................................................................................. 11 Figure 4: Attack on an eNB .............................................................................................................................. 11 Figure 5: Malicious eNB in GSM/3G/LTE ......................................................................................................... 12 Figure 6: Non-standalone 5G deployment (source: [9]) .................................................................................. 13 Figure 7: 5G security applied to CHARISMA CAL nodes .................................................................................. 13 Figure 8: Logical representation of control plane slicing ................................................................................ 18 Figure 9: The network hypervisor concept [23] .............................................................................................. 20 Figure 10: Recursive client-server relationships in hierarchies of SDN control plane [24]. A two level hierarchy effectively realizes the NH concept. ................................................................................................ 21 Figure 11: SDN Overlay across different Data Centres .................................................................................... 21 Figure 12: CHARISMA CMO control plane slicing overview ............................................................................ 22 Figure 13: CHARISMA CMO control plane slicing solution (detail) .................................................................. 23 Figure 14: CHARISMA Secure Control Plane Slicing Overview ........................................................................ 29
CHARISMA – D2.5 – v1.0 Page 5 of 37
Executive Summary
Future 5th Generation (5G) technologies are anticipated to address next generation network’s challenges and tackle the novel business requirements associated with different vertical sectors. It is anticipated that convergence, automation and flexibility are expected to be intrinsic traits of any 5G system. The introduction of this multitude of complex new requirements and novel technologies will immensely impact the security landscape of 5G and therefore the need to revisit its security properties becomes essential. The security vision for 5G will, at least, be a collection of security landscapes of all involved technologies (wired or wireless networks, virtualization, etc.) and vertical sectors. However, analysing the complete security landscape for all involved technologies and vertical sectors, in 5G, is out of the scope of this document. Though, in this document, we shall revisit the security aspect for CHARISMA architecture focusing on the end to end virtualised security (v-security) architecture.
The CHARISMA architecture targets 5G access network and enables an infrastructure owner to share its network with multiple virtual network operators (VNOs) through network slicing. Moreover, CHARISMA tightly knits the network slicing concept with the SDN/NFV environment in its infrastructure to facilitate VNOs fast track provision of network services on their leased-out network slices. [Reminder: A network slice in CHARISMA architecture consists of both compute and network resources. Furthermore, CHARISMA architecture considers both virtualized as well as physical resources in its infrastructure given the SDN/NFV environment]. The intelligence driven v-security solution reported in D3.4 provides a virtualized security defence from network service perspective enabling virtual security functions, security policy management and security monitoring on per service basis. However, for an end to end virtualized security blanket, in an SDN/NFV-based multi-tenant environment, control-plane slicing and its security aspects should also be considered in addition to network service level v-security.
This document focuses on the security of SDN-enabled control-plane slicing which combined with the intelligence driven v-security solution [D3.4], constitute the end to end v-security architecture. It describes the concept and functional requirements of control-plane slicing to perform a threat analysis which in turn enables to identify security requirements. The document proposes a solution and discusses how it could be adapted to CHARISMA control-plane architecture along with the description of the required key exchange mechanism.
Apart from the end to end virtualized security, this document also surveys security aspects at other layers of the stack in a 5G network, in general. This is an attempt to provide the reader with an overall view of an end to end security architecture for a 5G network.
CHARISMA – D2.5 – v1.0 Page 6 of 37
1. Introduction
The complexity of the security landscape of 5G systems is increasing at the same rate (if not at a faster rate) alongside the actual technology innovations associated with 5G converged communications technologies. On one hand, as 5G is developed and standards defined, the lessons learned from the current standard 4G/LTE, as well as the various related issues and problems that have been identified by the research community during recent years, particularly in the security area. In addition, important technology developments such as software-defined networking (SDN) and network functions virtualization (NFV) technologies are also imposing their own security requirements and technical issues, which also need to be solved in order for the emerging 5G solutions to be credible, trustworthy and secure. Thus, overall, the security aspects of 5G are increasingly important and critical.
Additional important considerations for the new security requirements imposed by 5G are related to the variety of new business models that are now emerging (and underpinned by the high performance expectations of 5G) and which involve a new set of stakeholders, actors, and services. Again, to ensure successful roll-out of the 5G technologies and services, acceptance of the new paradigms of how the network is organised and managed, as well as take-up of the new associated services, a credible end-to-end security architecture needs to be designed, which guarantees certain security key performance indicators (KPIs), related to reliability & availability, integrity & confidentiality, and authentication & authorisation.
In this deliverable D2.5 “CHARISMA e2e v-security architecture” we provide the description of the CHARISMA security solution that has shaped our final architecture design. In particular, we describe the available key distribution protocols, as well as the encryption and decryption functions available to us, while ensuring the low-latency operation of the network. In addition, the design and implementation of our virtualised-security approach, based upon CHARISMA’s virtualised infrastructure and control, management and orchestration (CMO) architecture is described.
This document is organised as follows. In Chapter 2 we provide the context of the state-of-the-art security landscape with respect to 4G/LTE security, where the weaknesses of LTE technology, together with new ideas and suggestions for 5G or beyond 5G networks are discussed. Although 5G will not provide a final solution for full end-to-end security, it certainly improves upon the existing 4G/LTE security. As part of the CHARISMA technical solutions, network-based source authentication, being an integral part of the 6Tree protocol, is discussed, together with new and established security paradigms at different network layer.
Chapter 3 discusses the control of the virtualized infrastructure enabling fully functional operational model for emerging virtual network operators (VNOs), which will come with 5G. The significant security challenges that must be tackled by the CHARISMA 5G architecture are discussed. A concept of control plane slicing, together with the functional requirements, and the integration of such capability with the CHARISMA CMO architecture are presented. An associated threat analysis for virtualised architectures is presented, as well as the CHARISMA key exchange solution.
Finally, conclusions are presented in Chapter 4.
CHARISMA – D2.5 – v1.0 Page 7 of 37
2. Secure E2E Architecture
This deliverable concerns mainly with solutions for (virtualized) end-to-end (E2E) security. First, the term end-to-end security will be introduced; afterwards the 5G security is discussed and finally specific questions for physical, MAC and IP layer are explained in the context of CHARISMA.
2.1. Introduction
E2E security is a the technical term in communications, used to refer to the desired situation where only the partners of a secure connection can read each other’s communication data; such security often being achieved by means of encryption. In which case, E2E encryption is therefore also commonly used as the means to achieve a desired E2E security. Such E2E security or encryption technologies, respectively try to guarantee that no other their party entities, like operators, device manufactures, or eavesdroppers are able to gain access to the messages.
In the context of a 5G mobile network E2E security can refer to various different communications endpoints; these being shown in the following .
At the top level is located an E2E connection using communication software running on a smart phone. It establishes a secure connection using the IP connectivity on top of the mobile network, where the secrecy is (almost) completely independent of the mobile network. In this case, signal [2], both parties need to trust the software manufacturer and the protocol used. An analysis of the messaging protocol can be found in [4].
On a level below is located the actual connection between two UEs using the mobile network. Although currently not used, in theory both UE could exchange keys for an encrypted connection very similar to the methods used in today’s messenger and voice applications. Another example of E2E encryption is that found in especially hardened mobile phones, as described in [14]. These types of phones have special hardware that controls the device and only permits secure operations.
Finally, an E2E connection could be established via the gNB and more specific the CU. In that case only operator equipment would be used and the wireless link between the UE and the Next Generation NodeB (gNB) would require a separate security measures.
CHARISMA – D2.5 – v1.0 Page 8 of 37
Figure 1: End-to-end security, and the different possible endpoints
In the , the communicating partners Alice and Bob are each using a (5G) smartphone to exchange information, such as voice or text messages. The secrecy of their E2E communication faces various challenges and requirements, which are discussed in the following section.
2.2. E2E security requirements and challenges
The end-to-end security concerns mainly with the security of the endpoints, the security of communication link itself, and the encryption technology. These three issues will be explained in the following paragraphs.
End-to-end security depends in the first place on the strength of the encryption protocol used. Two main types of encryption exist: firstly, symmetric encryption, where the key is used for both encryption and decryption; and secondly, asymmetric encryption, where a pair of keys – a public one and private one - are used.
In the case of asymmetric encryption (, right), the public key is used to encrypt the message, while the secret, private key is used for decryption. Mathematically, it depends on the factorisation of large integers or discrete logarithms. Asymmetric encryption is currently considered secure,., such that brute force attacks trying to find the key by chance using a high performance computer can be mitigated against by increasing the key length. Although it should be mentioned that theory suggests that a sufficiently powerful quantum computer (which does not exist today, can) could efficiently break this type of encryption.
EPC, MME
DU DU
Alice Bob
CUCU
E2e encryption on user devices(5G protocol stack)
E2e encryption for gNB (CU) connectingAlice and Bob
E2e encryption on application level(e.g. Signal)
E2e security
Key exchange
Key exchange
Key exchange
CHARISMA – D2.5 – v1.0 Page 9 of 37
Figure 2: Encryption and Decryption (source:[3])
In the case of symmetric encryption (, left), the secret key is used in both the encryption and decryption processes. Here, a key length of 64 bits, e.g. being used in A5/1-3, is already considered weak because of its shortness, but algorithms using a key length of 128 bits (e.g. A5/4, AES-128, SHA-256) are considered strong enough, even if future quantum computers were to become a practical reality [1].
The algorithms used for asymmetric encryption consume more resources, e.g. power and processing time in comparison to symmetric algorithms. As such, a hybrid combination of both technologies is now also being used in practice. Asymmetric algorithms can be used for both authentication and encryption, so that the asymmetric encryption is used for distributing symmetric one-time keys. The data transfer itself uses the symmetric algorithms.
Instead of attacking the encryption directly, like in a brute force attack an eavesdropper may try to impersonate Alice or Bob in order to get hold of the secret key. If successful, the eavesdropper can read the message, while both Alice and Bob still receive encrypted data. This issue can be avoided by authentication via certificates of a trusted entity.
The security of the endpoints of a communication is very important. A weakness in the hardware or software of the endpoint devices can be used to get hold of the secret keys or the decrypted message itself. Beside the existence of unknown weaknesses, the introduction of a known weakness (also known as backdoor) is also a threat to the endpoints.
2.3. 5G Security
2.3.1. Overview
Although 4G/LTE already provides a very good technical solution for security, 5G is enabling innovative scenarios and applications to make use of the ultra-high speed, low-latency telecommunication networks for fixed and mobile users, and machine-to-machine (M2M) communications. These scenarios, together with the introduction of the new paradigm for computing and network infrastructure, which decouples the actual functionality from the underlying hardware and middleware functions (Cloud Computing and SDN) further reinforces the need for additional security features in the telecommunications infrastructure. In particular, since a cloud-based paradigm that promotes this infrastructure is highly accessible and shared by multiple users (for instance, Virtual Network Operators), the concept of a highly secure network is gaining ever more relevance.
There are two different aspects that need to be taken into account in order to address the security aspects of upcoming 5G network: networking:
CHARISMA – D2.5 – v1.0 Page 10 of 37
i) The need to address the overall security of the network, composed of virtualized and non-virtualized resources (i.e. "traditional" or "classical"). Due to the virtualized nature of 5G networking, the effectiveness of traditional physical security devices is being diminished, mostly because they lack visibility into changes performed over the virtualized functions, service chains, and into the traffic being exchanged on virtualized platforms. Or putting into different words, a holistic security approach comprising both virtualized and non-virtualized (traditional) security functions therefore needs to be put in place.
ii) There is a need to cater for an automated security management solution for 5G networking. Today, we can’t foresee the new and ever changing threats that 5G networks will have to protect against; but we do have the basis to create autonomic network management solutions that shall cope with them, being fed with insights from governed real-time analytics systems on the one hand, and actuating on network resources to minimize or prevent the effects of the detected threats on real-time on the other hand. It is therefore of the utmost importance to be able to provide robust, flexible and proactive mechanisms to detect and prevent security issues, and to be able to perform this in real time and in an automated fashion.
Taking these into account, the infrastructure operator and the different tenants need, with different degrees of responsibility and different focus areas, to maintain the overall end-to-end security of the network, including end-user security, physical infrastructure security, and the security of the virtualized resources (be they applications or network functions).
In detail, the 5G network assets to be secured are: i) Endpoint Devices (i.e. UEs, sensors etc.); ii) Networks (including physical and virtualized elements), comprising the network Application Plane (VNFs), the Control Plane (SDN and NFV Orchestrators and Controllers), and the Data Plane; and iii) end-user applications.
2.3.2. LTE and 5G Architectures Discussion
In order to understand the overall context of 5G security better, the state of the art with respect to LTE security will now be discussed. The issues of LTE networks already give an important indication of where 5G needs to improve upon the current security situation.
2.3.2.1. LTE trust model The trust model for LTE can be described using (see also [5]). LTE considers the operator equipment to be part of the trusted domain, including the (evolved packet core) EPC functions and the (evolved) eNB entities. The link between EPC and eNB might pass through public networks, such that an IPSec tunnel therefore should be established between them, to ensure a secure connection.
The radio interface is by definition unsecure; such that needs to be considered non-trusted and requires strong encryption in order to secure the final link to the end-user device. Since encryption of GSM is nowadays considered too weak, a new symmetric encryption, using A5/4 (128 bit key length) the protocol is used in LTE.
CHARISMA – D2.5 – v1.0 Page 11 of 37
Figure 3: LTE trust model
2.3.2.2. LTE security research A closer look at the trust model of LTE as shown in already indicates some issues to be considered , since LTE does not provide a strict E2E encryption and security. An attacker might compromise an eNB and in consequence gain access to the decrypted data of the connected UEs. This type attack requires a lot of effort and is probably only an option for governmental agencies.
Figure 4: Attack on an eNB
A simpler and widely researched attack scenario are the “fake base station (IMSI catcher)” attacks as shown in , where an attacker can setup a fake and malicious eNB quite easily, and at low cost [7]. In a first step, the attacker needs to “convince” the UE to connect to the malicious eNB. In GSM/3G mode this is quite simple because of the missing mutual authentication between eNB and UE. In addition, the base station can turn off authentication and encryption without notification for GSM/3G.
Blom, et al.: „Security in the Evolved Packet system“, Ericsson review, 2/2010
EPC (home subscriber server, mobile management, packet gateway, service
gateway)
Trusted domain
Untrusted domain
radioeNB eNB
IPSec
Internet
UE
EPC (home subscriber server, mobile management, packet gateway, service
gateway)
Trusted domain
Untrusted domain
radioeNB eNB
IPSec
AttackerInternet
Attack on eNB
UE
CHARISMA – D2.5 – v1.0 Page 12 of 37
Figure 5: Malicious eNB in GSM/3G/LTE
To avoid such simple attacks LTE has introduced authentication between UEs and the radio network. But, there have been reports about “IMSI catcher” attacks also for LTE recently [6], [7], [12]. The known attack for LTE uses specification and protocol deficiencies as well as implementation flaws. Here, one example is related to the EMM protocol vulnerabilities. , where the main idea is to force the UE not to use LTE to connect to the network, but rather to use 3G/GSM instead, which is known for its weaknesses.
Another example is the tracking area update procedure as described in [7]. It can be described as follows:
UE sends “TAU request” to notify TA
MME & UE agree on the network mode
“TAU reject” message can be used to reject certain services – in this case LTE
UE connects to eNB using 3G/GSM (reject messages are not integrity protected)
Other issues with the security of LTE, beside the given example, have been discovered. The main reasons are listed below [8]:
Specification issues; these include, e.g. no mutual authentication, traffic that is not encrypted, or weak cryptography in general. Issues within the specification have the potential to affect all users and should be fixed quickly.
Implementation issues; these include software issues of the users broadband processor, like buffer overflow, and information leaks. In this case only a group of users might be affected. Usually the manufacturer of the mobile device then provides an update.
Protocol context discrepancy issues include cross-layer information loss, where again, all users are affected.
These issues will be discussed further in the context of 5G security in the following sections, together with some proposed solutions.
2.3.2.3. CHARISMA Access and Transport Layer Architecture In its first instantiation, the non-standalone mode, 5G will use the security methods of LTE. In this mode the new joint EPC will connect to both the eNB (LTE) and the gNB (5G central and distributed unit).
EPC (home subscriber server, mobile management, packet gateway, service
The application of the 5G non-standalone mode to the CHARISMA CAL node architecture is shown in Figure 7. The different coloured boxes group the different protocol layer (functions) and interfaces respectively (e.g. S1, X2 interface - brown, 5G functions – orange, TCP/IP – cyan, L1/L2 – light blue. The green edges notify instantiated VMs with the respective protocol functions. The dashed green edges locate infrastructure, where a VM could be instantiated, this allows the movement of protocol function from one node to another. More details about the CHARSIMA architecture can be found in D1.2 [10].
Figure 7: 5G security applied to CHARISMA CAL nodes
The CAL0 node holds the distributed unit (DU) or radio unit, (RU), while the CAL2 node contains the central or digital unit. In between, there is an optional aggregation node, which carries the entire Ethernet-based fronthaul traffic (F1 interface). The packet gateway as part of the EPC is located at CAL3 in this instantiation..
Since the trust model is the same compared to LTE () a potential attacker might try to gain access to the decrypted data at the central unit in CAL2. Since this function might be virtualized as part of a distributed cloud-RAN, the CMO must ensure the integrity of the VM, as well as secure the instantiation of VMs from an attacker.
2.3.2.4. 5G RAN security 3GPP is working on a completely new security architecture for 5G, where the first results can now be found in [11]. It already contains an extensive list of security requirements for the UE and gNB.
The requirements for the gNB are very similar to the eNB (LTE), as indicated by the following list from the same source:
e.g. 5G-RU
IP5G-PHY
5G-MAC
5G-RLC
5G-PDCP
5G-PHY
5G-MAC
5G-RLC
5G-PDCP
IP
user device(mobile phone)
5G distributed unit(CAL0)
5G central unit(CAL2)
5Gair
interface
TCP/UDP
APP
GTP
UDP
IP
GTP
UDP
IP
L2
IP
TCP/UDP
APP
App server(Remote host)
5GF1 (fronthaul)
interface
5GS1, X2
interface
L2
Aggregation node(CAL1)
e.g.L2: EthernetL1: fibre
CAL3 withvirtualized
Packet gateway
L1 L1
L2L2
L1 L1
L2L2
L1 L1
L2L2
L1 L1 L1 L1
e.g.L2: NG-PON2, OFDM-PONL1: fibre
e.g.L2: EthernetL1: fibre
e.g.L2: EthernetL1: 60GHz radio L1: 5G radio
5G-PHY
5G-PHY
5G-PHY
5G-PHY
5G-PHY
5G-PHY
IP
e.g
. P
G-V
M
e.g. DU-VM
PDCP sec
IP sec
CHARISMA – D2.5 – v1.0 Page 14 of 37
The gNB shall support ciphering of user data between the UE and the gNB.
The gNB shall support ciphering of RRC-signalling.
The gNB shall implement the following ciphering algorithms: NEA0, 128-NEA1, 128-NEA2
The gNB may implement the following ciphering algorithms: 128-NEA3
Confidentiality protection of user data between the UE and gNB is optional to use.
Confidentiality protection of the RRC-signalling and NAS-signalling is optional to use.
Confidentiality protection should be used whenever regulations permit.
This indicates that the mandatory encryption of user data is not planned. Since this is a measure to secure the wireless channel between UE and gNB, the encryption should be enabled by default and the UE should indicate if it is turned off. This would allow the end user to check the security of the connection, similar to the https indicator (lock) in a web browser.
A weak authentication can enable the deployment of fake base stations a.k.a. “IMSI catcher”. As discussed in the earlier section 1 researchers have found some loopholes in LTE, which encourage the forced fall-back to a GSM/3G connection. 5G needs to improve authentication procedures, especially those from the network to the end user.
In reference [11] improved authentication procedures are discussed, such as primary authentication and key agreement procedures. These support the binding of an anchor key to the serving network, which prevents one serving network from claiming to be a different serving network, and thus provides implicit serving network authentication to the UE.
Another issue discussed in 1 is the implementation weaknesses in the UE baseband processor. An attacker can potentially target mobiles by a specifically designed SMS, like in the case of the so-called “SMS of death” [12]. A possible solution here is to instantiate a VNF close to the affected users, which operates as a firewall to block such attacks. The affected mobile devices can also be identified by evaluating the TAC part of the phones’ IMEI number. Such a virtualized firewall function has been described and implemented in the respective WP3 and WP4 deliverables, though for a different application.
2.4. Transport & Access Layer Security
Security can be implemented at many levels of the OSI Model communications stack, often with particular focus at the higher, logical layers, e.g. MACSec (data link layer 2) and IPSec (network layer 3). However, the lowest physical layer (layer 1) offers a complementary approach to improve communications security, particularly in the context of wireless networking, where the physical properties of the communications system can also be exploited. Thus, physical layer security (PLS) is becoming an important aspect of 5G security design, but presents a technical challenge compared to 4G, due to several factors (already mentioned above) such as the introduction of a more distributed network architecture and of emerging technologies such as network virtualization. 5G networking also features both wireless (e.g. between end-users and the radio unit) and fixed links (e.g. for the front- and back-hauling) each of which has its own security issues.
The broadcast nature of the wireless domain and mobility of the users make them susceptible to a wide variety of security attacks such as passive (Traffic analysis and Eavesdropping) and active (Denial of Service (DoS) attack, Resource consumption, Masquerade attack, Replay attack, Information disclosure and Message modification)[15]. Traditional solutions to mitigate the security challenges are usually handled at the upper layer using various types of private and public secret keys via computation-based mechanisms (i.e. cryptography). The reliability in the exchange of information between a source node (“Alice") and an intended destination node (”Bob"), and security in terms of confidentiality and message integrity with respect to an adversary (“Eve") using computational security approaches have been reported to be susceptible to attacks [16][17], and in a dynamic mobile environment it is computationally complex and intensive [18][19]. Security is seen from the viewpoint of layered network design as an add-on feature, in
CHARISMA – D2.5 – v1.0 Page 15 of 37
particular separating the physical layer from the upper layers as a reliable bit pipe, and providing security at the PHY layer should be viewed as fortifying the existing computational security techniques [20].
2.4.1. PHYsec
Physical layer security (PLS) against passive and active attacks is classified into five major categories: i) theoretical secure capacity; ii) channel; iii) coding; iv) power and v) signal detection techniques. The fundamental issues of theoretical secure capacity have drawn much attention and most of the work in this area focuses on secrecy capacity; that is, the maximum rate achievable between the legitimate transmitter-receiver pair subject to the constraints on information attainable by the unauthorized receiver. In summary, information-theoretic security is an average-information measure and it also requires the knowledge of the channel state information that may not be necessarily accurate in practice. The channel approach is classified into three methods to provide physical layer security based on exploitation of the channel characteristics such as radio frequency (RF) fingerprinting, Algebraic Channel Decomposition Multiplexing (ACDM) pre-coding, and randomization of MIMO transmission coefficients. The main objective of the code approach is to improve resilience against jamming and eavesdropping. The code technique is subdivided into the use of error correction coding and spread spectrum coding. Information protection can also be facilitated using power techniques. The usual schemes here involve the employment of directional antennas and injection of artificial noise. A directional antenna facilitates receiving of data from the direction not covered by the attacking signal. Finally, in the case of introducing artificial noise, secret communication between legitimate nodes can be achieved. In [21], a method has been proposed in which discriminatory channel estimation is performed by injecting artificial noise into the remaining space of the legitimate receiver's channel to degrade the estimation performance of the eavesdropper. An improvement to this approach is discussed in [22], by exploiting the channel feedback information from the legitimate receiver at the beginning of each communication stage, and is also called a multi-stage training-based technique.
2.4.2. MACsec (L2 frame crypto), Link Layer technology
MAC layer security is a Layer2 security mechanism, which provides authentication, integrity and encryption. MACsec uses symmetric encryption (i.e. it is AES based), with the integrity also including the Layer 2 addresses. There are several mechanisms to provide data integrity and privacy protection: The downstream PHY frame is scrambled using a frame-synchronous scrambling polynomial. Despite the scrambler’s main purpose not actually being related to security, the shift register used to calculate this polynomial is reset by a preload pattern that changes for every downstream PHY frame. In the downstream frame, the preload pattern can be inferred from the downstream physical synchronization block (PSBd) block and it is also used to reset every upstream PHY frame of the corresponding downstream PHY frame. For that reason, in order to retrieve upstream information, synchronization between downstream and upstream is needed. Furthermore, NGPON2 supports a data encryption system, such as AES-128 cipher, in downstream and upstream directions. It can be applied not only to client services but also to the ONU management and control channel (OMCC) that uses the OMCI messages. OMCI messages and physical layer operation, administration and maintenance (PLOAM) messages have a message integrity check field that is used to verify the sender's identity and to prevent a forged PLOAM message attack. The receiver computes its version of the MIC and compares it with the MIC value carried in the received PLOAM message. If the two MIC values are equal, the PLOAM message is valid. Otherwise, the message is declared invalid.
The MACsec Key Agreement (MKA) protocol also allows for automatic, cyclic key distribution, by adding a adding a 16-bytes header field after the Ethernet source address. This field provides cipher information and counters for replay protection. MACsec encrypts just a point-to-point link, but is a strong protection against replay based attacks, which are normally the base for attacking the higher layers, as a man-in-the-middle attack. Here it should be noticed that MACsec protection doesn’t secure layer 2 forwarding, if it isn’t applied at the interim devices. This means protection against ARP spoofing is only possible if all interim switches are configured to check the MACsec security before they process the packet information for forwarding actions. Unfortunately, this is not a feature of MACsec, [32][33][34][35][36].
CHARISMA – D2.5 – v1.0 Page 16 of 37
Due to its modular layout, InnoRoute’s routing platform supports the integration of MAC layer security into its data path. This guarantees a secure and fast communication at the layer 2 level, because encryption can be offloaded in pipelined processing blocks, where key management can be done by the integrated CPU. The TrustNode also provides a solution for the spoofing based man-in-the-middle attacks which MACsec doesn’t cover (see next section).
2.4.3. 6TreeSec (network based source authentication)
A common routing infrastructure is flexible and doesn't have restrictions with respect to the address layout. On the other hand, this flexibility makes the IP routing vulnerable to attacks focusing on packet routing, e.g. [37][38][39][40]. . In addition, the use of IPv6 offers the possibility to restructure the routing infrastructure in a physical and logical way [41].
One of the key items proposed by CHARISMA is the hierarchically organized network structure, where a hierarchical address layout with specialised routing hardware is used to speed-up the traffic forwarding [42].
This is achieved by introducing the fast hierarchical routing concept. Here, 6Tree creates a trusted network where sender authentication is performed by the network itself. The routing of the 6Tree traffic is fully implemented in hardware. There is only one configuration parameter, which tells the device its logical position in the network [43][44][42][45].
Using this concept, the path of a packet through the network is strictly predefined by the value of the IPv6 address bits, which are inside the protection area of MACSec.
By applying a check for the source address on incoming packets the network devices are not vulnerable to L2+L3 address spoofing attacks. Therefore when a 6Tree packet is received, the source address and the way through the 6Tree network is verified, which authenticates the source towards the destination. The 6Tree network can also be used to secure the OpenFlow control channel, where misuse of this channel needs to be strenuously avoided. By mapping the OpenFlow control channel to the 6Tree network, control by a non-authorized user can thereby be avoided.
2.4.4. IPsec (L3 packet crypto)
IPSec functions at Layer 3, providing security by using end-to-end tunnels, with encryption undertaken only at the ends of each tunnel. For many years a major drawback to IPSec was its complexity: not only does it typically entail a dedicated encryption engine, but IPSec significantly enlarges the size of the Ethernet header. This compounds network overhead and adds to the overall solution cost (in contrast to MACsec which is a relatively simple protocol, and which only minimally expands the header -- see previous section). Also, MACsec can scale linearly with the number of links in hop-by-hop scenarios, and with the number of endpoints in end-to-end applications. An IPSec engine, on the other hand, usually can support only a certain amount of total capacity and a specific number of tunnels per port.
The new approach presented in CHARISMA project within the VNF acceleration in SmartNIC enables IPSec implementation to be like MACsec from a scalability point of view as a simple network-card upgrade, since SmartNIC can implement a lot of Key Associations increasing number of tunnels with the broadening of number of VNFs.
However, the two protocols are compatible and can also be highly complementary. A tag- and flow-based MACsec enhances IPSec on two levels: i) Firstly, in network equipment that’s either too costly or overly power-hungry, it’s now feasible to convert it into something MACsec-based only; ii) Secondly, looking at wireless network security to the level of small cells, the last mile-link between the small cell and central office doesn’t have to be IPSec anymore — it can also now be purely MACsec-based.
As such, IPSec is a good candidate as the overall network security technology of choice, and can also be complementary to L2. IPSec has been used for many years and has been adopted by many vendors, as well as passing lots of different IOTs (interoperability tests).
After reviewing the different security alternatives, this section tries to see how they map with onto the CHARISMA architecture, especially regarding the possible threats. Regarding the overall CHARISMA approach and related to the different layers security, various issues need to be discussed. First, a next-generation 5G network implementation must include both options; and in the case of IPSec, both AH+ESP together are required. Also, considering the hardware acceleration solution (SmartNIC/TrustNode Router) proposed within the project, it would be easy to offload IPSec for a high throughput network. Since IPv6 deployment will not require NAT it would be much easier to implement IPSec. In combination with hierarchical IPv6 the described 6Tree6tree6Tree concept can also provide source authentication and prevent L2+L3 spoofing attacks. The areas where MACSec is implemented already will continue their deployment to provide better integrity, especially at the edge of IoT network. But at best this would be a combination of both methods.
Function Algorithm
Crypto and Hash algorithms
NIST Suite B Compatible (*)
AES 128/192/256; ECB, CBC, GCM, CTR and XTS
Authentication, Hash and HMAC
SHA-1/SHA-256/SHA-224/SHA-384/SHA-512
GCM, (X)CBC-MAC, SSLMAC
Public Key Acceleration
RSA/DSA/Diffie-Hellman and ECC operations
RSA key size up to 2048-bit
ECC-GF up to 768-bit precision
True Random Number Generator FIPS-140-2/-3
Table 1 Algorithm recommendations for IPsec by CHARISMA
(*) According to our analysis at Layer 3, the most popular would be Suite B, which includes:
Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits. For traffic flow, AES should be used with either the Counter Mode (CTR) for low bandwidth traffic, or the Galois/Counter Mode (GCM) mode of operation for high bandwidth traffic (see Block cipher modes of operation) – symmetric encryption.
Elliptic Curve Digital Signature Algorithm (ECDSA) – digital signatures.
Secure Hash Algorithm 2 (SHA-256 and SHA-384) – message digest.
All other old and slow algorithms are to be deprecated.
CHARISMA – D2.5 – v1.0 Page 18 of 37
3. Securing SDN-enabled Control-Plane Slicing
Multi-tenancy in 5G comes with the ability to carefully handover control of the virtualized infrastructure to the underlying tenants, enabling in this way a fully functional operational model for the emerging virtual network operators (VNOs). This however poses significant security challenges that must be tackled by the CHARISMA 5G architecture. In the following, we first illustrate the concept of control plane slicing, as a means to deliver management and control capabilities to VNOs. We derive the functional requirements and present the integration of such capability with the CHARISMA CMO architecture. Building on these foundations, we then proceed in a careful assessment of the emerging security requirements, which lead our design towards securing the envisioned, sliced control plane. Our solution aims at addressing important security challenges emerging in the context of virtualization and network programmability, including two-way authentication and encryption between the emerging software entities of the virtualized (and sliced) control plane.
3.1. Control-Plane Slicing
3.1.1. Concept
The concept of multi-tenancy in CHARISMA, and beyond, foresees the creation of network slices with the purpose of isolating virtualized sets of network and compute resources for the dedicated use by VNOs. This necessitates the ability to provide VNOs with control over the allocated resources, leading to the requirement of a corresponding slicing of the control plane, i.e. allowing VNOs to manage/configure their virtualized resources. Such capability is expected to provide VNOs with a complete virtualized infrastructure for their services, which in any case necessitates the ability to set up and adjust according to the envisioned VNO services. In this work, we investigate the support of SDN-based control capabilities over the CHARISMA infrastructure, focusing on the example case of the SDN-enabled wireless backhaul equipment; however, the same principles apply to other entities, e.g. HW/SW switches. A typical example of the envisioned capabilities corresponds to the ability to setup forwarding rules and/or QoS management on the flows handled by a VNO over the available wireless backhaul (wBH) switches. A high-level schematic illustration of the concept is provided below. The slicing of the control plane is achieved with the realization of the virtualized SDN controllers for each VNO, allowing control over the sliced wBHs.
Figure 8: Logical representation of control plane slicing
CHARISMA – D2.5 – v1.0 Page 19 of 37
3.1.2. Functional Requirements
In the context of multi-tenancy in CHARISMA, VNOs are allocated with network and compute resources for the support of their (network) service. In the particular context of the targeted wireless backhaul area of the network, the allocation of resources corresponds to network resources at the wireless backhaul switches. VNOs are therefore provided the capability to manage the traffic passing through their slice of the wireless backhaul. Such management includes the capability to:
Apply traffic steering policies.
This functional requirement corresponds to the ability to control the forwarding behavior of backhaul switches as this is applied to the traffic of the corresponding VNO. A particular interest emerges in environments with rich PtP and PtMP topologies, where the forwarding options are multiple and are dictated by aspects related to resilience, latency, service function chaining (i.e., handling a flow to a particular set of virtual network functions (VNFs)), etc. (see also next bullet). The ability to support traffic steering depends on the corresponding ability to apply forwarding rules on the wireless backhaul switches. In the spirit of slice traffic isolation, this capability must only apply to flows belonging to the VNO’s operational domain.
Apply differentiated QoS treatment.
This functional requirement enables the prioritization of particular flows according to the associated QoS requirements. In turn this translates into the ability of assigning flows to particular wBH queues, managing these queues, while also further adjusting traffic policing and monitoring mechanisms. Resilience can also be part of the overall QoS features, potentially pointing to the support for fast failover mechanisms and/or traffic steering policies (see above).
Obviously, the aforementioned baseline functionality builds on control plane primitives that are readily available in SDN environments, including CHARISMA’s wireless backhaul. The challenge stems from the sharing of the same infrastructure, which dictates the isolation of the operational domains of the various co-located VNOs (and the infrastructure provider’s operational domain). This isolation takes first the form of traffic and resource isolation aiming at the correct and autonomous operation of isolated VNOs, i.e. no VNO network configuration can interfere any other’s VNO network configuration either in terms of forwarding decisions or in terms of QoS treatment or both. Towards this direction, the community has delivered solutions based on the concept of network hypervisors, namely, entities responsible for ensuring the isolation between control plane slices. The same concept has also been incorporated in the overall SDN paradigm, targeting the shaping of recursive client-server relationships between SDN orchestrators at various levels of SDN controller hierarchies [24][25].
We elaborate on these concepts in the following subsections (Section 3.1.3), subsequently sketching its adoption in the context of the CHARISMA CMO architecture (Section 3.1.4). Our purpose is to illustrate how CHARISMA can achieve the aforementioned functional requirements in the first place. Setting the architectural scene, we then proceed to a detailed security threat analysis that identifies the security risks in the envisioned solution (Section 3.2), and enables the identification and specification of the corresponding countermeasures (Section 1).
3.1.3. SDN Overlay and Network Hypervisors
The concept of network hypervisors has attracted intensive research interest during the last years, leading to a series of technical solutions supporting the aforementioned control plane slicing functional requirements [23]. presents a high level overview of the concept. In conventional SDN designs (a) an SDN controller is responsible for interfacing the physical infrastructure through the southbound interface, else known as the Data-controller plane interface (D-CPI). The SDN controller abstracts the infrastructure to the applications over the northbound interface, also known as the Application-controller plane interface (A-CPI). Hence,
CHARISMA – D2.5 – v1.0 Page 20 of 37
applications responsible for the management of resources are aware of the actual network topology and have control over it. The Network Hypervisor (NH) introduces an additional level of abstraction. Acting as an SDN controller, the NH has the view of the physical infrastructure as in conventional SDN (b). However, additional, virtual SDN controllers are introduced to handle each control plane slice. The NH exposes a different abstraction of the network infrastructure to these controllers that capture the operational boundaries of each vSDN controller (c), enforcing the aforementioned isolation. This abstraction refers both to the exposed topology of the network (e.g., identifying nodes that can be configured) and the set of resources subject to configuration by each vSDN, e.g. interfaces, flow tables, sets of flows, switch CPU resources, transmission rates/queue management etc. This abstraction is offered to vSDNs through a standard D-CPI e.g., OpenFlow. Similarly, applications on top of the vSDN interface the latter over standard A-CPIs, e.g. Intent NBI2.
Figure 9: The network hypervisor concept [23]
One of the first and well-known NHs is FlowVisor[24]. FlowVisor applies isolation through the concept of flowspaces which are defined as sub-spaces of the header field multi-dimensional space, e.g. IP src/dst, port, VLAN ID, etc.
It follows from the above that hypervisors actually realize a recursive use of the SDN model/concepts and interfaces, to apply the desired isolation between control plane domains, i.e. slices. This is depicted in . In the simplest case, the control plane slicing concept is facilitated by a two-level hierarchical SDN controller setup. The lower level SDN controller (equivalent to NH) interfaces the actual infrastructure, exposing a southbound interface (D-CPI) to the higher level SDN controllers (equivalent to vSDNs).
Figure 10: Recursive client-server relationships in hierarchies of SDN control plane [24]. A two level hierarchy effectively realizes the NH concept.
Another related active research area is SDN Overlays. SDN Overlays are able to manage the network traffic of VNFs, whereas Network Hypervisors are used to control the different Virtual Slices of VNOs. Both technologies could merge if the SDN controllers of SDN Overlays would subscribe to the vSDN controller of the VNO. In CHARISMA, such overlays could be used to monitor and program the VNFs internal networking.
An SDN Overlay provides networking management and control in a set of resources independently of the infrastructure configuration. Within CHARISMA, the set of resources maps to Virtual Slices, which consists of both compute and network resources. In order to have the resources subscribed to the SDN controller they must to be under the same LAN. Since this requirement may not be possible under every edge scenario, the usage of an Ethernet VPN might be mandatory.
Below exemplifies the deployment of an SDN Overlay Network Service across two different VIMs. Here, the Network Service (NS) includes two VNFs. VNF1 has three Virtual Deployment Units (VDUs) whereas VNF2 has only one VDU. The second VNF runs a SDN controller, which manages the OVS bridges of VNF1. As a result of interconnecting all VDUs to the Ethernet VPN, all VMs are discoverable the SDN controller.
Figure 11: SDN Overlay across different Data Centres
CHARISMA – D2.5 – v1.0 Page 22 of 37
As an overlay of the physical infrastructure, SDN Overlays empower VNOs with a certain degree of flexibility when configuring their own networking capabilities. The SDN Overlay also allows a higher degree of flexibility to implement Network Services within the network overlay, allowing their management and monitoring even after the VNF deployment phase and regardless of the infrastructure capabilities.
3.1.4. CHARISMA CMO Adaptation
CHARISMA adopts the well-established NH concept, to support control plane slicing for multi-tenancy. The high level approach is illustrated in . A NH, e.g. FlowVisor[24], is responsible for interfacing the physical infrastructure on behalf of the infrastructure operator. Each VNO gains control over the corresponding wireless backhaul slice through a dedicated vSDN, which controls the corresponding slice through the NH mediation. The Open Access Manager (OAM) is responsible for establishing control and data plane slices through the NH. Additionally, the OAM component may also act as a northbound application for vSDNs, providing specific parameters and configurations to the SDN controller’s applications.
Figure 12: CHARISMA CMO control plane slicing overview
A detailed representation of the CHARISMA CMO adaptation is provided in , where a VNF is created per tenant for the realization of the corresponding vSDN. Northbound applications can be either bundled within the same VNF or realized as separate VNFs. All control plane VNFs belong to the overall network service (NS) and are typically instantiated upon the realization of the network slice. The initialization is controlled by the OAM, which is responsible for creating the network slice abstraction at the network hypervisor. This is accomplished through an NH implementation specific interface such as JSON-RPC for the case of FlowVisor. It is noted that a NH is instantiated as a typical SDN controller over the physical infrastructure. Provided the instantiation of the corresponding control plane VNFs, the NH is further responsible for the bootstrapping of each tenant’ control plane domain. In the example case of the FlowVisor NH this happens with the following series of steps:
A new slice is created at the NH. This is initially a high level abstraction of a structure to be filled in with information about the corresponding flowspace and vSDN. Slice creation further enables the bootstrapping of the underlying topology with the currently (at each time) set of flowspaces (see next step).
CHARISMA – D2.5 – v1.0 Page 23 of 37
A new flowspaceis defined and associated to a slice. As packets may (in principle) match multiple flowspaces, a distinct priority is set to each of the corresponding slices. Fine-grained access rights are associated with each flowspace-slice mapping.
Figure 13: CHARISMA CMO control plane slicing solution (detail)
3.2. Threat Analysis and Security Requirements
In the previous subsection we described an extension to the CHARISMA CMO for the support of control plane slicing. The solution supports tenant isolation, and separates the operation domains of the VNOs. However, the envisioned setup does not aim at addressing concerns related to security threats/vulnerabilities. In the following we identify such risks through a security threat analysis, with the purpose of reaching a solid set of functional security requirements. We subsequently propose specific mechanisms/countermeasures to satisfy the identified security requirements. It is noted that in this work we focus on a set of important security risks, mostly related to cryptographic operations, while leaving others for future work, e.g. resilience against (distributed) DoS attacks.
3.2.1. Threat Analysis
Our threat analysis builds on the well-known STRIDE model [27], which is also compatible with recent advances on NFV Security, in the context of ETSI [28]. According to the STRIDE model, security threats are classified to the following categories:
Identity Spoofing Refers to threats related to a system user appearing as another system user, or assuming the security attributes of another user. This type of risk is related to user authentication processes.
Tampering Refers to threats related to the change of data delivered to/by a user or system. This type of risk is related to the integrity of the exchanged information/data.
Repudiation Refers to threats related to tracking user/system behaviour.
CHARISMA – D2.5 – v1.0 Page 24 of 37
Information Disclosure Refers to threats related to the rightful access to information by a user/system. This type of risk is related to the confidentiality of communication.
Denial of Service Refers to threats related to (DoS) attacks. This type of risk is related to the availability of a system.
Elevation of Privilege Refers to threats related to unauthorized change of user privileges. This type of risk is related to the authorization processes of a system.
Using this STRIDE model we identify the following set of security risks for our setup. For each threat we identify potential actors that can possibly launch the corresponding attack, the corresponding consequences, and the related architectural components. Additionally, we indicate the desired security countermeasure linked to this type of security threat, with the purpose of shaping the subsequent derivation of security requirements.
CHARISMA – D2.5 – v1.0 Page 25 of 37
Table 2: Security Threats in CHARISMA Control Plane Slicing
Threat Attacker Consequences Related components
Countermeasure
Information Disclosure
Eavesdropping: an attacker monitors communication over the A/D-CPI (passive attack).
Tenant/ VNO/ 3rd Party
• Obtain flow table statistical information – analyze forwarding capabilityof the ports – future attacks (DoS)
• Learn the QoS parameters of the created slices
NH – wBH, NH–vSDN
Confidentiality
* Encryption
Information Disclosure
Eavesdropping: an attacker monitors communication over the NH-OAM interface (passive attack).
Tenant/ VNO/ 3rd Party
• Learn the contents of JSON RPC messages and corresponding slicing setup of infrastructure provider
NH –OAM Confidentiality
* Encryption
Repudiation
Eavesdropping: an attacker monitors communication over the D-CPI and A-CPI (passive attack).
Tenant/ VNO/ 3rd Party
• By obtaining flow table statistical information, learning the QoS parameters as well as the content of the forwarding rules, the attacker can obtain useful information about the system behaviour of competing VNOs
NH – wBH, NH–vSDN,
NH –OAM
Confidentiality
* Encryption
Tampering
An attacker can tamper the communication messages over the D-CPI interface transferred between backhaul switches and hypervisor.
• Change notification messages from switches the SDN controller has incorrect view of NE’s state incorrect traffic forwarding decisions
NH – wBH, NH–vSDN
Integrity
* MACs
CHARISMA – D2.5 – v1.0 Page 26 of 37
Tampering
An attacker can tamper the communication messages over NH-OAM interface.
Tenant/ VNO/ 3rd Party
• Create fraudulent slices
• Violate traffic isolation
NH – wBH, NH–vSDN
Integrity
* MACs
Spoofing An attacker can impersonate a wBH, a vSDN or the NH.
Tenant/ VNO/ 3rd Party
• A malicious (v)SDNc can have full access to the wBH and disrupt the operation of the network.
• A malicious (v)SDNc can have non-legitimate access to VNO network state and configuration capabilities.
• A malicious switch can provide a deceitful view of the network state and can also overwhelm the hypervisor with traffic.
• A malicious NH can create non-legitimate fraudulent slices.
• A malicious NH can provide a deceitful view of the network state to a vSDN.
NH – wBH, NH–vSDN
Authentication/ authorization * Trust model for each couple of NEs,e.g.certificates
CHARISMA – D2.5 – v0.1 Page 27 of 37
3.2.2. Security Requirements
Based on the security threat analysis, in the following sections we identify and group the desired security-level functional requirements corresponding to the identified threats.
3.2.2.1. Authentication and Authorization Authentication mechanisms are required for addressing spoofing security threats, i.e.to enable the communicating entities (NH, vSDN, wBH) to authenticate themselves against each other, and prove their true identity. It is noted that for all pairs of communicating entity types, i.e. NH-vSDN, NH-wBH, NH-OAM, a two-way authentication mechanism is required so as to protect all communicating parties.
Given the availability of authentication mechanisms, authorization mechanisms are also further required to ensure that the communicating control plane entities have the appropriate privileges for each control plane action (see Section 1).
Typical authentication mechanisms employ public-key cryptography [29], which necessitates mechanisms for the exchange of asymmetric public/private key pairs and the placement of digital certificates at the communicating entities. In Section 1 we shed light on the details of such mechanisms and exactly how these can be employed within the multi-tenancy context of CHARISMA. Finally, it is important to further note at this point, that the concepts behind the NH are strongly related to authorization procedures. Namely, provided the support for authentication, the NH is responsible for further authorizing control actions on the underlying infrastructure, subject to the privileges defined during the creation of the corresponding slice, e.g. ensuring that a certain vSDN is authorized to apply forwarding rules only within a particular flowspace (see Section 1).
3.2.2.2. Confidentiality and Integrity The emerging confidentiality requirements point to the ability to encrypt the exchanged control plane traffic, allowing only legitimate entities (e.g. NH, vSDN, wBH) to decrypt it. This is typically achieved through symmetric cryptography mechanisms, e.g.AES GCM, which subsequently points to the requirement for the establishment of a shared key between the communicating entities.
Integrity further ensures that the exchanged control plane messages have not been altered by any intermediate malicious entity. This is typically achieved through Message Authentication Codes, e.g. SHA-256/SHA-384, which further necessitate the agreement on a common hash function between the communicating entities.
3.3. Key Exchange
Fulfilling the derived functional security requirements is achieved through the support of the following mechanisms:
Generation of public/private key pairs
Placement of digital certificates
Establishment of shared keys
Agreement on common hash function (for MAC)
This has to occur between all pairs of communicating entities in the adapted CHARISMA CMO architecture (see Section 1), namely:
NH-vSDN
CHARISMA – D2.5 – v0.1 Page 28 of 37
NH-wBH
NH-OAM
In the following we present the current SotA techniques for these functional requirements, focusing on Transport Layer Security (TLS) (see Section 1) and its support in the currently employed Software frameworks. We then describe how these mechanisms are employed in the context of CHARISMA so as to satisfy the identified security requirements.
3.3.1. State-of-the-Art Techniques
3.3.1.1. Transport Layer Security Transport Layer Security (TLS)[46] aims to support the establishment of security primitives in communication networks. TLS supports a handshaking procedure, which is employed by the communicating parties so as to negotiate the configuration of the employed security mechanisms. More specifically, the TLS handshake allows the participating entities to negotiate public-key cryptography, symmetric cryptography, and Message Authentication Codes settings, which correspond to the identified CHARISMA security requirements.
For public key cryptography, TLS can establish the agreed Digital Security Algorithm,e.g. Elliptic Curve DSA (ECDSA) that is to be employed for the generation of public/private key pairs. During the handshake procedure the communicating entities exchange public keys and Digital Certificates. This implies the subsequent requirement for the availability of a trusted (third party) certificate authority to securely introduce the two communicating entities to each other by signing digital signatures.
For symmetric cryptography, TLS can be used for establishing the key agreement/exchange protocol, e.g. Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), based on which the shared key will be agreed/exchanged, as well as for establishing the encryption algorithm, e.g. Advanced Encryption Standard (AES) / AES-128-GCM.
For Message Authentication Codes (MACs), TLS can support the negotiation of the cryptographic hash algorithm, e.g. SHA-256, unless already supported by the established encryption algorithm, e.g. AES-128-GCM.
3.3.1.2. TLS in OpenDayLight SDN Controller
OpenFlow Plugin
OpenDayLight (ODL) [30] is a widely adopted SDN controller, also employed by CHARISMA. ODL provides support for TLS through its OpenFlow Plugin[47][48] which is based on OpenSSL[49][50]. The plugin supports two-way authentication and authorization over the D-CPI, i.e. it supports the mutual authentication and authorization of the ODL controller and the underlying switches, both on a SW, i.e. OpenVSwitch[51], and a HW level, e.g. Brocade MLX Switch3. The underlying OpenSSL implementation further supports symmetric cryptography and MACs through TLS, as explained above.
It must be noted however that currently available technical solutions and common practices are heavily influenced by the existing SDN specifications. Characteristically, according to the ONF OpenFlow Switch Specification [31], TLS support for OpenFlow is typically recommended, but not a mandatory feature.
Unified Secure Channel (USC)4
An earlier ODL project, named Unified Secure Channel, has aimed also at supporting secure communication between the ODL SDN controller and the underlying switches. The project is based on an architecture that employs a USC Agent at each switch and a USC Manager on the ODL side. Secure communication is enabled
by the USC Plugin that provides TLS/DTLS support, and is employed by the USC Manager for communication with the USC Agents.
3.3.2. The CHARISMA Secure Control Plane Slicing Solution
The overall CHARISMA solution is illustrated in Figure 14. It is first assumed that the infrastructure provider (IP) and operator of the CHARISMA solution, has established a digital certificate at the OAM, NH and wBHs signed by a trusted third party certificate authority. This is required so as to ensure trust in the overall infrastructure in the first place. The exact technical means for this procedure are out of this deliverable’s scope; however, typically, such a certificate would be placed manually.
Figure 14: CHARISMA Secure Control Plane Slicing Overview
The TLS handshake procedure is subsequently triggered by the OAM towards the NH, establishing a secure communication channel. The NH also triggers the TLS handshake procedure with the wBHs. These two steps take place once, during initial (re-)configuration of the network. When the OAM initiates the creation of a new tenant/VNO, it contacts the NH so as to establish the network slice on both the data and control plane. This is accomplished over the previously-established secure communication channel; typically employing an HTTPS transport. The overall slice creation process also includes the instantiation of a vSDN as described above (not shown in the figure). Once the vSDN controller has been instantiated, the NH triggers the TLS handshake with it as well. This step is considered as part of the overall VNO slice bootstrapping process, which subsequently allows the vSDN to gain a view of the underlying virtual topology and become capable of configuring the wBHs through the NH.
3.3.3. Configuration details
In order to achieve a secure connection between network entities such as vSDN, e.g. ODL and wBHs, the management of their PKI (Public Key Infrastructure) is required. The exact configuration depends on the wireless backhaul vendor’s specifications, or the application framework in use.
In order to provide a general overview, since the same logic applies to any SDN network element, we will focus on vSDN, which in our case is ODL. ODL is implemented in Java, and Java has its own key management
CHARISMA – D2.5 – v0.1 Page 30 of 37
framework, accessible from the keytool terminal program. By default, the Java Virtual Machine (JVM) keystore is in:
$JAVA_HOME/jre/lib/security/<keystore-name>.jks
However it is best practice to start with a clean state in a new directory. The keytool utility is then invoked to create a new public and private key pair.
keyalg: the algorithm to be used for creating the keypair. In our case, it will be Elliptic Curve (i.e. EC)
alias: the domain name
keystore: the name of the keystore file
storepass: the password of the keystore
keysize: the size of each key to be generated. In our setup, it should be 256 bits.
Since, the certificate has to be signed by a certificate authority (CA), it is required to create a Certificate Signing Request (CSR), which will be sent to the CA. This can be done with the following command: keytool -certreq -alias {domain_name}-keystore{keystore_file}-file {my.csr}
where the -file parameter specifies the name of the output file. Then, the CSR should be sent to the CA in order to receive the Digital Certificate. Once received, the Certificate can be imported to the keystore with the following command:
Here, the -aliasand –keystoreparameters have the same meaning as previously, and the –file parameter specifies the certificate obtained from the CA.
Regarding the extraction of the certificate, it boils down to the format of the keystore of the other entities being communicated with, e.g.wBH, NH. In an example case, Open vSwitch requires a certificate in Privacy Enhanced Mail (PEM) format, so the .jks must be converted to .p12 and finally to .pem. Then, the certificate part of the .pem file is extracted and copied to the switch. This is accomplished through means of,e.g.SSH/SCP, which in turn builds on the support of a device-specific secure communication channel by the switch vendor. This is the necessary starting point for the subsequent establishment of secure communication channels on the logical control level (as opposed to the device level).
The installation of the switch certificate on the ODL, can be accomplished through the following command:
After appropriately configuring the PKI of the switch as well, the command for initiating the SSL/TLS connection for the OVS switch s1 case is ovs-vsctl set-controller s1 ssl:ip:port. The same logic applies to the SSL/TLS configuration of all network elements.
The security landscape of 5G systems increases exponentially due to the required tightly knitted alignment
with vertical industries, and the heterogeneous nature of the integrating technologies (wired or wireless
networks, virtualization, internetworking of virtual and physical resources, etc.). This documents reports the
CHARISMA end to end v-security solution as well as provides commentary on the end to end security
architecture for a general 5G network.
For the general 5G security end to end architecture, the document provides an overview and how it maps to
CHARISMA CAL node architecture from protocol stack perspective. The document also describes the
Transport and Access layer security including PHYsec, MACsec, 6TreeSec, and IPsec and how they are
implemented by different CHARISMA intelligent nodes.
The document mainly focuses on the end to end v-security solution. This solution targets the multi-tenant
virtualized nature of 5G networks and how and end to end virtualized security can be realized for VNOs. This
is achieved by complimenting the intelligence driven v-security solution (VSFs + SPM + M&A) [D3.4] with
SDN-based control-plane slicing security. The document also describes the concept and functional
requirements of the SDN-based control-plane slicing security and reports threat analysis accordingly. The
proposed secure control-plane slicing solution is also described and mapped to CHARISMA CMO along with
the explanation of constituent security mechanisms such as key exchange.
The document provides an overall overview of end to end security aspects for virtualized SDN/NFV-based
multi-tenant environments as well as from a general 5G network perspective.
CHARISMA – D2.5 – v0.1 Page 33 of 37
References
[1] Ericsson, “The Impact of Quantum Computers and Post Quantum Cryptography”, S3-161847, 3GPP TSG-SA3 Meeting #85, Santa Cruz de Tenerife, Spain, 7–11 November 2016
[3] Quantum Safe Cryptography and Security;An introduction, benefits, enablers and challenges, White paper, https://docbox.etsi.org/Workshop/2014/201410_CRYPTO/Quantum_Safe_Whitepaper_1_0_0.pdf, (retrieved 2017-10-06)
[4] Katriel Cohn-Gordon, et a. “A Formal Security Analysis of the Signal Messaging Protocol”, 2017 IEEE European Symposium on Security and Privacy (EuroS&P)
[5] Blom, et al.: “Security in the Evolved Packet System”, Ericsson review 2/2010, pp.4-7
[6] Altaf Shaik, et al.: “Practical Attacks Against Privacy and Availability in 4G/LTE Mobile Communication Systems”, https://arxiv.org/abs/1510.07563v3
[7] Ravishankar Borgaonkar, et al.: “LTE and IMSI catcher myths”, Blackhat EU, Amsterdam, Netherlands, 2015
[8] A. Dabrowski, “Lessons learned from 2G,3G,4G – what we need to fix in 5G”, ETSI Security Week 2017 – 5G Security
[9] M. Wong, “Security Considerations in 5G”, ETSI Security Week. Athens
[10] K. Habel, et al. “D1.2 Refined architecture definitions and specifications”, 2016, http://www.charisma5g.eu/wp-content/uploads/2017/01/CHARISMA-D1.2_final_v2.pdf, (retrieved 2017-10-27)
[11] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for 5G System (Release 15), 3GPP TS 33.501 V0.3.0 (2017-08), (retrieved 2017-10-17)
[12] Collin Mulliner, et al., “SMS of Death: from analyzing to attacking mobile phones on a large scale”, USENIX Security 2011
[13] Stig F. Mjlsnes, Ruxandra F. Olimid::“: “Easy 4G/LTE IMSI Catchers for Non-Programmers”, https://arxiv.org/pdf/1702.04434.pdf
[14] Highest security with the SiMKo 3 smartphone, http://www.laboratories.telekom.com/public/English/Newsroom/news/Pages/simko3-smartphone.aspx (retrieved 2017-10-06)
[15] Y.-S. Shiu, S. Y. Chang, H.-C. Wu, S. C.-H. Huang, and H.-H. Chen, “Physical layer security in wireless networks: a tutorial," IEEE Wireless Communications, vol. 18, no. 2, pp. 66{74, 2011.
[16] A. Biryukov, A. Shamir, and D. Wagner, “Real time cryptanalysis of a5/1 on a pc," in International Workshop on Fast Software Encryption, pp. 1-18, Springer, 2000.
[17] D. Wagner, B. Schneier, and J. Kelsey, “Cryptanalysis of the cellular message encryption algorithm," in Annual International Cryptology Conference, pp. 526-537, Springer, 1997.
[18] C. Adams and S. Lloyd, Understanding PKI: concepts, standards, and deployment considerations. Addison-Wesley Professional, 2003.
[19] T. Austin, PKI: A Wiley Tech Brief. John Wiley & Sons, Inc., 2000.
[20] A. D. Wyner, “The wire-tap channel," The bell system technical journal, vol. 54, no. 8, pp. 1355-1387, 1975.
[21] T.-H. Chang, Y.-W. P. Hong, and C.-Y. Chi, “Training signal design for discriminatory channel estimation," in Global Telecommunications Conference, 2009. GLOBECOM 2009. IEEE, pp. 1-6, IEEE, 2009.
[22] I. Csiszar and J. Korner, “Broadcast channels with confidential messages," IEEE transactions on information theory, vol. 24, no. 3, pp. 339-348, 1978.
[23] A. Blenk, A. Basta, M. Reisslein and W. Kellerer, "Survey on Network Virtualization Hypervisors for Software Defined Networking," in IEEE Communications Surveys & Tutorials, vol. 18, no. 1, pp. 655-685, Firstquarter 2016.
[24] J. Ordonez-Lucena, P. Ameigeiras, D. Lopez, J. J. Ramos-Munoz, J. Lorca and J. Folgueira, "Network Slicing for 5G with SDN/NFV: Concepts, Architectures, and Challenges," in IEEE Communications Magazine, vol. 55, no. 5, pp. 80-87, May 2017.
[25] ONF TR-518, “Relationship of SDN and NFV”, Oct. 2015
[26] Sherwood, Rob, et al. "Flowvisor: A network virtualization layer." OpenFlow Switch Consortium, Tech. Rep 1 (2009): 132.
[27] Howard, Michael, and David LeBlanc. "The STRIDE Threat Model. From the Book’Writing Secure Code’." (2002): 38-60.
[28] ETSI GS NFV-SEC 006 V1.1.1 (2016-04), Network Functions Virtualisation (NFV);Security Guide; Report on Security Aspects and Regulatory Concerns, http://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/006/01.01.01_60/gs_NFV-SEC006v010101p.pdf
[29] Stallings, William, and Mohit P. Tahiliani. Cryptography and network security: principles and practice. Vol. 6. London: Pearson, 2014.
[30] Medved, Jan, Robert Varga, Anton Tkacik, and Ken Gray. "Opendaylight: Towards a model-driven sdn controller architecture." In World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2014 IEEE 15th International Symposium on a, pp. 1-6. IEEE, 2014.
[31] Open Networking Foundation, “OpenFlow Switch Specification,” Version 1.5.1 (Wire Protocol 0x06), March 26, 2015
[32] Juniper Understanding Media Access Control Security (MACsec) 2017
[33] Brocade MACsec feature guide 2015
[34] Wikipedia IEEE 802.1AE --- Wikipedia, The Free Encyclopedia 2017
[35] Dubroca, S. MACsec: a different solution to encrypt network traffic 2016
[36] Indukuri, N. R. Layer 2 security for smart grid networks Advanced Networks and Telecommunications Systems (ANTS), 2012 IEEE International Conference on 2012, pp. 99-104
[37] Tan, S., Li, X. and Dong, Q. TrustR: An Integrated Router Security Framework for Protecting Computer Networks IEEE Communications Letters, IEEE, 2016, Vol. 20(2), pp. 376-379
[38] Wang, F., Vetter, B. and Wu, S. F. Secure routing protocols: Theory and practice Technical report, North Carolina State University, 1997
[39] Yin, J. and Madria, S. K. A hierarchical secure routing protocol against black hole attacks in sensor networks IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing (SUTC'06) 2006, Vol. 1, pp. 8-pp
[40] Ballani, H., Francis, P. and Zhang, X. A study of prefix hijacking and interception in the Internet ACM SIGCOMM Computer Communication Review 2007, Vol. 37(4), pp. 265-276
CHARISMA – D2.5 – v0.1 Page 35 of 37
[41] Hinden, R. and Deering, S. Internet Protocol Version 6 (IPv6) Addressing Architecture IETF, RFC 3513 (Proposed Standard), 2003(3513)
[42] Ulbricht, M. and Wagner, J. Accelerated Processing Delay Optimization in Hierarchical Networks Using Lowcost Hardware 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP) (CSNDSP16) 2016
[43] Choo, H. and JANG, S. Method of operating internet protocol address and subnet system using the same Google Patents, 2010
[44] Foglar, A. and Sonntag, S. Router IP port for an IP router Google Patents, 2009
[45] Foglar, A., Parker, M. and Rokkas, T. IPv6 Source Routing for ultralow Latency IETF, RFC draft, 2017(3513)
[46] Dierks, Tim, and Eric Rescorla. "RFC 5246: The Transport Layer Security (TLS) protocol." The Internet Engineering Task Force (2008) [https://tools.ietf.org/html/rfc5246]
[49] Viega, John, Matt Messier, and Pravir Chandra. Network security with openSSL: cryptography for secure communications. “O’Reilly Media, Inc.", 2002.
[50] OpenSSL Web-site: https://www.openssl.org/
[51] Pfaff, Ben, Justin Pettit, Teemu Koponen, Ethan J. Jackson, Andy Zhou, Jarno Rajahalme, Jesse Gross et al. "The Design and Implementation of Open vSwitch." In NSDI, pp. 117-130. 2015.
