análise e implementação do protocolo de segurança ipsec · pdf...
TRANSCRIPT
Análise e implementação do protocolo de
segurança IPsec na rede de acesso LTE
Rui Miguel de Sousa Fortio
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Orientador: Prof. António José Castelo Branco Rodrigues
Júri
Presidente: Prof. Fernando Duarte Nunes
Orientador: Prof. António José Castelo Branco Rodrigues
Vogal: Prof. João Miguel Duarte Ascenso
Novembro 2014
iii
Resumo
As vulnerabilidades de segurança existentes na rede de acesso LTE, decorrentes da sua
arquitectura e da utilização de redes de transporte IP inseguras, incentivam a introdução do
Internet Protocol Security (IPsec). O IPsec é um conjunto de protocolos que realizam
autenticação, integridade e encriptação de informação utilizando procedimentos e algoritmos
criptográficos.
O trabalho apresentado foi desenvolvido num contexto empresarial, tendo como objectivo
realizar a introdução do IPsec para protecção da rede e do tráfego, mantendo a resiliência e
desempenho da rede existente. Com este propósito, foi estudo e analisado o impacto na
arquitectura e no desempenho da rede, concluindo-se que:
A introdução do IPsec tem um grande impacto na arquitectura de rede. Os processos de
autenticação e encriptação são computacionalmente bastantes exigentes, obrigando à
introdução do um elemento dedicado, a Security Gateway (SecGW), para termino dos
tuneis IPsec e protecção da rede core;
A autenticação dos eNB deve ser realizada por certificados de chave pública, necessita de
uma infraestrutura de suporte, o Public Key Infrastructure (PKI), para emissão dos
certificados dos SecGW e dos eNB;
O encapsulamento introduzido pelo IPsec obriga à optimização da rede de transporte de
forma a manter a qualidade de serviço, evitar a fragmentação e minimizar o impacto no
desempenho.
De acordo com as conclusões do estudo, foi proposta uma solução para a arquitectura final da
rede. A solução proposta foi implementada em laboratório e avaliada com duas abordagens
diferentes:
Avaliação de desempenho de rede através do protocolo TWAMP [RFC5357];
Avaliação da experiência do utilizador através de testes aplicacionais.
Na avaliação com o protocolo TWAMP, a solução testada em laboratório, mostrou ter um
impacto mínimo no desempenho de rede, que se pode considerar tolerável tendo em
consideração a mais-valia de segurança que é acrescentada à rede e aos serviços
transportados. Nos testes realizados com o objectivo de percepcionar a experiência do
utilizador não foram detectadas diferenças no desempenho de rede.
Palavras-chave
LTE, IPsec, Segurança, Desempenho, QoS
v
Abstract
The security vulnerabilities present in the LTE access network, resulting from a simplified flat
architecture and the use of unsecure transport IP network, encourage the introduction of the
Internet Protocol Security (IPsec). IPsec is a protocol suite for data authentication, integrity and
encryption protection through procedures and cryptographic algorithms.
The presented work was carried out in an enterprise environment and has the objective to
implement the IPsec to protect the network and customer’s traffic, maintaining the resilience
and network’s best performance. For this purpose the impact in the LTE architecture and
performance was studied and analyzed, concluding that:
The introduction of IPsec has impact on the network architecture. The authentication and
encryption processes are computationally quite demanding, requiring the introduction of a
dedicated element in the network, the Security Gateway (SecGW), to terminate IPsec
tunnels and protect LTE core side;
eNB certificate-based authentication, using digital signature with asymmetric keys, needs a
support infrastructure, the Public Key Infrastructure (PKI), for SecGW and eNB public keys
certificate issuing;
The overhead introduced by IPsec, requires transport network optimization to maintain the
quality of service, avoid fragmentation and minimize performance degradation.
According to the study conclusions, it was proposed a solution for the network architecture. The
proposed solution was implemented and evaluated, in a laboratory environment, in two different
methods:
Evaluation of network performance through TWAMP protocol [RFC5357].
Evaluation of the end-user experience using software application tools.
In the TWAMP evaluation, the IPsec network solution tested in laboratory, had marginal impact
on network performance, but it is considered quite acceptable taking in to account the added
value in network security and in the carried services. In the end-user experience tests, no
differences were detected in the network performance.
Keywords
LTE, IPsec, Security, Performance, QoS
vii
Índice
RESUMO III
ABSTRACT V
ÍNDICE VII
AGRADECIMENTOS XI
LISTA DE FIGURAS XIII
LISTA DE TABELAS XVII
LISTA DE ACRÓNIMOS E ABREVIAÇÕES XIX
1 INTRODUÇÃO 1
1.1 ENQUADRAMENTO 1
1.2 MOTIVAÇÃO 2
1.3 OBJECTIVOS 3
1.4 ESTRUTURA DO DOCUMENTO 4
2 ESTADO DA ARTE 5
2.1 REDES DE TELECOMUNICAÇÕES CELULARES 5
2.1.1 REDES DE 1ª, 2ª E 3ª GERAÇÃO 5
2.1.2 REDES DE 4ª GERAÇÃO 6
2.1.3 EVOLVED PACKET SYSTEM (EPS) 7
2.1.4 EVOLVED UTRAN (EUTRAN) - REDE DE ACESSO LTE 8
2.1.5 REDE DE TRANSPORTE IP (IP BACKHAUL) 9
2.1.6 PROTOCOLOS NA REDE DE ACESSO LTE 9
2.2 SEGURANÇA NA REDE DE ACESSO LTE 11
2.2.1 VULNERABILIDADES 11
viii
2.2.2 AMEAÇAS 16
2.2.3 MECANISMOS E PROTOCOLOS DE SEGURANÇA 17
2.3 CONCEITOS DE CRIPTOGRAFIA 20
2.3.1 ENCRIPTAÇÃO SIMÉTRICA 20
2.3.2 ENCRIPTAÇÃO ASSIMÉTRICA 21
2.3.3 ENCRIPTAÇÃO SIMÉTRICA VERSUS ASSIMÉTRICA 22
2.3.4 ALGORITMO DIFFIE-HELLMAN 23
2.3.5 FUNÇÕES DE DISPERSÃO 23
2.3.6 ASSINATURAS DIGITAIS 24
2.3.7 PUBLIC KEY INFRASTRUCTURE (PKI) 25
2.3.8 CERTIFICADOS DIGITAIS X.509 26
2.3.9 PROCESSO DE OBTENÇÃO DO CERTIFICADO DE CHAVE PÚBLICA 27
2.4 INTERNET PROTOCOL SECURITY (IPSEC) 29
2.4.1 TIPOS DE PROTOCOLO 30
2.4.2 MODOS DE OPERAÇÃO 31
2.4.3 SECURITY ASSOCIATION 33
2.4.4 INTERNET KEY EXCHANGE PROTOCOL (IKE) 33
3 IPSEC NA REDE DE ACESSO LTE 37
3.1 NORMAS E POLÍTICAS DE SEGURANÇA 37
3.1.1 NORMAS 3GPP E RFC 37
3.1.2 POLÍTICA DE SEGURANÇA NO PLANO DE CONTROLO (SINALIZAÇÃO) 38
3.1.3 POLÍTICA DE SEGURANÇA NO PLANO DO UTILIZADOR (DADOS) 39
3.1.4 POLÍTICA DE SEGURANÇA NO PLANO DE GESTÃO 39
3.1.5 CONSIDERAÇÕES SOBRE AS NORMAS 39
3.2 CENÁRIOS DE IMPLEMENTAÇÃO DO IPSEC NA REDE DE ACESSO LTE 40
3.2.1 CENÁRIO A - PROTECÇÃO DA REDE CORE E DO TRÁFEGO 41
3.2.2 CENÁRIO B - PROTECÇÃO DA REDE CORE E PARCIAL DO TRÁFEGO 41
3.2.3 CENÁRIO C - PROTECÇÃO MÍNIMA DA REDE CORE 41
3.3 CONFIGURAÇÃO E PARAMETRIZAÇÃO DO IPSEC PARA O LTE 42
3.3.1 CONFIGURAÇÃO IKE (FASE 1) 43
3.3.2 CONFIGURAÇÃO ESP (FASE 2) 45
3.3.3 SECURITY ASSOCIATIONS 45
3.3.4 NÚMERO DE TÚNEIS 46
ix
4 SOLUÇÃO E ARQUITECTURA DE REDE 49
4.1 SECURITY GATEWAY (SECGW) 49
4.2 LOCALIZAÇÃO DA SECGW 50
4.2.1 ARQUITECTURA CENTRALIZADA 50
4.2.2 ARQUITECTURA DISTRIBUÍDA 51
4.3 REDUNDÂNCIA 52
4.4 ZONAS DE SEGURANÇA 53
4.5 INTEGRAÇÃO E AUTENTICAÇÃO DOS ENBS 55
4.5.1 INTEGRAÇÃO DOS ENB NA REDE 55
4.5.2 CERTIFICAÇÃO E AUTENTICAÇÃO DOS ENBS 56
4.6 QUALIDADE DE SERVIÇO 58
4.6.1 QOS EM REDES IP 58
4.6.2 QOS NO LTE 59
4.6.3 QOS NO IPSEC 60
4.7 ENCAPSULAMENTO IPSEC 61
4.7.1 ENCAPSULAMENTO 61
4.7.2 FRAGMENTAÇÃO 62
4.7.3 CÁLCULO DO FACTOR DE ENCAPSULAMENTO E MTU 63
5 AVALIAÇÃO DO DESEMPENHO DA SOLUÇÃO 67
5.1 TESTES DE DESEMPENHO DA REDE 68
5.1.1 PROTOCOLO TWAMP 69
5.1.2 INDICADORES DE DESEMPENHO 70
5.1.3 LATÊNCIA 70
5.1.4 VARIAÇÃO DA LATÊNCIA (JITTER) 73
5.1.5 PACOTES PERDIDOS, DUPLICADOS E DESORDENADOS 75
5.2 TESTES END-TO-END (EXPERIÊNCIA NO UTILIZADOR) 76
5.2.1 FERRAMENTAS E APLICAÇÕES 76
5.2.2 ESTIMAÇÃO DA TAXA DE TRANSFERÊNCIA TCP 77
5.2.3 ESTIMAÇÃO DA LATÊNCIA (RTT) 79
5.2.4 ESTIMAÇÃO DA TAXA DE TRANSFERÊNCIA UDP E ERROS 83
6 CONCLUSÕES E TRABALHO FUTURO 87
x
6.1 CONCLUSÕES 87
6.2 TRABALHO FUTURO 89
6.2.1 IMPACTO EM SERVIÇOS DE TEMPO REAL 89
6.2.2 AVALIAÇÃO DE DESEMPENHO EM AMBIENTE DE PRODUÇÃO 89
6.2.3 EXTENSÃO DO IPSEC A REDES 2G E 3G 89
6.2.4 AVALIAÇÃO DO IPSEC NO PROTOCOLO IPV6 89
ANEXO A - PDU 91
ANEXO B - TABELAS DE QOS 91
B.1 DSCP 91
B.2 ASSURED FORWARDING PHB - RFC 2597 92
B.3 IEEE 802.1Q (P-BIT) 92
ANEXO C - FORMATO TRAMA ESP 92
7 BIBLIOGRAFIA 93
7.1 REFERÊNCIAS 93
7.2 OUTRAS REFERÊNCIAS 95
7.2.1 LIVROS 95
7.2.2 NORMAS 3GPP 95
7.2.3 RFCS 95
xi
Agradecimentos
À família, amigos, colegas e professores. Em especial, à minha mulher Paula, ao meu colega
Paulino Corrêa e ao Professor António Rodrigues pelo incentivo e apoio imprescindível na
realização deste trabalho.
A dissertação aqui apresentada foi realizada num contexto empresarial e teve como base a
necessidade real de implementar uma solução de segurança na rede LTE.
xiii
Lista de Figuras
Figura 1-1 Introdução do IPsec na rede de acesso LTE............................................................. 3
Figura 2-1 Evolução da Redes Móveis (fonte 3GPP) ................................................................. 6
Figura 2-2 Arquitectura da Redes LTE ...................................................................................... 7
Figura 2-3 Rede WCDMA (3G) e Rede LTE (4G) ...................................................................... 8
Figura 2-4 Rede de acesso LTE ................................................................................................ 9
Figura 2-5 Rede de transporte IP (IP Backhaul) ........................................................................ 9
Figura 2-6 Pilha de protocolos na interface S1 (Rec. TS2 3.401) ............................................. 10
Figura 2-7 Pilha de protocolos LTE no modelo OSI ................................................................. 10
Figura 2-8 Core LTE em Pool .................................................................................................. 12
Figura 2-9 Registo do eNB no MME (Rec. TS 36.413) ............................................................. 13
Figura 2-10 S1 Setup Request (Captura com o Wireshirk) ....................................................... 13
Figura 2-11 S1 Setup Response (Captura com o Wireshirk) .................................................... 13
Figura 2-12 Encriptação na rede de acesso LTE ..................................................................... 14
Figura 2-13 Redes de acesso heterogéneas ........................................................................... 15
Figura 2-14 Monitorização e manipulação de informação ........................................................ 16
Figura 2-15 Ataque contra a rede (DOS) ................................................................................. 17
Figura 2-16 IPsec no modelo OSI............................................................................................ 18
Figura 2-17 RAN SecGW na Rede de Acesso LTE ................................................................. 19
Figura 2-18 Número de eNBs com IPsec (Previsão da Heavy Reading’s) ................................ 19
Figura 2-19 Encriptação Simétrica........................................................................................... 20
Figura 2-20 Encriptação Assimétrica ....................................................................................... 21
Figura 2-21 Função de Dispersão ........................................................................................... 23
Figura 2-22 Integridade com Função de Dispersão ................................................................. 24
Figura 2-23 Assinatura Digital ................................................................................................. 24
Figura 2-24 Modelo PKIX ........................................................................................................ 25
Figura 2-25 Certificado X.509 v3 ............................................................................................. 26
Figura 2-26 Emissão do certificado pela CA ............................................................................ 27
Figura 2-27 Protocolos CMP e SCEP ...................................................................................... 27
Figura 2-28 CMPV2 ................................................................................................................ 28
Figura 2-29 IPsec .................................................................................................................... 29
Figura 2-30 IPsec, Modos e Protocolos ................................................................................... 30
Figura 2-31 Modo Transporte .................................................................................................. 31
Figura 2-32 Modo Túnel .......................................................................................................... 31
Figura 2-33 Modo de Operação – Encapsulamento ................................................................. 31
Figura 2-34 Protocolo AH no Modo Transporte (RFC 4302)..................................................... 32
Figura 2-35 Protocolo AH no Modo Túnel (RFC 4302) ............................................................. 32
Figura 2-36 Protocolo ESP no Modo Transporte (RFC 4303) .................................................. 32
xiv
Figura 2-37 Protocolo ESP no modo Túnel (RFC 4303)........................................................... 33
Figura 2-38 Protocolo IKE ....................................................................................................... 33
Figura 2-39 Fluxo de mensagens no protocolo IKEv2 .............................................................. 34
Figura 2-40 Autenticação IKE com certificados ........................................................................ 36
Figura 3-1 Relação entre normas ............................................................................................ 38
Figura 3-2 Interfaces LTE ........................................................................................................ 38
Figura 3-3 Exemplo certificado X.509 (SecGW Juniper) .......................................................... 43
Figura 3-4 Exemplo pre-shared-key (SecGW Juniper) ............................................................. 44
Figura 3-5 Exemplo de uma proposta utilizada na fase 1 do IKE (SecGW Juniper) .................. 44
Figura 3-6 Exemplo de uma proposta utilizada na fase 2 do IPsec (SecGW Juniper) ............... 45
Figura 3-7 Exemplo IKE security association (SecGW Juniper) ............................................... 46
Figura 3-8 Exemplo IPsec security association (SecGW Juniper) ............................................ 46
Figura 4-1 SecGW na rede LTE .............................................................................................. 49
Figura 4-2 SecGW Cisco ASR9000 (esquerda) e Juniper SRX5800 (direita) ........................... 50
Figura 4-3 Arquitectura centralizada versus distribuída ............................................................ 51
Figura 4-4 Tipos de redundância ............................................................................................. 52
Figura 4-5 Redundância: Modo Activo/Passivo ........................................................................ 53
Figura 4-6 Domínios da rede LTE............................................................................................ 54
Figura 4-7 Introdução da SecGW na rede de acesso LTE ....................................................... 54
Figura 4-8 Integração de um eNB IPsec .................................................................................. 55
Figura 4-9 Certificação Automática por SCEP ......................................................................... 57
Figura 4-10 QoS no LTE, IP e Ethernet ................................................................................... 59
Figura 4-11 QoS no LTE ......................................................................................................... 61
Figura 4-12 MTU no Plano de utilizador do LTE ...................................................................... 62
Figura 4-13 Pacote IPsec ........................................................................................................ 63
Figura 4-14 Encapsulamento LTE ........................................................................................... 64
Figura 4-15 IMIX, Factor de encapsulamento .......................................................................... 66
Figura 5-1 Cenário de Teste .................................................................................................... 67
Figura 5-2 Modelo simplificado do cenário de testes TWAMP .................................................. 69
Figura 5-3 TWAMP ................................................................................................................. 70
Figura 5-4 Latência (downlink) ................................................................................................ 72
Figura 5-5 Latência (uplink) ..................................................................................................... 73
Figura 5-6 Variação da latência ............................................................................................... 75
Figura 5-7 Cenário de testes end-to-end (simplificado) ............................................................ 76
Figura 5-8 Velocidade medida no NetPerSec, sem IPsec ........................................................ 77
Figura 5-9 Velocidade medida no NetPerSec, com IPsec ........................................................ 78
Figura 5-10 Velocidade medida no NetPerSec, com IPsec (optimizado) .................................. 78
Figura 5-11 Taxa de Transferência TCP - Comparativo ........................................................... 79
Figura 5-12 RTT (Média e Desvio Padrão) .............................................................................. 80
Figura 5-13 RTT PDF (sem IPsec) .......................................................................................... 81
xv
Figura 5-14 RTT PDF (com IPsec) .......................................................................................... 81
Figura 5-15 RTT CDF (sem IPsec) .......................................................................................... 82
Figura 5-16 RTT CDF (com IPsec) .......................................................................................... 82
Figura 5-17 Carga no CPU e % de utilização da NIC do PC para tramas de 64 bytes .............. 85
Figura 5-18 Carga no CPU e % de utilização da NIC do PC para tramas de 1470 bytes .......... 85
Figura 5-19 Taxa de Transferência UDP e Pacotes Perdidos (sem IPsec) ............................... 86
Figura 5-20 Taxa de Transferência UDP e Pacotes Perdidos (com IPsec) ............................... 86
Figura C-1 Trama ESP no modo Túnel .................................................................................... 92
xvii
Lista de Tabelas
Tabela 2-1 Evolved Packet System (EPS) ................................................................................. 6
Tabela 2-2 Taxas de transferência no LTE ................................................................................ 6
Tabela 2-3 Parâmetros interface S1 ( 3GPP TS 36.413).......................................................... 12
Tabela 2-4 Encriptação e Autenticação ................................................................................... 14
Tabela 2-5 Tipo de estação Vs Transmissão ........................................................................... 15
Tabela 2-6 Encriptação Simétrica versus Assimétrica .............................................................. 22
Tabela 2-7 Diffie-Hellman ........................................................................................................ 23
Tabela 3-1 Protecção da informação em zonas consideradas seguras e inseguras ................ 39
Tabela 3-2 Cenários de protecção........................................................................................... 41
Tabela 3-3 Cenários (critérios) ................................................................................................ 42
Tabela 3-4 Perfil IKEv2 ........................................................................................................... 43
Tabela 3-5 Perfil ESP .............................................................................................................. 45
Tabela 3-6 Túneis IPsec ......................................................................................................... 47
Tabela 4-1 Tipo de Arquitectura .............................................................................................. 51
Tabela 4-2 Mapeamento DSCP / P-Bit .................................................................................... 58
Tabela 4-3 Características dos QCI definidos na norma 3GGP 23.203 .................................... 60
Tabela 4-4 Mapeamento QCI, DSCP, P-Bits ........................................................................... 60
Tabela 4-5 Encapsulamento IPsec .......................................................................................... 63
Tabela 4-6 Encapsulamento LTE com e sem IPsec ................................................................. 64
Tabela 4-7 IMIX ...................................................................................................................... 65
Tabela 4-8 IMIX, Factor de encapsulamento ........................................................................... 65
Tabela 5-1 Cenário de testes (Lista de equipamentos) ............................................................ 68
Tabela 5-2 Perfil IKE/IPsec utilizado nos testes ....................................................................... 68
Tabela 5-3 Latência ................................................................................................................ 72
Tabela 5-4 Variação da latência .............................................................................................. 74
Tabela 5-5 Pacotes Perdidos, Duplicados e Desordenados ..................................................... 75
Tabela 5-6 Testes aplicacionais .............................................................................................. 76
Tabela 5-7 RTT (Média e Desvio Padrão) ............................................................................... 80
Tabela 5-8 IPerf sem IPsec ..................................................................................................... 84
Tabela 5-9 IPerf com IPsec ..................................................................................................... 84
Tabela A-0-1 PDU ................................................................................................................... 91
Tabela B-0-1 DSCP ................................................................................................................ 91
Tabela B-0-2 Assured Forwarding PHB - RFC 2597 ................................................................ 92
Tabela B-0-3 IEEE 802.1Q (P-Bit) ........................................................................................... 92
xix
Lista de Acrónimos e Abreviações
3GPP 3rd Generation Partnership Project
ATM Asynchronous Transfer Mode
BSC Base Station Controller
BTS Base Transceiver Station
CA Certification Authority (PKI)
CMP Certificate Management Protocol
CPU Central Processing Unit
CRL Certificate Revocation List (PKI)
CS Circuit Switch
DDoS Distributed Denial of Service
DHCP Dynamic Host Configuration Protocol
DoS Denial of Service
DPD Dead Peer Detection
DSCP Differentiated Services Code Point
EDGE Enhanced Data rates for GSM and TDMA Evolution
ENB Evolved Node B (BTS 4G)
EPC Evolved Packet Core
EPS Evolved Packet System (EUTRAN + EPC)
EUTRAN Evolved UTRAN
FDMA Frequency Division Multiple Access
FTTH Fiber To The Home
FTTN Fiber To The Node
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile
GTP-U GPRS Tunneling Protocol User Plane
HSS Home Subscriber Server
HTTPS Hypertext Transfer Protocol Secure
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IMS IP Multimedia Subsystem
IP Internet Protocol
IPSEC Internet Protocol Security
ISAKMP Internet Security Association and Key Management Protocol
ITU International Telecommunication Union
LTE Long Term Evolution
MME Mobility Management Entity
MSS Maximum Segment Size
MTU Maximum Transmission Unit
NB Node B (BTS 3G)
NMS Network Management System
OAM Operation and Maintenance
OSPF Open Shortest Path First
xx
PCRF Policy and Charging Rules Function
PDU Protocol Data Unit
PKI Public Key Infrastructure
PS Packet Switch
PSK Pre-Shared Keys
QoS Quality of Service
RA Registration Authority (PKI)
RAN Radio Access Network
RNC Radio Network Controller RSA Algoritmo de criptografia inventado por Ron Rivest, Adi Shamir and
Leonard Adleman
S/P GW Serving and Packet Gateway
S1-AP S1 Application Protocol
SA Security Association
SAE System Architecture Evolution
SCEP Simple Certificate Enrollment Protocol
SCTP Stream Control Transmission Protocol
SECGW Security Gateway
SEG Security Gateway (na documentação 3GPP)
SGSN Serving GPRS Support Node
SMS Short Message Service
TAC Tracking Area Code
TCP Transmission Control Protocol
TDMA Time Division Multiple Access
TSL/SSL Transport Layer Security protocol / Secure Sockets Layer protocol
TWAMP Two-Way Active Measurement Protocol
UDP User Datagram Protocol
UE User Equipment
VoLTE Voice over LTE
VPN Virtual Private Network
VRRP Virtual Router Redundancy Protocol
WCDMA Wideband Code Division Multiple Access
X2-AP X2 Application Protocol
xDSL (Symmetric or Asymmetric) Digital Subscriber Line
1
1 Introdução
1.1 Enquadramento
Os operadores de telecomunicações móveis estão actualmente a introduzir as redes de quarta
geração (4G/LTE). O objectivo é disponibilizar maiores taxas de transferência de dados, e
suportar serviços multimédia e de tempo real numa única rede. De acordo com o organismo
3rd Generation Partnership Project (3GPP) [1], as redes móveis de nova geração têm como
propósito:
Dar resposta à necessidade de maiores larguras de banda e qualidade de serviço;
Optimização e menor complexidade da arquitectura da rede;
Redução dos custos de investimento e de operação da rede.
Na perspectiva da rede de acesso LTE1, esta evolução é conseguida através da simplificação
da arquitectura relativamente às redes de gerações anteriores, na utilização end-to-end da
tecnologia IP e na utilização de novos conceitos no planeamento rádio com a introdução das
redes heterogéneas.
Esta nova abordagem introduz também novos desafios em termos de segurança, até agora
afastados das redes de acesso móvel, deixando a rede LTE mais exposta e vulnerável aos
tradicionais riscos das redes IP fixas. Nas normas TS 33.210 e TS 33.401 o organismo 3GPP
recomenda a implementação do Internet Protocol Security (IPsec) e a introdução do elemento
de rede Security Gateway (SecGW) com o objectivo de proteger o core da rede LTE (EPC) e o
tráfego de possíveis ataques vindos da rede de acesso LTE (EUTRAN).
A SecGW deverá funcionar como um protector da rede core e da própria rede de acesso,
assegurando que apenas o tráfego certificado transita na rede. A confidencialidade e
integridade dos dados é garantida através do estabelecimento de túneis virtuais de segurança
(IPsec Tunnels) entre os evolved NodeB (eNBs) e a SecGW.
1 Entende-se por rede de acesso LTE, as estações base (eNB) e toda a infraestructura da rede de transporte IP (backhaul) que interliga os eNBs ao core LTE.
2
1.2 Motivação
O protocolo IPsec é tradicionalmente usado para a implementação de segurança em redes de
computadores e Internet. No entanto, a sua introdução nas redes de acesso móveis, mais
precisamente no LTE, é recente e levanta uma série de desafios que normalmente não se
colocam nas tradicionais redes IP fixas.
O LTE tem como propósito disponibilizar, de uma forma integrada e assente numa única rede,
serviços de banda larga e serviços de tempo real. Actualmente a release 8 disponibiliza taxa de
transferência de 300Mbps de downlink e 75Mbps de uplink, suporte a serviços de tempo real
de Voz (VoLTE), Vídeo (Interactive, Streaming e Broadcasting) e Jogos Interactivos. Para
assegurar esta diversidade de serviços a rede LTE tem que implementar uma política de
qualidade de serviço (QoS) que permita realizar a diferenciação. Esta diferenciação terá que
ser feita não só pela capacidade de transferência de dados, mas também pela latência,
variação da latência e erros de transmissão admitidos em cada um dos serviços.
Com a introdução do IPsec é espectável, em termos teóricos, uma menor eficiência da rede
devido ao aumento do encapsulamento introduzido pelo próprio protocolo, bem como pela
introdução de maiores latências devido á utilização de algoritmos de autenticação e de
encriptação bastante exigentes ao nível de processamento.
Além da possível degradação do desempenho, existe ainda a questão do aumento de
complexidade da rede com a necessária introdução da SecGW. A arquitectura resultante terá
que ser resiliente e possuir os adequados mecanismos de redundância.
O IPsec utiliza criptografia de chave assimétrica para autenticação mútua entre entidades. Os
eNB e a Security Gateways necessitam de gerar e certificar periodicamente estas chaves,
sendo necessário criar mecanismos e infraestruturas que efectuem estas funções de modo
automático e seguro. Esta infraestrutura é tipicamente designada por Public Key Infrastructure
(PKI).
3
1.3 Objectivos
A segurança nas redes de telecomunicações é um tema muito abrangente e complexo. A
dissertação apresentada pretende focar-se no estudo desta problemática ao nível da
infraestrutura da rede de acesso2, tendo como principal objectivo estudar e avaliar o impacto da
introdução do Internet Protocol Security (IPsec) e da Security Gateway (SecGW) na rede de
acesso LTE.
Será proposta uma solução para a implementação do IPsec e da SecGW, tendo em
consideração factores como as políticas de segurança definidas nas normas 3GPP, resiliência
e redundância da arquitectura, qualidade de serviço e desempenho da rede, processos de
autenticação e distribuição das chaves de encriptação.
Em ambiente laboratorial será avaliado o desempenho da solução proposta relativamente à
taxa de transferência, latência, variação da latência e erros de transmissão.
Figura 1-1 Introdução do IPsec na rede de acesso LTE
A Figura 1-1 mostra uma perspectiva global da introdução do IPsec e da SecGW na rede LTE.
Com o objectivo de proteger a rede core e o tráfego de possíveis ataques vindos da rede de
acesso, o eNB e a secGW possuem certificados emitidos pelo PKI para autenticação mútua e
estabelecem um túnel para troca segura de informação.
2 A análise de segurança ao nível da interface rádio, autenticação de utilizadores ou dos equipamentos terminais, não se enquadram neste trabalho.
eNB
EPCSecGw
Tunel IPSec
Rede SeguraRede Insegura
Public Key
Infraestrure
(PKI)
Rede
Core LTE
Rede de
Acesso LTE
CertificaçãoSecGW
CertificaçãoeNb
CertificateAuthority
Autenticação
4
1.4 Estrutura do Documento
Este documento está estruturado em seis capítulos:
1. Introdução;
2. Estado da arte;
3. Introdução do IPsec na rede de acesso LTE;
4. Proposta de uma solução para a arquitectura de rede;
5. Avaliação da solução proposta em laboratório;
6. Conclusões finais e trabalho futuro.
No primeiro e presente capítulo é realizada uma breve introdução ao tema em estudo, e
apresentado a motivação e os objectivos da dissertação.
O segundo capítulo aborda o estado da arte do problema em estudo. São apresentados
conceitos introdutórios sobre redes de telecomunicações celulares, com particular enfase na
problemática da segurança na rede de acesso LTE. É realizada uma análise detalhada ao
conjunto de protocolos e normas que constituem o IPsec e descritos os conceitos de
criptografia que lhe servem de suporte.
No terceiro capítulo é feito o desenvolvimento conceptual do problema em estudo. Tendo em
consideração as normas 3GPP e EITF, são propostos e analisados vários cenários para
implementação do IPsec. São também estudadas e apesentadas as diferentes configurações e
parametrização possíveis de aplicar na rede LTE.
No quarto capítulo é apresentada uma solução para a arquitectura de rede. São considerados
factores como a introdução e localização da SecGW, soluções de redundância, implementação
da qualidade de serviço e optimizações a efectuar na rede para acomodar o encapsulamento
introduzido pelo IPsec. É ainda abordada a problemática da certificação automática das chaves
públicas dos eNBs, e dos processos de integração na rede e de autenticação na SecGW.
No quinto capítulo são apresentados os resultados da avaliação da solução proposta, realizada
por dois métodos: avaliação de desempenho de rede através do protocolo TWAMP (Norma
RFC5357) e avaliação da perspectiva do utilizador final através de testes aplicacionais.
No sexto capítulo serão apresentadas as conclusões e o trabalho futuro.
5
2 Estado da Arte
Este capítulo tem como base o estudo teórico efectuado para a realização da dissertação. É
apresentado o estado da arte do tema em estudo, fornecendo uma visão geral sobre as redes
de telecomunicação móveis e sobre a problemática da segurança nas redes IP, com particular
ênfase na rede de acesso LTE. São também apresentados os conceitos de criptografia que
servem de base ao protocolo IPsec e efectuado um estudo mais aprofundado sobre o conjunto
de protocolos que constituem o IPsec.
2.1 Redes de Telecomunicações Celulares
2.1.1 Redes de 1ª, 2ª e 3ª Geração
A Primeira Geração (1G) de redes de telecomunicações móveis celulares surgiu nos anos 80.
Eram redes de voz suportadas na tecnologia rádio analógica FDMA (Frequency Division
Multiple Access). Um exemplo dessas redes é a NMT (Nordic Mobile Telephony).
A Segunda Geração (2G) de redes celulares móveis surgiu nos anos 90. Disponibilizaram pela
primeira vez serviços de voz e de dados, e assentavam sobre uma tecnologia rádio digital Time
Division Multiple Access (TDMA). O maior exemplo destas redes é o Global System for Mobile
communications (GSM) que teve duas evoluções posteriores. A geração 2.5G com a
introdução do General Packet Radio Service (GPRS) para disponibilização de serviços de
dados. Actualmente este serviço foi melhorado com a introdução do Enhanced Data rates for
GSM and TDMA Evolution (EDGE) e é genericamente referido como geração 2.75G.
No início do século XXI, o organismo ETSI/3GPP lançou a terceira geração (3G) das redes
móveis celulares ao definir o WCDMA (Wideband Code Division Multiple Access). A primeira
versão desta rede (R99) suportava serviços Circuit Switch (Voz e Vídeo) e Packet Switch a 384
Kbps. Várias versões foram especificadas e actualmente é possível realizar transferência de
dados a 84 Mbps nas redes 3G no entanto, estas redes apresentam algumas limitações em
termos de capacidade de uplink e consideráveis níveis de latência. [2]
Nas redes GSM e WCDMA os serviços de voz/vídeo e os serviços de dados são
disponibilizados por um core network diferentes.
A Figura 2-1 mostra de uma forma simplificada, mas representativa, a evolução da arquitectura
das redes de telecomunicações móveis.
6
Figura 2-1 Evolução da Redes Móveis (fonte 3GPP)
2.1.2 Redes de 4ª Geração
Na primeira década deste século o organismo 3GPP lança dois grupos de trabalho com o
objectivo de normalizar a nível mundial as redes de quarta geração (4G). Foi criado o grupo de
trabalho Long Term Evolution (LTE) para desenvolver as redes de acesso móvel e o grupo
System Architecture Evolution (SAE) para especificar a evolução da rede core. Como resultado
surgem as especificações 3GPP R8 que definiram o Evolved UTRAN (EUTRAN) para o acesso
e o Evolved Packet Core (EPC) para o núcleo da rede. Estas duas tecnologias formam o
Evolved Packet System (EPS). O EPS ficou genericamente conhecido como rede 4G ou LTE.
Tabela 2-1.
Grupo 3GPP
Tipo de Rede
Nome da Rede
Sistema
LTE Acesso EUTRAN EPS
SAE Core EPC
Tabela 2-1 Evolved Packet System (EPS)
Em 2011 o 3GPP fechou a especificação do LTE Advanced (Release 10) em que um dos
objectivos foi melhoria das taxas de transferência de downlink para 3 Gbps e de uplink para 1.5
Gbps [3], Tabela 2-2.
Release Downlink Uplink
LTE (R8) 300 Mbps 75 Mbps
LTE Advanced (R10) 3 Gbps 1.5 Gbps
Tabela 2-2 Taxas de transferência no LTE
Em termos comerciais o lançamento do LTE veio preencher a falta de oferta que existia entre
as redes fixas de alto débito e as redes móveis. Com o LTE é possível ter mobilidade, altas
7
taxas de transferência de downlink e uplink e baixas latências. Passou a ser possível ter
serviços de banda larga e serviços de tempo real como a voz (VoLTE), o vídeo (interactive,
streaming e broadcasting) e online gaming em mobilidade e de uma forma economicamente
viável.
2.1.3 Evolved Packet System (EPS)
Na Figura 2-2 está representado a arquitetura do EPS. O EPS é composto pela rede de acesso
(EUTRAN) e rede core (EPC). A EUTRAN é constituída pelos eNB e pela rede de transporte
(backhaul). O core do LTE (EPC) é constituídos pelo Mobility Management Entity (MME) com
funções de controlo de mobilidade dos UE e pelo Serving Packet GateWay (S/PGW) com
funções de routing dos dados, implementação de QoS e facturação. Os eNB ligam ao EPC
através da interface S1 e entre si através da interface X2. Esta interface tem como principal
objectivo a eficiência na realização de handover entre eNBs. Existem outros elementos e
funcionalidades como o Policy and Charging Rules Function (PCRF), o Home Subscriber
Server (HSS) e o IP Multimedia Subsystem (IMS), que não sendo especificamente elementos
ou funções LTE, fazem parte da infraestrutura base das redes de telecomunicações móveis.
Figura 2-2 Arquitectura da Redes LTE
Relativamente ao GSM e WCDMA, a rede LTE tem uma arquitectura simplificada e horizontal.
Foi reduzido o número de elementos de rede, possui apenas o domínio de comutação de
pacotes (Packet Switch-PS) e assenta no conceito ALL-IP em que toda a transmissão é
suportada em redes IP.
Internet
S1-MME
S1-U
X2-U
X2-CS11
eNB
EPC(Rede Core LTE)
EUTRAN(Rede Acesso LTE)
Sinalização
Dados
MME
SPGW
HSS
IMS
S6a
PCRF
SGi
SGi
Gx
UE
Uu
8
Na Figura 2-3 são comparadas as duas gerações de rede mais recentes, 3G (WCDMA) e 4G
(LTE). Como se pode observar no LTE deixam de existir os elementos de rede MSC Server e a
MGW do domínio comutação de circuitos (Circuit Switch-CS), sendo os tradicionais serviços
CS (voz, vídeo e SMS) disponibilizados no domínio PS com o controlo/sinalização realizado no
IMS.
Figura 2-3 Rede WCDMA (3G) e Rede LTE (4G)
Uma das principais diferenças do LTE em relação ao WCDMA e GSM é a inexistência dos nós
agregadores entre as estações base (Base Station - BS) e a rede core. Isto é, no LTE não
existe o nó equivalente à BSC do 2G e ao RNC do 3G. Devido à exigente capacidade de
processamento de sinalização e de dados concentradas nestes elementos, os BSC/RNC são
tipicamente factores críticos no desempenho, dimensionamento e custo da rede. Como
consequência as funcionalidades destes elementos foram distribuídas pelas BS do LTE (eNB)
e pelo core (EPC). Em termos funcionais, podemos dizer que na rede LTE, o NodeB do 3G
evolui para evolved NodeB (eNB), o SGSN evolui para MME e o GGSN evolui para P/S GW.
2.1.4 Evolved UTRAN (EUTRAN) - Rede de acesso LTE
Na Figura 2-4 está representada a rede de acesso LTE. A rede de acesso é constituída pelos
eNB e pela rede de transporte IP (backhaul) que interliga os eNBs entre eles (interface X2) e os
eNBs ao EPC (interface S1). O backhaul da rede de acesso é tipicamente constituída por redes
IP privadas e/ou alugadas e por redes IP públicas (internet).
SGSN
RNC
GGSN
NBNB
MME
S/PGW
eNBNBNB
E-UTRAN(LTE)
EPC(Core LTE)
CorePS
MSCServer
CoreCS
IMS
WCDMA (3G) LTE (4G)
eNB
VoLTE Outros serviços
MGw
RNC
UTRAN
9
Figura 2-4 Rede de acesso LTE
2.1.5 Rede de transporte IP (IP backhaul)
O backhaul da rede LTE é uma rede complexa e constituída por vários tipos de tecnologias. As
redes de fibra Fiber-To-The-Node (FTTN) e Fiber-To-The-Home (FTTH), as redes de micro-
ondas, a Internet e o xDSL, representadas na Figura 2-5, são exemplos de tecnologias de
transporte usadas na rede de acesso LTE.
Figura 2-5 Rede de transporte IP (IP Backhaul)
2.1.6 Protocolos na rede de acesso LTE
O protocolo IP desempenha um papel fundamental nas modernas redes de transporte, sendo o
protocolo utilizado na camada de rede. Tradicionalmente designado TCP/IP tem na verdade
vários modos de transferência de dados na camada de transporte, dos quais se destacam os
utilizados na rede de acesso LTE:
Transmission Control Protocol (TCP), é um protocolo connection-oriented para
transmissão de pacotes de uma forma sequenciada, detectando e retransmitindo
Rede de Transporte IP
(IP backhaul)
Núcleo Rede IP (IP Core Network)
Rede de AcessoAcesso Rádio Rede Core
eNBSmartphone
LTE (4G)
HSSIMS
PCRFS1X2
EPC (MME+SPGW)
eNB
Rede de Transporte IP
(IP backhaul)
eNB
eNB
eNB
FTTH Internet
FTTNMicroOndas EPC
10
pacotes perdidos. O TCP é utilizado para transferências de dados sensíveis a erros e
sem exigências de tempo real, como o por exemplo o email.
User Datagram Protocol (UDP), é um protocolo connection-less sem detecção de perda
de pacotes. O protocolo UDP é mais adaptado para transmissões menos sensíveis a
erros, mas com exigências de tempo real, como por exemplo a voz.
Stream Control Transmission Protocol (SCTP), combina algumas características do
TCP e UDP. É usado essencialmente para interfaces de sinalização e permite o uso de
multi-homing IP para efeitos de redundância na sinalização.
A Figura 2-6 mostra a pilha de protocolos usados na interface S1-MME (eNB-MME) e S1-U
(eNB-SGW). No domínio do plano de controlo (S1-MME) o eNB usa o protocolo S1-Application
Protocol (S1-AP) para comunicar com o MME. As mensagens S1-AP são transportadas através
do SCTP sobre IP na rede de transporte. No domínio do plano de utilizador, o eNB usa o
protocolo GPRS Tunneling Protocol (GTP-U) para comunicar com a SPGW. O GTP-U é
transportado sobre UDP sobre IP. Na interface X2 o conceito é semelhante, sendo utilizado o
X2-Application Protocol (X2AP) para sinalização.
Figura 2-6 Pilha de protocolos na interface S1 (Rec. TS2 3.401)
Na Figura 2-7 estão representados os protocolos utilizados na rede de acesso LTE e sua
correspondência no modelo OSI.
Figura 2-7 Pilha de protocolos LTE no modelo OSI
SCTP
L2
L1
IP
L2
L1
IP
SCTP
S1-MME eNodeB MME
S1-AP S1-AP
UDP
L2
L1
IP
L2
L1
IP
UDP
S1-U eNodeB S-GW
GTP-U GTP-U
Aplicação (LTE)
Transporte
Rede
X2-AP/S1-AP/GTP-U
TCP/UDP/SCTP
IP/IPSEC
Camada Protocolo
11
2.2 Segurança na rede de acesso LTE
Para atingir os objectivos a que se propõe, o LTE introduz uma nova abordagem nas redes de
telecomunicações móveis. Evolução para uma topologia de rede simplificada e horizontal,
utilização end-to-end da tecnologia IP e um planeamento rádio assente em redes heterogéneas
[4]. Estas alterações trazem também novos desafios em termos de segurança que até agora
estavam afastados das redes de acesso móvel. A rede LTE está mais exposta e vulnerável aos
tradicionais riscos das redes IP fixas. Os riscos de segurança deixam de estar focados apenas
nos equipamentos terminais ou em agentes externos e estão presentes também na própria
infraestrutura da rede. Na norma 33.401, o 3GPP segmenta a problemática da segurança na
rede LTE em 5 grupos:
1. Segurança na rede de acesso, para questões relacionadas com segurança no acesso
rádio;
2. Segurança no domínio da rede, para questões de segurança na rede de acesso e na
rede core;
3. Segurança no domínio do utilizador, relacionada com o equipamento terminal
4. Segurança no domínio da aplicação, segurança ao nível de aplicações;
5. Visibilidade e configuração da segurança, visibilidade para o utilizador.
A implementação efectiva de segurança numa rede terá que ser feita numa perspectiva end-to-
end e considerando todas as vertente acima descritas. No âmbito deste trabalho será abordada
a problemática referida na alínea 2 - segurança no domínio de rede, mais especificamente na
rede de acesso. Nesta secção são analisados os factores que contribuem para a maior
vulnerabilidade da rede de acesso LTE, a ameaças e ataques, relativamente às gerações
anteriores e apresentados os mecanismos disponíveis para repor os níveis de segurança.
2.2.1 Vulnerabilidades
Nas próximas secções, pretende-se identificar e analisar as principais causas e factores que
contribuem para a maior vulnerabilidade da rede de acesso LTE.
2.2.1.1 Arquitectura de Rede
Como referido na secção 2.1.2, com o objectivo de simplificar a arquitectura na rede 4G, foi
removido o elemento controlador de rádio equivalente ao BSC/RNC existente nas redes 2G e
3G. Ao contrário das redes 2G e 3G, em que as ligações das BTS terminam na BSC e no RNC,
na rede LTE as BTS ligam directamente ao core EPC. O core está directamente acessível e
vulnerável a ataques realizados a partir dos eNB ou da rede de transporte. Esta situação torna-
se ainda mais crítica quando é utilizada a arquitectura de rede EPC in pool [5]. Por questões de
redundância e balanceamento de carga os eNB podem ligar-se a vários MME e S-PGW
12
simultaneamente. Adicionalmente, por questões de eficiência na realização de handover, existe
a possibilidade de realizar ligações directas entre eNB (interface X2). Potencialmente cada eNB
pode ligar-se a 256 eNBs e a 64 MME3 simultaneamente.
Figura 2-8 Core LTE em Pool
A Figura 2-8 mostra a arquitectura da rede LTE anteriormente descrita. Devido a esta
arquitectura de rede em malha (full meshed), uma entrada não autorizada num único eNB pode
comprometer todas a rede LTE.
2.2.1.2 Configuração e Estabelecimento das interfaces S1 e X2.
Outro especto a ter em consideração é a forma como é realizado o estabelecimento da ligação
S1 entre a BTS e o core (S1 setup). No 2G e 3G sempre que uma estação base (BTS) é
colocada ao serviço é necessário realizar a configuração da estação rádio no respectivo BSC
ou RNC por um administrador do sistema. De certa forma é realizada uma “autenticação
manual” da BTS na rede. No LTE, o eNB e o MME funcionam numa base cliente/servidor, onde
não é necessário a intervenção de um administrador para que o eNB obtenha o serviço. O
processo é totalmente automático. Na Tabela 2-3 são apresentados os parâmetros que o eNB
precisa de conhecer para se registar no MME. É necessário apenas o IP do MME, a
identificação da rede (Network ID) e o código da área de serviço (Tracking Area Code -TAC),
parâmetros fáceis de obter com um analisador de rede. Esta informação pode ser
posteriormente utilizada em emuladores (ou falsos eNB) para iludir e atacar o core EPC.
Parâmetro Presença
Message Type Obrigatório
Global eNB ID Obrigatório
eNB Name Opcional
Supported TAs (TAC + PLMN) Obrigatório
Default Paging DRX Obrigatório
Tabela 2-3 Parâmetros interface S1 ( 3GPP TS 36.413)
3 Os valores apresentados podem variar entre fabricantes
eNB 1
eNB 2
EPC em Pool
EPC 1
EPC 3
EPC 2
13
Na Figura 2-9 são mostradas as mensagens trocadas entre o eNB e o MME durante o
estabelecimento da interface S1.
eNB
S1 SETUP REQUEST
MME
S1 SETUP RESPONSE
Figura 2-9 Registo do eNB no MME (Rec. TS 36.413)
Numa captura realizada em laboratório é possível, comprovar a simplicidade com que o
processo é efectuado. São trocadas apenas duas mensagens, uma de pedido de serviço por
parte do eNB (S1 Setup Request) e outra com a confirmação do serviço pelo MME (S1 Setup
Response). Na mensagem S1 Setup Request, o eNB envia o seu Global ID, o nome, as TACs
suportadas e o ciclo de paging. Figura 2-10
Figura 2-10 S1 Setup Request (Captura com o Wireshirk)
Na mensagem S1 Setup Response, o MME responde com o nome, o Global Unique MME ID
(GUMMEI) e a capacidade relativa para efeitos de distribuição de carga entre MMEs em Pool
Figura 2-11.
Figura 2-11 S1 Setup Response (Captura com o Wireshirk)
14
2.2.1.3 Protecção no control plane (CP) e user plane (UP)
Outro impacto resultante da alteração da arquitectura é a forma como é realizada a encriptação
de tráfego entre o equipamento terminal (UE) e o core EPS. Na rede 3G o tráfego do plano de
utilizador é encriptado do terminal até ao RNC. Considerando que o RNC está tipicamente
instalado num local físico ou edifício de acesso restrito e seguro, é garantida a
confidencialidade do tráfego do utilizador. Com a eliminação do RNC na rede LTE, o plano de
utilizador é encriptado apenas entre o UE e o eNB (air interface), sendo desencriptado neste
elemento e enviado em “texto plano” para a S/PGW. Figura 2-12.
Figura 2-12 Encriptação na rede de acesso LTE
Na Tabela 2-4 é efectuada uma comparação da protecção realizada no control plane (CP) e
user plane (UP) e do tipo de registo realizado pela BTS nas 3 redes. A rede 2G e LTE são
iguais e inferiores em termos de protecção de dados relativamente ao 3G. No LTE há ainda a
considerar que estamos perante um IP backhaul e portanto mais inseguro e vulnerável a
ataques.
Tecnologia Tipo Estação
Interface Integridade Encriptação Tipo registo da estação no core CP UP CP UP
2G BTS A-bis (BTS - BSC) X X X X Manual
3G NB Iub (NB - RNC) V(1) V(1) X V(1) Manual
4G eNB S1 (eNB - EPC) X X X X Automático
Tabela 2-4 Encriptação e Autenticação
(1) – A protecção é realizada por inerência da protecção realizada entre o equipamento
terminal (UE) e o RNC
2.2.1.4 Rede de transmissão IP (IP backhaul)
As redes de transporte baseadas em TDM/ATM, usadas inicialmente nas redes 2G/3G, não
satisfazem a maior necessidade de largura de banda do LTE, são redes bastante ineficientes e
com custos elevados.
O recente desenvolvimento das redes MetroEthernet, baseadas em redes de fibra óptica e
micro-ondas, disponibiliza uma maior eficiência e menor custo por Mbit, incentivando os
operadores a adoptaram as redes IP como rede transporte preferencial.
eNBUE EPC
encriptado Desencriptado
15
Estas redes não possuem mecanismos intrínsecos de segurança, são por natureza redes
inseguras onde não é garantida a autenticação e a confidencialidade da informação, sendo
essa protecção realizada pelas camadas superiores quando necessário. As redes TDM/ATM
eram redes mais fechadas e complexas, sendo por isso tecnicamente mais difíceis de dominar,
pelo contrário as redes IP são baseadas num protocolo aberto e genericamente conhecido.
A rede acesso de LTE passou assim a estar sujeita aos ataques e vulnerabilidade das
tradicionais redes IPs dentro da sua própria infraestrutura.
2.2.1.5 Planeamento celular (rede heterogéneas)
Com o previsível crescimento de subscritores e de tráfego na rede LTE, será necessário rever
o paradigma do planeamento celular. Além da utilização das tradicionais macro cells para
cobertura de zonas exteriores extensas, serão introduzidas as small e femto cells4 (HeNB) [4]
para expansão da capacidade e reforçar a cobertura das macros cells. Figura 2-13.
Figura 2-13 Redes de acesso heterogéneas
Com este propósito a instalação dos eNB será forçosamente realizada em locais pouco
seguros (públicos ou privados) e com a transmissão realizada sobre Internet. Facilitando o
acesso a pessoal não autorizado à infraestrutura da rede e tornando-a vulnerável a ataques
originados por intrusão nos eNB.
Tipo de estação Objectivo Tipo de transmissão
Macro cells Cobertura exterior Metro Ethernet, Micro-ondas
Small e Pico cells Reforço da cobertura exterior e
cobertura interior
Metro Ethernet, Micro-ondas,
Internet
Femto cells Reforço da cobertura exterior e
cobertura interior. Cobertura privada Internet
Tabela 2-5 Tipo de estação Vs Transmissão
4 O IPsec é actualmente implementado na solução femto cells 3G sempre que a Internet é usada como rede de transmissão. No entanto a rede 3G não têm os requisitos de desempenho existentes no LTE.
backhaul Internet
HeNB (femto)
Smallcell
EPC
Macro
Macro
16
2.2.2 Ameaças
Identificadas as vulnerabilidades na secção anterior, nessa secção é analisado o tipo de
ataques e ameaças que a rede de acesso LTE está sujeita:
Escuta intrusiva (eavesdropping). É um tipo de ataque passivo, realizado através do uso de
equipamentos de monitorização, com o objectivo de obter informação para análise ou
posterior utilização em outro tipo de ataques. Este tipo de ataque coloca, no mínimo, a
confidencialidade de informação em causa.
Interposição (man-in-the-middle). Situação em que o intruso escuta e altera informação
sem que esta acção seja notada pela rede. Este tipo de ataques origina falhas de
integridade devido à manipulação da informação não autorizada.
Falsificação de IP ou identidade dos eNB (Identity/IP Spoofing, Masquerade), situação em
que um falso eNB se identifica como um verdadeiro, usando os seus privilégios para
aceder ou modificar informação. Esta situação provoca falhas de confidencialidade e
integridade da informação devido à possibilidade monitorização e alteração.
A Figura 2-14 ilustra os locais da rede mais vulneráveis para a realização dos ataques acima
descritos. Os eNB e todos os equipamentos que constituem o backhaul IP (switch, router,
ligações rádio, etc) são os locais mais susceptíveis.
Figura 2-14 Monitorização e manipulação de informação
Existem outro tipo de ataques, mais focados no objectivo de afectar o normal funcionamento da
rede:
IP
EPC
eNB
EPS(Core LTE)
eNB
Router IP
RadioSniffer
Intruso
E-UTRAN(Aceso LTE)
NetSniffer
17
Replay attack, situação em que o intruso intercepta informação (ex: uma sequência de
pacotes IPs) para a reenviar posteriormente com o objectivo de saturar o sistema e
provocar indisponibilidade de serviço.
Indisponibilidade de serviço (Denial of Service - DOS), situação em que são realizados
ataques à rede core ou outros eNB (ex: solicitação excessiva de serviços) com o objectivo
afectar o normal funcionamento da rede ou de causar indisponibilidade do serviço. Este
tipo de ataques pode ser realizado no plano de controlo da rede (sinalização) ou no plano
dos dados.
Estes ataques podem ser realizados a partir de eNB comprometidos ou de falsos eNB (ex:
emuladores). Figura 2-15.
Figura 2-15 Ataque contra a rede (DOS)
Um estudo efectuado pela Stoke em conjunto com a universidade de Surrey [6] identificou
quais as principais ameaças na rede de acesso LTE, explorando apenas a vulnerabilidade
física dos eNB:
DDoS com origem em eNB comprometidos;
Injecção de tráfego no user-plane;
Intercepção de pacotes (eavesdropping);
Modificação dos pacotes (man-in-the-middle);
Sobrecarga de sinalização.
Este estudo revelou ainda que devido ao controlado custo de produção e maior exposição
pública as small e femto cell são as mais vulneráveis.
2.2.3 Mecanismos e protocolos de segurança
A introdução de mecanismos e protocolos de segurança tem como objectivo reduzir ao mínimo
as vulnerabilidades das redes, protegendo-as dos potenciais ataques e assegurando uma
EPC
eNB
E-UTRAN(Aceso LTE)
EPS(Core LTE)
eNBIntruso
FalsoeNB
DOS
DOS
18
comunicação segura entre as partes. Relativamente aos protocolos de segurança, estão
disponíveis vários tipos que operam em diferentes camadas do modelo OSI e com diferentes
especificidades de utilização5. Na Figura 2-16 são apresentados alguns dos protocolos de
segurança mais usados em rede IPs e a respectiva camada de protocolo onde é utilizado. O
Secure Shell (SSH) com utilização específica para executar comandos remotamente, o
Transport Layer Security/Secure Sockets Layer (TLS/SSL) utilizado nos web browsers, e o
IPsec com uma utilização mais genérica na implementação de redes privadas seguras.
Figura 2-16 IPsec no modelo OSI
No contexto desta dissertação, seguindo o especificado nas normas TS 33.210 e TS 33.401
pelo organismo 3GPP, é proposta a implementação do IPsec e a introdução da Security
Gateway (SecGW) com o objectivo de proteger a Rede Core e o tráfego de ataques realizados
a partir da Rede de Acesso (eNB).
O IPsec é na realidade um conjunto de protocolos definidos pelo Internet Engineering Task
Force (IETF) que disponibilizam serviços de segurança ao nível da camada de rede. Estes
serviços de segurança incluem autenticação, integridade, controlo de acesso e
confidencialidade. A utilização do IPsec tem a grande vantagem de implementar segurança na
camada de rede, protegendo automaticamente todas as camadas superiores. A desvantagem
da introdução do IPsec é a complexidade introduzida na rede para a sua implementação e da
possibilidade de introduzir ineficiências ao nível do desempenho de rede.
A implementação do IPsec obriga a que os eNB suportem intrinsecamente esta funcionalidade
e a introdução da SecGW, que deverá funcionar como um protector da rede Core e dos
próprios eNB, assegurando que apenas o tráfego certificado transita na rede. A
confidencialidade e integridade dos dados são garantidas através do estabelecimento de túneis
virtuais de segurança entre os eNBs e a SecGW. Figura 2-17.
5 A segurança não se esgota na introdução de protocolos, mas resulta também de políticas, processos e boas práticas que devem ser observadas por todas as entidades do sistema.
Aplicação
Transporte
Rede
SSH
TLS/SSL
IPsec
Camada Protocol
19
O IPsec e a SecGW deverão realizar:
Autenticação dos eNB, assegurando a sua verdadeira entidade;
Autenticação de origem da informação, atribuindo capacidade do EPC e eNB receptor
confirmar o eNB emissor da mensagem;
Integridade da informação, capacidade do EPC e eNB detectar possíveis alterações na
mensagem;
Confidencialidade, realização da encriptação e desencriptação do tráfego entre eNBs e
entre eNBs e core da rede;
Prevenir ataque contra eNB e core da rede (anti-replay e DoS).
Figura 2-17 RAN SecGW na Rede de Acesso LTE
De forma a proteger a rede de ataques que possam causar danos nos equipamentos ou no
normal funcionamento da rede, afectando o prestígio do operador e por conseguinte causando
perdas monetárias, os operadores móveis deverão implementar mecanismos de segurança na
rede LTE. A consultora de telecomunicações Norte Americana Heavy Reading’s [7] prevê que a
nível mundial, por motivos de segurança, em 2017 mais de metade dos eNB estejam
protegidos com o protocolo IPsec. Figura 2-18.
Figura 2-18 Número de eNBs com IPsec (Previsão da Heavy Reading’s)
Redes Externas
Backhaul(Fibra/Ethernet/IP)
Rede de AcessoAcesso Rádio Rede externa
EPC
BTS
RAN SECGW
BTS
Tuneis IPsec
20
2.3 Conceitos de Criptografia
A protecção realizada pelo protocolo IPsec tem como base métodos e algoritmos de
criptografia. Este capítulo pretende realizar uma breve, mas abrangente análise destes
conceitos, bem como das infraestruturas e protocolos auxiliares que servem de suporte e
facilitam a utilização do IPsec.
A criptografia é a ciência que estuda as técnicas de protecção de informação através de
processos matemáticos com o objectivo de assegurar:
Autenticação de identidade, garantindo que a entidade é na realidade quem diz ser. Para
este efeito pode ser usada a encriptação assimétrica ou certificados digitais;
Confidencialidade dos dados, protegendo o acesso á informação por terceiros. Usando
tipicamente encriptação e desencriptação simétrica;
Integridades dos dados, assegurando que a informação não é alterada por terceiros.
Podem ser usadas função de dispersão;
Autenticação da origem da informação, garantindo a verdadeira origem da informação.
Podem ser usadas função de dispersão.
2.3.1 Encriptação Simétrica
Os métodos de encriptação podem ser categorizados em dois tipos: Simétrica e Assimétrica
Figura 2-19 Encriptação Simétrica
Na encriptação simétrica, existe apenas uma chave secreta partilhada pelas duas entidades. A
mesma chave privada é utilizada para a encriptação e desencriptação dos dados em ambos os
sentidos. Matematicamente a encriptação simétrica pode ser escrita da seguinte forma:
Função de Encriptação: 𝑐 = 𝐸(𝐾𝑝𝑟𝑖𝑣𝑎𝑑𝑎 , 𝑝)
Função de Desencriptação: 𝑝 = 𝐷(𝐾𝑝𝑟𝑖𝑣𝑎𝑑𝑎 , 𝑐)
Mensagemconfidencial
qwehdkrudçncwyeodwye
Encriptação
Mensagemconfidencial
Desencriptação
Textoplano
Textoencriptado
Textoplano
Alice Bruno
ChavePrivada
ChavePrivada
21
Como é exemplificado na Figura 2-19, se a Alice pretender enviar uma mensagem confidencial
ao Bruno, encripta a mensagem com a chave privada comum previamente acordada. O Bruno
recebe a mensagem e desencripta-a com a mesma chave privada, obtendo a mensagem
inicial.
Este método apresenta limites de escalabilidade devido ao número de chave necessárias. Num
sistema de criptográfico simétrico o número de chave necessárias é dado por:
𝑁º𝑐ℎ𝑎𝑣𝑒𝑠 = ∑ 𝑘 = 1 + 2 + ⋯ + (𝑛 − 1) =𝑛(𝑛 − 1)
2
𝑛−1
𝑛=1
Isto é, uma chave por cada par de entidades. Outra desvantagem é a dificuldade na
distribuição e renovação das chaves secretas de uma forma segura. No caso de um intruso
obter a chave secreta toda a comunicação fica comprometida. Este problema foi contornado
por Whitfield Diffie e Martin Hellman ao introduzirem o conceito de encriptação assimétrica.
O Data Encryption Standard (DES) e o Advanced Encryption Standard (AES) são exemplo de
algoritmos actualmente usados na encriptação simétrica.
2.3.2 Encriptação Assimétrica
Figura 2-20 Encriptação Assimétrica
Na encriptação assimétrica cada entidade possui um par de chaves (chave pública e chave
privada), uma chave serve para encriptar e outra para desencriptar. A chave privada é gerada e
conhecida apenas pela entidade proprietária, enquanto a chave pública correspondente é
distribuída livremente pelas outras entidades do sistema. O par de chaves está relacionada
matematicamente, mas é computacionalmente inviável determinar a chave privada a partir da
chave pública. Desta forma, qualquer entidade pode enviar informação de forma segura,
encriptando os dados com a chave pública do destinatário, pois apenas este consegue
Mensagemconfidencial
qwehdkrudçncwyeodwye
Encriptação
Mensagemconfidencial
Desencriptação
Textoplano
Textoencriptado
Textoplano
ChavePrivadaBuno
ChavePublica BrunoAlice Bruno
22
desencriptar a mensagem recebida. Matematicamente a encriptação simétrica pode ser escrita
da seguinte forma:
Função de Encriptação: 𝑐 = 𝐸(𝐾𝑝𝑢𝑏𝑙𝑖𝑐𝑎 , 𝑝)
Função de Desencriptação: 𝑝 = 𝐷(𝐾𝑝𝑟𝑖𝑣𝑎𝑑𝑎 , 𝑐)
Como é exemplificado na Figura 2-20, se a Alice pretender enviar uma mensagem confidencial
ao Bruno, encripta a mensagem com a chave pública do Bruno. O Bruno desencripta a
mensagens recebida com a sua chave privada.
Num sistema de criptográfico assimétrico o número de chave necessárias é dado por:
𝑁º𝑐ℎ𝑎𝑣𝑒𝑠 = 2𝑛, duas chaves por utilizador.
O algoritmo Diffie-Hellman (dos inventores Whitfield Diffie and Martin Hellman), o RSA (iniciais
de inventores do algoritmo em 1977, Ron Rivest, Adi Shamir and Leonard Adleman,) e o Elliptic
Curve são exemplos de algoritmos assimétricos.
2.3.3 Encriptação simétrica versus assimétrica
Para o mesmo nível de protecção, a encriptação assimétrica utiliza chaves de maiores
dimensões e é mais exigente em termos computacionais, sendo mais adequada para encriptar
pequenas quantidades de informação, como as assinaturas digitais. A encriptação simétrica é
computacionalmente mais eficiente, sendo por isso, mais apropriada para encriptar e
desencriptar grandes quantidades de informação.
Os dois tipos de criptografia são portanto complementares. Os participantes podem iniciar uma
comunicação entre si com encriptação assimétrica (RSA, por exemplo) para decidir que chave
privada comum usar na posterior encriptação simétrica. Depois de trocadas a chave, o resto da
comunicação pode encriptada realizada utilizando um algoritmo de chave simétrica (ex: AES).
Encriptação Simétrica Encriptação Assimétrica
Chave secreta partilhada
Eficiente
Robusta, com chaves de menor dimensão (128 ou 256 bits)
Número de chaves: n (n-1) /2
Problema com a distribuição das chaves
Solução pouco escalável (não aplicável a sistemas com muitos utilizadores
Algoritmos: DES, AES
Par de chaves (publica e privada)
Lenta
Necessita de chaves de dimensões maiores (1024, 2048 bits)
Número de chaves: 2n
Distribuição de chaves segura
Solução Escalável
Necessita de uma pré-certificação de chave pública (PKI).
Algoritmos: Diffie-Hellman, RSA
Tabela 2-6 Encriptação Simétrica versus Assimétrica
23
Num sistema assimétrico existe a necessidade de provar que chave pública pertence
realmente ao seu verdadeiro proprietário, sendo necessário implementar um sistema de
certificação de chave pública, o PKI. Este assunto será analisado em pormenor na
secção 2.3.7.
2.3.4 Algoritmo Diffie-Hellman
O Diffie-Hellman (DH) é um algoritmo criptográfico utilizado para acordar chaves simétricas
num ambiente inseguro. Como se pode observar no exemplo da Error! Reference source not
ound., as entidades, Alice e Bruno, iniciam o processo acordando um número primo (p) e numa
raiz primitiva de módulo p (g) e tiram partido das propriedades dos números primos e de
operações matemáticas para determinam uma chave secreta (s) para encriptar e desencriptar
os dados. Os valores públicos são mostrados a verde e os privados a vermelho.
Operação Alice Bruno
Acordo do número primo (p) e raiz primitiva módulo p (g)
p
23 23
g
5 5
Nº inteiro secreto de Alice a
6
Resultado enviado para Bruno A A = g^a mod p 8 8
Nº inteiro secreto de Bruno b
15
Resultado enviado para Alice B B = g^b mod p 19 19
Chave secreta comum s S = B^a mod p 2
Chave secreta comum s S = A^b mod p
2
Tabela 2-7 Diffie-Hellman
(g^a mod p) ^b mod p = g^ab mod p (g^b mod p) ^a mod p = g^ba mod p
com: a mod p = a - p*int(a/p)
Este algoritmo é de extrema importância na distribuição de chaves no IPsec. (secção 2.4.4).
2.3.5 Funções de Dispersão
Outro elemento importante na criptografia são as funções de dispersão (hash functions). A
função de dispersão gera um valor de comprimento fixo (hash value ou message digest) a
partir um conjunto de dados. A partir da mesma informação é gerado sempre o mesmo
resultado, no entanto, qualquer alteração na informação original resulta num hash value muito
diferente. Outra característica importante é a impossibilidade de realizar a operação inversa
para obter a informação original, Figura 2-21.
Figura 2-21 Função de Dispersão
Mensagem
qwehdkrudçncwyeodwye
Função de HASH(SHA-1, MD5)
valor de hashTexto plano
24
As funções de dispersão têm várias aplicações em criptografia:
Integridade, comparando o hash value recebido na mensagem com valor calculado a partir
da mensagem recebida. Figura 2-22.
Autenticação, através do uso de Message Authentication Code (MAC). O MAC é um hash
value posteriormente encriptado (Keyed-Hashing-MAC - HMAC). O HMAC pode ser
calculado a partir de funções de dispersão como o MD5 (HMAC-MD5) e a SHA-1 (HMAC-
SHA1). Figura 2-22.
Assinaturas digitais, encriptando a informação (hash value) com a chave privada e
desencriptando com chave pública correspondente permite criar uma Assinatura Digital.
Figura 2-22 Integridade com Função de Dispersão
2.3.6 Assinaturas Digitais
Uma assinatura digital é um hash value encriptado com a chave privada do emissor. A entidade
que recebe a mensagem utiliza a chave pública do emissor para desencriptar, validando a
integridade e autenticação da origem dos dados.
Figura 2-23 Assinatura Digital
Mensagem Mensagem
Função de HASH(SHA-1, MD5)
qwehdkrudçncwyeodwye
qwehdkrudçncwyeodwye
qwehdkrudçncwyeodwye
=?
Alice Bruno
Função de HASH(SHA-1, MD5)
valor de hash
Texto planoTexto plano
valor de hash
Mensagemconfidencial
Algoritmo HASH(SHA-1, MD5)
Encriptação(RSA)
Texto
HASHAssinatura
Chave Privada Alice
qwehdkrudçncwyeodwye
qwehdkrudçncwyeodwye
Mensagemconfidencial
Algoritmo HASH(SHA-1, MD5)
Desencriptação(RSA)
Texto
HASH= ?
Assinatura
Chave Publica Alice
qwehdkrudçncwyeodwye
qwehdkrudçncwyeodwye
Alice
Bruno
Criação da Assinatura
Verificação da Assinatura
25
Como se pode observar na Figura 2-23, a Alice pode garantir a integridade e autenticação da
origem da informação enviada para o Bruno, assinando digitalmente com a sua chave privada
o hash value gerado a partir da mensagem. O Bruno recebe a mensagem juntamente com a
assinatura digital da Alice. Para verificar a integridade e origem dos dados, recalcula o hash a
partir da mensagem recebida e compara-a com o hash recebido e desencriptado com a chave
pública de Alice. Este método pode ser utilizado também para não-repudiação, isto é,
impossibilidade do emissor negar o envio da mensagem.
2.3.7 Public Key Infrastructure (PKI)
A criptografia de chave pública fica comprometida se não for assegurado que uma determinada
chave pública pertence ao seu verdadeiro detentor. O Public Key Infrastructure (PKI) tem como
objectivo resolver esta questão, através da existência de uma terceira entidade idónea, aceite
por todos as partes do sistema, o Certificate Authority (CA). O CA associa uma chave pública
ao verdadeiro proprietário através de um certificado de chave pública. O PKI foi inicialmente
definido pelo ITU_T através da norma X.509. Posteriormente o IETF tem vindo a trabalhar na
definição de recomendações para o PKI X.509 (PKIX). Como resultado, o PKI é actualmente
definido no RFC5280 [8]. A Figura 2-24 apresenta um esquema simplificado das principias
componentes do modelo PKI X.509 (PKIX).
Figura 2-24 Modelo PKIX
End Entity (EE) - é um termo genérico usado para referir os utilizadores finais (máquinas,
servidores, routers) ou qualquer outra entidade que possa ser identificada no campo subject do
certificado X.509. As End Entity usam os serviços PKI para solicitarem o certificado da chave
pública.
Certification Authority (CA) - O CA é o emissor dos certificados e das Certificate Revocation List
(CRL). Pode também realizar funções administrativas para os pedidos, mas estas funções são
habitualmente delegadas na Registration Authority (RA). Os CA podem estar hierarquicamente
organizados, sendo o CA do topo da cadeia designado root CA.
CA
CRL
End Entity (ex: eNB)
RA
End Entity (ex: secGW)
26
Registration Authority (RA) - O RA é uma componente do modelo PKIX opcional que pode
assumir as funções administrativas do CA. O RA é responsável pela recepção e gestão dos
pedidos de certificados, estabelecendo a interface entre a CA e as End Entity.
Certificate Revocation List (CRL) - Base de dados dos certificados emitidos, mas que foram
posteriormente revocados pelo CA.
Comercialmente estão disponíveis várias plataformas para suporte PKI, dos quais se
enumeram alguns dos mais utilizados.
INSTA: http://publicsafety.insta.fi/home;
neXus: http://www.nexusgroup.com/en/solutions/Public-Key-Infrastructure/
Simantec: http://www.symantec.com/verisign/managed-pki-service
Estão também disponíveis open sources, como por exemplo:
Enterprise Java Bean Certificate Authorit (EJBCA): http://www.ejbca.org explorado
comercialmente pela PrimeKey e Ericsson
OpenCA PKI: https://pki.openca.org/projects/openca/
2.3.8 Certificados Digitais X.509
No contexto do PKI, um certificado é um documento digital que associa uma entidade (subject)
a uma chave pública (public key) através de uma assinatura digital (certificate signature) de
uma autoridade idónea (Certificate Authority-CA). A Figura 2-25 mostra o modelo dos
certificados X.509 definidos na RFC 5280-Internet X.509 Public Key Infrastructure Certificate
[8].
Figura 2-25 Certificado X.509 v3
Certificate ID Certifcado_1
Version 1,2,3
Serial Number ABCDF01…
Algorithm ID sha1WithRSAEncryption
Issuer Organization, Country, Common name
Validity
Not Before 1-8-14 0:00
Not After 1-8-15 0:00
Subject Organization, Country, Common name
Subject Public Key Info
Public Key Algorithm RSAEncryption
Public Key 30:81:89:02 …
Extensions (optional) …
Certificate Signature Algorithm
sha1WithRSAEncryption
Certificate Signature 87:64:d1 …
27
Todas as entidades do sistema possuem um par de chaves pública-privada e o respectivo
certificado da chave pública. O próprio CA possui um par de chave pública – privada e o
certificado. Os certificados do CA são utilizados para que as entidades possam verificar que os
seus próprios certificados e das outras entidades são válidos e porque CA foram emitidos.
Figura 2-26 Emissão do certificado pela CA
A Figura 2 26 exemplifica o processo para obtenção do certificado da chave pública:
1. As entidades geram o par de chave pública-privada e realizam o pedido de certificação
da chave pública ao CA.
2. O CA emite e assina o certificado com a sua própria chave privada e envia para a
entidade.
2.3.9 Processo de obtenção do certificado de chave pública
O processo de obtenção e renovação dos certificados de chave pública junto do CA pode ser
realizado de uma forma manual ou automática. Num sistema constituído por milhares de
entidades, onde é necessário dar resposta aos constantes pedidos e renovação de certificados,
bem como manter a lista de certificados revocados actualizada (CRL). É portanto aconselhável
a implementação de processos automáticos e minimizar a intervenção de um administrador.
Figura 2-27 Protocolos CMP e SCEP
CA
Public Key Certificate
Public Key Certificate
12
Par chavePública-Privada
Public Key certifcate request
Norma X.509
Public Key certifcate signed
Norma X.509
Signed by CA
IPsec
EntidadeIPsec
EntidadeIPsec
PKI (CA/RA)
SCEP/CMP SCEP/CMP
28
O Certificate Management Protocol (CMP) e o Simple Certificate Enrollment Protocol (SCEP)
são dois protocolos utilizados para a renovação automática de certificados digitais X.509.
Figura 2-27. O SCEP é um protocolo usado universalmente devido essencialmente à
simplicidade relativamente ao CMP. No entanto, actualmente o IETF recomenda o uso do
protocolo CMPV2, devendo o SCEP ser usado apenas por questões de compatibilidades. Na
TS 33.310 o 3GPP recomenda também o uso do CMPv2, devido essencialmente à maior
segurança deste protocolo. Uma das vantagens do CMPV2 é possibilidade de pré-instalar um
“certificado de fábrica” nas entidades que pode ser usado como credencial no primeiro contacto
com o CA. No SCEP a autenticação é tipicamente realizada através de chave secreta. A
segunda versão do CMP (CMPv2) é definida na RFC 4210 [9]. O SCEP foi inicialmente
desenvolvido pela VeriSign para a Cisco Systems e é actualmente definido num draft do IETF
[10]. Figura 2-28.
Figura 2-28 CMPV2
1. Os eNB são pré-provisionados com um par de chaves público-privada e o certificado
de chave pública de fábrica;
2. No primeiro contacto com a rede, o eNB estabelece comunicação com o RA/CA
através do protocolo CMPv2 para realizar o pedido de certificado da chave pública de
operador, autenticando-se com o certificado de fábrica;
3. Na resposta, a BTS recebe o certificado de chave pública do operador e o certificado
do CA (chave pública do CA);
4. O eNB usa posteriormente estes certificados para se autenticar na SecGW.
EntidadeIPsec
(secGW)
EntidadeIPsec (eNB)
PKI (CA/RA)
Certificado CA
Certificado Fabrica
Certificado Operador
CMP
Ike/IPsec1
2
3
4
29
2.4 Internet Protocol Security (IPsec)
O IPsec permite realizar a transferência segura de informação em redes IP, através da
autenticação e encriptação dos dados. A Figura 2-29 mostra uma aplicação típica do IPsec,
interligando duas redes, através de uma outra rede não segura, criando uma única rede virtual
segura (Virtual Private Network - VPN).
Figura 2-29 IPsec
O IPsec é na realidade um conjunto de protocolos definidos em vários RFC, pelo Internet
Engineering Task Force (IETF), e disponibiliza os seguintes serviços de segurança [11] [12]:
Autenticação de identidade: capacidade de assegurar a verdadeira identidade, garantindo
que a entidade é realmente quem diz ser.
Autenticação da origem da informação: capacidade do receptor confirmar o emissor da
mensagem, verificando a identidade de quem declara ser a fonte de informação.
Integridade da informação: capacidade de detectar possíveis alterações na mensagem,
assegurando que qualquer modificação nos dados é detectável.
Protecção anti-replay: detecção de duplicação de pacotes IPsec dentro de uma
determinada janela. Se a sequência de pacotes IPsec chegar fora de uma determinada
ordem, os pacotes podem ser descartados.
Confidencialidade - serviço de segurança que previne a revelação não autorizada de
dados, através da encriptação e desencriptação do tráfego;
O IPsec possui dois modos de funcionamento: o Modo Transporte e o Modo Túnel e dois tipos
de protocolos: o Authentication Header (AH) e o Encapsulating Security Payload (ESP) para
transferência segura de informação.
Existe um terceiro protocolo, o Internet Key Exchange Protocol (IKE), que tem como função
realizar a autenticação das entidades envolvidas e gerir automaticamente as ligações IPsec.
Rede seguraRede segura
Rede nãosegura
IPsec
EntidadeIPsec
EntidadeIPsec
Rede virtual segura
30
A Figura 2-30 mostra um diagrama resumo dos protocolos e dos modos de funcionamento.
Figura 2-30 IPsec, Modos e Protocolos
2.4.1 Tipos de Protocolo
O IPsec disponibiliza dois tipos de protocolos para protecção de dados, o Authentication
Header (AH) e o Encapsulating Security Payload (ESP).
2.4.1.1 Protocolo Authentication Header (AH)
O protocolo Authentication Header (AH) disponibiliza os seguintes serviços de protecção:
Autenticação da origem da informação
Integridade da informação
Protecção anti-replay
São normalmente usados os algoritmos criptográficos Message Digest (MD5) ou o Secure
Hash Algorithm (SHA-1) para Autenticação e Integridade
2.4.1.2 Protocolo Encapsulating Security Payload (ESP)
O protocolo Encapsulating Security Payload (ESP) disponibiliza os mesmos serviços que
protocolo AH e adicionalmente o serviço de confidencialidade (encriptação).
Autenticação da origem da informação
Integridade da informação
Protecção anti-replay
Confidencialidade (encriptação)
São suportados algoritmos criptográficos como o Triple Data Encryption Algorithm (3DES) e o
Advanced Encryption Standard (AES) para encriptação assimétrica.
AH ESP IKE
Autenticação dos dados
Autenticação e Encriptação dos
dados
Autenticação das entidades IPsec e gestão
das SA
Protocolo
Transporte Tunel
MantémHeader IP
original
Header IPEncpasulado
(VPN)
Modo
IPsec
31
2.4.2 Modos de Operação
O IPsec possui dois modos de operação, o modo Transporte e o Modo Túnel. Ambos os
protocolos, AH e ESP, podem funcionar no modo Transporte e Túnel.
2.4.2.1 Modo Transporte
O Modo Transporte é utilizado para estabelecimento de ligações seguras entre hosts. Neste
modo é mantido o header original dos pacotes IP e protegido apenas a informação das
camadas superiores. Neste modo os hosts necessitam de suportar a funcionalidade IPsec.
Figura 2-31.
Figura 2-31 Modo Transporte
2.4.2.2 Modo Túnel
O Modo Túnel é o modo mais utilizado e serve para criar uma ligação segura (Virtual Private
Network – VPN) entre duas gateways ou entre uma gateway e um host. Neste método os
equipamentos internos não precisam de suportar o IPsec, pois a encriptação e desencriptação
ocorre nas IPsec Gateways. No Modo Túnel é criado um novo IP header e o pacote IP original
é totalmente protegido. Figura 2-32
Figura 2-32 Modo Túnel
A Figura 2-33 mostra o encapsulamento dos pacotes IPs realizado nos dois modos de
operação:
Figura 2-33 Modo de Operação – Encapsulamento
IPsecHost IPsec
GateWayGateWay
IPsecHost
Orig IP Hdr Data
Orig IP Hdr DataIPsecHdr
New IP Hdr
Orig IP Hdr DataIPsecHdr
Pacote Original
Modo Transporte
Modo Túnel
32
2.4.2.3 Protocolo AH no Modo Transporte
No Modo Transporte o protocolo AH realiza a autenticação e integridade dos dados do pacote
IP original. É mantido o IP header original e inserido o header do protocolo AH para a
protecção. A Figura 2-34 ilustra o encapsulamento do protocolo AH no modo transporte.
Figura 2-34 Protocolo AH no Modo Transporte (RFC 4302)
2.4.2.4 Protocolo AH no Modo Túnel
No Modo Túnel o protocolo AH realizada autenticação e integridade de todo o pacote IP
original. É inserido um novo IP header e o header do protocolo AH para a protecção. O IP
header original contém os endereços IP de origem e destino da mensagem, enquanto o novo
IP header contem os endereços IP das gateways IPsec. A Figura 2-35 ilustra o
encapsulamento do protocolo AH no modo transporte.
Figura 2-35 Protocolo AH no Modo Túnel (RFC 4302)
2.4.2.5 Protocolo ESP no Modo Transporte
No Modo Transporte, o protocolo ESP realizada autenticação, integridade e confidencialidade
(encriptação) do payload do pacote IP original. É mantido o IP header original e inserido o
header e o tailer do protocolo ESP para a protecção A Figura 2-36 ilustra o encapsulamento do
protocolo ESP no modo transporte.
Figura 2-36 Protocolo ESP no Modo Transporte (RFC 4303)
Orig IP Hdr Data
Orig IP Hdr DataHAHdr
| Protecção |
Orig IP Hdr Data
Orig IP Hdr DataHAHdr
New IP HDR
| Protecção |
Orig IP Hdr Data
Orig IP Hdr DataESPHdr
ESPTailer
ESPICV
| Encriptação |
| Protecção |
33
2.4.2.6 Protocolo ESP no Modo túnel
No Modo Túnel, o protocolo ESP realiza autenticação, integridade e confidencialidade do
pacote IP original. É inserido um novo IP header, um ESP header e um ESP Tailer para a
protecção. O IP header original contém os endereços IPs de origem e destino da mensagem,
enquanto o novo IP header contém os endereços IP das gateways IPsec. A Figura 2-37 ilustra
o encapsulamento do protocolo ESP no modo túnel.
Figura 2-37 Protocolo ESP no modo Túnel (RFC 4303)
2.4.3 Security Association
As Security Association (SA) são uma estrutura de parâmetros que definem o tipo de
segurança a implementar entre duas entidades IPsec. As SA definem o protocolo IPsec e os
algoritmos criptográficos, chaves e tempo de validade das chaves, entre outros parâmetros. A
todo o tráfego associado a uma determinada SA é aplicado o mesmo tipo de protecção de
segurança. Para proteger uma comunicação entre duas entidades, o IKE estabelece uma IKE
SA e a partir desta estabelece duas Child SA (IPsec SAs) para a utilização do protocolo AH ou
ESP. As IKE SA são bidirecionais e as IPsec SA são unidirecionais, sendo necessário uma SA
por cada sentido da comunicação.
2.4.4 Internet Key Exchange Protocol (IKE)
O Internet Key Exchange Protocol (IKE) faz parte do conjunto de protocolos designado por
IPsec. O IKE tem como objectivo realizar a troca segura das chaves simétricas através do
algoritmo Diffie-Hellman, realizar a autenticação mútua entre as entidades IPsec e gerir de uma
forma automática as Security Association (SA). As SA são ligações lógicas criadas pelo
protocolo IKE com o objectivo de proteger o tráfego transportado pelo próprio protocolo IKE e
pelos protocolos ESP e AH. Figura 2-38.
Figura 2-38 Protocolo IKE
Orig IP Hdr Data
Orig IP Hdr DataESPHdr
New IP HDRESP
TailerESPICV
| Encriptação |
| Protecção |
EndidadeIPsec
EndidadeIPsec
IKE
Dados Tunel IPsec (HA/ESP)
34
O protocolo IKE é constituído por duas fases destintas. Numa primeira fase é negociada e
criada a própria IKE SA, na segunda fase são criadas as IPsec SA. [13] A Figura 2-39 mostra a
mensagens trocadas durante as duas fases.
Figura 2-39 Fluxo de mensagens no protocolo IKEv2
AUTH Authentication IDr Identification – Responder
CERT Certificate KE Key Exchange
CERTREQ Certificate Request Ni, Nr Nonce
HDR IKE header SA Security Association
Idi Identification – Initiator SK Encrypted and Authenticated
A fase 1.1 (IKE_SA_INIT) tem como principal objectivo negociar os parâmetros para
proteger as próximas fases. O primeiro par de mensagens IKE_SA_INIT negocia os
algoritmos criptográficos e o Diffie-Hellman Group através das Security Associaion (SA),
realiza a troca da chave (KE) e dos nonces (N). Nesta fase as entidades utilizam o
algoritmo Diffie-Hellman para obter uma chave secreta comum.
A fase 1.2 (IKE_AUTH) tem como objectivo negociar e realizar a autenticação das
entidades (SecGW e eNB) envolvidas. Nesta fase as mensagens são autenticadas e
encriptadas com a chave calculada na fase 1.1.
As entidades (ID) fazem prova da sua entidade através do campo AUTH encriptado com
uma secreta (PSK), ou de uma forma mais robusta, assinando com a chave pública
presente nos certificados (CERT).
Initiator Responder
IKE_SA_INIT
IKE_AUTH
IKE SA
Child SA (IPsec SA)
Child SA (IPsec SA)
Fase 1
Fase 2
HDR, SAi1, KEi, Ni
HDR, SAr1, KEr, Nr, [CERTREQ]
HDR,SK{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2}
HDR, SK{IDr, [CERT,] AUTH, SAr2}
CREATE_CHILD_SA
HDR, SK {SA, Ni, [KEi]}
HDR, SK {SA, Nr, [KEr]}
35
Na fase 2 (CREATE_CHILD_SA) são estabelecidas as Child SA (AH ou ESP SA) para
transferência segura da informação segundo o negociado na fase 1. A encriptação do
trafego é realizada através da encriptação simétrica (chave secreta), mais eficiente que a
encriptação simétrica
2.4.4.1 Autenticação IKE com Pre-Shared Keys (PSK)
Na autenticação por Pre-Shared Keys (PSK) é necessário uma prévia definição da chave
secreta. As entidades IPsec são manualmente configuradas com uma chave secreta comum
por um administrador. O protocolo IKE usa estas chaves para autenticação das entidades
envolvidas. A autenticação por PSK tem, no entanto, duas grandes desvantagens, o número de
chaves necessárias e a dificuldade da sua distribuição de uma forma segura e eficiente pelas
várias entidades. O número de chaves necessárias, quando estão envolvidas N entidades, é
dado por N (N-1) /2. A distribuição pode ser feita manualmente quanto estamos perante um
reduzido número de entidades, mas tornasse impossível de gerir quando estão envolvidas
muitas entidades.
2.4.4.2 Autenticação IKE com certificados
Na autenticação por certificados, as entidades IPsec usam certificados digitalmente assinados
pelo Certificate Authority (CA). Neste caso, cada uma das entidades IPsec gera um par de
chaves, uma chave pública e outra chave privada. A chave privada é guardada local e
secretamente enquanto a chave pública é enviada, em forma de pedido de certificado de chave
pública para o CA. O CA ao receber o pedido, emite um certificado assinado com a sua própria
chave privada e envia para a identidade que o solicitou. Estes certificados serão
posteriormente usados para autenticar os participantes na negociação IKE.
Tradicionalmente é usado o algoritmo RSA com chaves de 1024-2048 bit para efectuar a
autenticação (assinatura) dos certificados. Para a realização da autenticação com o protocolo
IKE, cada entidade necessita de ter o seu próprio certificado de chave pública e o certificado do
CA (chave pública do CA) que assinou os certificados.
36
A Figura 2-40 mostra um exemplo dos pedidos de certificado de chave pública ao CA e a
posterior autenticação entre as entidades.
Figura 2-40 Autenticação IKE com certificados
1. As entidades IPsec A e B geram o seu par de chave pública – privada
2. As entidades IPsec A e B solicitam o certificado do CA, ou seja a chave pública do CA.
3. Cada entidade, A e B, faz o pedido de certificado para sua chave pública ao CA. O CA
emite os certificados assinados com a sua chave privada, de forma a associar a chave
pública recebida ao seu verdadeiro detentor.
4. Através do protocolo IKE as entidades trocam os certificados da sua chave pública. A
entidade A validade a chave pública recebida de B descodificando a assinatura do
certificado com chave pública do CA e a entidade B validade a chave pública recebida de A
descodificando a assinatura com chave pública do CA
Signed by CA
A Key Certificate
Signed by CA
CA Certificate
Signed by CA
B Key Certificate
Signed by CA
CA Certificate
CA
Entidade IPsec A Entidade IPsec B
Autenticação IKE1
2 2
3 3
1
4
37
3 IPsec na Rede de Acesso LTE
Neste capítulo pretende-se estudar a problemática da introdução do IPsec na rede de acesso
LTE através de uma análise e definição das políticas de segurança, tendo como referência as
normas 3GPP e IETF. Serão estudados e propostos cenários de implementação, bem como as
possíveis configurações e parametrização do IPsec na rede de acesso LTE.
3.1 Normas e Políticas de Segurança
Sendo o LTE um standard 3GPP, está ao abrigo de normas, e portanto qualquer desenho ou
solução de rede deve ter em consideração o especificado. Nesta secção, pretende-se realizar
um breve resumo conclusivo das principais normas e políticas de segurança com influência na
introdução do IPsec na rede LTE.
3.1.1 Normas 3GPP e RFC
Os aspectos relacionados com a segurança na rede LTE são definidos na serie 33 da
Technical Specification (TS) 3GPP, das quais se destacam as mais relevantes para o caso
particular da utilização do IPsec na rede de acesso:
A norma TS 33.210 - 3G security; Network Domain Security (NDS); IP network layer
security, define a arquitectura de segurança e o perfil IPsec/IKE que deve ser usado na
rede de acesso LTE para as interfaces S1, X2 e OAM.
A norma TS 33.310 - Network Domain Security (NDS); Authentication Framework (AF),
especifica o modo de autenticação entre a SecGW e o eNB, e o processo de certificação
entre estes elementos e o PKI.
A norma TS 33.401 - 3GPP System Architecture Evolution (SAE); Security architecture, tem
como principal objectivo definir uma arquitectura de segurança, definindo funcionalidades e
mecanismos de segurança para o EPS: Evolved Packet Core (EPC) e Evolved UTRAN (E-
UTRAN).
Estas normas remetem muitas vezes para os Request For Comments (RFC) do Internet
Engineering Task Force (IETF), organismo responsável para definir os Internet Standards,
onde se incluiu a especificação do IPsec, IKE, PKI e certificados x.509:
RFC 4302 – IP Authentication Header (AH)
RFC 4303 – IP Encapsulating Security Payload (ESP)
38
RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile
A Figura 3-1 mostra um diagrama com a relação das normas 3GGP envolvidas na definição de
segurança na rede LTE.
Figura 3-1 Relação entre normas
3.1.2 Política de segurança no plano de controlo (sinalização)
Na secção 5.3.4a (Requirements for handling Control plane data for the eNB) da norma 33.401
é especificado que o tráfego do plano de controlo (interface S1-MME e X2-C) da Figura 3-2
deve ser protegido em integridade, confidencialidade e anti-replay. Esta protecção deve seguir
o especificado na secção 11 da mesma norma, onde é referido que deve ser usado o protocolo
ESP do IPsec de acordo com o RFC 4303 [secção 7] e segundo o perfil especificado na norma
TS 33.210 [secção 5]. Deve ser usado a autenticação IKEV2 com certificados de acordo com a
noma TS33.310 [secção 6]. É ainda especificado que para estas interfaces a implementação
do Modo Túnel é obrigatório e o Modo Transporte é opcional, podendo ser usado com o
objectivo de reduzir o overhead introduzido pelo IPsec.
Figura 3-2 Interfaces LTE
TS 33.401 Politicas de segurança
no LTE
RFC 4303
Protocolo ESP
TS 33.210
Definição do perfile IKE/IPSec a usar no LTE
TS 33.310
Definição do perfile para os certificados
RFC 4302
Protocolo AH
S1-MME
S1-U
X2-U
X2-C S1-MME
S1-U
S11
eNB
EPS(Rede Core LTE)
EUTRAN(Rede Acesso LTE)
Sinalização
Dados
MME
SPGW
UE
Uu
NMSOAM
39
3.1.3 Política de segurança no plano do utilizador (dados)
Na secção 5.3.4 (Requirements for handling User plane data for the eNB) da norma 33.401 é
especificado que o tráfego do plano de utilizador (interface S1-U e X2-U da Figura 3-2) deve
ser protegido em integridade, confidencialidade e anti-replay, Esta protecção deve seguir o
especificado na secção 12 da mesma norma, onde é referido que esta protecção deve usar
protocolo ESP do IPsec de acordo com a norma RFC 4303 [secção 7] e segundo o perfil
especificado na norma TS 33.210 [secção 5],confidencialidade, integridade e anti-replay. É
ainda especificado que para estas interfaces a implementação do Modo Túnel é obrigatório e o
modo Transporte é opcional e que pode ser usado para reduzir o overhead introduzido pelo
IPsec. É também especificado na secção da 12 que no caso da interface S1 e X2 no plano de
utilizador ser considerada segura a implementação do IPsec não é obrigatória.
3.1.4 Política de segurança no plano de gestão
Na secção 5.3.2 (Requirements for eNB setup and configuration) da Norma 33.401 é
especificado que a comunicação entre os sistemas de Operação e o eNB deve ser protegida
em integridade, confidencialidade e anti-replay, a protecção criptográfica esta deve seguir o
especificado na secção 13 da mesma norma, onde é referido que esta protecção deve ser
realizada segundo o perfil especificado na norma TS 33.210 [secção 5], isto é usado o
protocolo IPsec ESP de acordo com a norma RFC 4303 [secção 7] com integridade,
confidencialidade e anti-replay.
E ainda especificado que para estas interfaces a implementação do Modo Túnel é obrigatório e
o Modo Transporte é opcional e que pode ser usado para reduzir o overhead introduzido pelo
IPsec.
3.1.5 Considerações sobre as normas
Da análise das normas 3GPP, conclui-se que o IPsec deve ser implementado, para protecção
de todas interfaces, sempre que se considere que o eNB está numa rede insegura. Em caso de
implementação da protecção, esta deve ser em autenticação de entidade, autenticação de
origem de informação, integridade e confidencialidade da informação, e anti-replay. A Tabela 3-
1 mostra o resultado da análise das normas para a situação de uma rede insegura e de uma
rede segura.
Interface Lógica Protocolo Acesso Core Rede
segura Rede
insegura
S1 Control (S1-C) S1-AP eNB MME SIM Opcional
S1 User (S1-U) GTP-U eNB SPGW SIM Opcional
X2 Control (X2-C) X2-AP eNB eNB SIM Opcional
X2 User (X2-U) GTP-U eNB eNB SIM Opcional
OAM
eNB NMS SIM Opcional
Tabela 3-1 Protecção da informação em zonas consideradas seguras e inseguras
40
As normas referem que a implementação de protecção criptográfica é uma decisão do
operador e, portanto, opcional no caso do eNB estar localizado num ambiente considerado
seguro. É deixado ao critério do operador a decisão de determinar se a rede é segura ou
insegura. A definição de rede segura não é um processo determinístico e os critérios podem
variar de operador para operador ou de factores tão subjectivos como o contexto sociopolítico
dos país ou da percepção e tolerância ao risco que cada operador admite. Na verdade, não é
possível dizer que um local ou rede é totalmente seguro. No entanto é possível definir critérios
objectivos que devem ser considerados na definição de rede segura/insegura.
Um factor importante está relacionado com o tipo de rede de transmissão que é
utilizada no LTE, isto é, se a rede assenta numa rede pública (internet), se o operador
é detentor da rede (rede privada) ou se esta é alugada ou partilhada com terceiros.
Outro aspecto são os locais de instalação dos eNB. Se são constituído por sites
fisicamente robustos, com acesso controlado e detecção de intrusão, ou se pelo
contrario são de acesso fácil, partilhado ou público.
Se o acesso ao próprio eNB e equipamentos de transmissão é protegido com
passwords, se existe logs ou outros mecanismos de controlo de acesso ao nodeB.
Leis e requisitos das entidades reguladoras que obriguem a protecção específica de
dados.
A ASMONIA, consórcio de várias empresas de telecomunicações e universidades alemãs, com
o apoio do Federal Ministry of Education and Research Alemão fez um estudo bastante
completo sobre esta problemática [14]. No contexto académico da tese iremos considerar que
estamos perante uma rede insegura e sujeita a ataques.
3.2 Cenários de implementação do IPsec na rede de acesso
LTE
Na secção 3.1 foram analisadas as normas que regulam a introdução do IPsec e que balizam
as opções e configurações de utilização deste protocolo por parte do operador quando aplicado
na rede de acesso do LTE. No âmbito deste trabalho iremos considerar que estamos perante
um ambiente potencialmente “inseguro” e portanto o IPsec deve ser utilizado. Neste contexto,
diferentes soluções, com diferentes níveis de segurança, desempenho e custos podem ser
implementadas. Partindo da análise das recomendações 3GPP realizada anteriormente são
propostos 3 cenários para a introdução do IPsec numa rede LTE e analisadas as vantagens e
desvantagens.
Cenário A, protecção do core da rede LTE (EPC) e do tráfego;
Cenário B, protecção do core da rede LTE (EPC) e parcial do tráfego;
Cenário C, protecção mínima do core da rede LTE (EPC);
41
3.2.1 Cenário A - Protecção da rede core e do Tráfego
Este cenário pretende tirar o máximo potencial do protocolo IPsec. Todo o tráfego que transita
na rede de acesso é protegido em autenticação e confidencialidade. As interfaces S1, X2, OAM
são protegidas no plano de controlo (sinalização) e no plano do utilizador (dados). Protegendo
todo o tráfego é também garantida a protecção do core EPC. O tráfego do plano do utilizador
(S1-U e X2-U) representa a grande maioria do volume de tráfego, a realização da encriptação
exige maior capacidade de processamento nos eNB e na SecGW. Esta situação pode ter
impacto no desempenho da rede ou exigir maior investimento em capacidade de
processamento. Em termos de complexidade de configuração, este cenário é o mais simples
de implementar, dado que todo o tráfego é tratado da mesma forma e pode ser transportado
em apenas um túnel IPsec.
3.2.2 Cenário B - Protecção da rede core e parcial do tráfego
Este cenário assume um compromisso entre segurança, desempenho e custos, e tem como
principal objectivo proteger a rede core. É realizada a autenticação e a encriptação das
interfaces S1, X2, mas apenas no plano de controlo (S1-MME e X2-C). O tráfego do plano de
utilizador (S1-U e S2-U) é apenas autenticado. Por questões de desempenho ou de custos
realiza-se apenas a encriptação do tráfego do plano de controlo e assume-se que o tráfego do
plano de utilizador é encriptado ao nível aplicacional sempre que existir essa necessidade (ex.:
HTTPS, SSH, etc.). A rede não garante a confidencialidade dos dados dos utilizadores,
deixando essa opção, tal como no caso das redes fixa para os utilizadores. Dado que o volume
de tráfego do plano de utilizador, substancialmente maior que o tráfego do plano de controlo,
não é encriptado é necessário menor capacidade de processamento nos eNB e na SecGW,
significando menor investimento na rede. Para acomodar as diferentes configurações será
necessário a implementação de um maior número de túneis IPsec.
3.2.3 Cenário C - Protecção mínima da rede core
Este cenário tem como objectivo proteger a rede core ao mais baixo custo possível. É realizada
apenas a autenticação do tráfego de controlo e dados (interfaces S1-MME, X2-C, S1-U, X2-U),
não sendo realizada encriptação. Assume-se que o tráfego do plano de utilizador é encriptado
nas camadas superiores, caso o utilizador o entenda. A Tabela 3-2 apresenta o resumo da
análise anteriormente descrita.
Interface Protocolo Nó X
Nó Y
Cenário A Cenário B Cenário C
Aut. Encr. Aut. Encr. Aut. Encr.
S1-MME S1-AP eNB MME V V V V V X
S1-U GTP-U eNB SPGW V V V X V X
X2-C X2-AP eNB eNB V V V V V X
X2-U GTP-U eNB eNB V V V X V X
OAM Vários eNB NMS V V V V V X
Tabela 3-2 Cenários de protecção
42
No cenário A, é protegido a rede core e tráfego do utilizador. No cenário B, é protegido a rede
core e parcialmente o tráfego. No cenário C, é efectuado a protecção mínima da rede,
autenticado apenas o tráfego.
A Tabela 3-3 mostra a avaliação numérica dos vários cenários e pode ser utilizada pelo
operador para decidir que cenário implementar. Considerando um peso igual em todos os
critérios a decisão recairia pelo cenário C.
Cenário Segurança Desempenho Custos Complexidade Resultado
Cenário A 3 1 1 3 8
Cenário B 2 2 2 1 7
Cenário C 1 3 3 2 9
Tabela 3-3 Cenários (critérios)
1.Pior; 2. Médio; 3. Melhor.
3.3 Configuração e parametrização do IPsec para o LTE
Como descrito na secção 2.4, o IPsec está desenhado para funcionar em diversos modos e
suportar qualquer algoritmo de autenticação, integridade e encriptação.
A configuração e parametrização do IPsec depende em primeiro lugar das funcionalidades
suportada por cada equipamento e do nível de segurança versus desempenho que se pretende
ter na solução final. Nesta secção será analisada e proposta uma configuração de referência
para o IPsec quando aplicado na rede LTE.
De uma forma genérica, no LTE, o IPsec deve ser configurado da seguinte forma:
Modo: Túnel, protecção de todo o pacote IP orginal.
Autenticação de entidade
IKEv2 com certificado x509 ou chave partilhada (Pre Shared Keys - PSK)
Protocolo: ESP com:
Integridade dos dados (data integrity);
Autenticação da origem dos dados (data origin authentication);
Proteção contra pacotes repetidos (anti-replay);
Confidencialidade
A protecção realizada pelo IPsec desenrolasse em duas fases (ver 2.4.4). A fase 1 – IKE e fase
2 – ESP. As respectivas configurações e parametrizações serão abordadas nas secções
seguintes.
43
3.3.1 Configuração IKE (Fase 1)
A fase 1 tem como objectivo negociar as SA, obtenção da chave secreta através do algoritmo
Diffie-Hellman e realizar a autenticação das entidades envolvidas (SecGW e eNB). Na
Tabela 3-4 são propostos dois perfis para configuração do protocolo IKEv2 [15]. Sendo o perfil
1, a configuração mínima sugerida e o perfil 2, a configuração recomendada.
IKEv2 Perfil 1 (mínimo) Perfil 2 (recomendado)
Fase 1.1 IKE_SA_INIT
Diffie-Hellman Group 2 (1024-bit MODP) Group 14 (2048-bit MODP).
Confidencialidade ENCR_3DES ENCR_AES_CBC (128/256)
Autenticação e Integridade
AUTH_ HMAC_MD5 AUTH_HMAC_SHA1_96
Renovação das SA 48h 24h
Fase 1.2 IKE_AUTH
Autenticação entidade
pre-shered keys (PSK) Certificados x.509 (RSA)
Tabela 3-4 Perfil IKEv2
3.3.1.1 Autenticação com certificados
Quando realizada com certificados, a autenticação deve ter o seguinte perfil [16]:
Certificados X.509 versão 3 (de acordo com o RFC5280)
Algoritmo Hash: Mínimo: SHA-1, Recomendado: SHA-256
Signature algorithm: RSAEncryption.
Public key algorithm: RSAEncryption.
Dimensão chave pública: mínimo 1024-bit, recomendado: 2048-bit.
Dimensão chave do CA mínimo 2048-bit, recomendado: 4096-bit
A Figura 3-3 mostra um exemplo de um certificado X.509 para uma chave de 1024 bits. E
assinatura digital RSA com hash sha1
Certificate identifier: ms-cert
Certificate version: 3
Serial number: 24ea0e4b000000000010
Issuer:
Organization: TelecomNetworks, Organizational unit: Eng, Country: PT,
State: LX, Locality: Lisbon, Common name: TELENET
Subject:
Organization: TelecomNetworks, Organizational unit: Sales, Country: PT
State: LX, Locality: Sunnyvale,Common name: VendorLX
Alternate subject: email empty, fqdn empty, 172.19.51.162
Validity:
Not before: 10-29-2010 20:36
Not after: 10-29-2025 20:46
Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:da:81:09:85:4d:db:91:7b:8b:de:bf:81:a6
…
d7:a7:8a:70:62:4d:c2:44:73:40:10:ea:10:0a:29:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Figura 3-3 Exemplo certificado X.509 (SecGW Juniper)
44
3.3.1.2 Autenticação com PSK
A configuração com PSK é bastante mais simples pois só é necessário definir uma chave
secreta (password) idêntica em cada uma das entidades IPsec (eNB e SecGW). Figura 3-4,
mostra um exemplo autenticação por PSK.
Preshared Key: 4578656d706c6f5f5072652d7368617265642d6b657921313233
Figura 3-4 Exemplo pre-shared-key (SecGW Juniper)
A chave secreta deve seguir critérios mínimos de robustez, por exemplo:
Dimensão mínima: 8 caracteres;
Deve conter: Letras Maiúsculas e Minúsculas, Números e Símbolos;
Período de renovação: 6 meses;
Não sejam iguais às últimas 6 chaves secretas utilizadas;
A Figura 3-4 mostra a pre-shared-key “Exemplo_Pre-shared-key!123” em Hexadecimal
3.3.1.3 Proposta IKE fase 1
A Figura 3-5 mostra a configuração de uma IKE SA proposal na SecGW para o perfil 2 da
Tabela 3-4. Autenticação por certificados, DH group14, utilização do algoritmo sha1 para
autenticação e do AES_CBC com chaves de 256 bit para encriptação.
proposal ike-phase1-proposal {
description "*** aes256 sha certificates ***";
authentication-method rsa-signatures;
dh-group group14;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 86400;
}
Figura 3-5 Exemplo de uma proposta utilizada na fase 1 do IKE (SecGW Juniper)
45
3.3.2 Configuração ESP (Fase 2)
No LTE deve ser utilizado o protocolo IPsec ESP com a configuração representada na
Tabela 3-5 [17], [18].
IKEV2 Perfil 1 (mínimo) Perfil 2 (recomendado)
Fase 2 CREATE_CHILD_SA)
Protocolo ESP ESP
Modo Transporte * Túnel
Autenticação e Integridade
AUTH_ HMAC_MD5 HMAC-SHA1-96 [RFC2404]
Encriptação TripleDES-CBC [RFC2451]
AES-CBC128/256 [RFC3602] **
Renovação SA 2h 1h
Tabela 3-5 Perfil ESP
* O Modo Transporte pode ser usado em caso de necessidade de reduzir o overhead
introduzido pelo IPsec)
** NULL [RFC2410] no caso de se optar por não realizar encriptação.
3.3.2.1 Proposta ESP fase 2
A Figura 3-6 mostra um exemplo de uma proposta para a configuração da fase 2 (IPsec), com
a utilização do protocolo ESP e autenticação por hmac-sha1-96 e encriptação por aes-256-cbc
proposal ipsec-phase2-proposal {
description "*** aes256 sha esp ***";
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;
}
Figura 3-6 Exemplo de uma proposta utilizada na fase 2 do IPsec (SecGW Juniper)
3.3.3 Security Associations
As Security Associations são o resultado dos parâmetros acordados na negociação da fase 1
(IKE) e fase 2 (IPsec).
3.3.3.1 IKE SA
A Figura 3-7 mostra um exemplo da configuração da IKE SA para o perfil 2. Onde é possível
verificar a utilização do algoritmo de autenticação sha1 e o aes-cbc para encriptação.
Autenticação IKE por Certificados (RSA-signatures).
46
IKE peer 10.0.153.4, Index 146577867, Gateway Name: 4TP0999
InitiatorCookie:860c8c035ac6dd97,ResponderCookie: 6c06391ea2b62b48
Exchange type: IKEv2, Authentication method: RSA-signatures
Local: 10.0.178.254:500, Remote: 10.0.153.4:500
Lifetime: Expires in 33762 seconds
Peer ike-id: 10.0.153.4
Algorithms:
Authentication : hmac-sha1-96
Encryption : aes256-cbc
Pseudo random function: hmac-sha1
Diffie-Hellman group : DH-group-14
Traffic statistics:
Input bytes : 6256
Output bytes : 5140
Input packets: 40
Output packets: 39
Figura 3-7 Exemplo IKE security association (SecGW Juniper)
3.3.3.2 IPsec SA
A Figura 3-8 mostra um exemplo da configuração das IPsec SA, onde é possível verificar a
existência de duas SA, uma para cada sentido da comunicação, utilização do ESP no modo
túnel com o algoritmo hmac-sha1-96 para autenticação e o aes-cbc para
encriptação/desencriptação do tráfego e o serviço de anti-replay activo. É também visível o
tempo restante para a renovação automática das SA.
ID: 131073 Virtual-system: root, VPN Name: 4TP0999
Local Gateway: 10.0.178.254, Remote Gateway: 10.0.153.4
Direction: inbound, SPI: 52deaaf
Soft lifetime: Expires in 2451 seconds
Mode: Tunnel
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: 74530a12
Soft lifetime: Expires in 2451 seconds
Mode: Tunnel
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Figura 3-8 Exemplo IPsec security association (SecGW Juniper)
3.3.4 Número de túneis
O número de túneis a definir entre os eNB e a SecGW é outro factor a ponderar na introdução
do IPsec da rede. A solução pode recair por ter apenas um túnel para todo o tráfego ou ter um
túnel dedicado para cada interface e tipo de tráfego. A primeira solução mostra-se mais simples
e com menos exigência de recursos. No outro extremo, a segunda solução é mais versátil,
permitindo ter por exemplo QoS por tipo de tráfego ou interface, é no entanto bastante mais
complexa de gerir. A Tabela 3-6 propõe 3 cenários, identificando as vantagens e desvantagens
de cada um.
47
Tuneis IPsec 1 Túnel 3 Túneis 3 Túneis
Racional 1 Túnel IPsec para
todas as interfaces
1 Túnel IPsec por cada tipo
de tráfego (CP + UP +
OAM)
1 Túnel IPsec por cada
tipo de interfaces (S1 + X2
+ OAM)
Distribuição por
túnel
Túnel 1: S1-C + S1-U
+ X2-C + X2-U +
OAM
Túnel 1: CP (S1-C + X2-C)
Túnel 2: UP (S1-U + X2-U)
Túnel 3: OAM
Túnel 1: S1 (S1-C + S1-U)
Túnel 2: X2 (X2-C + X2-U)
Túnel 3: OAM
Vantagens/
Desvantagens
- Mais fácil de gerir
- Menos flexibilidade,
mesmo perfil IPsec
para todo o tipo de
tráfego/interface
- Possibilidade de adaptar
o perfil IPsec por tipo de
tráfego
- QoS por tipo de tráfego
- Mais recursos
- Possibilidade de adaptar
o perfil IPsec por tipo de
interface
- QoS por tipo de interface
- Mais recursos
Tabela 3-6 Túneis IPsec
Outras combinações serão possíveis conforme as necessidades e arquitectura de rede do
operador. Numa fase inicial a escolha deverá recair por arquitectura mais simples, utilizando
apenas um túnel para todos os serviços e interfaces (S1-C, S1-U, X2-C, X2-U e OAM) e em
fases posteriores de desenvolvimento poderão ser criados novos túneis. Em caso de
implementação de redundância, isto é, necessidade de ligar o eNB a duas SecGW, é
necessário considerar a necessidade de duplicar o número de túneis em cada um dos
cenários.
Um cuidado especial deve ser dado no caso do sincronismo dos eNB ser realizado por
protocolos Ethernet (IEEE 1588v2 ou NTP). Estes tipos de protocolos são bastante sensíveis à
latência e jitter e deve ser equacionado a possibilidade de ter um túnel e QOS dedicado a este
tipo de tráfego.
49
4 Solução e Arquitectura de rede
Este capítulo tem como objectivo analisar e propor uma solução para a implementação do
IPsec na rede de acesso LTE. Será seguida uma abordagem na perspectiva do operador que
pretende introduzir o IPsec como o protocolo de segurança. São analisados aspectos
relacionados com o desenho de rede, redundância da arquitectura e zonas de segurança. São
também estudadas questões relacionadas com a implementação do QoS, bem como o impacto
do IPsec no aumento do encapsulamento e da consequente fragmentação dos pacotes IP e
desempenho de rede. Por último é proposto um processo automático de integração e
autenticação dos eNB numa rede de acesso com LTE com IPsec.
4.1 Security Gateway (SecGW)
A SecGW é o elemento de rede onde terminam os túneis IPsec no lado do core LTE, tendo
como objectivo realizar a autenticação dos eNB e a encriptação/desencriptação do tráfego. Em
termos de funcionalidade a SecGW pode ser integrada no próprio core da rede LTE (EPC),
terminado os túneis IPsec directamente no MME e SPGW. Esta solução possui algumas
desvantagens, pois exige capacidade de processamento adicional a equipamentos
vocacionados para outras tarefas e expõe de forma directa o EPC a ataques. É também pouco
apropriada no caso de se pretender expandir o IPsec para as redes 2G e 3G, pois obrigaria a
que RNC e BSC disponibilizassem também esta funcionalidade. Outra possibilidade, seria
adicionar esta funcionalidade nos routers da rede IP, mas também não há garantias que estes
elementos possuam funcionalidades e capacidade para acomodar o IPsec. As normas não
especificam se a funcionalidade SecGW deve ser um nó dedicado ou integrado noutro
equipamento, mas a solução dedicada mostra ser mais flexível, eficiente, segura e em última
análise seguida pelo mercado. Como exemplificado na Figura 4-1, a SecGW deve ser inserida
entre o EPC (MME e SPGW) e os eNB para proteger as interfaces S1 e X2.
Figura 4-1 SecGW na rede LTE
EdgeRouter
MME
SPGW
CoreRouterSecGW
eNB
SiteSwitch
eNB
SiteSwitch
Túnel IPsec
50
Em termos comerciais a “funcionalidade” SecGW foi desenvolvida com base em plataformas de
Routing ou Firewalling. As SecGW baseadas em routers têm tipicamente melhor desempenho
IPsec e maiores capacidades de transferência de informação, as baseadas em Firewalls
apresentam funcionalidades adicionadas de segurança e são mais inteligentes na detecção de
ataques. São exemplo de SecGW baseadas em routers, o ASR900 da Cisco Systems e
baseada em Firewall o SRX5800 da Juniper Nerworks. Figura 4-2.
Figura 4-2 SecGW Cisco ASR9000 (esquerda) e Juniper SRX5800 (direita)
No lado dos eNB os túneis IPsec devem terminar directamente nos eNB, garantido que não há
tráfego no exterior dos eNB, sem ser autenticado e encriptado. Por questões de controlo de
custos, a maioria dos vendedores optou por desenvolver as funcionalidades IPsec por
software. Deve ser tido em conta a capacidade do eNB para desempenhar esta funcionalidade
extra.
4.2 Localização da SecGW
A localização da SecGW na rede LTE pode ser realizada de uma forma mais centralizada,
junto ao EPC ou distribuída, mais perto dos eNB. A escolha deve ter em consideração a
capacidade da SecGW, a resiliência da solução e a latência introduzida. Estes factores
dependem do tipo de arquitectura de rede já existente, da dimensão e infraestrutura de
backhaul.
4.2.1 Arquitectura Centralizada
Numa arquitectura centralizada, a SecGW é integrada junto ao core LTE (EPC). Figura 4-3.
Esta solução exige menos SecGW, mas pode introduzir maiores latências na interface X2
(eNB-eNB) uma vez que o tráfego entre eNB é desnecessariamente obrigado a ir ao IP
backbone. Esta situação pode ser minimizada se tivermos perante um backhaul uniforme e de
alto desempenho em que a latência introduzida seja muito baixa (tipicamente inferior a 5 ms).
Deve ser a solução adoptada para uma rede pequena ou com pouco tráfego. Devido ao
reduzido número de SecGW devem ser consideradas soluções de redundância.
51
Figura 4-3 Arquitectura centralizada versus distribuída
4.2.2 Arquitectura Distribuída
A instalação da SecGW mais perto do eNB obriga ao uso de mais elementos. Figura 4-3. É
uma solução apropriada para as redes de maior dimensão ou com backhaul pouco eficiente.
Permite distribuir o volume de tráfego pela SecGW e tem a vantagem de introduzir menor
latência na interface X2. No entanto implica a introdução de um maior número de SecGW
criando uma rede mais capilar e introduzindo mais fronteiras entre eNB com serviço em
SecGW diferentes. A
Tabela 4-1 apresenta um resumo comparativo das duas arquitecturas.
Arquitectura Distribuída Arquitectura Centralizada
Rede de maior dimensão Backhaul diversificado ou com
grande latência
Exige maior número de SecGW
Redes de pequena dimensão ou em fase inicial
Backhaul com baixa latência
Menos SecGW
Necessita de soluções de redundância
Tabela 4-1 Tipo de Arquitectura
EdgeRouter
MME
SPGW
CoreRouterSecGW
eNB
SiteSwitch
eNB
SiteSwitch
EdgeRouter
MME
SPGW
CoreRouter
SecGW
SecGW
eNB
SiteSwitch
eNB
SiteSwitch
Bac
khau
l XB
ackh
aul Y
Bac
khau
l XB
ackh
aul Y
ArquitecturaCentralizada
ArquitecturaDistribuída
52
4.3 Redundância
Nas redes de telecomunicações é exigida uma disponibilidade de serviço próxima dos 100%.
Com este propósito, é necessário garantir que a solução implementada seja tolerante a falhas
de hardware e software, períodos de manutenção que exigem paragem de serviço, ou
acidentes naturais como inundações, incêndios ou terramotos. Tipicamente os equipamentos
de telecomunicações de alto-desempenho são desenhados para suportar pequenas falhas
internas e operações de manutenção programadas. Este tipo redundância é designado por
redundância intra-elemento. Numa situação de falha grave ou total de um elemento, o serviço
deve ser transferido para um segundo elemento. Este tipo redundância é designado por
redundância inter-elementos ou geográfica. Existem várias técnicas para implementação de
redundância geográfica.
Figura 4-4 Tipos de redundância
Sistema redundante 1+1 em modo Activo/Passivo
Um sistema redundante 1+1 em modo Activo/Passivo é constituído por 2 elementos em que
apenas o elemento activo está a processar tráfego. O elemento passivo não processa tráfego,
mas está sincronizado com o elemento activo. Em caso de falha do elemento activo o segundo
elemento assume as funções. De preferência cada elemento deve estar instalado em locais
físicos diferentes de modo a garantir redundância geográfica. Esta é a configuração de
redundância mais simples de implementar e operar, mas tem desvantagem de ter apenas um
elemento a processar tráfego. Figura 4-4.
Sistema redundante 1+1 em modo Activo /Activo
Semelhante ao primeiro caso, mas nesta situação ambos elementos estão a processar tráfego,
partilhando a carga entre eles. Esta solução tem a mesma capacidade que a anterior, mas
melhora o desempenho pois, em funcionamento normal, a carga de tráfego está distribuída
pelos dois elementos. É uma solução mais complexa de implementar e gerir.
Sistema redundante n+1 em grupo
Nesta situação existe um conjunto (ou pool) de n+1 elementos que partilham equitativamente a
carga de processamento. O dimensionamento deve ser calculado para que a falha um
elemento seja tolerada, isto é, devem existir n+1 elementos. Esta solução tem maior
flexibilidade na expansão de capacidade, mas é mais complexa de gerir e pode introduzir
A P A A
A A
A
Activo/Passivo Activo/Activo
Grupo N+1
53
maiores latências, pois o tráfego é distribuído aleatoriamente sem ter em conta o factor de
proximidade.
Figura 4-5 Redundância: Modo Activo/Passivo
Devido à complexidade da arquitectura em pool. A arquitectura mais usada é a de 1+1 em
modo activo/passivo ou activo/activo. A Figura 4.5 mostra a solução activo/passivo
implementada em laboratório. Para implementar esta solução foi necessário configurar os
Routers e a SecGW com o protocolo de routing dinâmico Open Shortest Path First (OSPF) [19]
para actualização automática de rotas, configurar o protocolo Virtual Router Redundancy
Protocol (VRRP) [20] para agrupar dois routers físicos num único router virtual e configurar o
protocolo Dead Pear Detection (DPD) [21] [22] [23] na SecGW e eNB para redundância de
tuneis IKE/IPsec.
4.4 Zonas de segurança
Por questões de routing e segurança a rede LTE deve ser segmentada em várias VPN ou
contextos de routing. O desenho de rede e a configuração da SecGW deve ser realizado para
que sejam criadas 4 VPN ou zonas de segurança destintas, conforme representado na Figura
4-6. A SecGW deve integrada nestes contextos e garantir a total separação destas zonas de
segurança:
Rede de Acesso (eNB e backhaul)
Rede core (EPC)
Rede de gestão e operação dos eNB (OAM)
Sincronismo de rede
A SecGW separa a VPN ‘Rede de Acesso’ não segura das restantes VPN. O tráfego originado
no eNBs só terá acesso às outras VPN via autenticação IPsec e permissão nas regras de
OSPF
IPBackhaul
Internet
EdgeRouter
MMESecGW
SPGWEdge
Router
SecGW
eNB
CoreRouter
CoreRouter
SiteSwitch
Tunel IPsec
Tunel IPsec redundante (DPD)
Server
Site B
Site A
54
Firewall ou Access Control List (ACL) da SecGW que eventualmente possam implementar
controlo de acesso.
Figura 4-6 Domínios da rede LTE
O PKI pode estar localizado na zona não segura, tipicamente quando são utilizados PKI
externos inseridos numa rede pública, ou na zona segura quando são usados PKI proprietários.
Na situação de uso de um PKI externo, deve ser dada especial atenção na comunicação
segura entre os eNB, a SecGW e o PKI para obtenção dos certificados de chave pública. Uma
possibilidade é a utilização do protocolo Hypertext Transfer Protocol Secure (HTTPS). No caso
de uso de um PKI proprietário, este deve ser protegido pela secGW e os eNBs devem possuir
um certificado de fábrica para se autenticar no primeiro contacto com a rede. Como resultado
final a SecGW deverá ter a seguinte integração lógica na rede de acesso.
Figura 4-7 Introdução da SecGW na rede de acesso LTE
RANeNB
SecGW
RedeCore
OAMPKI
Sincronismo
Domínios na zona não segura Domínios na zona segura
EPC
eNB NMS
Sync Servers
CA
eNB
MME
eNB
S1 S1-U
PKI
SecGW
S/PGW
Control PlaneUser Plane
OAM Plane
X2-U
S1-AP
eNB NMS
X2-AP
PKI Plane
Zona não Segura Zona Segura
Rede de Acesso (IP Backhaul)
Sincronismo
OAM
55
A Figura 4.7 ilustra a introdução da SecGW na rede de acesso LTE. Como se pode observar, a
SecGW é colocada entre os eNB e a core LTE de modo a que todas as interfaces lógicas
possam ser protegidas através da implementação do IPsec.
4.5 Integração e Autenticação dos eNBs
É usual existirem soluções que em laboratório cumprem todos os requisitos, mas que não
podem ser implementadas em produção devido à dificuldade de “industrializar” a solução.
Considerando que numa rede de telecomunicações o número de eNB a colocar ao serviço
pode facilmente atingir os milhares, o processo de configuração e integração na rede deve ser
o mais eficiente e automatizado possível. Com a introdução do IPsec há a necessidade
adicional de realizar a autenticação prévia na SecGW, levantando alguns desafios no processo
de automatização. Nesta secção prende-se propor uma solução para a integração e
autenticação automática dos eNB na rede de acesso LTE.
4.5.1 Integração dos eNB na rede
O processo proposto para a integração e autenticação dos eNBs está esquematizado na Figura
4-8 e é descrito em detalhe em baixo.
Figura 4-8 Integração de um eNB IPsec
IPCore
EPC
SecGWeNB
IPbackhaul
DHCP/Router CASwitch
Conectividade L2
Conectividade IP
Certificação chave Publica
Autenticação IKE/IPSec
Trafego Autenticado e Encriptado
NMS
56
1. Conectividade Ethernet (layer 2). O primeiro passo é o estabelecimento de ligação layer
2 do eNB na rede, isto é, obtenção do MAC address junto do backhaul. Está ligação é
tipicamente realizada junto de um switch co-localizado com o eNB.
2. Conectividade IP (layer 3). O passo seguinte consiste na atribuição do IP ao eNB,
informação sobre o IP do default route, o IP do CA e da SecGW. Esta operação dever ser
realizada junto de um servidor DHCP [24].
3. Certificação da chave pública. Depois de estabelecida a conectividade IP na rede de
transporte, e antes de entrar em contacto com a SecGW, o eNB deve solicitar o certificado
para a sua chave pública junto do CA. Este processo é detalhado em pormenor na secção
4.5.2
4. Autenticação IKE na SecGW. Após obtenção do certificado, o eNB reúne as condições
para se autenticar junto da SecGW e estabelecer o túnel IPsec.
5. Transferência segura de informação, nesta fase o eNB inicia o primeiro contacto com o
sistema de gestão (NMS) obtendo a restante configuração e parametrização rádio. Após
configuração, o eNB o contacta o MME para estabelecimento do serviço. As ligações X2
para os eNB vizinhos devem ser estabelecidas automaticamente conforme especificado na
parametrização recebida pelo sistema de gestão.
4.5.2 Certificação e Autenticação dos eNBs
Num sistema de autenticação por chave pública, antes que um eNB se possa autenticar junto
da SecGW é necessário obter um certificado que autentique a pertença da própria chave.
A gestão dos certificados de chave pública dos eNBs é um dos processos mais críticos para a
utilização bem-sucedida do IPsec.
Em sistemas de grande escala, como é caso da rede LTE, é necessário implementar um
processo que realize esta gestão automaticamente. O Public Key Infrastructure (PKI) é um
sistema que permite realizar a publicação, distribuição e renovação dos certificados digitais do
eNBs. Os protocolos o SCEP e o CMPv2, permitem que esta interacção seja realizada de um
forma automática. Na Figura 4-9 é exemplificado o processo utilizando o SCEP.
57
CA SecGWeNB A
Gerar par de chave Publica Privada
Request pub key certificabte
Send pub key certificate
Request Root CA certificate
Send Root CA certificate
Autenticação IKE
Request pub key certificabte
Send pub key certificate
Request Root CA certificate
Send Root CA certificateGerar par de chave
Publica Privada
Dados Autenticados e Encriptados
Figura 4-9 Certificação Automática por SCEP
1. Obtenção do certificado do CA (chave pública do CA)
Em primeiro lugar o eNB obtém o certificado do CA, ou seja a chave pública do CA
autenticada pelo próprio CA (root CA). Esta operação só será realizada uma vez por cada
eNB ou no caso do certificado do CA expirar. O certificado do CA será utilizado
posteriormente na fase de autenticação IKE para o eNB verificar que o certificado enviado
pela SecGW é genuíno e vice-versa.
2. Obtenção do certificado de chave pública
Depois de gerar o par de chaves pública/privada, o eNB solicita o certificado para a sua
chave pública ao CA. O CA verifica a entidade presente no certificado e assina-o com a
sua chave privada e envia de volta ao eNB. O certificado emitido pelo CA associa a
identidade do eNB à chave pública. O eNB verifica a validade do certificado originado pelo
CA descodificando com a chave pública do CA, previamente recebida (ponto 1).
3. Autenticação do eNB na SecGW
Durante a autenticação IKE, o eNB envia o seu certificado digital para a SecGW. Para
garantir que o certificado recebido é valido, a SecGW valida a assinatura digital utilizando a
chave pública do CA. Para este efeito os eNB e SecGW têm que ter pelo menos um CA em
comum. A partir desta fase o eNB e a SecGW podem estabelecer o túnel IPsec e iniciar a
transferência segura da informação.
58
4.6 Qualidade de Serviço
A rede LTE tem como objectivo ser uma rede única para transporte de todo o tipo de serviços.
Serviços como a voz, vídeo, internet browsing ou email irão concorrer entre si pelo recursos da
rede. A voz é um exemplo de um serviço com alguma tolerância a erros de transmissão, mas
muito sensível a latências ou variação de latências. Pelo contrario, o serviço de email, é pouco
exigente em termos de latência, mas necessita de baixas taxa de erro. O LTE terá de ter
mecanismos capazes de realizar a gestão dos seus próprios recursos de forma a satisfazer a
Qualidade de Serviço (Quality of Service - QoS) exigida por cada um destes serviços. Nesta
secção será analisada a forma como o QoS é implementado em rede IP e LTE e as
necessárias adaptações a realizar com a introdução do IPsec.
4.6.1 Qos em redes IP
O princípio base por detrás dos mecanismos usados para implementação do QoS nas redes de
transmissão Ethernet/IP é a classificação e marcação dos pacotes. A classificação e marcação
é realizada com base nos requisitos de cada tipo de serviço, de modo a que a cadeia de
equipamentos (routers, switchs, firewalls) possa, por exemplo em caso de congestão, decidir
qual o tráfego que deve ter prioridade (menor latência) ou o último a ser descartado (menos
erros). Esta marcação é realizada através do campo Differentiated Services Code Point (DSCP)
na camada de rede e dos Priority Bits (P-Bits) na camada Ethernet. O DSCP são 6 bits do
campo de oito bits Differentiated services Field (DS) presente no header do pacote IP. Os P-
Bits são 3 bits do campo VLAN TAG de 4 bytes da trama Ethernet 802.1Q. O DSCP é utilizado
para implementação do QoS ao nível da camada de rede (Layer 3) e os P-Bits para
implementação de QoS ao nível da camada de Ethernet (Layer 2). Tipicamente um
equipamento IP/Ethernet (router, switch, firewall) utiliza 8 filas com prioridades de
processamento diferente. A Tabela 4-2 mostra um possível mapeamento dos 64 valores
possíveis de DSCP e dos 8 possíveis P-Bit (Ethernet) nas filas de prioridades.
Filas de Prioridade
DSCP (L3)
P-Bits (L2)
7 (+ prioritário) 56-63 7
6 48-55 6
5 40-47 5
4 32-39 4
5 24-31 3
2 16-23 2
1 8-15 1
0 (- prioritário) 0-7 0
Tabela 4-2 Mapeamento DSCP / P-Bit
As filas de prioridades 6 e 7 são normalmente utilizadas para protocolos de routing. No Anexo
B - Tabelas de QoS, são apresentadas em detalhe as tabelas e o mapeamento entre campos
59
4.6.2 QoS no LTE
O LTE adiciona mais um nível de QoS com a introdução do QoS Class Identifier (QCI). O QCI é
um valor, definido por tipo de serviço e/ou utilizador, que determina o comportamento do
pacote IP desde o EPC ao Terminal. Os parâmetros de QoS atribuídos a um determinado
serviço ou utilizador são propagados desde o HSS/PCRF até ao EPC e eNB. Estes elementos
deverão ter a capacidade de mapear o QCI em valores de DSCP e p-bit para que os elementos
de backhaul (routers, switch e firewalls, etc) possam processar os dados adequadamente,
administrando filas de espera e gerindo a largura de banda disponível. A Figura 4-10 mostra o
fluxo de classificação e marcação deste o QCI até aos P-Bits.
Figura 4-10 QoS no LTE, IP e Ethernet
Dois dos factores mais importantes no desempenho na transferência de dados em redes IP, e
por consequência na rede de acesso do LTE, são a taxa de erros de transmissão e a latência.
Na Tabela 4-3 estão definidos os requisitos mínimos end-to-end destes dois parâmetros para
cada um dos serviços QoS Class Identifier (QCI) [25].
QCI Tipo de Recurso
Prioridade Latência Erros trama
Serviços exemplo
1
Granted Bit Rate (GBR)
2 100 ms 10-2 Conversational Voice
2 4 150 ms 10-3 Conversational Video (Live Streaming)
3 3 50 ms 10-3 Real Time Gaming
4 5 300 ms 10-6 Non-Conversational Video (Buffered Streaming)
5
Non Granted Bit Rate
(Non GBR)
1 100 ms 10-6 IMS Signaling
6 6 300 ms 10-6
Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video)
7 7 100 ms 10-3
Voice, Video (Live Streaming) Interactive Gaming
EPCUE Router
QC
I
DSCP
Fila 1
Fila N
Fila 2P-Bit
Fila i
Fila 1
Fila N
Fila 2
Fila i
LTE QoS IP QoS Ethernet QoS
Serviço 1 /utilizador 1
Serviço X/utilizador N
Serviço 2 /utilizador 2
Serviço i/utilizador i
eNB SwitchHSS
60
8 8 300 ms 10-6 Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
9 9 300 ms 10-6
Tabela 4-3 Características dos QCI definidos na norma 3GGP 23.203
Tendo em consideração a Tabela 4-2 e 4-3. Na Tabela 4-4 é proposto uma configuração de
QoS para os vários serviços. E o respectivo mapeamento entre camadas LTE (QCI), IP (DSCP)
e Ethernet (P-Bits)
QCI Tipo de tráfego (QCI) PHB DSCP P-bit
NA Network Synchronization EF 46 5
NA Routing, Network Control EF 46 5
QCI1 GBR Conversational Voice EF 46 5
QCI2 GBR Conversational Voice (Live Streaming) AF42 36 4
QCI3 GBR Real Time Gaming AF41 34 4
QCI4 GBR Non-Conversational Video (Buffered Streaming) AF43 38 4
QCI5 IMS Signaling EF 46 5
QCI6 Non-GBR TCP Specific Services AF31 26 3
QCI7 Non-GBR Voice/Video/Interactive Gaming AF11 10 1
QCI8 Non-GBR TCP Premium Bearer AF12 12 1
QCI9 Non-GBR TCP Default Bearer AF13 14 1
NA S1AP/X2AP - Inter-Node Signaling EF 46 5
NA eNB O&M Access EF 46 5
Tabela 4-4 Mapeamento QCI, DSCP, P-Bits
4.6.3 QoS no IPsec
O IPsec introduz mais um desafio no já complexo sistema de QoS. Como já foi referido, para
implementar o QoS, os eNB e o EPC mapeiam o QCI recebido do HSS/PCRF no DSCP/P-bit.
O valor do DSCP/P-bit deverá ser respeitado em toda a cadeia IP/Ethernet. A utilização do
IPsec em Modo Túnel realiza o encapsulamento do IP header original entre a SecGW e o eNB
(ver secção 2.4.6), impossibilitando a leitura do DSCP pelo backhaul. Nesta situação é
necessário que os elementos que fazem a fronteira para o IPsec (isto é, SecGW e eNB)
marquem o DSCP do IPsec header com o valor correcto. Uma técnica simples e eficiente
consiste em copiar o DSCP do IP header original para o IPsec header de forma a manter o
QoS pretendido. Esta problemática é abordada com grande detalhe no RFC 2983 Differentiated
Services and Tunnels. Na Figura 4-11 está representado o QoS end-to-end, destacando o troço
IPsec.
61
Figura 4-11 QoS no LTE
4.7 Encapsulamento IPsec
O encapsulamento adicional introduzido pelo protocolo IPsec tem como resultado o aumento
do tamanho dos pacotes IP que transitam na rede. Esta situação pode resultar na degradação
do desempenho da rede, originada quer pela fragmentação quer pela menor taxa de
transferência devido à menor relação payload/overhead. Nesta secção pretende-se calcular o
factor de encapsulamento introduzido pelo IPsec e determinar o impacto no dimensionamento
do Maximum Transmit Unit (MTU). O MTU define o tamanho do maior Protocol Data Unit (PDU,
ver Anexo A) que uma camada de um protocolo pode transmitir.
4.7.1 Encapsulamento
A introdução do protocolo IPsec adiciona mais um nível encapsulamento à pilha de protocolos
do LTE, aumentando a dimensão do PDU que é necessário transportar na camada Ethernet e
obrigando ao redimensionamento do MTU para evitar a fragmentação. A Figura 4-12 mostra a
pilha de protocolos na interface entre o eNB e a SPGW (S1-User plane). A troca de mensagens
entre o eNB e a SPGW é realizada através do protocolo GTP-U, que por sua vez é
encapsulado nos protocolos UDP e IP sucessivamente. Antes de serem transportadas pelas
camadas Ethernet e Física o pacote IP é encapsulado pelo protocolo IPsec no eNB. Na
SecGW é removido o encapsulamento IPsec antes do reencaminhamento para o SPGW.
Internet
SPGW
MME
UE
HSS
IP QoS
End-to-End QoS
IPsec QoS IP QoS
LTE QOS
IP QOS
S1 QCIUu QCI
S11
SecGWeNB
IPBackhaul
Router
LTE External QoS
E2E QOS
User A/service Y » QCI 1User B/service Z » QCI 2
Ethernet QoSEthernet QoS Ethernet QoSL2 QOS
62
Figura 4-12 MTU no Plano de utilizador do LTE
No control plane (não representado na figura), interface entre o eNB e o MME, as mensagens
S1-AP são transportadas pelo protocolo SCTP sobre IP. Estas mensagens são igualmente
encapsuladas pelo protocolo IPsec entre o eNB e SecGW, sendo desencapsuladas neste
elemento e enviadas para o MME.
4.7.2 Fragmentação
Um pacote IP pode ter uma dimensão até 65536 bytes (2^16), no entanto o seu tamanho é
geralmente limitado a dimensões muito inferiores pela MTU na camada Ethernet. De modo a
suportar vários MTU o protocolo IP permite a fragmentação (divisão de um pacote IP em
pacotes mais pequemos). Sempre que um pacote IP tem uma dimensão superior ao MTU é
dividido em pacotes mais pequenos que serão posteriormente reagrupados no destino.
A fragmentação é um processo bastante ineficiente, necessita de processamento e memória
adicional nos routers, adiciona mais encapsulamento e no caso de existir a perda de um
fragmento todo o pacote IP original terá de ser reenviado. Nos equipamentos que só suportem
funcionalidades de camada 2 (ex.: switch), sem capacidade de realizar fragmentação, todas a
tramas que excedam a MTU da camada Ethernet serão descartadas.
Será, portanto, necessário determinar a MTU mínima necessária para evitar a fragmentação.
No caso de algum equipamento de rede não suportar alteração da MTU para valores maiores
que o valor padrão (1500 bytes), outra solução possível para evitar a fragmentação, é a
diminuição forçada do Maximum Segment Size (MSS), tradicionalmente igual a 1460. Resolve
o problema no TCP, mas não é aplicável ao protocolo UDP e reduz a taxa de transferência.
L1
GTP-U
UDP
Eth/L1 Eth/L1
IPsec IPsec
Eth/L1
IPIP
PDCP
RLC
L1
MAC
PDCP
RLC
L1
MAC
IP
Eth/L1
IP
GTP-U
UDP
IP IP
TCP/UDP
Aplicação
TCP/UDP
Aplicação
Eth
IP
Eth
IP
UE eNB SecGW SPGW Server
UU S1-U S1-U Gi
Message MTU
Frame MTU Packet MTU
L1
63
4.7.3 Cálculo do factor de encapsulamento e MTU
Com o objectivo de determinar e minimizar o impacto do IPsec no desempenho da rede, nesta
secção será calculado o factor de encapsulamento introduzido pelo IPsec e a MTU mínima
necessária para evitar a fragmentação. O cálculo será realizado apenas para user plane, pois
no controlo plane (sinalização) a mensagens são de pequena dimensão.
4.7.3.1 Encapsulamento IPsec
O encapsulamento (em bytes) introduzido pelo IPsec depende do tipo de protocolo (ESP ou
AH), do modo (Transporte ou Túnel) e do tipo de algoritmos de encriptação usados. A Figura 4-
13 mostra os vários campos e os respectivos bytes adicionados ao payload para o caso do
ESP em modo túnel.
Figura 4-13 Pacote IPsec
Na Tabela 4-5 são apresentados os cálculos para determinar o encapsulamento no caso do
protocolo ESP, no modo túnel, para dois dos algoritmos de encriptação mais usados, 3DES e
AES.
Campo 3DES_CBC [bytes]
AES_CBC [bytes]
IPsec IP header (modo túnel) 20 20
ESP header 8 8
Initialization Vector (= tamanho do bloco) 8 16
Padding (Máximo = tamanho bloco -1 byte) 7 15
ESP tail (PAD length, next header) 2 2
Integrity Check Value (ICV) 12 12
Total 57 73
Tabela 4-5 Encapsulamento IPsec
O IPsec com algoritmo AES adiciona, no máximo, 73 bytes de encapsulamento, mais 16 bytes
que o 3DES que adiciona 57 bytes. Estes dois algoritmos operam em blocos de dimensão fixa,
adicionando bits à informação original (padding) sempre que é necessário completar a
dimensão fixa do último bloco. No modo criptográfico Cipher Block Chaining (CBC), a entrada
do algoritmo de encriptação é constituída pelo XOR do texto plano com o bloco de precedente
encriptado. Para criar o primeiro bloco encriptado é utilizado um Initialization Vector (IV). O AES
usa um IV de 16 bytes (128 bit) enquanto o 3DES usa IV de 8 bytes (64bits). [26] [27]. O
Padding(7/15)
IV(8/16)
ESP Hdr(8)
Tunnel H(20)
Payload(...)
ESP tail(2)
ESP ICV(12)
Tunel ESP Algoritmo de Cifra Tunel ESP Utilizador
64
Integrity Check Value (ICV) é utilizado para autenticação e integridade. Usando como exemplo
o algoritmo HMAC-SHA-1-96, que produz um hash de 20 Bytes (160 bit) sendo utilizados os
primeiros 12 bytes (96 bits). [28]
4.7.3.2 Encapsulamento LTE
Para determinar o MTU é necessário calcular o tamanho máximo da trama na camada
Ethernet, adicionando aos dados do utilizador o encapsulamento total introduzido pelos
protocolos desde a camada aplicacional até a camada Ethernet. Para este exercício foi
considerado um encapsulamento IPsec de 73 bytes, calculado na secção anterior e
exemplificado na Figura 4-14.
Figura 4-14 Encapsulamento LTE
Considerando dois cenários (com e sem IPsec), a utilização do algoritmo de encriptação AES e
um payload no utilizador de 1460 bytes (valor tipicamente configurado num PC) foram
realizados os cálculos apresentados na Tabela 4-6.
PDU Campo Sem IPsec
[bytes] Com IPsec
[bytes]
Utilizador (no PC)
Payload 1460 1460
TCP Header 20 20
IPv4 Header 20 20
LTE + Transporte
GTP-U Header 8 8
UDP Header 8 8
IP Header 20 20
IPsec Header 0 73
Ethernet Header 18 18
IEEE (802.1Q) 4 4
MTU = PDU (Utilizador + LTE) 1558 1631
Factor de encapsulamento 0,07 0,12
Tabela 4-6 Encapsulamento LTE com e sem IPsec
Payload(1500)
GTP-U H(8)
UDP H(8)
IPv4 H(20)
Eth H(22)
IPsec H(73)
GTP-U H(8)
UDP H(8)
IPv4 H(20)
Eth H(22)
APP Payload(1460)
TCP H(20)
IPV4 H(20)
Payload(1500)
IP LTE Utilizador802.1Q IPsec
65
Como se pode verificar, no cenário “sem IPsec”, a MTU mínima na camada Ethernet para evitar
a fragmentação é de 1558 bytes, apresentando um factor de encapsulamento de 7%
relativamente ao payload. Para o cenário “com IPsec” o valor do MTU é de 1631 bytes,
aumentando o factor de encapsulamento para 12%. É de notar que os factores de
encapsulamento foram calculados nas condições óptimas, isto é, considerando que cada
pacote IP transporta sempre um payload de 1460 bytes. Para determinar um valor do factor de
encapsulamento mais próximo da realidade, será necessário considerar o perfil de tráfego
transportado pela rede. Para cálculos de desempenho da rede, é prática corrente o uso do
Internet MIX (IMIX), isto é, definir o tamanho e percentagem de pacotes pequenos, médios e
grandes que transitam numa determinada rede.
Tipo de Pacotes
Tamanho [bytes]
Distribuição [%]
Pequenos 72 60
Médios 576 25
Grandes 1418 15
Média 400 100
Tabela 4-7 IMIX
Utilizado o perfil IMIX da Tabela 4-7 e determinada a média ponderada, podemos considerar
que um pacote médio terá a dimensão de 400 bytes. O gráfico e a tabela em baixo mostram o
factor de encapsulamento introduzido pela pilha de protocolos para as várias dimensões dos
pacotes do perfil IMIX, para um pacote médio de 400 bytes e um pacote máximo de 1460
bytes.
PDU Campo
Payload 72B
Payload 400B
Payload 576B
Payload 1418B
Payload 1460B
A Utilizador (no PC)
Payload 72 400 576 1418 1460
TCP Header 20 20 20 20 20
IPv4 Header 20 20 20 20 20
B LTE + Transporte
GTP-U (LTE) 8 8 8 8 8
UDP (IP) 8 8 8 8 8
IP Header (IP) 20 20 20 20 20
Ethernet Header (L2) 18 18 18 18 18
IEEE 802.1Q (L2) 4 4 4 4 4
C = A + B MTU = Utilizador + LTE + Transporte 170 498 674 1516 1558
D = (C - A) /A Factor Encapsulamento LTE 1,36 0,25 0,17 0,07 0,07
E IPsec IPsec Header (IPsec) 73 73 73 73 73
F = D + E MTU = Utilizador + LTE + Transporte + IPsec 243 571 747 1589 1631
G = (F - A) /A Factor Encapsulamento LTE + IPsec 2,38 0,43 0,30 0,12 0,12
Tabela 4-8 IMIX, Factor de encapsulamento
66
Como se pode observar na Tabela 4-8, para o pacote médio de 400 bytes, o factor de
encapsulamento relativo ao LTE é 0,25 (25%) e 0,43 (43%) considerando o encapsulamento
adicional do IPsec (LTE + IPsec).
Figura 4-15 IMIX, Factor de encapsulamento
Como se facilmente se pode observar na Figura 4-15, o factor de encapsulamento introduzido
pelo LTE varia de 1,36 (136%) para pacotes de 72 bytes e 0,07 (7%) para pacote de 1460
bytes. Considerando o factor total de encapsulamento adicional introduzido pelo IPsec os
valores passam de 2,38 (238%) para 72 bytes e 0,12 (12%) para pacotes 1460 bytes de
payload.
67
5 Avaliação do Desempenho da Solução
Neste capítulo são apresentados os resultados da avaliação do desempenho da solução
proposta. O principal objectivo é determinar se após a introdução do IPsec, a rede de acesso
LTE possui o mesmo desempenho e se mantem a mesma experiência para o utilizador. Para
este efeito utilizou-se uma abordagem comparativa entre o cenário de rede “sem IPsec” e “com
IPsec”, e foram utilizadas duas metodologias diferentes de avalição:
Testes de desempenho de rede, utilizando o protocolo Two-Way Active Measurement
Protocol (TWAMP) [RFC5357].
Testes de utilizador (end-to-end), utilizando aplicações normalmente disponíveis a
qualquer utilizador, com o objectivo de avaliar a experiência percepcionada pelo
utilizador.
A Figura 5.1 descreve o cenário de testes e o equipamento de medida TWAMP implementado
no laboratório.
Figura 5-1 Cenário de Teste
Na Tabela 5.1 são descritos os principais equipamentos e características que constituem o
cenário de teste.
Internet
EdgeRouter
MMESecGW
SPGWEdge
Router
IP
Backhaul
SecGW
eNB
CoreRouter
CoreRouter
SiteSwitch
Tunel IPsec
Tunel IPsec redundante
FTPServer
Site B
Site A
CA
TWAMP Actuator
HSS
PCRF
R
Laptop
68
Elementos 3GPP (LTE)
eNB RBS Ericsson 6601, DUS31, SW L13B, 1800Mhz 20Mhz. max UL: 50Mbits, max DL: 150Mbits
SecGW Juniper SRX5800
SPGW Cisco Version 12.0
MME Ericsson MK8 version 2013B CP02
Conectividade IP
IP backhaul (rede de acesso) *
Conectividade local: switch Cisco 2941 Anel L2: switch Cisco 3400 Agregação do Anel (L3): router Cisco ASR 9000
IP Backbone (rede core)*
Edge router: Cisco 6500 core router: Cisco 6500
Ferramentas de testes
vsftpd FTP Server
HW: PC Pentium(R) Dual CPU E2200 @ 2.20GHz NIC: Intel 82566DM-2 Gigabit Network Connection SW: Ubunto (Linux 2.6.31-23-generic i686)
FileZilla FTP client PC Window7: DELL dual core
Modem 4G (Pen) Huawei k5005, max UL: 50Mbits, max DL: 100Mbits
Ferramentas de medida e captura
TWAMP Sender: Accedian eNB Reflector: Ericsson
Captura Wiresharke
CA (PKI) CA (PKI) Enterprise Java Bean Certificate Authority (EJBCA)
Tabela 5-1 Cenário de testes (Lista de equipamentos)
*De forma a garantir que não existe limitação na taxa de transferência na rede de transmissão,
o débito mínimo disponível entre o eNB e o Servidor de testes é de 1Gbit/s.
Para a realização dos testes de avaliação foi utilizada a parametrização IPsec definida na
Tabela 5-2.
Tabela 5-2 Perfil IKE/IPsec utilizado nos testes
5.1 Testes de desempenho da rede
Para a realização dos testes de avaliação do desempenho da rede foi utilizado o protocolo
Two-Way Active Measurement Protocol (TWAMP) [RFC5357]. O TWAMP é uma evolução do
One-way Active Measurement Protocol (OWAMP) [RFC4656] e tem como objectivo medir
parâmetros de desempenho da rede, como a latência, a variação da latência e perda de
pacotes, através do envio de pacotes IPs de teste e monitorizando a sua experiência na rede.
IKE Version 2
Encriptação AES - CBC (256)
Autenticação e Integridade
HMAC_SHA-1-96
ESP Modo Túnel
Encriptação AES - CBC (256)
Autenticação e Integridade
HMAC_SHA1
69
5.1.1 Protocolo TWAMP
Com o objectivo de medir a diferença de desempenho da rede LTE “sem IPsec” e “com IPsec”,
foi instalado um sistema de medidas TWAMP no cenário de testes. O princípio de
funcionamento do TWAMP consiste no envio de pacotes IP de teste a partir de um
equipamento emissor (twamp sender) que são ‘reflectidos’ no eNB (twamp reflector) de volta
para o emissor. Os pacotes de testes são marcados com o mesmo valor de DSCP dos pacotes
reais de forma a terem a mesma experiência na rede.
twamp sender, equipamento emissor de pacotes IPs de teste com várias dimensões e
prioridades de modo a simular o tráfego real.
twamp reflector, equipamento reflector de pacotes IP. Recebe os pacotes IP enviados pelo
sender e reenvia-os com a informação do tempo de chegada e partida.
A Figura 5-2 mostra um esquema simplificado do sistema de medidas TWAMP no cenário
implementado “com IPsec”. O cenário “sem IPsec” é idêntico, mas sem a existência da SecGW.
Figura 5-2 Modelo simplificado do cenário de testes TWAMP
O sender e o reflector estão sincronizados no tempo através do protocolo Network Time
Protocol (NTP) e o processo de medidas é realizado da seguinte forma:
T=0, tempo de partida do pacote IP de teste (1, 2, …, n) do sender
T=1, tempo de chegada do pacote IP de teste (1, 2, …, n) ao reflector no eNB
T=2, tempo de partida do pacote IP de teste (1, 2, …, n) do reflector no eNB
T=3, tempo de chegada do pacote IP teste (1, 2, …, n) ao sender
Através da análise comparativa dos 4 tempos medidos para cada pacote IP e da verificação da
sequência entre pacotes, são calculados os parâmetros, latência, variação da latência e os
pacotes perdidos, duplicados ou desordenados.
TWAMPReflector
(eNB)
SecGW
IPSec Tunnel
TWAMPSender
R
A
T=1 (Chagada ao reflector no eNB )
T=2 (Saida do reflector no eNB )
T=0(Partida do Sender)
T=3 (Chagada ao Sender )
70
Utilizando o método anteriormente descrito foi medida a diferença de desempenho no troço da
rede que sofre alterações com a introdução do IPsec, isto é, entre o eNB e a SecGW. É
excluído portanto, toda a rede a montante da SecGW (EPC, File Server, etc) e a interface rádio
entre o terminal e o eNB. A Figura 5-3 mostra o cenário final implementado, com o twamp
sender instalado junto do EPC e um twamp reflector instalado no próprio eNB.
Figura 5-3 TWAMP
5.1.2 Indicadores de Desempenho
Utilizando o método em cima descrito, foram calculados os seguintes indicadores de
desempenho de rede para o cenário “sem IPsec” e “com IPsec”.
Métricas de Tempo:
Latência (Delay);
Variação da latência entre pacotes (Inter Packet Delay Variation – IPDV) ou Jitter;
Métricas de Erros:
Pacotes Perdidos;
Pacotes Duplicados ou Desordenados;
5.1.3 Latência
5.1.3.1 Objectivo do Teste
Medição da latência entre o eNB e o EPC num cenário com e sem IPsec.
A latência da rede (network delay) é o tempo de transferência de um pacote IP entre a origem e
o destino. Existindo vários factores que influenciam a latência numa rede de transporte IP:
Tempo de propagação do sinal, que dependente da distância e do meio utilizado;
Processamento dos equipamentos de rede (routers, switch, firewall, servidores,
equipamento terminal);
IP
Backhaul
Internet
EdgeRouter
MME
SecGW
SPGWEdge
Router
eNBReflector
CoreRouter
CoreRouter
SiteSwitch
Tunel IPsec
TWAMP
FTPServer
CA
TWAMP Sender
HSS
PCRF
R
71
buffers para armazenamento dos dados
Processamento adicional para protecção dos dados (ex.: encriptação, desencriptação)
A taxa de transferência do TCP depende da latência da rede e da taxa de erros. O cálculo
teórico é dado pela fórmula Mathis: [29]
Taxa de Transferência TCP ≤𝑀𝑆𝑆
𝑅𝑇𝑇 √𝑃𝑙𝑜𝑠𝑠 , com:
RTT= Round Trip Time = soma da latência nos dois sentidos
MSS = Maximum Segment Size (tradicionalmente igual a 1460)
Ploss = Probabilidade de erro> 0
5.1.3.2 Metodologia do teste
De modo a medir a latência adicional introduzida pelo IPsec foram realizados quatro cenários
de teste:
Sem IPsec, com dimensão dos pacotes a 84 bytes e 1400 bytes.
Com IPsec, com dimensão dos pacotes a 84 bytes e 1400 bytes
O período de amostragem para cada um dos cenários foi de 2 h com o envio de 10 pacotes de
testes por segundo (10 PPS). Em períodos de 30 s foi medido o valor máximo, mínimo e a
mediana dos 300 pacotes de teste enviados. Calculou-se a média dos 8 valores mais altos
verificados no período das 2 h para cada um destes valores.
1. Envio de 10 pacotes/s durante 2h de teste
2. Período de amostragem = 30s (300 pacotes = 10 pps * 30 s)
3. Ordenação por ordem crescente dos 300 pacotes
4. Cálculo do Mínimo, Mediana e Máximo em cada período de amostragem de 30s (300
pacotes)
5. Para apresentação dos resultados foi considerada a média dos 8 valores mais altos dos
Mínimos, Medianas e Máximas verificados nas duas 2h
72
5.1.3.3 Resultado e conclusão do teste
Na Tabela 5-3 estão representados os valores obtidos nas 4 experiências:
Latência
Latência (mínimo) [ms]
Latência (mediana) [ms]
Latência (máximo) [ms]
Min_dl Min_ul Med_dl Med_ul Max_dl Max_ul
Sem_IPSEC_84B 0,21 0,22 0,23 0,24 0,25 0,30
Com_IPSEC_84B 0,45 0,47 0,47 0,50 0,50 0,51
Incremento_84B 114% 114% 104% 108% 100% 70%
Sem_IPSEC_1400B 0,36 0,38 0,37 0,40 0,40 0,50
Com_IPSEC_1400B 0,68 0,69 0,70 0,73 0,80 0,84
Incremento_1400B 89% 82% 89% 83% 100% 68%
Tabela 5-3 Latência
Observando os resultados obtidos, podemos verificar que para os valores da mediana, o
incremento da latência é de 104% no downlink (Med_dl) e 108% no uplink (Med_ul) nos
pacotes de pequena dimensão (84 bytes) e de 89% no downlink e de 83% no uplink para o
caso dos pacotes de grande dimensão (1400 bytes).
Nos valores máximos, o incremento da latência é de 100% no downlink (Max_dl) e 70% no
uplink (Max_ul) para o caso de pacotes de pequena dimensão (84 bytes) e de 100% no
downlink e de 68% no uplink para o caso dos pacotes de grande dimensão (1400 bytes).
Apesar do incremento percentual da mediana e dos máximo ser relativamente alto, os valores
absolutos da mediana são inferiores a 0,74 ms e os das latência máxima são sempre inferiores
a 1 ms. Valores bastantes satisfatórios para uma rede IP onde a latência end-to-end deverá ser
inferior a 50 ms para jogos em tempo real e 100 ms para voz (ver secção 4.6).
Os gráficos das Figura 5-4 e Figura 5-5, obtidos a partir dos valores da Tabela 5-3, mostram os
valores da latência de downlink e uplink para as várias métricas (mínimo, mediana e máximo)
Figura 5-4 Latência (downlink)
73
Figura 5-5 Latência (uplink)
Nos gráficos é bem visível o aumento da latência no downlink e no uplink quando é introduzido
o IPsec. No entanto outras conclusões podem ser retiradas. È possível verificar que a latência
no downlink e uplink aumenta com a dimensão dos pacotes independentemente do uso ou não
do IPsec. Este aumento pode ser justificado com o tempo de processamento e buffering
necessário nos pacotes de maior dimensão. Existem também pequenas diferenças entre o
uplink e o downlink que em teoria não deveriam existir, mas que podem ser explicados com a
possível menor capacidade do eNB relativamente ao EPC e à SecGW para processar o
tráfego.
5.1.4 Variação da Latência (jitter)
5.1.4.1 Objectivo do teste
Medição da Variação da Latência entre pacotes (Inter Packet Delay Variation - IPDV) ou Jitter.
Por definição a Variação da latência é a diferença da latência entre pacotes IP consecutivos e
pode ser escrita da seguinte forma:
Variação Latência (pacote i) = Latência (pacote i) – Latência (pacote i - 1)
Tal como a latência, a variação da latência tem impacto em aplicações de tempo-real e pode
ter que ser compensada/evitada com o correcto dimensionamento de buffers. [30]
5.1.4.2 Metodologia
Foi utilizada a mesma metodologia do teste da secção 5.1.3
74
5.1.4.3 Resultado e conclusão do teste
Variação da Latência
Mediana [ms]
downlink uplink
Sem_IPSEC_84B 0,0035 0,0120
Com_IPSEC_84B 0,0075 0,0137
Incremento_84B 114% 14%
Sem_IPSEC_1400B 0,0030 0,0110
Com_IPSEC_1400B 0,0065 0,0125
Incremento_1400B 117% 14%
Tabela 5-4 Variação da latência
A Tabela 5-4 e a Figura 5-6 mostram os valores da mediana da variação da latência obtidos
nos 4 cenários.
Independentemente do uso do IPsec, os valores de downlink são bastante inferiores
relativamente aos valores de uplink. Teoricamente estes valores deveriam ser da mesma
ordem de grandeza. Durante a realização dos testes não foi evidente a razão para a existência
desta diferença. Algumas hipóteses podem ser consideradas como, por exemplo, uma menor
ineficiência devido a erro de configuração num dos equipamentos ou uma menor capacidade
de processamento do reflector-twamp (realizada por sw no eNB) relativamente ao sender-
twamp (HW dedicado). De qualquer forma, os resultados são considerados válidos, uma vez
que análise é diferencial entre o cenário “sem IPsec” e “com IPsec”.
No cenário de 84 bytes a introdução do IPsec aumenta em 114% a mediana da variação da
latência no downlink e em 14% no uplink. No cenário de 1400 bytes a introdução do IPsec
aumenta em 117% a mediana da variação da latência no downlink e em 14% no uplink.
O aumento verificado no cenário IPsec pode ser justificado com a introdução da SecGW e pelo
processamento adicional dos algoritmos de encriptação e desencriptação. Existe também um
maior aumento no downlink que no uplink, mas em valor absoluto os valores de downlink
continuam inferiores aos de uplink.
É notar que todos os valores medidos são muito baixos relativamente aos valores de
referência. Baseado em testes laboratoriais, a Cisco considerou que valores inferiores a 30 ms
são aceitáveis para voz sobre IP [31]. Provando que os valores obtidos para a Variação de
Latência podem ser considerados negligenciáveis.
75
Figura 5-6 Variação da latência
5.1.5 Pacotes Perdidos, Duplicados e Desordenados
5.1.5.1 Objectivo do teste
Medição dos pacotes perdidos, duplicados e desordenados. Para que uma rede IP tenha um
bom desempenho, qualquer destas métricas tem que ser muito baixa (ver secção 4.6). O
protocolo TCP e SCTP resolvem a questão dos erros, de forma transparente para as camadas
superiores, mas com impacto na taxa de transferência. O protocolo UDP não tem mecanismo
de correção de erros e terão que ser as camadas superiores a corrigir estas situações.
5.1.5.2 Metodologia
Foi utilizada a mesma metodologia do teste da secção 5.1.3
5.1.5.3 Resultado e conclusão do teste
Durante o período de amostragem realizado para o cenário “sem IPsec” e “com IPsec” não
foram detectados pacotes perdidos, duplicados e desordenados. A Tabela 5-5 mostra os
valores medidos no downlink (DL) e uplink (UL).
Pacotes Perdidos [%]
Pacotes Duplicados [%]
Pacotes Desordenados [%]
DL UL DL UL DL UL
Sem_IPSEC_84 0 0 0 0 0 0
Com_IPSEC_84 0 0 0 0 0 0
Sem_IPSEC_1400 0 0 0 0 0 0
Com_IPSEC_1400 0 0 0 0 0 0
Tabela 5-5 Pacotes Perdidos, Duplicados e Desordenados
76
5.2 Testes end-to-end (experiência no utilizador)
Esta secção tem como objectivo apresentar o resultado dos testes realizados para avaliar a
qualidade de serviço percepcionada pelo utilizador num cenário “sem IPsec” e “com IPsec”.
Com este propósito foram utilizadas aplicações normalmente disponíveis ao utilizador.
5.2.1 Ferramentas e aplicações
A Tabela 5-6 enumera os testes realizados e a ferramentas utilizadas
Objectivo do Teste Ferramentas utilizadas Medidas
Estimação da taxa de transferência TCP
FTP Mozzila (modo TCP) e NetperSec
Taxa de Transferência
Estimação da Latência Ping - Internet Control Message Protocol (ICMP)
Round Trip Time (RTT) soma latência nos dois sentidos
Estimação da taxa de transferência UDP
IPerf (modo UDP) Taxa de Transferência
Estimação da taxa de erros
IPerf (modo UDP) Taxa de Erros
Tabela 5-6 Testes aplicacionais
Os testes foram realizados em laboratório, num ambiente controlado, sem tráfego adicional e
com condições óptimas de rádio. A Figura 5-7 mostra o cenário de testes criado para a
realização dos testes descritos na Tabela 5-6.
Figura 5-7 Cenário de testes end-to-end (simplificado)
eNB AEPC
(Core LTE)SecGw
IPSec Tunnel
Laltop
Modem LTE
ServidorFTP
CA
E2E
77
5.2.2 Estimação da Taxa de Transferência TCP
5.2.2.1 Objectivo do Teste
Avaliar o impacto da introdução do IPsec na experiência do utilizador na transferência de
ficheiros, determinando a velocidade de transferência que um utilizador consegue realizar com
uma só sessão de FTP.
5.2.2.2 Metodologia do teste
Estimação da Taxa de Transferência TCP através do protocolo File Transfer Protocolo (FTP),
realizando upload e download dessincronizado de um ficheiro de 1,5 GBytes para cada um dos
seguintes cenários:
Sem IPsec, download e upload do ficheiro;
Com IPsec, download e upload do ficheiro;
Para a realização dos testes foi utilizado o cliente FTP Mozzila (windows) e o servidor FTP
vsftpd (LINUX). Para medir a velocidade de transferência foi utilizada a aplicação NetPerSec.
5.2.2.3 Resultado e conclusão do teste
1) Sem IPsec:
Transferência de downlink: média = 100.7 Mbits/s, máximo 102.4 Mbits/s
Transferência de uplink: média = 50.2 Mbits/s, máximo 51.1 Mbits/s
Figura 5-8 Velocidade medida no NetPerSec, sem IPsec
É de referir que os valores médios e máximos obtidos excederam os valores máximos teóricos
de uplink (100 Mbits/s) e downlink (50 Mbits/s) possíveis. Esta situação pode ser justificada
pelos erros de medida existente neste tipo de aplicações.
78
2) Com IPsec:
Transferência de downlink: média = 96.1 Mbits/s, máximo 100.7 Mbits/s
Transferência de uplink: média = 45.2 Mbits/s, máximo 47.2 Mbits/s
Figura 5-9 Velocidade medida no NetPerSec, com IPsec
A introdução do IPsec reduziu a taxa de transferência. Após análise foi verificado que essa
degradação foi causada pela existência de fragmentação. Depois de ajustados os valores de
MTU para evitar fragmentação, os resultados obtidos foram iguais aos resultados sem IPsec.
3) Com IPsec (MTU optimizado)
Transferência de downlink: média = 101.1 Mbits/s, máximo 101.7 Mbits/s
Transferência de uplink: média = 50.2 Mbits/s, máximo 51.1 Mbits/s
Figura 5-10 Velocidade medida no NetPerSec, com IPsec (optimizado)
79
Na Figura 5-11 é realizado o comparativo entre os três testes realizados
Figura 5-11 Taxa de Transferência TCP - Comparativo
Depois de ajustado os parâmetros de MTU para evitar a fragmentação, os resultados obtidos
com e sem IPsec são idênticos.
5.2.3 Estimação da Latência (RTT)
Através da realização de pings entre o PC cliente e o Servidor é possível calcular a latência
com base no Round Trip Time (RTT). O RTT representa o tempo entre o envio do pacote ICMP
echo request e recepção do ICMP echo reply, o RTT é portanto a soma da latência do uplink e
do downlink.
5.2.3.1 Objectivo do Teste
Calcular o RTT e a perda de pacotes entre o PC cliente e o Servidor num cenário ‘com IPsec’ e
‘sem IPsec’ através da realização de pings.
5.2.3.2 Metodologia do teste
Para cada um dos cenários em estudo foram realizados 100 pings entre o PC cliente e o
Servidor com as seguintes dimensões: 64, 128, 256, 512, 1024, 1500, 1631, 1700.
ping 83.174.60.95 -c 100 -s [packet size]
Exemplo do teste realizado para a dimensão do pacote de 128 bytes:
ping 83.174.60.95 -c 100 -s 120 128 bytes from 83.174.60.95: icmp_seq=1 ttl=125 time=33.7 ms 128 bytes from 83.174.60.95: icmp_seq=1 ttl=125 time=33.8 ms … rtt min/avg/max/mdev = 22.542/28.288/34.369/2.920 m
80
5.2.3.3 Resultado e conclusão do teste
A partir dos dados obtidos na experiência, foram calculados os pacotes perdidos, a média e
desvio padrão do RTT para cada uma das dimensões do ICMP (ping).Tabela 5-7.
PDU ICMP
Enviados
Sem IPsec Com IPsec
ICMP perdidos
Média
() [ms]
Desvio Padrão
() [ms]
ICMP perdidos
Média
() [ms]
Desvio Padrão
() [ms]
PDU 64 100 0 28,24 2,94 0 28,38 3,01
PDU 128 100 0 36,43 2,93 0 36,54 3,01
PDU 256 100 0 37,11 2,92 0 36,53 2,97
PDU 512 100 0 36,35 3,25 0 36,67 3,16
PDU 1024 100 0 36,75 2,95 0 36,55 3,13
PDU 1500 100 0 37,66 3,83 0 37,43 3,47
PDU 1631 100 0 37,74 4,71 0 37,80 4,79
PDU 1700 100 0 37,93 3,59 0 39,29 3,70
Tabela 5-7 RTT (Média e Desvio Padrão)
Figura 5-12 RTT (Média e Desvio Padrão)
Partindo das médias () e dos desvios padrão () obtidos foram traçadas a Função Densidade
de Probabilidade (PDF) e a Função Cumulativa de Probabilidade (CDF) para cada um dos
cenários:
𝑓(𝑥; 𝜇, 𝜎2) =1
𝜎√2𝜋𝑒−
12
(𝑥−𝜇
𝜎)
2
81
A Figura 5-13 mostra a Função Densidade de Probabilidade (PDF) do RTT no cenário “sem
IPsec”
Figura 5-13 RTT PDF (sem IPsec)
A Figura 5-14 mostra a Função Densidade de Probabilidade (PDF) do RTT no cenário “com
IPsec”
Figura 5-14 RTT PDF (com IPsec)
As funções densidade de probabilidade são bastante semelhantes, revelando que ambos os
cenários têm o mesmo comportamento e que a introdução do IPsec não altera o RTT. O
melhor desempenho foi para ping de 64 bytes (valor por defeito do ping) e pior nos casos em
que os pacotes são de maior dimensão. O maior tempo de RTT verificado nos pings com
dimensão superior a 1500 bytes deve-se essencialmente à fragmentação realizada no PC com
MTU limitada a 1500 bytes.
C:\User>netsh interface ipv4 show subinterfaces MTU MediaSenseState Bytes In Bytes Out Interface ------ --------------- --------- --------- ------------- 1500 1 61835950 13447490 Mobile Broadband Connection 1500 5 0 0 Local Area Connection
82
A Figura 5-15 mostra a Função Cumulativa de Probabilidade (CDF) para o RTT “sem IPsec”
Figura 5-15 RTT CDF (sem IPsec)
A Figura 5-16 mostra a Função Cumulativa de Probabilidade (CDF) para o RTT “com IPsec”
Figura 5-16 RTT CDF (com IPsec)
Como era de esperar a Função Cumulativa de Probabilidade apresenta dados semelhantes
para ambos os cenários. 100% das amostras dos pings de 64 bytes, em ambos os cenários,
estão abaixo dos 35 ms. Para as restantes dimensões de pacotes a totalidade das amostras
situa-se abaixo do 60 ms.
Podemos concluir que em termos de RTT end-to-end (PC Cliente – Servidor FTP) as
diferenças entre o cenário “sem IPsec” e “com IPsec” são muitos pequenos e que a dimensão
dos pacotes tem maior impacto na latência que a própria introdução do IPsec. A mesma
conclusão já se tinha verificado nos testes de latência na secção 5.1.3.
É de notar que o RTT obtido através de ping pode apresentar valores por excesso, uma vez
que o ping não tem QoS associado e que algumas máquinas, por protecção a ataques, limitam
a capacidade de processamento deste tipo de pacotes. De qualquer forma o valor da latência
no pior caso foi de 30 ms (RTT = 60 ms, Latência = RTT/2 = 30 ms), valor inferior aos
requisitos apresentados na secção 4.6.2 - QoS no LTE.
83
5.2.4 Estimação da Taxa de Transferência UDP e Erros
Para determinar a taxa de transferência com o protocolo UDP foi utilizada a ferramenta IPerf. O
IPerf é um software de utilização livre desenvolvido originalmente pela National Laboratory
Applied Network Research/Distributed Application Support Team (NLANR/DAST) [32] e que
permite medir o desempenho das rede IP utilizando os protocolos TCP e UDP.
5.2.4.1 Objectivo do Teste
Determinar a capacidade de taxa transferência de dados para diferentes dimensões de pacotes
UDP no cenário “com IPsec” e “sem IPsec” Foi utilizado o IPerf no modo UDP, sem controlo de
fluxo, permitindo testar a máxima capacidade de transferência da rede IP
5.2.4.2 Metodologia do teste
Envio de pacotes UDP (sem controlo de fluxo e correcção de erros) de várias dimensões do
Servidor para o PC com o objectivo de realizar uma análise comparativa entre o cenário com e
sem IPsec. Em termos teóricos a capacidade de transferência da rede está limitada na
interface rádio com 100 Mbit/s no downlink e 50 Mbit/s no uplink.
Configuração no servidor: Envio de 100 Mbit/s em pacotes UDP durante 10 s para cada
tamanho de pacote (64, 128, 256, 512, 1024, 1470, 1700.).
Comando executado no servidor:
iperf -c 83.174.60.69 -u -b 100M -t10 -i 1 –l (tamanho do pacote)
Configuração no PC: Recepção do tráfego enviado pelo servidor no modo UDP.
Comando executado no PC:
iperf -s -u -i 1
5.2.4.3 Resultado e conclusão do teste
Neste cenário há a considerar algumas limitações verificadas durante os testes:
Por limitações de packet rate o servidor só consegue realizar 100 Mbits/s com pacote
superiores a 256 bytes.
A carga nos processadores do PC é sempre muito alta só baixando dos 80% a partir dos
1024 bytes.
Apenas nos testes T5, T6 e T7 em ambos os cenários (com e sem IPsec) podemos
considerar que estamos dentro do limite de capacidade das várias máquinas envolvidas.
84
As tabelas 5-8 e 5-9 mostram os resultados dos testes realizados.
Sem IPsec
Teste Dim.
Pacote [bytes]
Server [Mbit/s]
PC [Mbit/s]
Pacotes Perdido eNB [%]
Pacotes Perdido
SecGW [%]
Pacotes Perdido e2e [%]
Carga no PC
[%]
Útiliz. NIC [%]
T1 64 35 10,8 0 NA 69,1 96 11,53
T2 128 70,3 18 0 NA 74,4 95 19,65
T3 256 100 35 0 NA 65,0 92 35,21
T4 512 100 63,3 0 NA 36,7 97 68,54
T5 1024 100 100 0 NA 0,3 79 99,00
T6 1470 100 100 0 NA 0,2 45 99,00
T7 1700 100 97,3 0 NA 2,7 63 96,25
Tabela 5-8 IPerf sem IPsec
Com IPsec
Teste Dim.
Pacote [bytes]
Server [Mbit/s]
PC [Mbit/s]
Pacotes Perdido eNB[%]
Pacotes Perdido
SecGW[%]
Pacotes Perdido e2e [%]
Carga no PC
[%]
Útiliz. NIC [%]
T1 64 35 10,7 0 0 69,4 91 12,15
T2 128 68,4 18,1 0 0 73,5 87 20,00
T3 256 100 35,3 0 0 64,7 98 35,77
T4 512 100 61,6 0 0 38,4 90 55,00
T5 1024 100 100 0 0 0,4 80 95,00
T6 1470 100 100 0 0 0,3 61 100,00
T7 1700 100 95,8 0 0 4,2 55 97,00
Tabela 5-9 IPerf com IPsec
Como se pode observar em todos os casos houve perda de pacotes end-to-end. Em nenhum
dos casos foi medido perda de pacotes no eNB, SecGW ou em qualquer outro elemento da
rede IP. Analisando a carga do CPU do PC podemos concluir que a perda de pacotes se deve
a limitações no próprio PC. Por limitação de packet rate no servidor ou no PC cliente
(Figura 5-17 e Figura 5-18) apenas se conseguiu atingir as taxas de transferência end-to-end
de 100 Mbit/s (aprox.) nos casos de pacotes com dimensão de 1024, 1470 e 1700 Bytes
(testes 5, 6 e 7).
85
Limitações no CPU do PC não permitem a máxima utilização da network interface controller
(NIC), que se situa abaixo dos 12,5%. Figura 5-17.
Figura 5-17 Carga no CPU e % de utilização da NIC do PC para tramas de 64 bytes
Nos testes 5, 6 e 7, não são verificadas limitações de processamento no CPU do PC (NIC),
sendo a taxa de transferência efectuada á máxima velocidade possível, isto é, 100Mbit/s.
(100% da ligação). Figura 5-18.
Figura 5-18 Carga no CPU e % de utilização da NIC do PC para tramas de 1470 bytes
86
Apesar das limitações verificadas no cenário de testes é possível concluir que, do ponto de
vista do utilizador, o desempenho do sistema é o mesmo “com IPsec” e “sem IPsec”. Os
gráficos das Figura 5-19 e Figura 5-20 mostram que taxa de transferência UDP e a
percentagem de pacotes perdidos end-to-end é idêntica em ambos os cenários.
Figura 5-19 Taxa de Transferência UDP e Pacotes Perdidos (sem IPsec)
Figura 5-20 Taxa de Transferência UDP e Pacotes Perdidos (com IPsec)
87
6 Conclusões e Trabalho Futuro
6.1 Conclusões
A simplificação da arquitectura da rede LTE e a utilização das redes IP como rede transporte
(backhaul) expõem o core network (EPC) e o tráfego a ameaças de segurança até agora
afastadas das redes móveis. Os ataques realizados a partir da própria infraestrutura da rede de
acesso (eNB e IP backhaul) são uma realidade.
O organismo 3GPP recomenda a introdução do IPsec e da Security Gateway como meio para
repor os níveis de segurança. Esta solução trás, no entanto, grandes desafios em termos de
desenho e desempenho de rede.
A realização deste trabalho teve como ponto de partida a análise das falhas de segurança da
rede LTE (secção 2.2) e das políticas de segurança para o LTE definidas nas normas 3GPP
(secção 3.1), tendo como objectivo propor soluções para implementação do IPsec.
Foram propostos 3 possíveis cenários de implementação, tendo em consideração
factores como o desempenho, a segurança, o custo e a simplicidade de gestão da
rede. (secção 3.2).
Foram avaliadas diferentes configurações e parametrização para aplicação do IPsec na
rede LTE. Concluindo-se que no LTE, o IPsec deve funcionar em modo túnel (VPN),
com o protocolo ESP implementando autenticação da origem da informação,
integridade da informação, protecção anti-replay e confidencialidade. A autenticação
dos eNB deve ser automática e realizada através do protocolo IKEv2 e utilizando
certificados de chave pública (secção 2.4). O IPsec possibilita a utilização dos mais
modernos algoritmos criptográficos, como o por exemplo o AES na encriptação
simétrica, o SHA-1 para autenticação e integridade de informação, e certificados x.509
(com assinaturas digitais RSA) para autenticação dos eNB (secção 3.3).
As alterações na arquitectura da rede são consideráveis, sendo necessário implementar
soluções de redundância, criar zonas de segurança e alterar os processos de integração dos
eNB na rede.
As SecGW podem ser integradas de uma forma centralizada (mais perto dos eNB) ou
distribuída (mais perto do core network), dependendo da sua capacidade, da dimensão
da rede LTE e do tipo de backhaul existente (secção 4.2). Em qualquer das
arquitecturas, principalmente na centralizada, devem ser implementadas soluções que
mantenham a resiliência e redundância da rede (secção 4.3).
88
Adicionalmente ao estabelecimento dos túneis e da realização da autenticação dos
eNBs, a SecGW deve ter a funcionalidade de firewall criando diferentes zonas de
segurança e determinando que tipo de tráfego deve transitar entre zonas (secção 4.4).
Devido à dimensão das redes LTE, que em países com a dimensão de Portugal pode
chegar à dezena de milhar de eNBs, a integração e autenticação dos eNB deve ser
realizada de uma forma automática. A autenticação por pre-shared-keys é menos
segura e tem pouca escalabilidade para redes desta dimensão, sendo necessário
realizar autenticação por certificados, obrigando à implementação do PKI (secção 4.5).
De acordo com as conclusões do estudo, foi proposta uma solução para a aquitectura final da
rede. A solução proposta foi implementada e avaliada em laboratório, permitindo concluir que:
É necessário adaptar a política de QoS e garantir que a SecGW e os eNB fazem a
marcação e “tradução” correcta do QoS entre as zonas fronteira ‘IPsec’ e ‘não IPsec’
(secção 4.6). É também necessário ajustar o MTU para valores superiores aos
tradicionais 1500 bytes em toda a cadeia eNB, backhaul e SecGW para evitar a
fragmentação e a resultante degradação no desempenho da rede (4.7).
O impacto no desempenho está muito dependente do perfil de tráfego (IMIX)
considerado. No mínimo espera-se que o encapsulamento total na rede LTE com IPsec
seja de 12%, mas que pode chegar a 43% se consideramos um pacote médio de 400
bytes (4.7).
Para avaliar o desempenho da rede foram, realizados testes em laboratório utilizando o
protocolo TWAMP [RFC5357] e para avaliação da experiência do utilizador final foram
realizados testes aplicacionais. Na avaliação com o protocolo TWAMP, a solução
testada em laboratório, mostrou ter um impacto mínimo no desempenho de rede, que
se pode considerar tolerável tendo em consideração a mais-valia de segurança que é
acrescentada à rede e aos serviços transportados. Nos testes realizados com o
objectivo de percepcionar a experiência do utilizador não foram detectadas diferenças
no desempenho de rede. (secção 5.1 e 5.2).
Em suma, a realização deste trabalho permitiu concluir que a introdução do IPsec é
indispensável para repor os níveis de segurança na rede de acesso LTE, e que apesar ser um
protocolo complexo e exigir grandes alterações na arquitectura da rede, é possível definir
soluções que minimizem esse impacto e mantenham o bom desempenho da rede.
89
6.2 Trabalho Futuro
Como trabalho futuro deve ser tido em consideração o desenvolvimento dos seguintes temas:
6.2.1 Impacto em serviços de tempo real
A avaliação de desempenho realizada neste trabalho incidiu apenas sobre serviços de dados.
Deverá ser avaliado também o impacto da introdução do IPsec em serviços de tempo real
como o VoLTE (Voice Over LTE, serviço de Voz sobre IP no LTE) e jogos online interactivos.
6.2.2 Avaliação de desempenho em ambiente de produção
Os testes de desempenho foram realizados em laboratório, sem tráfego adicional além do
realizado no próprio teste. A avaliação só fica completa com testes realizados num sistema em
carga. Como trabalho futuro, sugere-se a realização de testes controlados em ambiente de
produção.
6.2.3 Extensão do IPsec a redes 2G e 3G
Com o impulso do LTE e a disponibilidade de grande largura de banda no backhaul baseados
em fibra, muitos operadores estão também migrar as redes de 2G e 3G para IP. Apesar de
nestas redes o core network estar mais protegido devido as existência da BSC/RNC, situações
de falha de segurança semelhantes ao 4G podem resultar também nestas redes. A utilização
do IPsec no GSM e no WCDMA deve ser considerado.
6.2.4 Avaliação do IPsec no protocolo IPv6
Apesar da introdução do IPv6 ainda ser residual, a sua implementação será uma realidade no
futuro, o que justifica uma análise.
91
Anexo A - PDU
O Protocol Data Unit (PDU) é um bloco de dados que é transmitido entre duas camada e que
por convecção tem diferentes nomes nas camadas do protocolo TCP/IP.
Camada PDU
1 - Física Bit ou símbolo
2 - Data Link Trama (Frame)
3 - Rede Pacote (Packet)
4 - Transporte TCP segmento, UDP datagrama
5,6,7 - Aplicação Mensagem
Tabela A-0-1 PDU
Anexo B - Tabelas de QoS
B.1 DSCP
Tabela B-0-1 DSCP
Decimal Binário Classe Drop
0 none 0 000000 000 000 Best effort (BE)
cs1 8 001000 001 000 Class Selector (CS)
af11 10 001010 001 010 Assured Forwarding (AF) – Classe 1 Low Drop (gold)
af12 12 001100 001 100 Assured Forwarding (AF) – Classe 1 Med Drop (silver)
af13 14 001110 001 110 Assured Forwarding (AF) – Classe 1 High Drop (bronze)
cs2 16 010000 010 000 Class Selector (CS)
af21 18 010010 010 010 Assured Forwarding (AF) – Classe 2 Low Drop (gold)
af22 20 010100 010 100 Assured Forwarding (AF) – Classe 2 Med Drop (silver)
af23 22 010110 010 110 Assured Forwarding (AF) – Classe 2 High Drop (bronze)
cs3 24 011000 011 000 Class Selector (CS)
af31 26 011010 011 010 Assured Forwarding (AF) – Classe 3 Low Drop (gold)
af32 28 011100 011 100 Assured Forwarding (AF) – Classe 3 Med Drop (silver)
af33 30 011110 011 110 Assured Forwarding (AF) – Classe 3 High Drop (bronze)
cs4 32 100000 100 000 Class Selector (CS)
af41 34 100010 100 010 Assured Forwarding (AF) – Classe 4 Low Drop (gold)
af42 36 100100 100 100 Assured Forwarding (AF) – Classe 4 Med Drop (silver)
af43 38 100110 100 110 Assured Forwarding (AF) – Classe 4 High Drop (bronze)
cs5 40 101000 101 000 Class Selector (CS)
ef 46 101110 101 110 Expedited Forwarding (EF)
6 cs6 48 110000 110 000 Class Selector (CS) - IP routing protocols
7 cs7 56 111000 111 000 Class Selector (CS) - routing protocol keep alive
DSCP
5
1
2
3
4
92
B.2 Assured Forwarding PHB - RFC 2597
Assured Forwarding (AF) Behavior Group
Class 1 (lowest) Class 2 Class 3 Class 4 (highest)
Low Drop AF11 (DSCP 10) AF21 (DSCP 18) AF31 (DSCP 26) AF41 (DSCP 34)
Med Drop AF12 (DSCP 12) AF22 (DSCP 20) AF32 (DSCP 28) AF42 (DSCP 36)
High Drop AF13 (DSCP 14) AF23 (DSCP 22) AF33 (DSCP 30) AF43 (DSCP 38)
Tabela B-0-2 Assured Forwarding PHB - RFC 2597
B.3 IEEE 802.1Q (P-Bit)
P-Bit Prioridade Tipo de tráfego
0 0 (baixa) Background
1 1 Best Effort
2 2 Excellent Effort
3 3 Critical Applications
4 4 Video, < 100 ms latency and jitter
5 5 Voice, < 10 ms latency and jitter
6 6 Internetwork Control
7 7 (alta) Network Control
Tabela B-0-3 IEEE 802.1Q (P-Bit)
Anexo C - Formato Trama ESP
Figura C-1 Trama ESP no modo Túnel
Security Parameters Index (SPI)
Sequence Number (SN)
Initialization Vector IV (optional)
Rest of Payload Data (variable)
IP Datagrama(Header+Payload)
TFC Padding * (optional, variable)
Padding (0-255 bytes)
Pad
Length
Integrity Check Value-ICV (variable)
Padding (cont)
0-7 8-15 16-23 17-31
ESP Header
Payload
ESP Tail
ESP AuthTail
TunnelHeader
IP Header (outer IPs)
(20 bytes)
Encrip
tado
Au
tenticad
o P
elo IC
V
Next
Header
Anti-replay
HMAC
93
7 Bibliografia
7.1 Referências
[1] M. Nohrborg, 3GPP, [Online]. Available: http://www.3gpp.org/technologies/keywords-
acronyms/98-lte. [Acedido em 01 10 2014].
[2] Ericsson Academy, LTE/SAE Sytem Overview, Student Book.
[3] J. Wannstrom, “LTE-Advanced,” 3GPP, [Online]. Available:
http://www.3gpp.org/technologies/keywords-acronyms/97-lte-advanced. [Acedido em 01
10 2014].
[4] J. Wannstrom e K. Mallinson, “Heterogeneous Networks in LTE,” 3GPP, [Online].
Available: http://www.3gpp.org/technologies/keywords-acronyms/1576-hetnet. [Acedido
em 01 10 2014].
[5] 3GPP, “23.401 [4.3.10-Functionality for Connection of eNodeBs to Multiple MMEs],”
[Online]. Available: http://www.3gpp.org/ftp/specs/archive/23_series/23.401/. [Acedido em
27 09 2014].
[6] Stoke, “LTE Security Concepts and Design Considerations, pag 7,” August, 2013. [Online].
Available: http://www.stoke.com/Document_Library.asp.
[7] Heavy Reading’s on behalf of Juniper, “The Security Vulnerabilities of LTE Opportunity
and Risks for Operators,” [Online]. Available:
http://forums.juniper.net/jnet/attachments/jnet/IndustrySolutionsEMEA/326/1/Download%2
0Here%20-
%20The%20Security%20Vulnerabilities%20of%20LTE%20Opportunity%20and%20Risks
%20for%20Operators.pdf. [Acedido em 01 10 2014].
[8] IETF, “RFC5280- Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile.,” May 2008. [Online]. Available:
http://www.ietf.org/rfc/rfc5280.txt.
[9] IETF, “Internet X.509 Public Key Infrastructure - Certificate Management Protocol (CMP),”
[Online]. Available: http://www.ietf.org/rfc/rfc4210.txt.
[10] IETF, “draft-nourse-scep-23 - Simple Certificate Enrollment Protocol,” [Online]. Available:
http://tools.ietf.org/html/draft-nourse-scep-23.
[11] IETF, “RFC 4301 - Security Architecture for the Internet Protocol [Appendix A: Glossary],”
December 2005. [Online]. Available: http://tools.ietf.org/html/rfc4301.
[12] 3GPP, “TS 33.210 Network Domain Security (NDS); IP network layer security. 3.1-
Definitions,” [Online]. Available: http://www.3gpp.org/ftp/specs/archive/33_series/33.210/.
[13] ietf, “rfc4306 - Internet Key Exchange (IKEv2) Protocol,” [Online]. Available:
94
http://www.ietf.org/rfc/rfc4306.txt.
[14] ASMONIA, “Threat and Risk Analysis for Mobile Communication Networks and Mobile”.
[15] 3GPP, “TS 33.210 - [5.4.2 Profiling of IKEv2 ],” [Online]. Available:
http://www.3gpp.org/ftp/specs/archive/33_series/33.210/. [Acedido em 01 10 2014].
[16] 3GPP, “3GPP TS 33.310 V12.0.0 (6.1.1 Common rules to all certificates),” em Technical
Specification Group Services and System Aspects;Network Domain Security
(NDS);Authentication Framework (AF) (Release 12).
[17] 3GPP, “3GPP TS 33.210 - 3G security, Network Domain Security (NDS), [5.3-Profiling of
IPsec],” [Online]. Available: http://www.3gpp.org/ftp/specs/archive/33_series/33.210/.
[Acedido em 01 10 2014].
[18] IETF, “RFC 4835 - Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH),” [Online].
Available: http://tools.ietf.org/html/rfc4835.
[19] IETF, “rfc2328 - OSPF,” [Online]. Available: http://tools.ietf.org/html/rfc2328.
[20] ietf., “rfc3768 - Virtual Router Redundancy Protocol (VRRP),” [Online]. Available:
http://tools.ietf.org/html/rfc3768. [Acedido em 27 09 2014].
[21] IETF, “RFC 3706 - A Traffic-Based Method of Detecting Dead Internet,” [Online]. Available:
http://www.ietf.org/rfc/rfc3706.txt.
[22] V. Bollapragada, M. Khalid e S. Wainner, “IPSec VPN Design,” Cisco, March 2005.
[Online]. Available: http://my.safaribooksonline.com/book/networking/vpn/1587051117.
[23] Juniper, “Understanding Dead Peer Detection,” [Online]. Available:
http://www.juniper.net/techpubs/en_US/junos12.1x46/topics/concept/ipsec-dead-peer-
detection-understanding.html. [Acedido em 01 10 2014].
[24] IETF, “DHCP Options and BOOTP Vendor Extensions,” [Online]. Available:
https://www.ietf.org/rfc/rfc2132.txt. [Acedido em 01 10 2014].
[25] 3GGP, “TS 23.203 Policy and charging control architecture, 6.1.7.2 Standardized QCI
characteristics,” [Online]. [Acedido em 01 10 2010].
[26] W. Stallings, “Chapter 6 - block cipher operation,” em Cryptography and network security
principles and practice, fifth edition.
[27] NIST, “ADVANCED ENCRYPTION STANDARD (AES),” [Online]. Available:
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. [Acedido em 01 10 2014].
[28] Agilent, “LTE and the Evolution to 4G Wireless - Design and Measurement Challenges,”
[Online]. Available: http://www.keysight.com/upload/cmc_upload/All/Security_in_the_LTE-
SAE_Network.PDF?&cc=PT&lc=eng. [Acedido em 01 10 2014].
[29] J. S. J. M. Matthew Mathis, “The Macroscopic Behavior of the TCP Congestion Avoidance
Algorithm,” [Online]. Available:
https://www.cs.cornell.edu/People/egs/cornellonly/syslunch/fall02/ott.pdf. [Acedido em 24
95
09 2014].
[30] IETF, “RFC 5481 - Packet Delay Variation Applicability Statement,” [Online]. Available:
http://tools.ietf.org/html/rfc5481.
[31] Cisco, “Quality of Service Design Overview - QoS Requirements of VoIP,” [Online].
Available: http://www.ciscopress.com/articles/article.asp?p=357102. [Acedido em 01 10
2014].
[32] [email protected] , “iperf,” [Online]. Available: https://iperf.fr/. [Acedido em 01 10 2014].
7.2 Outras referências
7.2.1 Livros
Cryptography and Network Security - Prins and Pract. 5th ed - W. Stallings (Pearson, 2011)
BBS
Applied Cryptography – Bruce Schneier. Second Edition John Wiley Sons [ISBN0471128457]
7.2.2 Normas 3GPP
36 Series - LTE (Evolved UTRA) and LTE-Advanced radio technology
33 Series - Security aspects
TS 33.210 - 3G security; Network Domain Security (NDS); IP network layer security
TS 33.310 - Network Domain Security (NDS); Authentication Framework (AF)
TS 33.401 - 3GPP System Architecture Evolution (SAE); Security architecture
7.2.3 RFCs
RFC 4301 – Security Architecture for the Internet Protocol
RFC 4302 – IP Authentication Header (AH)
RFC 4303 – IP Encapsulating Security Payload (ESP)
RFC 4307 – Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4308 – Cryptographic Suites for IPsec
RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 3706 – A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 4835 – Cryptographic Algorithm Implementation Requirements for Encapsulating Security
Payload (ESP) and Authentication Header (AH)
RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile
RFC 4210 – Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
Internet-Draft – Simple Certificate Enrolment Protocol (SCEP) by Cisco Systems, Inc