Security Gate & Gi Firewall

Transcription

1 Security Gate & Gi Firewall Protecting the Mobility Infrastructure Introduction By the year 2015, it is predicted that there will be 25B devices connected to the Internet, more than three for every person on the planet. By 2020, that number is expected to double to more than six per person. The overwhelming majority of these devices will be wireless devices, connected to WiFi and 3GPP mobility networks such as LTE. Unlike the rise of 2G/3G/3.5G networks, the mobility network infrastructure needed to support this tsunami of new device will require the deployment of large numbers of microcell devices, from large metrocells supporting dense urban areas to residential femtocells needed to provide coverage where only terrestrial broadband Internet connectivity exists. Securing this complex set of software interfaces between sets of nodes will be a critical challenge in meeting the growth requirements of mobility networks. It is equally important to understand that these mobility network architectures are not static. LTE must coexist with older 3GPP architecture, and support handoff of devices between architectures. The classes of devices defined within 3GPP Release 10 (Advanced LTE) can support up to 1Gbps DL/500Mbps UL per device, a ten fold increase compared to current LTE devices supporting 100Mbps DL/50 Mbps UL per device. Round-trip latency requirements have reduced from 100ms for 3G networks, to 10ms for LTE and 5ms for Advanced LTE. The industry crossover from selling mostly standard phones to smartphones means the need to support increasing numbers of concurrent sessions and session rate for application growth. Security solutions for mobility networks must have a proven ability to scale with these requirements as well.this white paper will discuss the background of 3GPP mobility network architectures from a security standpoint, biased towards LTE (Long Term Evolution 3GPP R8 and better). We will explore the concept around two specific security implementations: the Security Gateway (SeGW) to protect the network infrastructure and resources, and the Gi Firewall to inspect traffic from mobility users to packet data networks (including the Internet and Carrier IMS services). Finally we will discuss how the FortiGate can be used to server each of these two roles. While an effort is made in this paper to educate IP security engineers with a background in the architectural concepts and terminology associated with 3GPP mobility networks, it is not intended to substitute for experience or substantive technical information available from reference books and many internet sites. Whenever possible, this paper will make use of the 3GPP terminology, which is rich in acronyms and summary terms. A list of the terms and acronyms used in this are provided at the end. Understanding 3GPP Mobility Networks Prior to LTE, 2G/3G/3.5G networks were primarily designed to handle voice as circuit-switched traffic, to ultimately connect to the similarly circuit-switched PSTN. A separate packet-switched environment handled carrying data such as web, , and SMS/MMS services to packet data networks (PDNs), including the Internet. The radio network controllers (RNCs) associated with these networks have the task of provisioning radio resourcing for both voice and data, but are predominantly biased towards voice. While not the first smartphones on the market, the growth of BlackBerry devices in 2005/2006 and introduction of the Apple iphone in 2007 resulted in a massive demand for data resources on carrier 2G then 3G networks, to the point where RNCs were straining to deliver both voice and data services to the growing number of devices joining the mobility networks. In older 2G/3G environments, a single device receiving a large could use the radio resources equivalent to up to 30 voice calls. 1

2 There are a large number of software interfaces defined within the GPRS network, but of significant security concern are: Figure 1 Older 3GPP mobility network architectures. In the majority of the world (and 30 of the larger 32 carriers), 2G/3G networks are based on GSM/UMTS. However, in the US has majority of subscribers associated with 2G/3G networks based on CDMA (CDMAone/CDMA2000), which supports larger cell sizes with fewer towers. 3GPP specifications and carriers upgraded to improve radio resourcing and data performance. This includes HSPA+ (part of the 3GPP R7) for UMTS networks, with data speeds rivaling LTE. Many HSPA+ carriers market HSPA+ services as 4G, although for this purposes of this paper we are using the term 3.5G, to prevent confusion with LTE, as well as the fact that HSPA+ is compatible with 3G data architectures to allow reuse of existing network packetswitched components. CDMA based carriers have generally opted to migrate data (and eventually voice) services to LTE, rather than upgrade their 3G (EV-DO) packet-switched environments. Regardless of the radio technology used, the core of 2G/3G/3.5G network is the General Packet Radio Service, or GPRS. Relative to security requirements, the principal components of the GPRS are: Gn which is an IP-based interface between the SGSN and internal GGSNs, as well as to other SGSNs, DNS, and external GRX (GPRS Roaming Exchange) providers. This interface uses GTP (GPRS Tunneling Protocol) and DNS Gp which is an IP-based interface between the SGSN and external GGSNs, for use by roaming UEs. This interface uses GTP. Gi which is an IP-based interface between GGSN and external PDNs such as the Internet. This is a general IP interface, although carriers can optionally support various encapsulation/encryption protocols on this interface Unlike older 3GPP networks, LTE combines voice and data traffic onto a common packet-switched network called the Evolved Packet Core EPCs. The role of the RNC has been incorporated into the base stations, or evolved NodeBs (enb), to reduce overall network latency and performance. The role of the SGSN has been split into two components: - S-GW Serving Gateway which is responsible for the delivery of packets to/from UEs within the S-GW geographical service zone - MME Mobility Management Entity which is responsible for the authentication of subscriber UEs, as well as their assignment to S-GWs within same geographical service zone. The MME is the principal control node for the LTE access network SGSN Serving GPRS Support Node which is responsible with the authentication of subscriber User Endpoints (UEs, which are the mobile devices), and the delivery of data packets to/from UEs within the SGSN s geographical service area GGSN Gateway GPRS Support Node which is responsible for internetworking between the carrier s GPRS network and external PDNs, including the Internet Figure 2 Evolution to 4G-LTE. 2

3 The purpose of this segregation is to provide flexibility growth of LTE within geographical areas. MMEs and S-GW are placed into MME and S-GW pool areas, which correlate to unique UE tracking areas. UE tracking areas can contain multiple cells, but a cell is a member of only one UE tracking area. To add complexity, an enb can service cells from different UE tracking areas. Each UE tracking area is associated with MMEs and S-GWs in their respective pool areas. As UEs move between UE tracking areas, they can remain connected to their original MME and/or S-GW, as long as their new UE tracking areas is still associated with the same pool area of the original assignment. Figure 3 Scaling LTE by use of MME and S-GW pool areas. Therefore, if a given UE tracking area requires more access capacity, they can add additional MMEs to its Associated MME pool area. Also, if a given UE tracking area needs more data bandwidth, they can increase the number of S-GWs within the associated SG-W pool areas, and load-balance UE assignments between them. The PDN Gateway, or P-GW, replaces the role of the GGSN. The differential is the inclusion of support for LTE software interfaces, as well as support for QoS requirements in servicing packet-based voice calls through to IP Multimedia Subsystem (IMS) services, which are carrier internal PDN beyond the P-GW. All software interfaces within an LTE network are now IP-based, where some older networks made use of SS7- based signaling on some interfaces. LTE introduces a set of new and renamed software interfaces, many of which need to be considered relative to security requirements. These include: S1-MME which is a control-plane interface between the enb and the MME, and is used to control UE access to the EPC. This interface runs an S1-AP application that is transported over SCTP (Stream Control Transmission Protocol) S1-U which is a user-plane interface between the enb and the S-GW, and is used to transfer data from UEs to their assigned S-GW. This interface uses GTP S3 In order architectures, communication between SGSNs is handled by the Gn interface. LTE supports interoperability with older networks by supporting control-plane communications between the MME and SGSNs. This interface uses GTP S4 Similar to S3, this interface allows LTE to support interoperability with older networks by supporting userplane data transport bewteen SGSNs and LTE P-GWs. This interface uses GTP S5 which is both the control-plane and user-plane interface between S-GWs and internal P-GWs. This interface uses GTP or Proxy Mobile IPv6 plus Generic Routing Encapsulation (PMIPv6/GRE). Note that some LTE products combine the S-GW and P-GW interface into a common device, and in these cases, the S5 interface does not exist externally S6a which provides communication between the MME and HSS (Home Subscriber Server), in support of LTE access operations. This interface uses the Diameter protocol. Note that the MME can communicate with its native HSS or a foreign HSS, for support of roaming users S8 Similar to S5, this interface supports both the control-plane and user-plane communications between the S-GW and foreign P-GWs. The interface uses GTP S10 which is used for communication between MMEs, in support of handoff and management operations. This interface uses GTP S11 which is used for communication between the MME and S-GW, for management communications. This interface uses GTPv2 S12 which is optionally used to allow direct tunneling of data from UEs in older networks to the S-GW of an LTE network. This provides efficiency over using relaying data to the SGSN to be passed by the S4 interface, and requiring coordination via the S3 interface. The S12 interface uses GTP X2 which is the interface that allows enbs to communicate between each other in support of handoff, load-balancing and congestion control. This interface uses SCTP. However, it should be noted that the nature of this interface is that X2 sessions between enbs should be established directly as possible. Therefore it is possible to use an L2 media other than Ethernet. 3

4 SGi which is the interface between the P-GW and external PDNs. It is a generic IP interface, also the optional use of various encryption/encapsulation protocols is supported. It is identical to the Gi interface in older networks As previously noted, substantial growth in the LTE network will come from the deployment of microcells. These have a significant advantage over macrocells (tower-based units). Their smaller footprint allows them to be much easier to position to achieve the most cost effective coverage for a given area. They can also be deployed in both indoor and outdoor settings, which can greatly improve coverage with building that shield tower-based communications, or even allow the deployment of a microcell to cost-effectively cover a macrocell sized rural area that only has light duties. It should be noted that many microcells today can simultaneously support multiple 3GPP network technologies, such as both HSPA+/LTE, to support a wide range of UE devices and deployment models. There are roughly four general types of microcells, although the form factor, usage, and terminology can vary widely between carriers and equipment providers. These are: 1. Metrocells These microcells have a cell size of a few hundred meters, and multiple units can be deployed within densely populated urban areas to meet coverage and subscriber density requirements. 2. Picocells These microcells are generally used in large indoor environments such as shopping centers, with cell sizes that are tens of meters in size. For example, an electronics retailer selling mobile phones from multiple carriers may deploy picocells supporting different carriers to provide high-quality connections for the devices they sell. 3. Small Cells This is a wide-term for a variety of microcells designed to cover lower subscriber density requirements. Their cell sizes can vary up to multiple kilometers in size. For example, an outdoor small cell mounted on a pole or other highpoint in a rural area could provide coverage for a few hundred subscribers in a 2km radius. 4. Femtocells These are a special class of microcells that consumers can purchase to improve connections in their home or small office. Unlike other microcells, the HeNB (Home enb) in these units are lockable to a definable set of UEs. They are designed make use of the consumer s home broadband Internet connection. In general, microcells use available broadband Internet connectivity as backhaul to the carrier s EPC. This broadband connectivity can be provided by the carrier or from a third-party, and can use a variety of broadband media (DSL, cable, fiber, even wireless). These backhaul connections can require encryption/encapsulation (VPN) to support the integrity and confidentiality of the data on the backhaul from the microcells enb to the EPC. Security Requirements for Mobility Networks Before we begin to define the security requirements for mobility networks, a word of caution is provided to the reader. The Internet is IP-based, from which can be inferred that as its commercial use grew from the early 1990 s until today, IP security mechanisms have evolved to meet an ever growing set of threat vectors. Mobility networks may have evolved over the same time from analog circuitswitched to IP-based packed switched networks, but the security of these networks have been generally based on the establishment of isolated IP networks for their management. The focus of improvement of mobility networks has always been to maintain and improve the quality of the subscriber s experience, in the face of subscriber growth and improvement in UE technology. It will come as no surprise that it may be difficult for IP security practitioners to communicate effectively with telecom engineers, the latter of whom are more focused on improvements to radio interface technologies and operational considerations. It is the deployment of mobility network components across third-party providers and the increasing use of IP-based management systems that is forcing the migration away from the security shield offered by isolated IP networks. It is equally important to note that the principal requirement for evaluating the effectiveness of a security solution deployed on a mobility network will be its impact on the performance, reliability, and reported subscriber experience of the network, rather than its demonstrated security effectiveness. Security solutions introduced into mobility networks must have long-term scalability in forwarding performance vectors such as session capacitance (session rate and total number of concurrent sessions) and effective 4

5 throughput, while maintaining low-latency and reliable operation. While HSPA+ is extending the usefulness of UMTS-based 3G networks, with performance at near-parity to LTE-based 4G networks, the discussion of these security devices will be centered on LTE EPC deployments rather than UMTS/CDMA GPRS core deployments. Based on our understanding of mobility network architectures, we can define a set of security requirements need to protect them. There are three distinct types of traffic we need to consider: 1. Control-Plane Generally this is the messaging/ applications between components that make up the infrastructure of the mobility network. As previously noted, the types of protection that can be deployed can be derived from the IP based protocols used to transport these messages/applications 2. Data-Plane Generally this is the data flowing between UEs and the PDNs providing services to them. While traversing the mobility network, much of this traffic is encapsulated in GTP or GRE. However connectivity on the Gi/SGi interface from the GGSN/P-GW is usually open to a variety of content inspection mechanisms 3. External Encryption/Encapsulation As the nature of mobility growth is resulting in the use of third-party networks to backhaul traffic, additional security devices may be required to provide services that are not inherent to the mobility infrastructures themselves. This can support the integrity of both control-plane and/or data-plane communications. For example, a high performance VPN concentrator may be required to terminate IPSec connection from enbs associating themselves with a set of MMEs/S-GWs. Another example could be a VPN device used to provide connectivity from a set of P-GWs to a specific PDN hosted via a third-party network. From these, we can derive two distinct security devices that can be deployed onto mobility networks: a security gateway (SeGW) to protect and provide integrity for control-plane communications, and a Gi firewall (GiFW) to protect, inspect, and provide integrity for data-plane communications (user traffic) to/from external PDNs. It is important to note that for the security functionality defined for both of these security devices, support for both IPv4 and IPv6 is required. The principal role of the SeGW can be defined to include the following security functions: High performance stateful firewall support across LTE interfaces, to generally limit communications between specifically defined devices. QoS support, including rate-limiting, queuing, and support for DSCP marking of packets to allow signaling of QoS requirements to/between other devices DoS protection, to protect the availability of mobility resources from misbehavior of mobility infrastructure devices GTP firewall protection, with support for GTP-C v2 for control plane traffic (S3, S5, S8, S10, S11) and GTP-U for data-plane encapsulation of user-traffic (S1-U, S4, S5, S8, S12) SCTP firewall protection, to limit communications between specifically defined devices (S1-MME, X2) Diameter firewall protection, to protect and control AAA messages (S6a) High performance VPN concentrator support to provide termination of large numbers of VPN tunnels from the enbs to the EPC (MME/S-GW). It is assumed that this will make use of IPSec VPN technology, although it is noted that some carriers and equipment providers are making use of TLS-based VPNs based on OpenVPN/OpenConnect capabilities Support for VPN termination between local and foreign network components, as required by carrier agreements As the GiFW s inspects data-plane traffic between UEs and RDNs, the security functions it can will support can vary widely based on carrier requirements, and even evolve to include value-added functionality. It is important to note that a principal role of the GiFW is to provide protection for UEs from PDN-based attacks, and vice-versa. A set of security functions to be considered include: High performance next-generation firewall (NGFW) for the SGi interface. NGFW functions are considered to include: FW, IPS, and Application Control QoS support, including rate-limiting, queuing, and support for DSCP marking of packets to allow signaling of QoS requirements to/between other devices DoS protection, to protect PDNs from misbehaving UEs DDoS protection, to mitigate the affects of PDN-based DDoS attacks against subscriber UEs, as well as resource protection for data-plane mobility infrastructure components 5

6 Support for VPN termination between the EPC and PDN resources located across third-party networks, as well as termination of management VPN connections The ability to include valve-added unified threat management (UTM) security functionality on a per user, group, or device-type basis. Examples of this would include: Web content filtering Anti-malware filtering, sandbox analysis for zero-day threats Botnet protection Data leakage prevention Anti-spam other control/filtering functionality Multimedia messaging service (MMS) scanning Support for NAT functionality, including carrier-grade NAT (CGN), in support of extending IPv4 address resources and aiding native IPv6 deployments to UEs across IPv4 mobility infrastructures (6rd) 4. Terminating VPN connections support backhaul communications between enbs and the EPC across third-party network For the GiFW, the two distinct deployment roles include: 1. Between GGSNs within the GPRS core of older 3GPP networks and PDNs (including the Internet) 2. Between P-GWs within EPCs of LTE networks and PDNs (including the Internet) This is not meant to imply that the same physical appliance cannot perform multiple deployment roles. Virtualizon technology can be used to consolidate multiple deployment roles into a common physical appliance. However, it is important to consider the effect such a consolidation may have on long-term scalability and resiliency requirements of the security solution. The Fortinet Advantage FortiASIC Accelerated FortiGate Appliances The Fortinet FortGate consolidated security platforms offer unmatched performance, flexibility, scalability, and security for carriers and service providers seeking a SeGW solution for their mobility networks. Using FortiASIC technologies, they are capable of sustaining high-performance, lowlatency operation, and can scale to meet multi-year operational and performance targets. Figure 4 Deployment SeGW and GiFW functions into mobility network architectures. The diagram above describes the general deployment of SeGWs and GiFWs, relative to mobility network architectures. For SeGWs, the four distinct deployment roles include: 1. Within the GPRS core of older 3GPP network architectures, notably between SGSN and GGSN resources 2. Between LTE and older 3GPP networks, supporting traffic on LTE interfaces provided for network architecture interoperability (S3, S4, S6a, S8, S12) 3. Between components within the LTE EPC Figure 5 Overview of the Fortinet LTE security solution. 6

7 Appliances supporting FortiASIC Network Processor (NP) technology benefit from the wire-speed firewall performance, QoS support, and DoS protection offered by this family of FortiASICs. The current FortiASIC-NP4 can support these functions at up to 40Gbps, with a packet performance rate supporting any packet size. Supporting extremely low-latency operations (<10 μs), the FortiGate platform far exceeds the performance requirements for insertion into LTE and Advanced-LTE mobility networks The FortiASIC-NP4 also supports hardware acceleration of inter-vdom links. In GiFW implementations, these inter- VDOM links can be used to provide full segregation of PDN security requirements, while providing aggregation to a common set of P-GWs. A wide range of FortiGate mid-size and high-end appliance models are available, to provide flexibility in deploying SeGW & GiFW functionality within production mobility networks. FortiGate appliances also operate as high-performance VPN concentrators. Each FortiASIC-NP4 is capable of supporting up to almost 9 Gbps of IPSec encryption/decryption, and up to 64K IPSec SAs per ASIC. FortiGates support of Virtual Domains (VDOMs), Fortinet s firewall virtualization technology, provides for full segregation of policy, forwarding, and management functions, with support for up to 500 VDOMs per physical appliance. Operating as an SeGW, VDOMs can be used to segregate software interface functions and/or device types within the mobility network architecture, allowing a single hardware platform to perform all of the distinct deployment roles outlined in the requirements section. Figure 7 FortiGate mid-range and high-end models supporting FortiASIC-NP4 technology. Additionally, the FortiGate 5000 series chassis, with networking and security blades, offers the highest combination of performance and flexibility in developing and deploying SeGW & GiFW solutions. FortiGate security blades can operate independently, or a variety of clustering technologies on the central FortiSwitch/FortiController networking blades can be used to scale performance requirements across multiple FortiGate security blades. Figure 6 Representation of using VDOMs and inter-vdom links to consolidate multipe SeGW and FiFW functions into a single appliance. Figure 8 Fully loaded FortiGate 5140B chassis. 7

8 FortiOS/FortiCarrier OS The FortiOS 5.0 operating system provides a wide range of FW/VPN, NGFW, and UTM functions supported within FortiGate hardware and virtual appliances, including the VDOM support to fully segregate security functions within complex mobility networking architectures. However, there are a few carrier-specific security features developed by Fortinet, which require a specially licensed version of FortiOS, called FortiCarrier OS. These functions include: GTP Firewalling and Inspection MMS Scanning Diameter protocol validation Prior to version 5.0, FortiCarrier OS was only supported on specific FortiCarrier hardware models. In version 5.0 FortiCarrier is now supported on both existing FortiCarrier hardware models, as well as on a wide-range of standard FortiGate models by applying a FortiCarrier upgrade license to an existing FortiGate hardware or virtual appliance. GTP Sequence Number Checking GTP & SCTP Stateful Inspection APN, IMSI, MSISDN Filtering Over Billing Protection Support for GTP Profiles Support for APN Objects Support for IMSI Objects Quick Reconnection of GTP Tunnels GTP-in-GTP Tunnel Blocking MMS scanning is a carrier-specific function incorporated in the GiFW role. FortiCarrier OS provides MMS scanning support as follows: Directly to/from UE devices, via the MM1 interface Between the carrier s internal MMS relays/servers to external servers, such as servers, via the interface Between the carrier s internal MMS relays/servers and those belonging to other carriers, via the MM4 interface Between the carrier s internal MMS relays/server to/ from external value-added service providers, via the MM7 interface Billing System MMS VAS Application MMS User Databases MMS MM7 MMS HLR MMS MMS User Agent MM1 Relay MMS Relay/Server MM2 Server MM4 Foreign MMS Relay/Server Figure 9 FortiOS/FortiCarrier OS security functionality. GTP-C v2 firewall support is a critical function for SeGW deployments, which is supported in FortiCarrier OS. As a SeGW, a FortiGate can inspect GTP traffic as follows: External Server #1 (e.g. ) External Server #2 (e.g. Fax) External Server #3 (e.g. UMS) External Server #N Figure 10 FortiCarrier OS MMS scanning deployments. MMS User Agent GTP-C v2 firewall support is a critical function for SeGW deployments, which is supported in FortiCarrier OS. As a SeGW, a FortiGate can inspect GTP traffic as follows: Support for GTP-C v0/v1/v2, and GTP-U GTP Protocol Anomaly Detection and Prevention GTP Packet Forward and Route GTP Multiple Filter Options (Message, APN, IE removal) GTP Sanity Checking all Header field check FortiCarrier OS extends many FortiOS security functions to MMS traffic, including anti-virus scanning, anti-spam and flooding protection, and data leakage prevention (DLP). A special build of FortiCarrier OS provides Diameter protocol validation, which supports the protocol over SCTP or TCP. This functionality supports RFC-6733 and 3GPP application validation, as well as attribute value pair (AVP) validation. Diameter validation is important to maintain both internal and roaming authentication security. 8

9 Summary Given the explosive demand and growth in mobility networks, and subscriber reliance on the performance, security, and reliability of these networks, there is a clear need to deploy scalable, high-performance, and reliable Security Gateway (SeGW) and Gi Firewall (GiFW) solutions. With the migration towards LTE and all IP-based mobility networks, as well as necessary use of third-party networks as backhaul solutions in microcell deployments, carriers can no longer rely on IP network isolation to meet their security requirements. Fortinet has a long history of providing carriers and service providers with security solutions to meet the growing demands placed on their networks. FortiASIC accelerated FortiGate appliances provide the performance, scalability, low-latency, and resiliency to meet the long-term requirements for SeGW and GiFW deployments. FortiOS/ FortiCarrier OS provide a rich and continuously evolving set of features needed to meet the current and future security requirements of mobility networks. Coupled with Fortinet s management and analysis platforms (FortiManager/FortiAnalyzer), security research from FortiGuard Labs, and support for FortiCare, carriers and service providers can rapidly develop and deploy fully managed security solutions into today s advanced mobility infrastructures. GLOBAL HEADQUARTERS Fortinet Inc Kifer Road Sunnyvale, CA United States Tel: Fax: EMEA SALES OFFICE 120 rue Albert Caquot 06560, Sophia Antipolis, France Tel: Fax: APAC SALES OFFICE 300 Beach Road The Concourse Singapore Tel: Fax: LATIN AMERICA SALES OFFICE Prol. Paseo de la Reforma 115 Int. 702 Col. Lomas de Santa Fe, C.P Del. Alvaro Obregón México D.F. Tel: (55) Copyright 2013 Fortinet, Inc. All rights reserved. Fortinet, FortiGate, and FortiGuard, are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance metrics contained herein were attained in internal lab tests under ideal conditions, and performance may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to the performance metrics herein. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet s internal lab tests. Fortinet disclaims in full any guarantees. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable. 9