9.2 Protection of the Backhaul

9.2.1 Cryptographic Protection Compared to Other Protection

As discussed, 3GPP in a number of cases mandates the use of IPsec for the mobile backhaul, unless the network is physically secure. IPsec is addressed in a separate section (9.3).

In addition to the services provided by IPsec protocols, further protection within the mobile backhaul may need to be considered. Backhaul service may be disturbed even if IPsec is deployed, if the backhaul is open to threats by other means of attack, or by attacks on other protocol layers. 3GPP does not specifically address the need for protection on other layers, or protection of the mobile backhaul in general.

As an example, a router may forward the IPsec encapsulated traffic to a false destination, if the routing table has been manipulated maliciously. Similarly, a Layer-2 bridge may be overloaded with non-legitimate traffic, so that the IPsec encapsulated packets cannot be forwarded further.

This type of issues and threats are not specific to the mobile network backhaul only, nor are the design practices and features that address them. Some of the key issues, mostly related to L2, are included in this section. They are specific to a packet mobile backhaul, as similar threats did not exist in the TDM era.

Protection of the backhaul against various threats is closely related with QoS and resilience. QoS features, such as ingress policing or admission control, prevent unauthorized or excessive use of network resources. Resilience targets maintain the service. Many threats aim at making the service unavailable. Security and resilience have thus a common goal of keeping the network operational.

Traffic separation, as well as other non-cryptographic protection, can be considered as additional and complementary measures to IPsec. They are not replacing the protection IPsec offers. On the other hand, IPsec alone does not address all of the threats within the mobile backhaul.

9.2.2 Leased Service and A Self-Deployed Backhaul

A mobile operator may have his own self-managed mobile backhaul or it may be leased from a service provider. Often it is a combination of the two.

Security has to do with trust, and protection is often deployed at the administrative boundaries, between two operator's domains. These operator domains are also different security domains. If the network service is not trusted, a security gateway can be implemented at the network border. Traffic can be carried within an IPsec VPN over the service provider's network.

The situation is, however, not as simple. Threats originate also from the inside of a security domain, not only from an external attacker. Misconfigurations take place. They may be unintentional, or done maliciously. Many of these threats can at least partly be mitigated by sound network design guidelines and operating practices. Besides, many topics are vendor and node technology specific. A few of these topics are addressed in the subsequent text.

9.2.3 Traffic Separation

Separating traffic logically isolates the backhaul network into separate sections or domains. Communication over a domain is typically restricted and controlled, which increases robustness of the system.

At the Ethernet layer, VLANs limit the broadcast domain so that unknown unicast and broadcast frames are not flooded into other VLANs. This already increases the level of protection, as issues (whether due to attacks or misconfigurations) in one VLAN, do not necessarily impact the service on other VLANs.

For traffic to pass on from one VLAN to another, a router is required. With a router, an IP layer control point is introduced. Traffic flows may be allowed or blocked according to a security policy, e.g. by using an Access control list (ACL).

Often, management plane (O&M) traffic is first separated from any other traffic type. As O&M allows many kinds of procedures with a remote configuration, it is specifically a concern. There is also no legitimate traffic need between O&M and user or control plane within the mobile system. Connectivity is only needed to the management system, and thus should be blocked to other destinations.

Metro Ethernet service definition include Ethernet Private Line (EPL), Ethernet Private LAN (EPLAN), Ethernet Virtual Private Line (EVPL) and Ethernet Virtual Private LAN (EVPLAN) services. EVPL and EVPLAN allow an Ethernet virtual connection (EVC) to be separated according to VLAN, so that VLAN based separation is also supported over the service.

Similarly with self-deployed Carrier Ethernet with MPLS/IP, VLANs can be used at the PE ingress node when mapping the attachment circuit to the service. In the MPLS core, traffic from different VLANs is kept separate from each other.

9.2.4 Ethernet Services

With MEF services, E-Line defines a point-to-point connectivity while E-LAN supports multipoint connectivity. (E-Tree is a variant of E-LAN as a rooted multipoint with a restricted connectivity between spokes, which can only reach the hub node).

All of these services logically extend the Ethernet LAN service over the wide area network, using e.g. MPLS/IP. While the MPLS/IP core itself is not vulnerable to the Ethernet LAN related threats, the customer service (e.g. E-LAN), basically has the vulnerabilities of a LAN. With an E-LAN, the provider network looks like a virtual bridge: MAC address learning is supported, with bridging functions like unknown unicast and broadcast flooding.

E-LAN service, if utilized for the mobile backhaul, offers Ethernet level connectivity between all sites connected to the same service instance (VLAN). Logically this is a single VLAN where every station can reach every other station. Allocating stations to different VLANs support further traffic separation.

Point-to-point service (E-Line), or rooted multipoint (E-Tree) provide better isolation, as the spoke stations are not able to communicate with each other. With 2G and 3G, there is also no need for BTS to BTS connectivity, as the logical topology is a hub-and-spoke (E-Tree –like).

LAN related security risks, as well as proposed countermeasures, are discussed e.g. by Vyncke and Paggen [12]. Many topics are vendor specific, in that the configuration options and parameters available to harden the bridges vary. Not all Ethernet LAN related threats and risks can be covered here. A few examples, based on [12], are given in order to illustrate the topic.

Basically plugging in a new station to the LAN allows direct connectivity at the Ethernet layer, via the flooding, bridging/MAC learning processes. The first topic is to disable unused bridge ports. They can also be configured to an unused VLAN. This isolates the port.

DoS attack is easy if the LAN can be accessed via some active port. Traffic can be flooded, either as broadcast frames, or as control traffic. Control frames, such as spanning tree BPDUs or other Ethernet control protocols need processing, and control processor may crash unless protected. Ingress policing limits the maximum amount of traffic that is allowed at ingress of any port, and control plane policing limits the amount of control traffic that is allowed to enter the control processor.

Spanning tree protocol may be needed in the customer sites for redundancy. When spanning tree initially was developed, security vulnerabilities were not considered.

One topic in spanning tree is the root bridge selection. If a bridge is added to the LAN with a better (lower) bridge ID, it claims the root role. All traffic is thus passed via this new bridge. Bridges may have configuration options that limit the possibilities of accepting better bridge IDs from certain ports, or even accepting any type of BPDUs. There typically are also further (vendor specific) parameters to harden the bridge against misconfigurations and malicious attacks.

A simple attack consists of flooding BPDUs that need to be processed by the control processor. This can be mitigated similarly by not accepting BPDUs from a certain port. Also, the incoming frames can be policed so that a certain maximum rate is not exceeded.

Similarly as spanning tree, ARP protocol vulnerabilities were not considered at the time of the design. ARP is not authenticated. Also, all stations connected to the VLAN will learn the IP/MAC address mapping. As all stations also receive ARPs due to the broadcast nature, they also need to process it.

With an ARP spoofing attack, fake ARP replies (gratuitous ARP) are generated by an attacker. Consequently, the attacker receives all frames that were directed to the corresponding IP address. If this is the address of the default gateway, the attacker receives all traffic that is forwarded to the default gateway. For the mobile network, this may in practice mean all traffic from a certain radio access area, depending on the backhaul architecture.

One simple way is to not to allow hosts and devices to accept gratuitous ARP. This, however, slows down recovery in the case of failures. Another way is to maintain a table of ‘valid’ IP – MAC address tables and detect if an attempt is made to modify the bindings.

What is the level of protection IPsec can then provide? Clearly, IPsec does not mitigate Ethernet level vulnerabilities. However, the IP layer remains protected. DoS attacks are possible at the layer below. Application (radio network layer in the case of mobile backhaul), however, remains protected.

9.2.5 IEEE 802.1x and IEEE802.1ae

IEEE is addressing L2 security in recent work, in IEEE802.1x Port-based Network Access Control, in IEEE 802.1ae Media Access Control (MAC) security, and in 802.1ar Secure Device Identity.

Previously, wireless LANs (IEEE Std 802.11) support mutual authentication, generation of cryptographic keys, and using those keys for protecting the frames over the wireless LAN.

Port-based Network Access control supports authentication of devices attached to the LAN. Generation of the Secure Association Keys (SAKs) is defined in 802.1x. Secure Device Identity supports a cryptographic identity, that binds the identity to a device (such as a LAN station). Secure Device Identity supports authentication by IEEE802.1x.

MAC security means cryptographic protection. The default cipher suite is GCM-AES-128. Security relationships are maintained by MACsec Key Agreement. A definition of a secure Connectivity Association (CA) is used. Each CA supports Secure Channels (SCs) with symmetric keys. Each SC in the CA uses the same Cipher Suite. Within SCs, Secure Associations (SAs) are supported. These SAs use a Security Association Key (SAK). MAC security introduces a new Ether type (88E5H), with a new security tag.

802.1ae has been amended in 2011, with IEEE Std 802.1AEbn. The amendment adds a GCM-AES-256 Cipher Suite as an alternative.

When native Ethernet (or an Ethernet service) is used in the mobile backhaul, these protocols are candidates for increasing protection on the first mile from the BTS to the IP edge device.

9.2.6 MEF

In MEF service specifications, security is based on traffic separation, with EVCs defining how subscriber's traffic is kept separate (MEF10.2). Additional functionality is subject to subsequent phases in MEF 10.2. In the mobile backhaul implementation agreement (MEF22) for EVP-Tree, essentially a similar type of notion is given. A level of protection is achieved by the use of traffic separation.