Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO TECNOLÓGICO
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Tássio Costa de Carvalho
Arquitetura de Pré-Autenticação Segura com Suporte à QoE
para Aplicações Móveis Multimídia em Redes WiMAX
DM: 11/2009
UFPA – ITEC – PPGEE
Belém – Pará – Brasil
2009
TÁSSIO COSTA DE CARVALHO
Arquitetura de Pré-Autenticação Segura com Suporte à QoE para Aplicações Móveis Multimídia em Redes WiMAX
Dissertação submetida à Banca Examinadora do Programa de Pós-Graduação em Engenharia Elétrica da UFPA para a obtenção do Grau de Mestre em Engenharia Elétrica com Ênfase em Computação Aplicada.
Orientador: Prof. Dr. Kelvin Lopes Dias
DM: 11/2009
UFPA – ITEC – PPGEE
Belém – Pará – Brasil
2009
TÁSSIO COSTA DE CARVALHO
Arquitetura de Pré-Autenticação Segura com Suporte a QoE para Aplicações Móveis Multimídia em Redes WiMAX
Dissertação submetida à avaliação da banca examinadora aprovada pelo colegiado do programa de pós-graduação em engenharia elétrica da Universidade Federal do Pará e julgada adequada para obtenção do grau de mestre em engenharia elétrica com ênfase em computação aplicada.
Aprovada em: 19 de Junho de 2009
____________________________________________________
Prof. Dr. Kelvin Lopes Dias (ORIENTADOR – UFPA)
____________________________________________________ Prof. Dr. Agostinho Luiz da Silva Castro
(MEMBRO – UFPA)
____________________________________________________ Prof. Dr. Eduardo Coelho Cerqueira
(ENGCOMP – UFPA)
____________________________________________________ Prof. Dr. Mauro Margalho Coutinho
(MEMBRO – UNAMA)
VISTO: ____________________________________________________
Prof. Dr. Marcus Vinícius Alves Nunes (COORDENADOR – UFPA)
Aos meus pais pelo apoio,
incentivo e motivação durante todas
as fases da minha vida, me dando
forças incondicionais e
constantemente me mostrando o
caminho correto a ser seguido.
AGRADECIMENTOS
Primeiramente a Deus, por me possibilitar a existência e a vida, sem a
qual nada disso seria possível. Graças a ele e a fé depositada conseguimos
encontrar forças quando precisamos podendo sobrepujar caminhos difíceis.
Agradeço aos meus pais Ipojucan Lopes de Carvalho e Ediléa de Jesus
Costa de Carvalho pelo amor incondicional, pela amizade, pelo carinho, apoio,
incentivo e força que sempre me deram nos bons e maus momentos e aos meus
irmãos Taíssa Costa de Carvalho e Tálles Costa de Carvalho pelas palavras de
carinho e pela motivação. Deus me possibilitou a vida e meus pais me ensinaram
a vivê-la.
Agradeço ao meu amigo e orientador Kelvin Lopes Dias, por ter
acreditado no meu potencial, pela amizade e por ter estado sempre ao meu lado,
me ajudando a trilhar caminhos mais longínquos e a traçá-los de forma correta.
Meus amigos do UCNL (Ubiquitous Computing and Network
Laboratory), em especial ao Jailton, Diego, Thiago, Otávio, Fabrício e Valber
pela amizade e pelo companheirismo.
Aos bons amigos que sempre me apoiaram e me ajudaram seja com
conselhos, dicas ou palavras para que tudo se tornasse possível, em especial a
Aline, Marília, Reinaldo e Renata que sempre me motivaram nos momentos
mais difíceis.
“You may say, I’m a dreamer. But
I’m not the only one. I hope someday you’ll join us. And the world will be as one.” (Jonh Lennon)
RESUMO
O padrão IEEE 802.16 para redes metropolitanas sem fio freqüentemente
conhecido como WiMAX (WordWide Interoperability for Microwave Access)
foi concebido desde o princípio com uma camada de segurança que viabiliza
os mecanismos de autenticação, autorização e contabilização (AAA –
Authentication, Authorization and Accounting) e criptografia. Por outro lado,
a mobilidade proporcionada aos usuários e a possibilidade de mudar de
estação rádio base (BS – Base Station), implica na necessidade que o usuário
realize novamente o processo de autenticação com a nova BS. Este processo
de re-autenticação pode degradar o desempenho das aplicações durante o
handover entre domínios administrativos. Dessa forma, visando garantir a
continuidade de serviço e a segurança na distribuição de conteúdo multimídia
para usuários móveis, esta dissertação propõe uma arquitetura de pré-
autenticação para redes WiMAX, provendo uma política de antecipação de
handover com suporte à micro e macro mobilidade e à Qualidade de
Experiência (QoE – Quality of Experience). A proposta é avaliada por meio de
simulação utilizando o simulador ns-2 (network simulator). O resultados de
desempenho obtidos em termos das métricas de vazão, atraso, PSRN (Peak
Signal to Noise Ratio), SSIM (Structural Similarity Index) e VQM (Video
Quality Metric) ratificaram a eficácia da proposta para prover handover
transparente para aplicações multimídia.
Palavras – chaves: IEEE 802.16, WiMAX, AAA, Segurança, Qualidade de
Experiência (QoE).
ABSTRACT
The IEEE 802.16 standard for wireless metropolitan area networks commonly
known as WiMAX (WordWide Interoperability goes Microwave Access) was
conceived from the beginning with safety layer that makes possible the
authentication mechanisms, authorization and accounting (AAA -
Authentication, Authorization and Accounting) and cryptography. On the
other way, the proportionate mobility to the users and the possibility of
changing of radio base station (BS - Base Station), it implicates in the need
that the user accomplishes again the authentication process with the new BS.
That re-authentication process can degrade the performance of the applications
during the handover among administrative domains. In that way, seeking to
guarantee the service continuity and the safety in the distribution of content
multimedia for the mobile users, this dissertation proposes a pré-authentication
architecture for WiMAX networks, providing a politics of handover
anticipation with support to micro and macro mobility and to the Quality of
Experience (QoE – Quality of Experience). The proposal is evaluated through
simulation using the simulator ns-2 (network simulator). The results of
performance metrics obtained in the metric terms of throughput, delay, PSRN
(Peak Signal to Noise Ratio), SSIM (Structural Similarity Index) and VQM
(Video Quality Metric) ratified the effectiveness of the proposal to provide a
transparent handover multimedia applications.
Keywords: IEEE 802.16, WiMAX, AAA, Security, Quality of Experience
(QoE).
LISTA DE ABREVIATURAS E SIGLAS
AAA Authentication, Authorization e Accounting
AES Advanced Encryption Standard
AK Authentication Key
ASN Access Service Network
ATM Asynchronous Transfer Mode
BS Base Station
BS (QoS) Best Effort Service
BWA Broadband Wireless Access
CA Certification Authority
CBC Cipher Block Chainning
CBC-MAC Cipher Block Chainning Message Authentication Code
CBR Constant Bit Rate
CCM Counter with CBC-MAC
CDMA Code Division Multiple Access
CID Connection Identifier
DCD Downlink Channel Description
DES Data Encryption Standard
DHCP Dynamic Host Control Protocol
DL-MAP Downlink Map
DNS Domain Name System
DSL Digital Subscriber Line
EAP Extensible Authentication Protocol
ErtPS Extended real-time Polling Service
ETSI European Telecommunications Standards Institute
FBSS Fast Base Station Switching
FHMIP Fast Hierarchical Mobile IP
FSM Finite State Machine
GPS Global Position System
GSM Global System for Mobile Communication
HHO Hard Handover
HIPERMAN High Performance Radio Metropolitan Area Network
HO Handover
HSDPA High-Speed Data Packet Access
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
ITU International Telecommunication Union
KEK Key Encryption Key
LOS Line of Sight
MAC Media Access Control
MAC-PDU Media Access Control Packet Data Unit
MAN Metropolitan Area Network
MSHO Macro Diversity Handover
MH Mobile Host
MIMO Multiple Input Multiple Output
MIP Mobile IP
MPLS Multi Protocol Label Switching
MS Mobile Station
MN / NM Mobile Station / Nó Móvel
NLOS Non Line of Sight
nrtPS non real-time Polling Service
NTP Network Time Protocol
OFDM Orthogonal Frequency Division Multiple
OFDMA Orthogonal Frequency Division Multiple Access
PKI Privacy Key Infrastructure
PKM Privacy Key Management
PSNR Peak Signal to Noise Radio
QoE Quality of Experience
QoS Quality of Service
RADIUS Remote Authentication Dial in User Service
RSA Ron Rivest, Adi Shamir, Len Adleman
rtPS real-time Polling Service
SA Security Association
SAID Security Association Identifier
SFID Service Flow Identifier
SS Subscriber Station
SSIM Structural Similarity Index
SSL Secure Socket Layer
SVH Sistema Visual Humano
TEK Traffic Encryption Key
TFTP Trivial File Transfer Protocol
UCD Uplink Channel Description
UL-MAP Uplink Map
UGS Unsolicited Grant Service
UMTS Universal Mobile Telecommunication System
VQM Video Quality Metric
Wi-Fi Wireless Fidelity
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
WMAN Wireless Metropolitan Area Network
SUMÁRIO
1. INTRODUÇÃO 17
1.1 Motivação 17
1.2 Objetivos 20
1.3 Estrutura da Dissertação 20
2. REDES METROPOLITANAS SEM FIO (WIMAX) 22
2.1 Padrão IEEE 802.16/WiMAX 22
2.2 Características Gerais e Aplicações 23
2.2.1 O Padrão e suas Emendas 24
2.2.2 Protocolos e Arquitetura 27
2.2.3 Handover em Redes WiMAX 29
2.2.4 Qualidade de Serviço (QoS) 31
2.3 Resumo do Capítulo 33
3. SEGURANÇA EM REDES WIMAX 34
3.1 Funções MAC e a Conexão com a Rede 34
3.2 Associações de Segurança e o Protocolo PKM 38
3.3 Autenticação 41
3.4 Criptografia 45
3.4.1 Criptografia em Redes WiMAX 47
3.5 Subcamada de Segurança 48
3.5.1 Protocolo PKMv1 (versão 1) 51
3.5.2 Máquina de Estados Finitos (FSM) 54
3.6 Resumo do Capítulo 62
4. TRABALHOS RELACIONADOS 63
4.1 Antecipação de Handover 63
4.2 Considerações de Segurança 65
4.3 Métodos de Pré-Autenticação 67
4.4 Resumo do Capítulo 69
5. ARQUITETURA DE PRÉ-AUTENTICAÇÃO 70
5.1 Qualidade de Experiência (QoE) 70
5.1.1 PSNR 71
5.1.2 SSIM 72
5.1.3 VQM 73
5.2 Arquitetura Proposta 73
5.3 Implementação do Módulo de Segurança 78
5.4 Política de Pré-Autenticação 79
5.5 Resumo do Capítulo 81
6. AVALIAÇÃO DA ARQUITETURA DE PRÉ-AUTENTICAÇÃO 82
6.1 Parâmetros de Simulação 82
6.2 Cenários 83
6.3 Análise das Simulações 85
6.3.1 Cenário 1 85
6.3.2 Cenário 2 87
6.4 Resumo do Capítulo 98
7. CONCLUSÃO 99
7.1 Trabalhos Futuros 100
8. REFERÊNCIAS BIBLIOGRÁFICAS 102
ANEXOS 108
LISTA DE FIGURAS
Figura 1 - Mobilidade de Estações Assinantes (SSs) entre Estações Base (BSs) ___________ 18
Figura 2 - Aplicação do IEEE 802.16/WiMAX para usuários fixos ou móveis _____________ 23
Figura 3 - Desenvolvimento do Padrão IEEE 802.16 ________________________________ 25
Figura 4 - Modelo da pilha de protocolos do Padrão IEEE 802.16 _____________________ 27
Figura 5 – Componentes de uma Arquitetura WiMAX _______________________________ 28
Figura 6 - Hard Handover _____________________________________________________ 29
Figura 7 - Fast Base Station Switching ___________________________________________ 30
Figura 8 - Macro Diversity Handover ____________________________________________ 31
Figura 9 - Conexão com a Rede WiMAX/IEEE 802.16 _______________________________ 38
Figura 10 - Exemplo da comunicação segura em uma rede IEEE 802.16/WiMAX _________ 41
Figura 11 - Dados transmitidos e interceptados na interface aérea pelo usuário C _________ 43
Figura 12 - Relação de confiança necessária para autenticação da SS com a Rede ________ 43
Figura 13 - Autenticação e troca de chaves de criptografia ___________________________ 46
Figura 14 - Criptografia do AES ________________________________________________ 48
Figura 15 - Pilha de protocolo da Subcamada de Segurança __________________________ 49
Figura 16 - Diagrama de fluxo da máquina de estados de autorização __________________ 55
Figura 17 - Diagrama de fluxo da máquina de estados TEK __________________________ 59
Figura 18 - Arquitetura proposta do WiMAX com a utilização do FHMIP _______________ 75
Figura 19 - Sinalização da Arquitetura WiMAX + FHMIP ___________________________ 77
Figura 20 - Diagrama do módulo de segurança da subcamada da camada MAC __________ 78
Figura 21 - Representação gráfica do Cenário 1 ___________________________________ 84
Figura 22 – Representação gráfica do Cenário 2 ___________________________________ 85
Figura 23 - Comparação da vazão da rede com a política e sem a política _______________ 86
Figura 24 - Visualização do Cenário 2 no NAM do NS-2 _____________________________ 87
Figura 25 – Comparação da vazão do Cenário 2 com e sem a arquitetura _______________ 88
Figura 26 – Comparação do número de seqüência do Cenário 2 com e sem a arquitetura ___ 88
Figura 27 - Vazão do Cenário 2 com a arquitetura proposta __________________________ 89
Figura 28 - Número de Seqüência do Cenário 2 com a arquitetura proposta _____________ 90
Figura 29 - Atraso no Cenário 2 sem a arquitetura proposta (Atraso/Frame) _____________ 91
Figura 30 - Atraso no Cenário 2 com a arquitetura proposta (Atraso/Frames) ____________ 91
Figura 31 - Vídeo transmitido sem a arquitetura de pré-autenticação ___________________ 92
Figura 32 - Vídeo transmitido com a arquitetura de pré-autenticação ___________________ 93
Figura 33 - Vídeo transmitido sem a arquitetura de pré-autenticação ___________________ 94
Figura 34 - Vídeo transmitido com a arquitetura de pré-autenticação ___________________ 94
Figura 35 - Comparação dos resultados do PSNR com e sem a arquitetura proposta _______ 96
Figura 36 - Comparação dos resultados do SSIM com e sem a arquitetura proposta _______ 97
Figura 37 - Comparação dos resultados do VQM com e sem a arquitetura proposta _______ 98
LISTA DE TABELAS
Tabela 1 - Índices de qualidade do PSNR _________________________________________ 72
Tabela 2 - Parâmetros de Simulação _____________________________________________ 83
Tabela 3 - Parâmetros de simulação de tráfego de vídeo _____________________________ 84
Tabela 4 - Resultados obtidos diante das métricas de QoE ____________________________ 96
LISTA DE QUADROS
Quadro 1 - Comparação das Principais Emendas do IEEE 802.16 _____________________ 26
Quadro 2 - Aplicações e Qualidade de Serviço (QoS) do WiMAX móvel _________________ 32
Quadro 3 - Matriz de transição de estados da FSM de Autorização _____________________ 55
Quadro 4 - Matriz de transição de estados da FSM TEK _____________________________ 59
Quadro 5 - Relação dos trabalhos relacionados de acordo com seus assunstos chave ______ 69
17
1. Introdução
Este Capítulo descreve a motivação, os objetivos e a organização da Dissertação,
explanando sobre os problemas encontrados durante a autenticação dos usuários
móveis, uma breve introdução sobre o trabalho e a proposta de alternativas para
solucionar os problemas encontrados durante o procedimento de entrada na rede por
parte dos clientes móveis. Introduz assuntos relacionados à mobilidade e a segurança
assim como descreve a proposta desta dissertação.
1.1 Motivação
Sistemas sem fio possuem a capacidade de agrupar vastas áreas geográficas sem
necessitar de um custo elevado de infra-estrutura como nas redes ethernet locais que
necessitam de ligações individuais (Marks et al., 2002). Porém, a segurança é um
assunto de altíssima prioridade e mais ainda importante quando se trata de uma rede
metropolitana sem fio que trafega seus dados através da interface aérea ficando a mercê
mais facilmente de ataques do que em redes tradicionais, fixas e delimitadas apenas ao
contexto físico.
Com o passar dos anos, percebe-se um crescimento notório das redes
metropolitanas sem fio (WMAN – Wireless Metropolitan Area Network), que
proporciona áreas de grande cobertura para um número massivo de usuários em grandes
cidades. Para este tipo de rede, destaca-se o padrão IEEE 802.16 (IEEE Std 802.16-
2001, 2002), que define uma especificação de interface aérea para redes metropolitanas
sem fio de banda larga.
Este padrão ficou popularizado comercialmente como WiMAX (Worldwide
Interoperability for Microwave Access), nome dado pelo fórum responsável pela
certificação e interoperabilidade entre fabricantes de equipamentos que implementam o
padrão IEEE 802.16, bem como, pela definição de uma arquitetura completa para as
operadoras (WiMAX Forum, 2008). O WiMAX é uma arquitetura que defini o IEEE
802.16 na interface aérea.
Quando se trata de redes metropolitanas sem fio, dois conceitos são de extrema
importância no cenário atual: o de mobilidade e o de segurança. O IEEE 802.16 fornece
um conjunto de mecanismos e técnicas de segurança e criptografia para garantir que os
18
dados sejam protegidos de forma segura e que os clientes possam transmiti-los através
de microondas e sob a interface aérea de forma íntegra.
O outro ponto de extrema importância no padrão é o conceito de mobilidade,
buscado cada vez mais nas definições modernas das redes sem fio. Tal conceito permite
ao cliente móvel a possibilidade de se locomover através da área de cobertura de uma
estação rádio base (BS – Base Station) e/ou se re-conectar à outra BS, conforme mostra
a Figura 1.
Figura 1 - Mobilidade de Estações Assinantes (SSs) entre Estações Base (BSs)
Devido ao complexo procedimento de autenticação e criptografia executado pelo
processo de segurança durante a entrada na rede, verifica-se uma sobrecarga que atrasa
re-conexão do usuário sempre que este realiza o handover1.
Por outro lado, além dos aspectos da mobilidade tradicional e da segurança, com
o aumento da demanda por acesso à Internet baseado nas redes de banda larga sem fio,
as operadoras precisam prover continuidade de serviço e suporte a QoS/QoE (Quality of
Service – Qualidade de Serviço/Quality of Experience – Qualidade de Experiência) para
1 Procedimento empregado em redes de computadores e de comunicação para tratar a transição de
uma SS móvel (cliente móvel) de uma célula de cobertura à outra.
19
seus usuários de forma transparente, sobretudo, para o número crescente de usuários
móveis que acessam serviços e aplicações multimídia.
Durante o procedimento de handover pode haver perda de pacotes e dados que
podem prejudicar as aplicações, sobretudo as de tempo real que necessitam de banda
constante para suprir seu tráfego. O suporte adequado à experiência do usuário em
relação a um determinado serviço pode ser um dos diferenciais no mercado competitivo
das operadoras (Carvalho et. al., 2008).
Neste contexto, existe um interesse crescente no projeto de novos protocolos,
mecanismos e algoritmos para prover QoS e QoE para aplicações móveis nas várias
camadas da pilha TCP/IP (Transmission Contol Protocol/Internet Protocol). Na próxima
geração de redes móveis, também conhecidas como 4G (Fourth Generation) ou All-IP
(Fratasi et al., 2006), a integração dos protocolos da camada 2, tais como os protocolos
específicos do padrão IEEE 802, com a pilha TCP/IP, necessita de mecanismos e
algoritmos que garantam handover transparente (Manner & Kojo, 2004).
A utilização das variações do protocolo IP (camada de rede/3) para o
gerenciamento de mobilidade (Akyildiz et al., 2004) permitirá a integração sinergética
entre os procedimentos de gerenciamento de mobilidade específicos de tecnologia,
executados na camada 2, com aqueles que viabilizam a conectividade IP das SSs,
executadas na camada 3. Estudos (Lopes et al., 2004) (Hsieh et al., 2003) sobre
mobilidade IP em redes locais sem fio baseadas no padrão IEEE 802.11 já foram
conduzidos, contudo, a interação entre a camada da pilha requer maiores investigações e
entendimento quanto a sua aplicabilidade em redes metropolitanas sem fio.
Além do gerenciamento de mobilidade, também é de extrema importância no
cenário atual que aspectos de segurança como o processo de autenticação na rede e o de
criptografia de dados, concebidos já desde a camada 2 no padrão IEEE 802.16, auxiliem
na autenticidade, integridade e confiabilidade da comunicação sem impor sobrecargas
em termos de armazenamento, processamento ou sinalização, e atrasos excessivos que
causem impactos na QoE percebida pelos usuários.
A concepção de arquiteturas seguras e com suporte à QoE para aplicações
móveis multimídia são um desafio para o projeto de redes metropolitanas sem fio de
banda larga.
20
1.2 Objetivos
Esta dissertação propõe uma arquitetura de pré-autenticação segura através da
utilização de uma política de antecipação e da inclusão do FHMIP (Fast Handover for
Hierarchical Mobile IP) (Manner & Kojo, 2004) como protocolo para o gerenciamento
de mobilidade das SSs que atravessem subredes IP pertencentes ao mesmo domínio
administrativo ou de domínios distintos.
O mecanismo de antecipação do handover opera em conjunto com os
mecanismos de segurança fornecidos pela camada de controle de acesso ao meio (MAC
– Media Access Control) das redes IEEE 802.16e. A arquitetura proposta neste trabalho
também consiste na utilização do protocolo FHMIP uma extensão do protocolo IP para
tratar de mobilidade inter e intra domínios administrativos. Dessa forma, a utilização do
FHMIP auxilia na provisão de handover transparente em conjunto com a técnica de
antecipação para re-autenticação segura tanto para cenários de micro quanto de macro
mobilidade.
A arquitetura viabilizará o procedimento de handover transparente para
aplicações multimídia, tendo o usuário móvel tanto continuidade de seus serviços
quanto a manutenção do processo de autenticação seguro e confiável, além de diminuir
o sobrecarga durante a autenticação através da proposta de antecipação.
1.3 Estrutura da Dissertação
Este Capítulo apresentou uma breve introdução aos aspectos de mobilidade
encontrados em redes WiMAX e das propostas desta dissertação, trazendo consigo uma
pequena iniciação dos assuntos que serão discutidos posteriormente.
O Capítulo 2 trará conceitos sobre redes metropolitanas sem fio, descrevendo
sua definição, seus padrões homologados, um pouco de seu histórico, suas emendas e
aprofundará o conceito de mobilidade e handover.
O Capítulo 3 explanará sobre o processo de segurança no WiMAX descrevendo
seus principais conceitos, o seu funcionamento, suas camadas, o gerenciamento de
funções MAC e o módulo de segurança do IEEE 802.16.
21
O Capítulo 4 descreverá alguns trabalhos relacionados com o tema proposto por
esta dissertação descrevendo resumidamente seus pontos fortes e criticando seus pontos
fracos.
O Capítulo 5 descreve a arquitetura proposta pela dissertação, o módulo de
segurança implementado para prover o processo de autenticação e criptografia, a
política de pré-autenticação, os elementos da arquitetura e o FHMIP para prover o
procedimento de handover em cenários de micro e macro mobilidade.
O Capítulo 6 descreve a avaliação da proposta analisando os cenários e os
resultados deste trabalho, explicando os resultados obtidos com a utilização da
arquitetura proposta.
Posteriormente se tem as conclusões finais desta dissertação assim como as
referências utilizadas e os anexos correspondentes ao código utilizado no simulador.
22
2. Redes Metropolitanas Sem Fio (WiMAX)
Este capítulo descreve o padrão IEEE 802.16 e o WiMAX, arquitetura baseada
no padrão e que define seus aspectos através da interface aérea. Descreve suas
evoluções, seus protocolos, suas emendas e as duas principais camadas do padrão IEEE:
A camada física (PHY) e a camada de controle de acesso ao meio (MAC – Media
Access Control), subcamada da camada de enlace. Introduz também conceitos de QoS e
mobilidade, além de definir elementos de rede e a arquitetura do WiMAX.
2.1 Padrão IEEE 802.16/WiMAX
Como qualquer tecnologia padronizada, as empresas interessadas no seu sucesso
criaram uma organização para promover sua adoção no mercado e garantir que os
dispositivos de diferentes fabricantes sejam compatíveis entre si. A interoperabilidade é
ocasionalmente difícil de alcançar, pois a maioria dos padrões oferece muitas opções de
execução, deixando coisas abertas à interpretação do fabricante.
Desde a sua publicação em 2002, o padrão possui o nome WiMAX atribuído a
sua definição devido a organização WiMAX Forum (WiMAX Forum, 2008). Além de
promover a tecnologia, eles definem um número de normas para garantir a
interoperabilidade e lançam um programa de certificação WiMAX, onde os interessados
podem certificar os seus equipamentos em testes laboratoriais.
O WiMAX é uma tendência de comercialização de mercado do WiMAX Fórum
(WiMAX Forum, 2008) para descrever tecnologias no IEEE 802.16. O padrão WiMAX
refere-se a um conjunto de capacidades que são susceptíveis a aplicações de experiência
generalizada (Viscaíno, 2008). O WiMAX tem como objetivo estabelecer a parte final
da infra-estrutura de conexão de banda larga, atingindo dessa forma o último quilometro
(Maheshwari, 2006) (Alexa, 2005).
O grupo de trabalho para acesso de banda larga sem fio (Working Group for
Broadband Wireless Access Standard) IEEE 802.16 foi estabelecido em meados de
1999 com o objetivo de preparar especificações formais para o desenvolvimento de uma
rede metropolitana sem fio (WMAN) operando em banda larga. Em outubro de 2001 o
processo de padronização foi finalizado e o padrão publicado em abril de 2002 .
23
Este padrão definia uma interface de WMAN em banda larga que operava em
freqüência de 10 a 66 GHz para aplicações com visada direta, comunicações ponto
multiponto para localizações fixas e baixa mobilidade (limitada à célula da BS).
2.2 Características Gerais e Aplicações
O WiMAX é uma tecnologia de rede de alta velocidade e com controle
distribuído para serviços múltiplos. Uma WMAN em banda larga e com o objetivo de
fornecer uma infra-estrutura com conectividade para o uso doméstico, pontos de acesso,
empresarial, governamental e até em cidades vizinhas, conforme mostra a Figura 2.
Figura 2 - Aplicação do IEEE 802.16/WiMAX para usuários fixos ou móveis
Possui como proposta fundamental o acesso a banda larga sem fio em grande
escala, baixo custo e grande área de cobertura, sem as limitações de distância das
tecnologias de banda larga fixas, como o acesso via linha digital de assinante (DSL –
Digital Subscriber Line) e as redes óticas.
A tecnologia trás consigo diversas diferenças que se delimitam desde a sua
arquitetura até a forma de comunicação. O padrão IEEE 802.16 trouxe também
vantagens como o suporte à Qualidade de Serviço (QoS – Quality of Service), técnicas e
24
algoritmos de segurança mais robustos e eficazes e a premissa de suportar mais usuários
quando comparado às redes sem fio tradicionais (Carvalho et. al., 2008).
Inicialmente, o IEEE 802.16 ratificado em 2001 definia uma transmissão em
banda larga ponto a ponto e focava-se basicamente nas faixas de freqüência entre 10
GHz e 66 GHz, que permitiam apenas transmissão com visada direta (LoS – Line of
Sight).
Posteriormente, passou a se preocupar com cenários mais ideais aos próprios
preceitos da tecnologia como uma WMAN, portanto, com transmissão em banda larga
ponto multiponto e em cenários de grande interferência como regiões metropolitanas
devido à presença de obstáculos como construções e edificações e/ou árvores que
viessem a se tornar barreiras e interferissem, obstruíssem ou mesmo coexistissem com a
zona de comunicação da interface aérea, causando dessa forma uma interface sem
visada direta (NLoS – Non Line of Sight).
2.2.1 O Padrão e suas Emendas
O WiMAX é adotado tanto pelo IEEE quanto pelo grupo ETSI (European
Telecommunications Standards Institute) HIPERMAN (High Performance Radio
Metropolitan Area Network), versão européia para o endereçamento do acesso à
espectros de freqüência abaixo de 11 GHz e possui normas bem definidas ao redor do
mundo (Viscaíno, 2008).
Durante o ano de 2002, surgiram duas emendas adicionais: O IEEE 802.16b, que
tratava de aspectos de QoS como o atraso no recebimento do pacote no destino, a
variação do atraso e os erros, além de permitir o uso de freqüência entre 5 e 6 GHz não
licenciadas e o IEEE 802.16c que garantia um tratamento adicional à interoperabilidade
entre diferentes fabricantes através de protocolos e especificações de testes na
freqüência de 10 a 66 GHz.
Posteriormente à ratificação do padrão e às emendas adicionais de 2002,
formalizou-se a emenda IEEE 802.16a em 2003, que definia uma transmissão em banda
larga ponto multiponto que incluía a utilização do OFDM (Orthogonal Frequency
Division Multiplex) e do OFDMA (Orthogonal Frequency Division Multiplex Access)
como técnicas de transmissão da camada física. A partir deste momento, o padrão
25
também passou a operar nas faixas de freqüências menores, entre 2 e 11 GHz e com
aplicações em NLoS, além de contemplar aspectos de interoperabilidade (Sauter, 2006).
Depois de inúmeras revisões nas emendas anteriores e das inclusões feitas por
estas, surge em junho de 2004 um novo padrão. Uma atualização do padrão IEEE
802.16 que consolida as emendas padronizadas IEEE 802.16a, IEEE 802.16b e IEEE
802.16c fundindo-os em um único padrão, o IEEE 802.16-REVd (IEEE 802.16-2004)
(IEEE Std 802.16-2004, 2004).
No WiMAX “nomádico” (fixo ou nômade, IEEE 802.16REVd) por exemplo,
cada BS permite um raio de cobertura que pode chegar a 50 km, mobilidade com
velocidade máxima de 150 km/h limitado ao raio da atual BS e atingindo taxas de
transmissão de aproximadamente 70 Mbps.
Em dezembro de 2005 surge um padrão para emendar e complementar o padrão
base de 2004, o IEEE 802.16e-2005 [IEEE Std 802.16e-2005, 2005] que trás consigo a
adição de mobilidade ao WiMAX, atingindo grandes velocidades dentro da área de
cobertura das BSs e se necessário transitar entre elas através do procedimento de
handover. As evoluções das emendas podem ser visualizadas na Figura 3.
Figura 3 - Desenvolvimento do Padrão IEEE 802.16
26
O novo padrão opera redes tanto em ambientes LoS quanto em ambientes NLoS
e trás como uma das suas principais melhorias, o suporte a antenas MIMO (Multiple
Input Multiple Output), o que aumenta a confiabilidade do alcance com multipercurso1
e a facilidade para instalação de antenas indoor2 (WiMAX Forum, 2006).
Algumas emendas/padrões surgiram assim como outras ainda estão sendo
estudadas e analisadas. Entre as conhecidas destacam-se: o IEEE 802.16f que introduz
conceitos de redes em malha (redes mesh); O IEEE 802.16g que traz outra evolução
para os conceitos de mobilidade podendo gerenciar procedimentos e serviços de vôo
(aviões); O IEEE 802.16k traz uma ligação (bridging) na camada MAC do 802.16 em
conjunto ao 802.1D; O IEEE 802.16m para altas taxas de transmissão que podem atingir
1 Gbit/s para aplicações fixas; O IEEE 802.16j ou MMR (Mobile Multihop Relay)
encarregado de desenvolver alterações para melhorar o IEEE 802.16e-2005 para
suportar operações multihop relay, entre outros. O Quadro 1 mostra algumas
informações das principais emendas do padrão IEEE 802.16.
Quadro 1 - Comparação das Principais Emendas do IEEE 802.16
IEEE 802.16 802.16 802.16a 802.16d 802.16e Homologação Dezembro
de 2001 Janeiro de
2003 Junho de
2004 Dezembro de
2005 Faixa de
Freqüência 10 – 66
GHz 2 – 11 GHz
2 – 11 GHz
2 – 6 GHz
Condições do Canal para Aplicações
LOS (line-of-
sight)
NLOS (non-line-of-
sight)
NLOS (non-line-of-
sight)
NLOS (non-line-of-sight)
Arquitetura MAC
32 – 134 Mbps
Máximo de 75 Mbps
Máximo de 75 Mbps
Máximo de 15 Mbps
Largura de Banda dos
Canais
20, 25 e 28 MHz
Selecionáveis entre 1,25 e 20
MHz
Selecionáveis entre 1,25 e 20
MHz
Entre 1,25 e 20 MHz e
sub-canais uplink Mobilidade Fixa Fixa e
Nômade Fixa e
Nômade Mobilidade, Handover
Raio da Célula
2 – 5 km
5 – 10 km (podendo alcançar 50 km dependendo do tamanho da antena e a mercê de parâmetros
como o ganho e a potência)
2 – 5 km
1 Enlaces com rotas alternativas para a rede. Percursos alternativos.
2 Antenas de ganho menor e, portanto, voltadas para locais com pequenas áreas de cobertura.
27
2.2.2 Protocolos e Arquitetura
O padrão IEEE 802.16 usa o modelo de camadas de protocolos mostrado na
Figura 4 composto pelas duas principais camadas: a camada MAC (e suas respectivas
subcamadas) e a camada PHY.
Figura 4 - Modelo da pilha de protocolos do Padrão IEEE 802.16
Devido às inúmeras responsabilidades agregadas a camada MAC, ela é dividida
em três subcamadas diferentes: MAC privacy sublayer, MAC common part sublayer e
MAC convergence sublayer (Carvalho et. al., 2008).
A subcamada de privacidade ou subcamada de segurança (MAC privacy
sublayer), localizada acima da camada física, é responsável pelo processo de
autenticação e pela criptografia dos dados do usuário.
Esta subcamada fornece privacidade às estações cliente, através da criptografia
das conexões geradas, protegendo as BSs contra o acesso não autorizado de seus
serviços, através de um protocolo de gerenciamento de chaves, métodos de autenticação
baseado em certificações digitais e criptografia.
A subcamada comum MAC (MAC common part sublayer) é responsável pelo
estabelecimento das conexões da estação assinante e administra do tempo de vida das
conexões individuais. Além disso, a subcamada é responsável pelo empacotamento dos
28
dados do usuário recebidos das camadas mais altas em pacotes que se ajustam a
estrutura da camada física.
A subcamada de convergência (MAC convergence sublayer) é responsável pelo
gerenciamento de protocolos das camadas mais altas em uma interface unificada e
padronizada para entregar dados de usuário à camada 3.
A Figura 5 mostra uma arquitetura de uma rede WiMAX/IEEE 802.16 onde
pode-se observar a presença dos clientes móveis e as estações base que correspondem as
definições do padrão IEEE 802.16 delimitando-se as camadas 1 e 2.
Figura 5 - Componentes de uma Arquitetura WiMAX
Os outros elementos pertencentes às definições do padrão WiMAX engloba os
componentes das duas primeiras camadas e também contempla os elementos de
camadas superiores, apresentando a arquitetura com a presença dos gateways ASN
(Access Service Network), CSN (Connectivity Service Network), Home Agent (HA –
Agente da Rede Sede), servidores AAA, DHCP/DNS (Dynamic Host Control
Protocol/Domain Name System), NTP (Network Time Protocol), entre outros.
A ASN é definida como um conjunto completo de funções de rede que fornece o
acesso a rádio a um cliente WiMAX incluindo um servidor AAA, uma função de
endereçamento DHCP e outros recursos baseados no IP, incluindo o gerenciamento da
29
rede. O CSN é definido como um conjunto de funções de rede que fornece serviços de
conectividade IP para os clientes do WiMAX através da ASN (WiMAX Forum, 2008)
(WiMAX Forum, 2006) (MOTOROLA, 2007).
2.2.3 Handover em Redes WiMAX
O procedimento de handover ou handoff em redes de comunicação pode
apresentar diversas definições. Pode descrever um conceito de mudança de célula, de
freqüência ou de canal. Este trabalho utiliza-se da definição de transição de uma SS
móvel dentro da área de cobertura ou célula pertencente a uma BS à outra. O
procedimento de handover acontece com a desconexão por parte do cliente móvel com
a BS a qual está conectado para que possa detectar o sinal da nova BS para qual migra
e, assim, iniciar um novo procedimento de autenticação na camada 2 e/ou em camadas
superiores, iniciando desta forma, o registro com a nova rede.
As redes WiMAX possuem três tipos de handover permitidos pela mobilidade
da camada MAC: HHO (Hard Handover), FBSS (Fast Base Station Switching) e o
MDHO (Macro Diversity Handover).
O hard handover apresentado na Figura 6 (Silva & Dias, 2007) é o processo pelo
qual a SS móvel perde sua comunicação (desconexão) com a BS atual a fim de migrar a
uma nova BS.
Figura 6 - Hard Handover
30
Durante este processo, há perda de pacotes e de conectividade até que o cliente
seja aceito pela nova rede e possa estabelecer a conexão para a continuidade de seus
serviços. Dos três métodos de handover existentes, o HHO é o único obrigatório.
Como é opcional, o FBSS precisa ser configurado para ser utilizado. Se usado, a
SS móvel terá que rastrear freqüentemente as BSs vizinhas e enviar resultados de
medidas de sinal da rede. A BS e a SS podem concordar no uso de várias estações base
simultaneamente, mantendo uma lista das BSs envolvidas no sistema da rede e do
cliente e as monitorando-as constantemente.
Se esta lista possuir mais de uma BS, a SS móvel informará dinamicamente à
rede dizendo de qual BS gostaria de receber os dados e a estação base dispararia o
procedimento de handover conforme mostra a Figura 7.
Figura 7 - Fast Base Station Switching
É importante ressaltar, que para o FBSS se tornar prático e viável, é necessário
que todas as BSs envolvidas estejam sincronizadas e usem a mesma estrutura de frame1.
Desta forma, todas as BSs operam na mesma freqüência, no entanto, a SS não precisará
1 Um conjunto de quadros ou pacote inteiros que formam uma imagem, vídeo ou arquivo.
31
de re-sincronização com a nova estação base e as interrupções causadas pelo handover
serão minimizadas (Silva & Dias, 2007).
O MDHO é opcional assim como o FBSS e é o tipo mais suave de handover do
WiMAX. Quando este tipo de handover é ativado devido a uma possível falha ou
interferência de sinal, por exemplo, todas as estações base de uma lista conjunto (lista
de BSs) transmitem os dados simultaneamente.
Desta forma, a SS móvel se aproveita do ganho de potência devido à
combinação de energia de rádio-freqüência provocado pelas transmissões das BSs que
operam na mesma freqüência para fortalecer a transmissão.
Se, por acaso, a recepção de alguma estação base da lista conjunto se tornar
fraca, esta BS é imediatamente excluída da lista.
A Figura 8 exemplifica o funcionamento do MDHO.
Figura 8 - Macro Diversity Handover
2.2.4 Qualidade de Serviço (QoS)
Enquanto a camada MAC gerencia e controla as funcionalidades da rede, a
camada física (PHY) fornece os meios materiais para a transferência de dados.
Uma das prioridades do padrão IEEE 802.16 é garantir o fluxo de serviços.
Enquanto algumas aplicações necessitam de largura de banda constante, baixo atraso e
32
nenhuma variação de atraso, outras aplicações são tolerantes ao atraso, embora
necessitem de elevadas largura de banda. O WiMAX utiliza um modelo orientado à
conexão para transferir os dados em conexões unidirecionais e assim garantir QoS. A
conexão é identificada através de um CID (connection identifier), que é parte do
cabeçalho MAC de cada pacote. Para uma sessão IP entre um usuário e a rede, um CID
é usado na direção uplink e o outro para downlink, fazendo com que a rede controle as
propriedades deles independentemente.
Garantir largura de banda máxima é uma das propriedades que pode ser
diferente entre as direções uplink e downlink e o padrão IEEE 802.16e/WiMAX define
cinco classes de QoS para acomodar tais aplicações: UGS (unsolicited Grant service),
rtPS (real-time polling service), ErtPS (Extended real-time polling service), nrtPS (non
real-time polling service) e o BE (best effort service). O Quadro 1 exemplifica as
categorias de QoS.
Quadro 2 - Aplicações e Qualidade de Serviço (QoS) do WiMAX móvel
Classes de QoS Aplicações Especificações QoS
UGS (Unsolicited grant
service)
VoIP
• Vazão máxima sustentada/garantida
• Latência máxima tolerada • Jitter tolerado
rtPS (real-time polling
service)
Fluxo de Áudio ou
Vídeo
(Streaming)
• Vazão mínima reservada • Vazão máxima
sustentada/garantida • Latência máxima tolerada • Prioridade de tráfego
ErtPS (Extended real-time
polling service)
Detecção de Atividade de
Voz
(VoIP)
• Vazão máxima reservada • Vazão máxima
sustentada/garantida • Latência máxima tolerada • Jitter tolerado • Prioridade de tráfego
nrtPS (Non real-time polling service)
Protocolo de Transferência
de Arquivos
(FTP)
• Vazão mínima reservada • Vazão máxima
sustentada/garantida • Prioridade de tráfego
BE (Best effort)
Transferência da Dados, Web Browsing, etc.
• Vazão máxima sustentada/garantida
• Prioridade de tráfego
33
2.3 Resumo do Capítulo
O presente Capítulo apresentou a estrutura e a definição do padrão IEEE 802.16
para redes metropolitanas sem fio. Descreveu as evoluções do padrão, apresentou a
estrutura e a arquitetura preconizada pelo Fórum WiMAX, além das camadas do padrão
e algumas das questões de QoS.
Capítulo 3 discutirá o processo de segurança em redes WiMAX móveis, suas
definições e explicará o processo de entrada na rede, os passos que uma estação
assinante móvel tem que cumprir antes de estabelecer conexão com rede e,
principalmente, o processo de segurança que garante a autenticidade e a autenticação do
cliente.
34
3. Segurança em Redes WiMAX
Este Capítulo descreve o funcionamento dos mecanismos, dos protocolos e das
técnicas envolvidas na segurança das redes WiMAX.
Primeiramente, o Capítulo explica o funcionamento das funções MAC e o
procedimento de entrada inicial na rede. Depois de explica os passos envolvidos e as
mensagens trocadas, explicando as associações de segurança, o protocolo de
gerenciamento de chaves privadas, o processo de autenticação, a subcamada de
segurança e a criptografia pelos quais a estação assinante, deve passar durante o
procedimento inicial ou de re-conexão com a rede.
3.1 Funções MAC e a Conexão com a Rede
A subcamada comum MAC é responsável pela administração da ligação entre a
estação assinante e a estação base. Além disso, possui como função a manutenção da
comunicação. A camada MAC inclui também a funcionalidade de atualizar a
configuração e o software do cliente tal como métodos para re-estabelecer a conexão
com a rede por parte da SS caso o sinal e, conseqüentemente, a conexão sejam perdidos.
A primeira tarefa administrativa da SS após ser iniciada é procurar e conectar-se
a uma rede. Para que a SS possa procurar e postergar uma conexão a uma estação
transmissora de sinal para que faça parte e adentre na rede, ela necessita passar por
diversos passos importantes para o seu reconhecimento e troca de informações por parte
dos envolvidos no processo.
Em um primeiro passo, a SS busca os últimos parâmetros (downlink e uplink) de
sistemas conhecidos e verifica constantemente a interface aérea na procura da última
freqüência conhecida com o objetivo de verificar a existência de algum canal
pertencente a uma rede. Caso o canal não seja detectado, a SS começará uma nova
varredura em busca de possíveis canais a serem utilizados.
A SS reconhece sinais válidos de downlink se for capaz de decodificar com
sucesso o preâmbulo na inicialização dos frames. Decodificando o preâmbulo, é
possível sem informações adicionais obter um padrão de bits conhecidos (Sauter, 2006).
Caso o dispositivo tenha encontrado um canal IEEE 802.16 válido, ele deve
decodificar o início do recebimento dos subframes de downlink para obter os
35
parâmetros atuais do sistema e a configuração do canal de downlink (DCD – downlink
channel description), o DL-MAP (Downlink Map) e o UL-MAP (Uplink Map).
O procedimento é executado novamente caso o cliente perca a sincronização
com a rede e não possa decodificar as mensagens DCD e DL-MAP durante um intervalo
de tempo configurado, que tem como valor limite, 600 ms (Sauter, 2006).
Uma vez que sejam conhecidos todos os parâmetros para o acesso inicial a rede,
a SS inicia o procedimento de ranging, um processo definido no IEEE 802.16, que
permite a SS adquirir corretamente time offset1.
Para adquirir o time offset, a SS envia uma mensagem de requisição de ranging
(RNG-REQ) com uma baixa energia de transmissão no início de um subframe uplink.
O tamanho da área do ranging baseada em contenção e outros parâmetros são
enviados através de broadcast pela mensagem DL-MAP. Se nenhuma resposta é
recebida, a mensagem é repetida com uma maior energia de transmissão. O
procedimento é repetido diversas vezes até que uma resposta seja recebida ou um
determinado número máximo de tentativas seja alcançado.
A mensagem RNG-REQ também contém um parâmetro para a rede com a
modulação e esquemas de código satisfatórios para a SS usar no downlink. A seleção de
valores no lado do cliente é baseada nas condições de recepção downlink que a SS têm
experimentado até o momento.
Quando a rede recebe uma mensagem contendo um pedido de requisição de
ranging, ela a analisa imediatamente checando seu conteúdo, sua intensidade de sinal e
o timeout da mensagem. Desta forma, a rede envia uma mensagem de resposta de
ranging (RNG-RSP) para informar a estação assinante se os ajustes de timeout são
necessários para sincronizar mensagens adicionais de uplink em um tempo inicial exato.
Se a rede fica satisfeita com os ajustes de tempo e de potência durante o período
de ajuste, ela retorna uma mensagem de RNG-RSP contendo um endereço MAC da
estação assinante e os CIDs para downlink e uplink.
Nesta mensagem (RNG-RSP), a rede também informa à SS se a modulação e os
esquemas de codificação foram aceitos ou se prefere usar valores default.
Cada estação assinante é nomeada individualmente por um CID para a
administração da conexão que será usada para trocar mensagens de administração
adicionais para a organização da conexão. Estas conexões também são usadas mais
1 Período de ajuste correto para a rede.
36
tarde para trocar informações de administração entre a SS e a rede, com o objetivo de
manter a conexão.
Na próxima fase do procedimento de estabelecimento de conexão inicial, a
estação base e a estação assinante trocam informações de capacidade básica como a
modulação suportada e os esquemas de código além do suporte ao tipo de operação (full
duplex ou half duplex).
Como a estação assinante tem recebido CIDs para a troca de mensagens de
administração, ela monitora as mensagens de UL-MAP e DL-MAP para a sua
administração de CID e o uso de slots alocados em um frame uplink para enviar a sua
informação de capacidade através de uma SS com uma mensagem de requisição de
capacidade básica (SBC-REQ). A rede responde com uma mensagem de resposta (SBC-
RSP) para confirmar a própria recepção. A mensagem de SBC-RSP também contém as
capacidades básicas suportadas pela rede.
Posteriormente a troca de informações de capacidade, a SS necessita se
autenticar à rede, verificar a sua identidade e começar o processo de criptografia a ser
utilizado no enlace da autenticação.
Isso é feito pela estação assinante através do envio de uma mensagem de
informação de autenticação do gerenciamento de chaves privadas e uma mensagem de
requisição de autenticação (PKM-REQ) para a estação base.
A rede verifica as credenciais e finaliza o processo de autenticação com uma
mensagem de resposta de autenticação (PKM-RSP).
Depois que o processo de autenticação é finalizado, a estação assinante precisa
cumprir um novo passo e necessita se registrar na rede. Isso é feito através do envio de
uma mensagem de requisição de registro (REG-REQ). A rede reconhece a mensagem
devolvendo uma mensagem de resposta de registro (REG-RSP).
Neste momento, a estação assinante é aceita na rede e o fluxo de serviços para a
troca de dados de usuário pode ser estabelecido.
O passo obrigatório final do procedimento é montar um fluxo de serviços e CIDs
correspondentes que serão usados para transferir dados de usuário e ter a SS como
origem e destino, ou seja, transferir dados a partir da estação assinante e em direção a
própria.
Na maioria das situações, os fluxos de serviço são pré-estabelecidos na rede. A
rede inicia o processo enviando uma mensagem de requisição de adição de serviço
37
dinâmico (DSA-REQ) se a BS for capaz de cumprir as exigências de QoS do fluxo de
serviços.
A mensagem contém os CIDs para o fluxo de serviços de dados do usuário, a
identidade do fluxo de serviços (SFID – service flow identifier) e os parâmetros de
serviço do fluxo de serviços.
A estação assinante então se prepara para enviar dados de usuário sobre o fluxo
de serviços e respostas para a mensagem com uma mensagem de resposta de adição de
serviços dinâmicos (DSA-RSP). Para finalizar o processo, a estação base envia uma
mensagem DSA-ACK (confirmação) e o three-way handshake1 é finalizado.
Parâmetros de QoS como a garantia de largura de banda de fluxo de serviços
podem ser mudados pela rede a qualquer momento através de um pedido (requisição) de
mudança de serviços dinâmicos (DSC-REQ) para a estação assinante.
A estação assinante verifica a validade do pedido, faz as mudanças apropriadas
para o fluxo de serviços e reconhece a mudança com a mensagem DSC-RSP.
Novamente, a confirmação é enviada pela rede para a estação assinante (DSC-ACK)
para completar o three-way handshake.
A rede ou a SS podem eliminar o fluxo de serviços a qualquer momento
enviando uma mensagem com o pedido de exclusão dos serviços dinâmicos (DSD-
REQ). Assim, ambos os lados deixam de usar o fluxo de serviços e a transação é
confirmada pelo outro lado enviando uma mensagem DSD-RSP.
A Figura 9 mostra todas as mensagens envolvidas pelos seis passos do processo
de entrada na rede ilustrando-as para uma finalização de um processo de conexão com
sucesso. Quando um cliente móvel ou fixo necessita entrar a uma rede (BS) WiMAX,
este precisa passar por todos os passos aqui descritos para receber uma resposta positiva
na rede que credencie sua autenticação e assim possa usufruir dos serviços.
Caso contrário, sua credencial baseada no certificado X.509 pode ser recusada e
assim este não poderá vir a usufruir dos serviços oferecidos pela rede, necessitando
reiniciar o procedimento de requisição de conexão.
1 Um processo que envolve a troca de três mensagens com o objetivo de garantir o estabelecimento de
uma conexão.
38
Figura 9 - Conexão com a Rede WiMAX/IEEE 802.16
3.2 Associações de Segurança e o Protocolo PKM
As redes WiMAX utilizam um mecanismo de gerenciamento de chaves privadas
PKM (Privacy Key Management) e os certificados digitais, mais especificamente o
certificado X.509 para garantir a autenticidade dos usuários que queiram utilizar os
39
serviços da rede, além da criptografia para proteger suas mensagens de comunicação e
os dados da rede (Pelaez et. al., 2008).
A utilização de técnicas cada vez mais robustas e contendo mecanismos de
segurança mais complexos para garantir a segurança e se precaver dos diversos tipos de
ataques pode gerar sobrecarga e atrasos cada vez maiores no processo envolvido,
prejudicando desta forma a QoS e a QoE das aplicações, do fluxo de serviços e da rede,
sobretudo, quando a SS móvel precisar realizar um procedimento de handover.
As associações de segurança (Security Association – SA) são informações
protegidas pela conexão compartilhada entre duas redes com o objetivo de transmitir
informações de forma segura. Estas informações podem ser compartilhadas também
entre as BSs e um ou mais clientes (Chandra, 2008).
Existem três tipos de associações de segurança: as SAs primárias, as SAs estáticas e
as SAs dinâmicas.
• As associações de segurança primárias são estabelecidas pelas estações
assinantes (pelos clientes) durante o seu processo de inicialização.
• As associações de segurança estáticas são fornecidas pelas BSs.
• As associações de segurança dinâmicas são estabelecidas e eliminadas conforme
o início e o término do fluxo de serviços específicos.
Tanto as SAs estáticas quanto as dinâmicas podem ser compartilhadas por
inúmeras SSs, sendo que cada SA é identificada de forma particular através de um
SAID (Security Association Identifier). As SAs possuem duas chaves de criptografia de
tráfego (TEKs): a chave atual de operação e a nova chave já solicitada para quando a
primeira perder seu tempo de vida.
A base da segurança no WiMAX móvel definida pelo padrão IEEE 802.16e
encontra-se sobre o protocolo PKM. O protocolo gerencia a segurança MAC usando um
controle de criptografia de tráfego, troca de chaves de autenticação e enviando
mensagens seguras em Multicast/Broadcast para a rede.
O protocolo de gerenciamento de chaves privadas provê uma sincronização
segura dos dados relativos a chaves de segurança entre as BSs e as SSs, permitindo
assim, uma forma segura de comunicação entre a rede e o cliente.
O protocolo serve também como uma maneira das estações clientes obterem
autorização para a utilização de serviços junto à estação base e se utiliza de certificados
40
digitais X.509, do algoritmo de criptografia de chave pública RSA (Rivest Shamir
Adleman) e outros algoritmos para que seja assegurada a troca de chaves entre as
estações base e as estações cliente.
Existem dois tipos de certificados digitais X.509. Um deles possui a função de
identificar fabricantes específicos de dispositivos IEEE 802.16, podendo desta forma,
ser assinado pelo próprio fabricante ou por terceiros que possuam tal responsabilidade.
O outro tipo identifica uma estação assinante específica contendo sua chave pública e
seu endereço MAC. Tal certificado é normalmente emitido pelo fabricante do cliente.
A primeira mensagem (opcional), PKM-REQ, envia uma informação de
autenticação, que contém o certificado do fabricante, assumindo que todos os
dispositivos fabricados por ele são confiáveis. Se a estação base receptora desta
primeira mensagem estiver pré-configurada pela política de segurança para permitir
apenas dispositivos previamente conhecidos, esta mensagem será automaticamente
ignorada.
Independente a isso, a segunda mensagem, PKM-REQ novamente, envia uma
requisição de autenticação e possui o certificado X.509 da estação assinante, uma
descrição dos algoritmos de criptografia os quais ele suporta e o identificador básico da
conexão que se tornará o SAID primário do cliente. Esta segunda mensagem é enviada
imediatamente após o envio da primeira (caso seja enviada).
Caso a SS seja autorizada, a BS responde com uma terceira mensagem, PKM-
RSP, com uma resposta de autenticação. Esta mensagem possui a AK (Authentication
Key) criptografada com chave pública da estação cliente (contida no certificado X.509)
e seu respectivo lifetime. Este protocolo assume que somente as estações em questão
possuirão a AK. Após esse período inicial, a SS busca periodicamente uma re-
autorização com a estação base.
A Figura 10 mostra uma comunicação segura entre a SS e a BS interligada a um
servidor RADIUS (Remote Authentication Dial in User Service) para prover o AAA a
uma arquitetura WiMAX em conjunto ao PKM (PKMv1 ou PKMv2) com a criptografia
do RSA (Rivest Shamir Adleman) ou EAP (Extensible Authentication Protocol).
41
Figura 10 - Exemplo da comunicação segura em uma rede IEEE 802.16/WiMAX
Como o cliente é autenticado, o processo previne ataques partindo de estações
assinantes clonadas1. No entanto, como nenhuma certificação digital é fornecida pela
BS e sua resposta é construída utilizando informações públicas, os clientes podem sofrer
ataques partindo de estações base forjadas (clonadas).
3.3 Autenticação
Gerenciadores da rede necessitam de proteção contra o uso fraudulento e
usuários necessitam de um forte esquema de segurança para impedir que terceiros
possam usufruir de suas assinaturas e gerar custos por serviços que não utilizaram.
Além disso, mecanismos de segurança também têm que assegurar que os dados
do usuário não sejam interceptados nem decodificados por qualquer um, além da rede e
do usuário. Semelhante a outros sistemas sem fios, a segurança é alcançada através da
autenticação do usuário durante o procedimento de entrada de rede e mantida
periodicamente durante todo o período de sua conexão. Para proteger os dados
1 Um tipo de ataque comum em redes de computadores onde um usuário malicioso se faz passar por
um cliente (forjando sua assinatura) da rede tentando utilizar de seus serviços.
42
transmitidos, a criptografia é usada através de uma chave individual por usuário (Sauter,
2006) (Dutta et. al., 2008).
Diferentemente de outros sistemas sem fio, o WiMAX utiliza chaves públicas
durante a autenticação e a criptografia a fim de validar as credenciais das estações
assinantes. O método trabalha da seguinte maneira: cada SS recebe de seu fabricante
uma chave pública e uma chave privada. A chave pública da estação que pertence ao
usuário assinante é conhecida pela rede, enquanto os demais dados fundamentais, tal
como a chave privada nunca será transmitida através da interface aérea (Sikkens, 2008).
Dados criptografados com a chave pública só podem ser decriptografados pela
chave privada correspondente. O processo funciona também de forma inversa e jamais
permitirá que os dados sejam criptografados e decriptografados pela mesma chave
utilizada no primeiro passo, ou seja, jamais será permitido criptografar e decriptografar
com a mesma chave. Em outros sistemas diferentes, a estação assinante e a rede não
possuem a mesma chave para a autenticação, mas usam um par de chaves
pública/privada (Sauter, 2006).
Durante um processo de comunicação entre um usuário e uma rede ou mesmo
entre dois usuários, os dados que necessitam ser mandados a outro destino através da
interface aérea são criptografados através do par de chaves pública/privada.
Supondo que um usuário A queira enviar dados de forma segura a um usuário B.
Para que o primeiro usuário criptografe os seus dados de forma a assegurar que apenas o
usuário B terá conhecimento dele, este necessita conhecer um algoritmo de criptografia
comum à rede com o qual o dado será criptografado. Desta forma, o usuário A utiliza a
chave pública do usuário B (chave B), que é conhecida pela rede para criptografar os
dados que serão transmitidos e que só poderá ser lido pelo usuário que possua a chave
privada correspondente, neste caso, o usuário B.
Assim, mesmo que outros usuários ouçam a interface aérea e possam realizar
algum ataque a ponto de interceptar os dados trafegados se passando pelo possível
receptor como um possível usuário C, este não poderá visualizar a mensagem ou o dado
que trafegou pelo canal de comunicação, pois não possuirá a chave privada pertencente
ao receptor de origem ao qual a mensagem foi encaminhada inicialmente, o usuário B.
A Figura 11 (Kurose & Ross, 2008) apresenta uma explicação melhorada para a
descrição e para um melhor entendimento do conceito de chaves públicas/privadas.
43
Figura 11 - Dados transmitidos e interceptados na interface aérea pelo usuário C
Além do par de chaves pública/privada, um certificado X.509 é utilizado pelo
processo de autenticação do WiMAX (Housley et. al., 1999). O certificado é emitido
por uma autoridade certificadora (Certification Authority – CA) e utiliza uma
propriedade bem conhecida pela estação assinante, o endereço MAC como a sua chave
pública. A CA adiciona uma assinatura ao certificado, que é uma cópia criptografada do
certificado X.509 que contém tanto o endereço MAC quanto a chave pública do usuário.
A criptografia da assinatura é executada com a chave privada da CA.
A chave pública da CA é conhecida pela BS da rede que assim pode
decriptografar a assinatura e comparar os valores com o endereço MAC e a chave
pública enviados sem criptografia.
Um hacker em potencial poderia modificar apenas a parte clara do texto do
certificado, mas não a assinatura, pois apenas a chave privada (e não a chave pública) da
CA pode ser usada para gerar uma assinatura.
Se o certificado é modificado, por exemplo, e um invasor tentar associar um
endereço MAC diferente com uma chave pública, a assinatura e a parte clara do
certificado não iriam emparelhar, divergindo e fazendo com que a autenticação falhasse.
Como a chave pública da CA é conhecida, um invasor também poderia verificar
a validade do certificado. Porém, o mesmo só poderia validar um assinante. Ele não
44
poderia usar a informação para adquirir acesso à rede, uma vez que a chave privada do
usuário não é parte do certificado. Até mesmo se o invasor tentasse mudar o MAC do
seu dispositivo para se igualar ao endereço do certificado interceptado, a autenticação
ainda seria inútil, pois a chave privada que pertence ao certificado ainda é desconhecida
e comunicações futuras com a rede ainda falhariam (Sauter, 2006).
Por outro lado, é possível no WiMAX que o fabricante da estação assinante
possua sua própria CA e assine seu próprio certificado. A chave pública do fabricante
da CA é dada ao operador da rede, que estabelece a relação de confiança necessária pelo
certificado (Bogdanoski et. al., 2008). A Figura 12 mostra o processo de confiabilidade
entre uma estação assinante WiMAX, a CA e a rede WiMAX.
Figura 12 - Relação de confiança necessária para a autenticação da SS com a Rede
Durante o procedimento inicial de entrada na rede, a estação assinante envia o
seu certificado X.509 à estação base. A BS confere a assinatura e retorna uma chave de
autenticação (AK – Authentication Key) para o cliente, para a SS.
Para prevenir que a AK seja comprometida, ela é criptografada com a chave
pública da SS que se encontra dentro do certificado.
O entendimento da AK só é possível por parte da estação assinante devido à
própria possuir embutida em si uma chave privada correspondente com a qual poderá
45
decriptografar e ter acesso a mesma. A AK é usada para gerar chaves de criptografia
para toda a troca de dados subseqüentes.
3.4 Criptografia
Uma vez que a AK é recebida da rede como parte do processo de autenticação, a
SS inicia o processo de criptografia. Em um primeiro passo, a rede e a estação assinante
derivam uma chave de criptografia de chaves (Key Encryption Key – KEK) da AK.
No segundo passo, a estação assinante pede a ativação da criptografia. A rede
gera então uma chave de criptografia de tráfego (Traffic Encryption Key – TEK) que é
usada para criptografar a conexão para o usuário. A TEK não é devolvida ao usuário de
forma clara, mas é codificada através do uso da KEK. Como a rede e o cliente estão
atentos a KEK, a SS pode decriptografar a TEK e pode usar isto para criptografar os
dados do usuário no futuro. O tráfego de dados do usuário só pode ser modificado uma
vez que a criptografia esteja correta.
A chave de criptografia tem um lifetime limitado e é de responsabilidade da SS
requisitar uma nova TEK antes que o tempo de vida da atual se esgote.
O padrão IEEE 802.16 especifica dois padrões de criptografia de dados: o DES
(Data Encryption Standard) e o AES (Advanced Encryption Standard).
A TEK pode ser usada como um parâmetro de entrada para uma máquina de
criptografia em um 56-bit DES ou em um AES, sendo ambos capazes de executar um
forte processo de criptografia de dados rapidamente.
Após a autorização e a autenticação sucessiva da estação assinante junto à
estação base, a SS mantém uma máquina de estados TEK para cada um de seus SAIDs.
Periodicamente, uma mensagem de requisição de chave é enviada à BS,
solicitando a renovação da chave em uso.
A cada momento, existem duas chaves ativas, sendo uma a chave atual que está
sendo utilizada com lifetime encurtado devido à utilização e próxima do seu
encerramento e uma chave mais recente já previamente solicitada para suprir o término
do tempo de vida da primeira. A BS responde a requisição da SS com as duas chaves
TEK atuais e seu tempo de vida (Carvalho et. al., 2008)
46
A Figura 13 mostra a troca de mensagens necessária para a autenticação no
primeiro passo e a negociação das chaves de criptografia como um segundo passo,
todos executados através do protocolo de gerenciamento de chaves privadas PKM.
Figura 13 - Autenticação e troca de chaves de criptografia
O padrão IEEE 802.16 especifica dois padrões de criptografia de dados: o DES
(Data Encryption Standard) e o AES (Advanced Encryption Standard).
A TEK pode ser usada como um parâmetro de entrada para uma máquina de
criptografia em um 56-bit DES ou em um AES, sendo ambos capazes de executar um
forte processo de criptografia de dados rapidamente.
Após a autorização e a autenticação sucessiva da estação assinante junto à
estação base, a SS mantém uma máquina de estados TEK para cada um de seus SAIDs.
Periodicamente, uma mensagem de requisição de chave é enviada à BS,
solicitando a renovação da chave em uso.
A cada momento, existem duas chaves ativas, sendo uma a chave atual que está
sendo utilizada com lifetime encurtado devido à utilização e próxima do seu
47
encerramento e uma chave mais recente já previamente solicitada para suprir o término
do tempo de vida da primeira. A BS responde a requisição da SS com as duas chaves
TEK atuais e seu tempo de vida.
Além da renovação periódica das chaves de criptografia, a SS tem também que
executar re-autenticações periódicas devido ao tempo de vida limitado da AK. Tanto a
rede quanto a estação assinante usam uma máquina de estados com cronômetros para
assegurar que tanto a autenticação quanto a criptografia sejam sempre válidas e as novas
chaves sejam obtidas enquanto a atual ainda seja válida dentro de seus respectivos
lifetime.
3.4.1 Criptografia em Redes WiMAX
Como citado anteriormente, o WiMAX/IEEE 802.16 possibilita o uso de dois
algoritmos de criptografia: o DES e o AES.
Enquanto a criptografia do certificado digital é feita pelo RSA de acordo com as
escolha ao qual o padrão possui suporte, a criptografia de dados pode ser executada por
quatro algoritmos: DES em modo CBC (Cipher-Block Chainning), o AES em modo
CCM (Counter with CBC-MAC), o AES em modo CTR (também conhecido como ICM
– Integer Counter Mode) e o AES em modo CBC, sendo este último, o escolhido por
este trabalho devido a sua abrangência no mundo acadêmico proporcionalmente com
seu excelente e complexo algoritmo de criptografia.
O DES funciona em modo CBC, o que indica que, antes de um bloco de dados
ser criptografado, o mesmo realiza uma operação de “ou exclusivo” com o resultado da
criptografia do resultado anterior a ele.
Além do DES que já se fazia presente nas redes Wi-Fi, o padrão do WiMAX
trouxe suporte a outro padrão, mais seguro e mais robusto, o AES em modo CCM
(Counter with CBC-MAC). Este modo combina os modos Counter, que gera blocos de
chaves através da criptografia de valores sucessivos de um contador e do CBC-MAC
(Cipher Block Chainning Message Authentication Code), que utiliza o modo CBC para
a criação de um código de autenticação de mensagens.
O AES pega uma chave de criptografia e um contador como entrada para
produzir um fluxo de bits. O fluxo de bits é um XOR (ou exclusivo) sobre um texto
48
original que sobre a ação do algoritmo de criptografia produz um texto criptografado
conforme mostrado na Figura 17 (Bogdanoski et.al., 2008) (Marks et. al., 2006).
O ponto forte do algoritmo de criptografia AES com 256 bits CBC-MAC
encontra-se no fator dele gerar resultados de saída da criptografia diferentes para cada
vez que determinado texto ou dado necessita ser criptografado, fazendo com que seja
muito difícil mesmo para programadores experientes descobrirem um padrão para
descobrirem seu funcionamento e assim “roubar” a informação. A Figura 14
exemplifica o funcionamento da criptografia executada pelo AES.
Figura 14 - Criptografia do AES
O algoritmo AES é uma recomendação do padrão IEEE 802.16 devido ao
mesmo prover uma proteção mais robusta e forte a roubo de serviço e a transmissão de
dados pela interface aérea de redes móveis sem fio (IEEE Std 802.16e-2005, 2005).
Com a criptografia dos dados, além de prover um procedimento de autenticação
confiável no qual um cliente se autentica em uma rede, o mesmo passa a utilizar seus
serviços e trafegar seus dados de forma mais segura e válida, impedindo ou mesmo
dificultando que terceiros possam interceptar seus dados ou usufruir de serviços
ilegalmente.
3.5 Subcamada de Segurança
Como mencionado anteriormente, a autenticação é garantida durante o
procedimento de entrada na rede e permanece em funcionamento protegendo os dados
transmitidos através da criptografia destes. Isso é permitido devido à implementação da
subcamada de segurança que se encontra na camada dois, citada anteriormente. Embora
49
muitas técnicas de segurança sejam implementadas em diversas camadas de rede, a
autenticação feita pela camada MAC é a mais importante e fundamental quando se trata
de redes WiMAX (WiMAX Forum, 2009) (Ahson & Ilyas, 2008).
A subcamada de segurança provê privacidade, autenticação e confidencialidade
a clientes de redes de banda larga sem fio. Isso se faz através da criptografia das
comunicações que transitam entre a SS e a BS e vice-versa.
Além disso, a subcamada de segurança proporciona operadores com forte
proteção contra o roubo de serviço. A BS protege contra o acesso não autorizado ao
serviço de transporte destes dados assegurando o fluxo de serviços associados pela rede.
A subcamada de segurança emprega um protocolo autenticado de gerenciamento
de chaves cliente/servidor em que a BS, controla a distribuição de chaves para a SS,
assim como provê a criptografia do fluxo de serviços associados através da rede.
Adicionalmente, os mecanismos de segurança básicos são fortalecidos pela autenticação
de dispositivos assinantes baseado na adição do certificado digital para o protocolo de
gerenciamento de chaves (Marks et. al., 2006) (Carvalho et. al., 2008).
A arquitetura dessa subcamada é dividida em dois protocolos: Um protocolo de
encapsulamento responsável pela criptografia dos pacotes de dados através de redes
fixas BWA (Broadband Wireless Access) e o protocolo PKM que permite uma
distribuição segura de chaves de dados da BS para a SS (Marks et. al., 2006). A Figura
15 (IEEE Std 802.16e-2005, 2005) apresenta os componentes de segurança da pilha.
Figura 15 - Pilha de protocolo da Subcamada de Segurança
50
Serviços de criptografia são definidos como um conjunto de capacidades dentro
da subcamada de segurança MAC. Informações específicas do cabeçalho MAC para
criptografia são alocadas no formato do cabeçalho genérico MAC.
A criptografia é aplicada para a carga útil do MAC PDU (Media Access Control
Packet Data Unit) quando se faz necessário.
O cabeçalho genérico MAC não é criptografado. Todas as mensagens de
administração MAC serão enviadas para facilitar o registro, o ranging e a operação
normal do MAC.
O protocolo PKM é responsável tanto pela autenticação mútua quanto a
autenticação unilateral (onde a BS autentica a SS e não o contrário). Ele também
suporta a periódica re-autenticação/re-autorização e atualização de chaves.
O protocolo de administração de chaves privadas usa o EAP (Extensible
Authentication Protocol) (Aboba et. al., 2004) ou o certificado digital X.509 (ITU-T-
X.509, 1998) junto com o algoritmo de chave o pública RSA (Kaliski et. al., 1998) ou
uma sucessão que começa pela autenticação RSA e segue através da autenticação de
EAP. O protocolo usa poderosos algoritmos de criptografia para executar com
segurança a troca de chaves entre a SS e a BS.
O protocolo de autenticação PKM estabelece um segredo compartilhado (AK)
entre a SS e a BS. O segredo compartilhado é usado para assegurar a troca PKM
subseqüente de TEKs. Esse mecanismo de dois níveis para a distribuição de chaves
permite a atualização das TEKs sem incorrer em grandes sobrecargas devido às
operações computacionais intensivas (Marks, 2006).
Uma BS autentica um cliente SS durante a autorização inicial. Cada SS
apresenta suas credenciais: um certificado digital X.509 único emitido pelo fabricante
da SS (no caso da autenticação RSA) ou uma credencial específica de operador (no caso
de uma autenticação baseada no EAP).
A BS associa a identidade autenticada de um cliente SS e autoriza o acesso a
serviços de dados que o mesmo é autorizado acessar. Assim, com a troca de AK, a BS
determina a identidade autenticada do cliente SS e os serviços que o mesmo terá
autorização para acessar. Considerando que a BS autenticou a SS, o cliente fica
51
protegido contra ataques que empreguem clones da SS válida, com ataques como o
masquerading1 (Marks, 2006).
Uma SS usa o protocolo PKM para obter a autorização e o chaveamento do
tráfego da BS. O PKM suporta dois mecanismos distintos de protocolos de autenticação:
• O protocolo RSA (obrigatório no PKMv1 e opcional no PKMv2)
• O EAP (opcional)
Para a execução de testes e dos cenários de simulação na implementação da
subcamada de segurança e da arquitetura de pré-autenticação, este trabalho focou-se no
protocolo RSA que se utiliza do certificado digital X.509 para validar suas SSs clientes.
O protocolo de autenticação PKM RSA usa o certificado digital X.509, o
algoritmo de criptografia de chave pública RSA que liga a criptografia de chave pública
RSA aos endereços MAC das SSs.
3.5.1 Protocolo PKMv1 (versão 1)
Existem dois protocolos do gerenciamento de chave de privacidade permitidas
pelo padrão IEEE 802.16e: PKMv1 e o PKMv2. A segunda versão tem algumas
características melhoradas, como uma nova hierarquia de chaves (Marks, 2006).
Inicialmente o trabalho preocupou-se com o entendimento do protocolo de
gerenciamento de chaves de privadas versão um (PKMv1). Embora já existisse o
protocolo PKMv2 (versão 2), o mesmo ainda encontrava-se em um período de testes no
início da pesquisa e era relativamente recente.
Com isso, o trabalho preocupou-se primeiramente com a implementação do
protocolo PKMv1, que embora seja menos poderoso, era uma opção permitida pelo
padrão IEEE 802.16e (Marks, 2006) (IEEE Std 802.16e-2005, 2005), que possibilitava
a sua escolha e atendia as necessidades da proposta em fornecer a implementação da
subcamada de segurança de forma a prover proteção ao cliente do WiMAX.
A autorização da SS é controlada por uma máquina de estados de autorização e é
um processo onde a BS garante a autenticidade de uma SS. A BS autentica uma SS
1 Tipo de ataque onde uma SS falsa tenta se passar pela original na tentativa de validar sua autenticação
junto à rede.
52
através de uma chave de autenticação (AK), da qual é derivada uma chave de
criptografia de chaves (KEK), utilizadas para a transferência segura das chaves de
criptografia de tráfego (TEK), sendo estas últimas as chaves que criptografam os dados
dos fluxos de serviços.
Uma SS usa o protocolo PKM para obter a autorização e o chaveamento de
tráfego da BS, além de permitir a atualização das chaves e a re-autorização
periodicamente. O protocolo de gerenciamento de chaves, conforme definido e
escolhido para a execução deste trabalho usa os certificados digitais X.509, o algoritmo
de criptografia de chave pública RSA e poderoso algoritmo AES com 256 bits para
criptografar todo o tráfego da rede posterior ao processo de autenticação.
O protocolo PKM segue um modelo cliente/servidor, onde a SS, um “cliente”
PKM, requisita as chaves necessárias, e a BS, o “servidor” PKM responde a essas
requisições garantindo que o corresponde cliente receba individualmente as chaves
correspondentes a ele autorizadas. O protocolo faz uso do gerenciamento de mensagens
MAC com as mensagens definidas anteriormente PKM-REQ e PKM-RSP para
implantar o processo de autenticação da subcamada de segurança definida pelo padrão.
Quando duas partes estabelecem uma ligação, eles são protegidos através de um
conjunto de protocolos que garantem a confidencialidade e o acesso único das partes
autorizadas. A mensagem única entre as duas entidades; nomeadamente a estação
assinante (SS) e a estação base (BS) é feito na camada MAC através da subcamada de
segurança (Li, 2006):
Uma BS autentica o cliente SS durante a troca de autorização inicial. Cada SS
possui um único certificado digital X.509 que é garantido pelo fabricante da estação
assinante correspondente. O certificado digital possui a chave pública e o endereço
MAC da SS.
Quando requisita a AK, a SS apresenta a BS correspondente o seu certificado
digital. A BS por sua vez, verificada a validade do mesmo, usa a chave pública validada
para criptografar a AK e então responder a requisição da SS com a chave de
autenticação. O uso do certificado X.509 previne o emprego de ataques do tipo cloned1.
1 Um tipo de ataque de redes de computadores onde um usuário ou uma estação se fazem passar por
outra.
53
3.5.1.1 Autorização da SS, AK e a TEK
A autorização da SS é controlada pela máquina de estados de autorização e é um
processo da (Kaliski, 1998):
a) BS autenticando a identidade de um cliente SS;
b) BS liberando a SS autenticada uma AK, a qual é derivada gerando uma
KEK;
c) BS provendo a SS autenticada com identidades (por exemplo, a SAID) e
propriedades de SAs primárias e estáticas.
Depois de ser autorizada com sucesso, a SS periodicamente verifica a re-
autorização junto a BS também através do gerenciamento da máquina de estados de
autorização, para que assim possa manter seu status de autorização válido com a BS e
ser capaz de atualizar as TEKs constantemente.
O procedimento de autorização se inicia através de uma mensagem da SS em
direção a respectiva BS com informações básicas da tentativa de autorização que está
por vir.
Logo após o envio da primeira mensagem de informação, a SS envia uma
mensagem de requisição de autorização, solicitando por uma AK assim como uma
SAID identificando as associações de segurança estática da SS que está sendo
autorizada. A requisição de autorização inclui:
a) O certificado X.509 assegurado pelo fabricante;
b) A descrição dos algoritmos de criptografia suportados na requisição da SS;
c) O CID básico da SS. O CID básico é o primeiro CID estático que a BS
assina para uma SS durante o ranging inicial. O primeiro SAID ao CID
básico.
Caso seja validada com sucesso, a SS recebe uma AK criptografada com sua
chave pública assim como seu tempo de vida. A SS recebe também informações sobre
as associações de segurança.
A SS deve atualizar periodicamente a sua AK emitindo uma requisição de
autorização a BS. O processo de re-autorização é idêntico a autorização inicial com
54
exceção à mensagem de informação de autenticação que não deve mais ser enviada.
Depois do processo de autorização inicial e da geração da KEK através da derivação da
AK, um novo procedimento de troca de mensagens se inicia entre as estações
envolvidas.
Depois do processo de autorização, se inicia uma máquina de estados de TEK
separadamente para cada SAID identificada na mensagem de resposta de autorização.
Como discutido no Capítulo 3, a SS requisita nesse momento uma TEK para finalizar a
segurança implementada pela subcamada e começar a transmitir os dados criptografados
logo após a troca de mensagens de registro e da criação do fluxo de serviços da rede.
Em resposta, a TEK é criptografada através de uma KEK derivada da AK
correspondente e assim enviada de volta a estação cliente SS. Através dessa TEK
recebida pela estação assinante, e após os passos de registro na rede onde a SS é
realmente registrada junto à estação base e a mensagens de fluxo de serviços, os dados
trafegados posteriormente serão finalmente criptografados através dessa chave de
criptografia de tráfego postergando e validando a implementação da subcamada de
segurança e o processo de autenticação e autorização proposto pela implementação do
protocolo de gerenciamento de chaves privadas.
3.5.2 Máquina de Estados Finitos (FSM)
Para a devida implementação da máquina de estados de autorização com
objetivo de fornecer a simulação sobre a subcamada de segurança necessitou-se
implementar toda a máquina de estados finitos de autorização tal como a máquina de
estados finitos TEK a fim de postergar a validade dos procedimentos visualizados pelo
padrão e pelos processos envolvidos durante o procedimento de entrada na rede (Marks,
2006).
3.5.2.1 FSM de Autorização
A máquina de estados consiste em seis estados e oito eventos distintos
(incluindo o recebimento de mensagens) que podem engatilhar transições de estados. A
máquina de estados finitos de autorização é representada a seguir na Figura 16 (IEEE
55
Std 802.16e-2005, 2005) em um modelo gráfico do fluxo de estados e em uma matriz de
transição de estados mostrada pelo Quadro 3 (IEEE Std 802.16e-2005, 2005).
Figura 16 - Diagrama de fluxo da máquina de estados de autorização
Quadro 3 - Matriz de transição de estados da FSM de Autorização
Os estados da máquina de estados de autorização são: Start, Authorize Wait,
Authorized, Reauthorize Wait, Authorize Reject Wait e Silent; E os oito eventos distintos
56
que podem acionar transição de estados são: Communication Estabilished, Auth Reject,
Perm Auth Reject, Auth Reply, Timeout, Auth Grace Timeout, Auth Invalid e Reauth.
3.5.2.1.1 Estados
a) Start → É o estado inicial da FSM. Os relógios estão desligados e nenhum
processamento é agendado.
b) Authorize Wait (Auth Wait) → Depois da troca de capacidades, a SS envia tanto
a informação de autenticação quanto a requisição de autorização, esperando pela
resposta.
c) Authorized → A SS recebe a resposta de autorização com uma lista de SAIDs
válidas além de uma AK. A transição neste estado engatilha de uma FSM da
TEK para cada SAID de uma SS.
d) Reauthorize Wait (Reauth Wait) → Devido ao término de uma autorização atual
ou uma autorização inválida por parte de uma SS, esta pode enviar um novo
pedido de autorização junto a BS e esperar por uma resposta.
e) Authorize Reject Wait (Auth Reject Wait) → A SS recebe uma rejeição de
autorização em sua última requisição. Junto ao estado, a SS liga um
temporizador e a mesma permanece em espera e presente no estado até que o
tempo expire.
f) Silent → Este estado acontece quando a SS não é autorizada a se utilizar do
tráfego e usufruir da conexão da rede, caracterizando uma rejeição de
autorização permanente (Perm Auth Reject).
3.5.2.1.2 Mensagens
� Authorization Request (Auth Request) → Requisita uma AK e uma lista de
SAIDs autorizadas.
� Authorization Reply (Auth Reply) → Recebe uma AK e uma lista de SAIDs
estáticas autorizadas. A AK é criptografada com a chave pública da SS.
� Authorization Reject (Auth Reject) → Rejeição da tentativa de autorização.
� Authorization Invalid (Auth Invalid) → A BS envia uma mensagem de
autorização inválida à cliente SS.
57
� Authentication Information (Auth Info) → Essa mensagem contém o certificado
X.509 do fabricante da SS, garantido por uma autoridade externa.
3.5.2.1.3 Eventos
� Communication Established → A máquina de estados de autorização gera este
evento durante a entrada no estado start se o MAC completou a negociação das
capacidades básicas.
� Timeout → Uma retransmissão ou um término do tempo de espera. Geralmente
uma requisição é reenviada.
� Authorization Grace Timeout (Auth Grace Timeout) → Este temporizador inicia
uma quantidade de tempo configurável antes que a autorização atual expire,
sinalizando a SS a re-autorizar antes que sua autorização atual termine.
� Reautorize (Reauth) → Este evento é gerado em resposta a um SNMP (Simple
Network Management Protocol) selecionando um gatilho a um ciclo de re-
autorização.
� Authorization Invalid (Auth Invalid) → É um evento gerado internamente pela
SS quando ocorre uma falha de autenticação ou externamente durante o
recebimento de uma mensagem de autorização inválida, enviada da BS para a
SS.
� Permanent Authorization Reject (Perm Auth Reject) → Código de erro de
natureza permanente, sujeitos ao controle administrativo da própria BS. Pode ser
causado por uma assinatura inválida no certificado da SS, por um fabricante
desconhecido (não possui uma CA que certifique aquele certificado digital).
Quando a SS recebe uma mensagem Perm Auth Reject, a máquina de estados de
autorização se movimenta ao estado Silent.
� Authorization Reject (Auth Reject) → Ao contrário da rejeição permanente, a
rejeição de autorização não indica rejeição completa. Pode significar apenas uma
falha devido a um tempo de espera ou uma transição pelo estado Auth Reject
Wait.
Os seguintes eventos são enviados pela máquina de estados de autorização para
a máquina de estados TEK.
58
� [TEK] Stop: Enviado pela FSM de autorização para uma FSM TEK ativa para
terminar o FSM e remover o material das chaves da correspondente SAID da
SS.
� [TEK] Authorized: Enviado pela FDM de autorização para uma FSM TEK
válida, porém, não ativada ainda.
� [TEK] Authorization Pending (Auth Pend): Enviado pela FSM de autorização
para uma FSM TEK específica para o lugar de uma FSM TEK em um estado de
espera até que a FSM de autorização possa completar sua operação de re-
autorização.
� [TEK] Authorization Complete (Auth Comp): Enviado pela FSM de autorização
pela FSM TEK na Operational Reauthorize Wait (Op Reauth Wait) ou ao estado
Rekey Reauthorize Wait (Rekey Reauth Wait) para limpar o estado de espera
iniciado pela FSM TEK no evento de pendência de autorização.
3.5.2.2 FSM TEK
A máquina de estados TEK consiste em seis estados e nove eventos distintos
(incluindo o recebimento de mensagens) que podem engatilhar a transição de estados.
Assim como na máquina de estados de autorização, a máquina de estados TEK é
representada tanto em um modelo gráfico do fluxo de estados demonstrado pela Figura
17 (IEEE Std 802.16e-2005, 2005) quanto em uma matriz de transição de estados
representada pelo Quadro 4 (IEEE Std 802.16e-2005, 2005).
Os estados da máquina de estados TEK são: Start, Op Wait, Op Reauth Wait,
Op, Rekey Wait e Rekey Reauth Wait; E os nove eventos distintos que podem acionar
transição de estados são: Stop, Authorized, Auth Pend, Auth Comp, TEK Invalid,
Timeout, TEK Refresh Timeout, Key Reply e Key Reject.
59
Figura 17 - Diagrama de fluxo da máquina de estados TEK
Quadro 4 - Matriz de transição de estados da FSM TEK
60
3.5.2.2.1 Estados
a) Start → É o estado inicial da FSM. Os relógios estão desligados e nenhum
processamento é agendado.
b) Operational Wait (Op Wait) → A máquina de estados TEK envia a sua
requisição inicial (Key Request) por um material de chaveamento de SAIDs e
espera pela resposta da BS.
c) Operational Reauthorize Wait (Op Reauth Wait) → É um estado de espera da
máquina de estados TEK que ocorre enquanto a máquina de estados de
autorização está no meio do ciclo de re-autorização.
d) Operational → A SS tem um material de chaveamento válido para a SAID
associada.
e) Rekey Wait → O temporizador da atualização de TEK expirou e a SS requisitou
uma atualização de chave para esta SAID. É importante ressaltar que a mais
nova das duas chaves ainda não está expirada e ainda pode ser usada na
criptografia e descriptografia dos dados.
f) Rekey Reauthorize Wait (Rekey Reauth Wait) → O estado de espera da máquina
de estados TEK caso a mesma possua um material de chaveamento de tráfego
válido, tenha uma requisição pendente para o último material de chaveamento e
a máquina de estados de autorização inicie um ciclo de re-autorização.
3.5.2.2.2 Mensagens
� Key Request → Requisita uma TEK para a uma SAID correspondente.
� Key Reply → Reposta da BS trazendo consigo dois conjuntos ativos de material
de chaveamento de tráfego para a SAID solicitada.
� Key Reject → Reposta da BS para a SS com o propósito de indicar que a
respectiva SAID não é mais válida e que nenhuma chave será enviada.
� TEK Invalid → A BS envia esta mensagem a SS se for determinado que a SS
criptografou algum dados com uma TEK inválida.
61
3.5.2.2.3 Eventos
� Stop → Enviado pela FSM de autorização para uma FSM TEK ativa e remove o
material de chaveamento de chaves correspondente das chaves da SS.
� Authorized → Enviado pela FSM de autorização para uma FSM TEK inativa
para notificar a mesma do sucesso no processo de autorização.
� Authorization Pending (Auth Pend) → Enviado pela FSM de autorização para a
FSM TEK para colocar a mesma em estado de espera enquanto a FSM de
autorização completa o processo de re-autorização.
� Authorization Complete (Auth Comp) → Enviado pela FSM de autorização para
a FSM TEK nos estados Operational Reauthorize Wait ou Rekey Reuthorize
Wait para limpar o estado de espera iniciado pelo evento prioritário
Authorization Pending.
� TEK Invalid → Este evento é ativado tanto pela descriptografia lógica do pacote
de dados de uma SS ou pelo recebimento de mensagens inválidas TEK da BS. O
pacote de dados da descriptografia lógica da SS dispara um evento TEK Invalid
caso reconheça a perda de sincronização da chave TEK entre si mesma e a
criptografia da BS.
� Timeout → O temporizador de uma tentativa termina. Normalmente, a
requisição particular é retransmitida.
� TEK Refresh Timeout → Espera o temporizador TEK estourar. Este evento
temporizador sinaliza a máquina de estados TEK para garantir que uma nova
requisição de chave esteja a caminho para atualizar o material de chaveamento.
A atualização do temporizador é um conjunto de opções configuráveis durante o
tempo (TEK Grace Time) antes do término da TEK recebida pela SS mais
recentemente.
Os parâmetros de configuração Authorize Wait Timeout (Auth Wait Timeout),
Authorization Grace Timeout (Auth Grace Timeout) e Authorize Reject Wait Timeout
(Auth Reject Wait Timeout) pertencentes à máquina de estados de autorização, assim
como os parâmetros de configuração Operational Wait Timeout, Rekey Wait Timeout e
TEK Grace Time pertencentes à máquina de estados TEK utilizam valores default
62
definidos pelo próprio padrão IEEE 802.16e (Marks, 2006) e serão utilizados desta
forma nos cenários executados a seguir em simulador.
3.6 Resumo do Capítulo
Esse capítulo abordou assuntos relacionados à segurança encontrada no padrão
WiMAX em conjunto ao padrão IEEE 802.16e no qual o mesmo é baseado. Mostrou o
funcionamento das funções MAC voltadas ao processo de entrada na rede por parte de
uma SS que tenta receber o sinal de uma BS e todo o procedimento que tem de ser
transcorrido, demonstrando os passos e as mensagens trocadas assim como as suas
funções para que usuário usufrua da conexão/conectividade.
Descreveu a idéia das associações de segurança e definiu o PKM, responsável
pelo processo de autenticação em uma rede WiMAX, descrevendo a existência da
certificação X.509, dos algoritmos de criptografia e da subcamada de segurança.
O Capítulo 4 mostrará alguns trabalhos relacionados a esta dissertação com
temas pertinentes ao handover, a segurança e a pré-autenticação, resumindo-os,
criticando seus pontos fracos e enaltecendo seus pontos importantes.
63
4. Trabalhos Relacionados
Esse capítulo descreve alguns dos trabalhos relacionados encontrados durante a
pesquisa desta dissertação. Os trabalhos são agrupados em: Mobilidade Transparente
em Redes Sem Fio, Considerações e Métodos de Segurança em Redes Sem Fio e
Métodos de Pré-Autenticação e Segurança são demonstrados em uma tabela organizada
ao término deste.
Os tópicos fazem menção e resumem um pouco de cada trabalho, mostrando de
maneira sucinta e direta as conclusões básicas assim como algumas críticas.
4.1 Antecipação de Handover
No trabalho (Li et. al., 2006), os autores desenvolvem um esquema de handover
sem perdas para o padrão IEEE 802.16e baseado em redes de acesso em banda larga
sem fio e comumente conhecidas como redes WiMAX. Através de um esquema que
minimiza o atraso do handover e elimina a perda de pacotes durante o mesmo através da
integração eficiente dele nas camadas MAC e de rede, resultados de simulação
demonstram que o esquema proposto permite uma entrega de pacotes livre de perdas e
sem a ocorrência da duplicação dos pacotes impedindo um aumento significativo da
vazão do sistema.
O trabalho propõe um esquema de handover transparente de micro mobilidade
para o WiMAX. Para isso, consideram inicialmente algumas variáveis. Primeiramente,
o handover da camada MAC e o handover da camada de rede devem ser integrados para
minimizar o impacto no desempenho do serviço. Considerando que o mecanismo
proposto progrida, pode-se evitar a perda de pacotes e reduzir o atraso do HO.
De acordo com as informações das BSs vizinhas recebida pela sua atual BS, a
SS inicia um procedimento de seleção de célula devido à escolha de seu próximo ponto
de acesso de acordo com sua mobilidade atual. A BS alvo recebe uma mensagem da BS
atual do SS e desta forma o handover pode ser iniciado antes da queda de conectividade
para uma possível re-conexão. Com isso, a MS pode usufruir normalmente de seus
serviços e o atraso durante o procedimento de handover é reduzido devido as duas BSs
terem se comunicado previamente e antecipado o procedimento do SS. Além disso, a
perda de pacotes é inibida já que o procedimento é antecipado.
64
Os autores de (Li et. al., 2006) validam sua proposta através do network
Simulator (ns-2) e provam que sem o método proposto haveriam diversas perdas de
pacotes sempre que a SS tentasse migrar de células correspondentes as BSs, no entanto
com o mecanismo proposto, não existe perda de pacotes e a vazão se mantém ativa e
constante.
Em (Huang et. al., 2007), os autores propõem um esquema de reserva de largura
de banda baseado no cross-layer1 para reduzir a probabilidade de terminação forçada
dos handovers multimídia em redes WiMAX móveis 4G. O esquema proposto adota um
modelo de predição de mobilidade probabilístico para estimar a largura de banda
necessária em células vizinhas.
Os resultados de simulação mostram que o esquema proposto pode alcançar um
desempenho superior aos representativos esquemas de reserva de largura de banda
presentes na literatura quando as métricas do desempenho são medidas em termos da
probabilidade de terminação forçada dos handovers, a probabilidade de bloqueio da
chamada para as novas conexões e utilização da largura de banda.
A predição de mobilidade proposta considera um cálculo com base na
probabilidade da SS se locomover para fora da área de cobertura da célula da atual BS
em direção a qualquer célula de uma BS que circunda a primeira. Com base em
cálculos, os autores presumem o caminho que a SS irá percorrer e para qual célula de
cobertura de determinada BS ele se deslocará. Assumindo que os padrões de movimento
de uma SS são exponencialmente distribuídos e com base na probabilidade da função de
densidade do movimento de uma SS em decorrência da distância e do tempo, a BS
origem é informada sobre a necessidade de reserva de largura de banda para as
aplicações da SS que está a caminho, permitindo desta forma a sua predição.
Através de simulações, os autores de (Huang et. al., 2007), comprovam que o
esquema proposto de predição de mobilidade probabilístico baseado no esquema de
reserva de largura de banda é superior a esquemas de banda fixa e esquemas sem a
reserva de largura de banda.
Já em (Junior et. al., 2008), os autores propõem uma nova arquitetura que integra
a tecnologia de acesso WiMAX com os protocolos IP móvel e MPLS móvel assim
como um algoritmo para prover o handover de forma transparente e com isso evitar a
perda e o atraso dos pacotes, garantindo desta forma a qualidade de serviço de
1 Esquema que permite que diversas camadas interajam entre si e compartilhem informações para
otimizar a alocação de recursos e melhorar o desempenho da rede.
65
aplicações de tempo real baseada em tráfego CBR (Constant Bit Rate) sempre que a SS
migrar entre BSs.
Para agilizar o roteamento no backbone e dar suporte à mobilidade das SSs, o
protocolo MPLS móvel foi implementado em todos os roteadores da topologia e nas
pontas da tecnologia IEEE 802.16e (Junior et. al., 2008). O algoritmo antecipa o
handover das SSs baseando-se em informações passadas pelo GPS que trazem consigo
dados referentes à velocidade e a intensidade do sinal em relação à atual BS
determinando o momento. Através destes dados, é possível prever quando um
procedimento de handover é iminente e pode-se desta forma disparar de forma
antecipada o processo de handover.
Os autores de (Junior et. al., 2008) validam sua proposta através de simulações
no network simulator (ns-2) e provam a eficácia do algoritmo utilizado para antecipar o
handover de forma transparente utilizando a arquitetura WiMAX/MPLS móvel e além
do IP móvel.
Embora em (Li et. al., 2006), (Huang et. al., 2007) e (Junior et. al., 2008) se
façam presente simulações que buscam o esquema de antecipação de handover e levem
em consideração o procedimento de entrada, eles pecam por uma validação maior sobre
o procedimento de segurança e da troca de chaves que em muito poderia contribuir com
o atraso dos procedimentos avaliados.
Simulações baseadas no IEEE 802.16e necessitam de técnicas de autenticação e
para que os trabalhos acima mencionados fossem mais completos, estes deveriam ser
avaliados através de protótipos matemáticos. Isso pode contribuir para a degradação do
procedimento de handover inclusive prejudicando qualquer processo de re-autenticação.
O trabalho (Huang et. al., 2007) não considerou simulações mais robustas
quanto ao número de usuários móveis. O trabalho (Li et. al., 2006) não abrangeu
aspectos de variações de mobilidade para as SSs que foram demonstrados em (Junior et.
al., 2008) para uma exemplificação mais real e em maior escala.
4.2 Considerações de Segurança
Em (Xu et. al., 2006) tem-se uma pesquisa e uma visão geral do padrão IEEE
802.16-2004 a respeito da resolubilidade dos diversos problemas descobertos e de
falhas pertinentes quando se trata de aspectos de segurança.
66
Os autores fazem uma avaliação do padrão, firmando-se principalmente na
camada MAC e com maior foco na subcamada de segurança. Eles avaliam as falhas de
segurança presentes no padrão assim como em alguns trabalhos relacionados ao
assunto, ilustrando possíveis perigos para os protocolos de autenticação e de
administração de chaves.
Após a pesquisa na área, os mesmos propõem algumas melhorias e possíveis
soluções para prevenir problemas de segurança assim como um protocolo de handover
seguro que poderia ser utilizado futuramente pela mobilidade advinda do protocolo
IEEE 802.16e.
O trabalho avalia o procedimento de autenticação mostrado no padrão baseado
no gerenciamento de chaves privadas e na certificação X.509 para garantir o processo
de autenticidade de uma SS. Eles citam alguns possíveis ataques como o replay attack1
que pode interceptar uma mensagem de autenticação de uma SS válida fazendo com que
uma BS possa negar requisições de autenticação e serviços. Para isso, eles propõem
uma possível solução com a inclusão de um marcador de tempo junto à mensagem de
autenticação com o objetivo de garantir o processo e coibir qualquer repúdio.
Os autores do (Xu et. al., 2006) propõem um handover rápido (fast handover)
seguro e com suporte ao protocolo PKMv2 além de prevenir muitos ataques
mencionados, além de fazer uma recomendação quanto a uma maior preocupação nos
assuntos relativos a segurança antes de padronizá-los.
No trabalho (Deininger et. al., 2008), os autores preocupam-se nas diferentes
vulnerabilidades de segurança encontradas no padrão IEEE 802.16e assim como
mostrar possíveis soluções para eliminá-las. Essas vulnerabilidades são as
possibilidades de forjar mensagens fundamentais em operações multicast e broadcast,
algumas mensagens não autenticadas que são suscetíveis a falsificação e a
administração de comunicação não criptografada que revelam importantes informações
de administração.
As vulnerabilidades citadas encontram-se sobre algumas mensagens que não são
cobertas por nenhum mecanismo de autenticação e não possuem nenhuma proteção de
integridade devido à ação de algum algoritmo hash, ficando, portanto, a mercê de
alguns ataques. As criticas situam-se basicamente sobre as mensagens enviadas em
broadcast para a conexão e sobre a possibilidade de SSs que compartilham chaves
1 É uma forma de ataque em que uma transmissão de dados válida é atrasada ou repetida de forma
fraudulenta ou maliciosa por um terceiro usuário que possui o objetivo de interceptar dados.
67
poderem forjar mensagens e gerar dígitos de autenticação válidos, como por exemplo,
mensagens de identificação de tráfego, mensagens de identificação dos vizinhos, entre
outras.
Para solucionar o problema, eles propõem um processo de autenticação das
mensagens enviadas durante o gerenciamento de conexão básico ou primário através de
dígitos HMAC ou CMAC. Através da criptografia da administração da comunicação,
consegue-se resolver as vulnerabilidades que existem desde a versão do padrão.
Além disso, os autores de (Deininger, 2008) apresentam três soluções para
prevenir o abuso de chaves no algoritmo de re-chaveamento multicast e broadcast:
soluções baseadas em unicasting, criptografia assimétrica e encadeamento hash (hash
chaining). Gerar chaves de criptografia de tráfego em um hash chain é uma solução
rápida que não introduz muita sobrecarga.
Os trabalhos (Xu et. al., 2006) e (Deininger et. al., 2008) se preocupam com a
questão de segurança nas redes do padrão IEEE 802.16, definindo seu funcionamento e
criticando partes de algumas das possíveis vulnerabilidades encontradas.
Porém, (Xu et. al., 2006) e (Deininger et. al., 2008) poderiam se fixar mais em
algumas mensagens do processo de entrada na rede bem como fazer alguma simulação
para validar de melhor forma a sua pesquisa embora mostre bastante do funcionamento
do processo definido pelo padrão IEEE 802.16. No entanto, o (Deininger et. al., 2008)
possui lógica bem fundamentada diante do funcionamento de proteção, que é inexistente
sobre algumas mensagens, o que deixam a mercê que atacantes externos possam se
aproveitar de tais vulnerabilidades.
4.3 Métodos de Pré-Autenticação
O trabalho (Sun et. al., 2007) se firma sobre o surgimento e a presença do padrão
IEEE 802.16e que tinha a extensão da mobilidade antes não prevista pelo seu
antecessor. Com a inclusão da mobilidade, considerou-se a possibilidade do handover
por parte das estações assinantes assim como o custo de energia e a latência da
consideração de tal processo.
Os autores propõem esquemas teóricos para prover métodos diferentes para
garantir um procedimento de autenticação seguro e eficiente, um esquema de pré-
autenticação para redes WiMAX.
68
O esquema proposto integra o framework PKI (Privacy Key Infrastructure) aos
métodos já existentes e definidos no padrão IEEE 802.16e. A criptografia dos dados do
padrão provê a confidencialidade dos mesmos assim como os certificados digitais
provêem a confidencialidade das mensagens. Com base nisso, o esquema proposto é
baseado principalmente nas propriedades de segurança importantes do PKI.
Após isso, o trabalho faz uma discussão sobre a proposta e analisa a sua
eficiência quando aplicado sobre cenários com procedimentos de handover em macro
mobilidade e entre redes ASN diferentes (redes de acesso a serviços para o
gerenciamento eficiente do tráfego da rede e suporte a serviços avançados), provendo
desta forma um procedimento de re-autenticação seguro e rápido.
O trabalho (Sun et. al., 2007) tem uma proposta interessante para prover um
esquema de handover com re-autenticação rápida, mas não valida sua proposta com
nenhuma simulação ou funções matemáticas além de não prover uma avaliação as
métricas de QoS e QoE. Ele não verifica também os atrasos encontrados nem permite
handover em micro mobilidade, limitando-se apenas a fundamentações teóricas de
macro mobilidade.
O trabalho (Hur et. al., 2008) descreve a falta de suporte por parte do
gerenciamento de chave baseado no EAP se torna o principal impedimento a realização
de um handover seguro e eficiente em redes WiMAX móveis IEEE 802.16e.
Os autores descrevem uma visão geral dos procedimentos de handover baseado
no EAP do padrão IEEE 802.16e, determina a sua segurança e analisa as suas falhas,
propondo possíveis soluções para o handover seguro.
Para reduzir o delay associado com o re-estabelecimento da SA (Security
Association) muitas arquiteturas de rede incluindo o grupo de trabalho do IEEE
802.16e, além de muitos esquemas como em (Xu et. al., 2006) têm sido escolhidos para
transferir as chaves de segurança de uma BS a próxima. No entanto, o esquema de pré-
autenticação proposto (Hur et. al., 2008) resulta no estabelecimento de uma AK na SS e
de uma BS alvo a qual a SS desloca-se antes do handover se iniciar, sendo apenas
necessário executar um 3-way handshake e posteriormente a atualização da TEK.
Por fim, os autores criticam os procedimentos de handover do padrão apontando
falhas além da falta de definição de um processo de pré-autenticação, mas afirmam que
o esquema de handover proposto fornece ao padrão, um protocolo de autenticação
simples e seguro.
69
Em (Hur et. al., 2008), verifica-se o processo de pré-autenticação seguro para o
padrão IEEE 802.16e embora critique o processo de segurança mesmo já na utilização
do PKMv2. O trabalho não realiza nenhuma validação para comprovar suas críticas.
Nenhuma das propostas apresentadas integra protocolos otimizados para reduzir
atrasos e perdas em conjunto com técnicas de antecipação do handover. Embora
proponham melhorias e estudos sobre aspectos de segurança, nenhum deles avalia a
integração da subcamada de segurança, da pré-autenticação em cenários de micro e
macro mobilidade e fundamentados nas camadas 2/3.
Os trabalhos aqui apresentados foram divididos de acordo com tópicos
apropriados aos temas chaves de seu contexto e são demonstrados no Quadro 5.
Quadro 5 - Relação dos trabalhos relacionados de acordo com seus assunstos chave
Mobilidade Transparente em
Redes Sem Fio
Considerações e Métodos de Segurança
em Redes Sem Fio
Métodos de Pré-Autenticação e
Segurança
(Li et. al., 2006)
(Huang et. al., 2007)
(Junior et. al., 2008)
(Xu et. al, 2006)
(Deininger et. al., 2008)
(Sun et. al., 2007)
(Hur et. al., 2008)
4.4 Resumo do Capítulo
Este capítulo descreveu alguns dos trabalhos relacionados ao tema desta
dissertação e os separou em três subgrupos de acordo com temas relativos. Houveram
trabalhos que descreveram aspectos de antecipação de handover e validaram algumas
simulações, outros que se focaram exclusivamente dos processos de segurança e por
último os que envolvem pré-autenticação.
O Capítulo 5 descreverá a contribuição da dissertação junto a arquitetura
proposta dissertando suas melhorias e sua importância para redes IEEE
802.16e/WiMAX.
70
5. Arquitetura de Pré-Autenticação
Este Capítulo apresenta a proposta de uma da arquitetura de pré-autenticação
segura com suporte a QoS/QoE para aplicações móveis multimídia em redes IEEE
802.16/WiMAX. Apresenta uma explicação sobre qualidade de experiência (QoE),
explanando suas principais e mais conhecidas métricas para análise do tráfego
multimídia quanto a qualidade final do vídeo.
O Capítulo apresenta também a política de antecipação do handover em
conjunto a implementação do módulo de segurança padronizado pelo padrão IEEE
802.16 e fornecido por esta dissertação preconizando em uma arquitetura de pré-
autenticação que fornece aos clientes móveis a segurança na camada 2 em conjunto a
um processo de handover transparente (camada 2/3) através da utilização do FHMIP,
formalizando uma arquitetura WiMAX para domínios administrativos diferentes ou
semelhantes de forma segura e confiável.
5.1 Qualidade de Experiência (QoE)
O conceito de Qualidade de Experiência está relacionado à avaliação das
aplicações multimídia do ponto de vista da percepção do usuário. O conceito de QoE,
embora antigo, veio para suprir as “lacunas” deixadas pela avaliação tradicional
realizada pelas métricas de QoS que avaliam o impacto das aplicações do ponto de
vista da rede para suprir tais requisitos de desempenho (Ferreira, 2009).
As métricas de QoS não refletem a experiência do usuário diante de um vídeo,
não permitindo afirmar se a qualidade do vídeo recebido pelo mesmo pode ser
qualificada como boa. Pois, em se tratando de avaliações de aplicações multimídias, a
sensibilidade humana é primordial (Winkler, 2005) (Wang, 2002) (Lambrecht &
Verscheure, 1996) (Pinson & Wolf, 2004).
Os aspectos e métricas de QoS (vazão, atraso e variação de atraso) causam
impacto no ponto de vista da rede, mas não em termos de percepção humana. Quando se
trata de aplicações multimídia, a experiência/percepção humana é importante para
determinar a qualidade de tais aplicações. O fato de uma aplicação multimídia estar com
uma boa vazão não nos permite afirmar que a qualidade da mesma está satisfazendo à
necessidade ou desejo do usuário.
71
Desta forma, as novas arquiteturas não estão sendo mais avaliadas apenas em
termos de aspectos de QoS, mas também em aspectos de QoE (Quality of Experience).
Análises baseadas em QoE suprem as limitações de estudo baseados apenas nas
métricas de QoS, pois fornecem informações sobre a percepção, a visão, a experiência
do usuário diante de uma aplicação multimídia. As métricas de QoE servem como
extensão aos parâmetros do QoS, permitindo avanços nas transmissões de aplicações de
áudio e vídeo em redes IP e podem proporcionar melhorias nos protocolos (Ferreira,
2009) (Pinson & Wolf, 2004) (ITU, 2009).
Vale ressaltar que a avaliação do vídeo do ponto de vista do usuário é subjetivo.
Dessa forma, um mesmo vídeo que pode ser considerado de boa qualidade para uma
pessoa A por exemplo pode vir a ter qualidade ruim para uma segunda pessoa. Assim
sendo, existem as métricas de QoE que possuem como objetivo quantificar e qualificar
o vídeo final se adaptando a experiência do usuário para verificar a resultante final
quanto a qualidade do vídeo.
As avaliações de QoE não tem como foco trazer melhorias no plano fim–a–fim
nas arquiteturas de redes mas, sim, melhorias para as aplicações multimídias a partir da
perspectiva/experiência do usuário. Em linhas gerais, as métricas de QoE, que podem
ser subjetivas ou objetivas, retornam um valor quantitativo que é mapeado para uma
faixa de valores qualitativos (Ferreira, 2009).
5.1.1 PSNR
A métrica mais tradicional de QoE é o PSNR (Peak Signal to Noise Ratio), que
estima a qualidade do vídeo em decibéis, comparando o vídeo original com o vídeo
recebido pelo usuário considerando o aspecto de luminosidade. A métrica é obtida por
meio da seguinte fórmula (Jain, 2004):
Onde:
M x N = Quantidade de pixels do vídeo
Ys (i,j) = Posição dos pixels no vídeo original
( ) ( )
−
=
∑∑−
=
−
=
1
0
1
0
210
,,1
255log20
M
i
N
j
jiYdjiYsMxN
PSNR
72
Yd (i,j) = Posição dos pixels no vídeo recebido pelo usuário.
Para cada faixa de valores de PSNR, há uma qualificação para o vídeo que foi
recebido pelo usuário. Veja a Tabela 1.
Tabela 1 - Índices de qualidade do PSNR
PSNR
(dB)
Qualidade
> 37 Excelente
31 – 37 Bom
25 – 31 Aceitável
20 – 25 Pobre
< 20 Péssimo
5.1.2 SSIM
A métrica Structural Similarity Index (SSIM) baseia-se na medição quadro a quadro do
vídeo original com o vídeo recebido pelo usuário. O SSIM compara a similaridade entre
os vídeos nos seguintes aspectos: contraste, luminosidade e estrutura. O SSIM é
expresso como um valor decimal entre 0 e 1. Quanto mais próximo do valor 1, melhor é
a qualidade do vídeo. O valor de SSIM é obtido através da seguinte fórmula (Uemura et
al, 2008) (Niranjan et al, 2000):
Onde:
µx é média de x ;
µy é a média de y ;
é a variância de x;
73
é a variância de y ;
covxy é a covariância de y ;
c1 = (k1L)2, c2 = (k2L) são duas constantes ;
L o valor máximo que pode ser atribuído a cada pixel;
k1 = 0,01 e k2 = 0,03 por padrão.
5.1.3 VQM
A métrica Video Quality Metric (VQM) também compara o vídeo original em
relação ao vídeo recebido pelo usuário, sendo considerada a métrica mais completa,
VQM analisa os seguintes aspectos: embaçamento, ruído, distorção dos frames, cor.
Por avaliar tais características citadas anteriormente, VQM é a métrica que mais
se aproxima do SVH. O valor VQM é expresso em um número real e quanto mais
próximo o valor for de 0, melhor será a qualidade do vídeo, o que indica uma menor
distorção em relação ao vídeo original (Niranjan et al, 2000) (Ferreira, 2009).
5.2 Arquitetura Proposta
Avaliando o padrão IEEE 802.16e (Marks, 2006) que trouxe consigo aspectos de
mobilidade, surgiu a oportunidade de SSs se locomoverem e eventualmente
requisitarem procedimentos de handover.
O processo de handover tratado nesta dissertação implica na mudança de BS por
parte de uma SS móvel que ao se movimentar pode necessitar uma mudança de rede
devido a uma perda na qualidade de sinal com a BS atual.
O avanço das comunicações móveis tem permitido o acesso a serviços em
qualquer instante, em qualquer lugar e com liberdade de movimentação. No entanto,
existem problemas intrínsecos nas comunicações sem fio como a escassez de recursos
(Nagamuta, 2005).
74
Em redes WiMAX, baseadas no padrão IEEE 802.16e, quando um cliente móvel
se encontra fora da área de cobertura de uma rede, este passa a buscar na interface aérea
uma nova BS, o que caracteriza o procedimento de handover.
No entanto, quando o protocolo utilizado é o MIP (Mobility IP) (Mip, 2002),
uma extensão do protocolo IP para dar suporte à mobilidade, preservando conexões
existentes, a SS móvel é identificada através de seu endereço IP que se mantém fixo
(home address). A SS móvel é associada também a um endereço IP provisório CoA
(Care-of-Address) relativo a rede, dependendo do ponto de acesso para onde a SS
móvel desloca-se.
Quando uma SS móvel migra e muda de rede, conexões são perdidas por se
tratar de um Hard Handover. Além disso, os pacotes são encaminhados incorretamente
(ao endereço IP antigo) até que a conexão com a nova BS seja estabelecida. Com esse
procedimento, a SS móvel perde seu CoA.
Durante o handover, até que a mensagem de atualização enviada pelo FA
(Foreign Agent – Agente Estrangeiro) informando o procedimento de Handover chegue
no HA (Home Agent – Agente de Origem), os pacotes destinados a SS móvel são
perdidos pois no MIP, sempre que uma SS móvel realizar o handover, esta terá que
avisar o seu HA que controla tal processo.
Com isso, perde-se um tempo considerável na rede para que o controlador (HA)
saiba que a SS móvel não faz mais parte da BS a qual está enviando seus dados.
Já no FHMIP (Yantov & Wiethoelter, 2006) (Jung et. al., 2005), uma extensão
do MIP, a SS móvel não precisa informar a HA sobre a mudança de BS e sim o MAP
(Mobile Anchor Point) que passa a ser o controlador do handover e agiliza o processo
devido a uma maior proximidade com a BS e o FA.
O MAP é uma entidade que faz parte de uma hierarquia de roteadores que
controla os triggers (disparos) do handover. Ele fica na rede externa e por isso passa a
controlar o handover, fazendo com que o tempo de informação ao controlador seja
menor, demorando um intervalo menor do que informar a HA.
O procedimento do FHMIP é mais rápido, pois o MAP tem um conhecimento
acelerado do novo CoA da SS móvel atualizando a nova rota dos gateways para o envio
dos dados provenientes do CN.
A Figura 18 ilustra uma arquitetura WiMAX móvel que utiliza o FHMIP. Nela,
nota-se uma estação assinante móvel conectada a uma BS/FA (Base Station/Foreign
Agent) conectada a gateways ASN (Access Service Network) que fazem parte de redes
75
CSN (Connectivity Access Network) e estão conectados ao MAP, o controlador do
handover do FHMIP e que recebe os dados do CN (Correspondent Node) e do HA.
Figura 18 - Arquitetura proposta do WiMAX com a utilização do FHMIP
Durante um processo de mobilidade, uma SS móvel WiMAX pode necessitar
migrar entres BSs e realizar um procedimento de handover.
Durante o procedimento de handover na camada 2, a SS inicia o processo junto
ao recebimento dos parâmetros de downlink e uplink da BS. A estação base envia as
mensagens: DL-MAP, que contém especificações físicas, o valor de configuração e a id
da BS; DCD, que informa a SS móvel as características do canal de downlink; UCD,
que informa a SS móvel as características do canal de uplink e UL-MAP que
corresponde ao tempo de alocação de recursos além das especificações físicas que estão
sendo utilizadas pela BS, conforme mostra o passo 1 representado na Figura 19.
Depois de tais dados serem atualizados e o procedimento na camada 2 ter sido
iniciado, a SS móvel envia para a BS uma mensagem de Ranging Request (RNG-REQ)
com o objetivo de averiguar e descobrir a qualidade do enlace (modulação, intensidade
76
do sinal, ajustes de tempo) e a BS responde através da mensagem Ranging Response
(RNG-RSP), conforme mostra o passo 2 representado na Figura 19.
O terceiro passo do processo corresponde a implementação desta dissertação
correspondente a subcamada de segurança da camada MAC (camada 2) e se inicia pela
SS com um pedido de Authentication Request (PKM-REQ). A BS avalia o pedido
checando a validade de seu certificado digital X.509 em relação a autoridade
certificadora (CA) e caso seja válida, autoriza a autenticação do cliente com uma
mensagem Authentication Response (PKM-RSP), conforme mostra o passo 3
representado na Figura 19.
Para finalizar o processo de registro na camada 2 após um procedimento de
autenticação, a SS envia uma mensagem de Registration Request (REG-REQ) e a BS
responde com um Registration Response (REG-RSP), conforme mostra o passo 4
representado na Figura 19 (IEEE Std 802.16e-2005, 2005).
Após os quatro passos correspondentes a arquitetura do WiMAX na camada 2 da
rede, inicia-se o processo de handover na camada IP (camada 3) demonstrada pela
arquitetura que utiliza o FHMIP e pelo passo 5 da Figura 19.
O MAP envia para a SS móvel a mensagem Proxy Router Advertisement
(PrRtAdv) que informa sobre os enlaces das BSs vizinhas. A SS móvel responde com a
mensagem Fast Binding Update (FB Update) que informa ao MAP para que ele
encaminhe o seu tráfego para a nova BS/FA. O MAP envia a mensagem Handover
Initation (Handover Init) para a nova BS/FA indicando o início do handover. A nova
BS/FA responde ao MAP com a mensagem Handover Acknowlegde (Handover ACK)
confirmando o recebimento da mensagem Handover Init e conseqüentemente tomando
conhecimento sobre o inicio do handover. O MAP envia então uma mensagem Fast
Binding Acknowlegde (FB ACK) para a SS móvel, para BS/FA atual e nova BS/FA
confirmando a vinculação da SS móvel perante a nova BS/FA para a qual passa a
encaminhar os pacotes.
A nova BS/FA informa a vinculação para a SS móvel e conseqüentemente
anuncia o novo CoA através da mensagem Fast Neighbor Advertisement (FNA). A SS
móvel responde para a nova BS/FA com uma mensagem Fast Binding Acknowlegde
(FB ACK) e esta passa a entregar os pacotes.
A SS móvel envia uma mensagem Local Binding Update (LB Update) para a
nova BS/FA avisando da vinculação local e esta retorna a mesma mensagem ao MAP.
O MAP envia uma mensagem Local Binding Acknowlegde (LB ACK) confirmando o
77
recebimento do LB Update da SS móvel para a Nova BS que encaminha a própria
mensagem a SS móvel, finalizando arquitetura WiMAX proposta com a utilização do
FHMIP.
Figura 19 - Sinalização da Arquitetura WiMAX + FHMIP
78
5.3 Implementação do Módulo de Segurança
Para fornecer segurança à arquitetura, fez-se necessário a implementação do
módulo de segurança provido pela subcamada de segurança da camada MAC descrito
no Capítulo 3. Essa implementação foi feita em C++ em conjunto ao patch do WiMAX
e simulado no simulador de redes ns-2 (Network Simulator version 2) (Network
Simulator, 2009).
A Figura 20 ilustra o diagrama de classes da implementação do módulo de
segurança do padrão IEEE 802.15/WiMAX inseridos no network Simulator para a
resultante final desta dissertação.
Figura 20 - Diagrama do módulo de segurança da subcamada da camada MAC
Com a implementação do módulo, foi possível simular o funcionamento do
processo de autenticação provido pelo PKM e inexistente no simulador. Com essa
79
contribuição pode-se avaliar o overhead causado pela inclusão de técnicas de segurança
e criptografia durante o procedimento de handover, mostrando que a QoS/QoE das
aplicações são prejudicas devido ao processo em sentido inverso a possibilidade de
prover autenticidade, confiabilidade e integridade as aplicações (Carvalho et. al., 2008).
Todo o procedimento de autenticação e criptografia provido pelo PKM, o
certificado X.509, a AK, TEK e as máquinas de estados de autorização e de TEK foram
implementadas em simulador para a execução do testes.
No entanto, o procedimento de autenticação mostrado no passo 4 da Figura 19
provia a subcamada de segurança a arquitetura WiMAX+FHMIP mas degradava o
procedimento de handover aumentando o tempo necessário para a SS móvel se re-
autenticação e re-conectar a uma nova BS. Para suprir essa falta, precisou-se fazer uma
nova implementação que antecipasse o procedimento de handover e assim formalizasse
o procedimento de handover transparente, provendo a arquitetura de pré-autenticação.
5.4 Política de Pré-Autenticação
Quando um cliente se locomove da área de cobertura de uma operadora para a
área de cobertura de outra operadora é necessário um suporte para que o mesmo não
perca conectividade e conseqüentemente dados da sua aplicação durante essa passagem
e mudança de estação BS WiMAX.
Para prover qualidade de serviço (QoS) e qualidade de experiência (QoE)
durante o handover, uma política de antecipação é proposta para que o cliente possa
manter a continuidade dos seus serviços durante procedimento.
A política de antecipação de handover é baseada em duas métricas de decisão de
disparo de sinalização: A velocidade da estação assinante móvel e a probabilidade da
conexão cair (Junior et. al., 2008) (Ferreira, 2009).
A probabilidade da conexão cair é obtida através das informações da camada
física a respeito da intensidade do sinal. A probabilidade da conexão cair é obtida
através da razão entre a média da qualidade do sinal com a qualidade do sinal no
momento de acordo com a fórmula:
80
( )
( ) dRxthresholdRxthresholFactorAvgdRxthresholFactorp
−×
−×= (4)
Onde:
Avg = Média de Intensidade do Sinal
Factor = Fator de conectividade do Padrão
RXThreshold = Valor da Intensidade do Sinal Puro
A velocidade do assinante móvel é obtida através de um GPS (Global Position
System) instalado no mesmo que a repassa a informação para a BS atual. O GPS é de
suma importância para a antecipação do handover, pois a idéia é determinar qual o
melhor instante para disparar o processo para que o mesmo seja transparente ao usuário.
Pois assinantes móveis poderão ter velocidades distintas ao longo do tempo e para
velocidade especifica há o momento certo de disparo da política de antecipação, por
exemplo, o handover de clientes com velocidades alta precisam ser antecipados
primeiro que o handover de clientes com baixa velocidade (Carvalho et. al., 2008).
A combinação dessas duas métricas permite determinar o melhor instante para
antecipar o handover de acordo com a situação de momento do cliente. A política de
antecipação de handover é disparada de acordo com os seguintes critérios:
1) Cliente de Baixa velocidade (inferior a 5ms): Probabilidade de conexão
falhar for igual ou superior a 90%.
2) Cliente de Média velocidade (superior a 5ms e inferior 10ms): Probabilidade
de conexão falhar for igual ou superior a 70%.
3) Cliente de Alta velocidade (superior a 10ms): Probabilidade de conexão
falhar for igual ou superior a 50%.
A predição do handover não compromete o mecanismo de segurança, ela só
antecipa o processo (associação e autenticação) fazendo com que este ocorra antes,
compensando desta forma o atraso provocado pelo módulo de segurança e criptografia.
81
Essa arquitetura proposta provê qualidade de serviço aos clientes e permite aos
mesmos a continuidade de seus serviços e conexão quando migram entre estações base,
entre redes, devido ao processo de disparo que antecipa uma desconexão iminente.
Essa antecipação inibe um processo de autenticação que seria iniciado apenas
após a queda da conexão, um processo conhecido como hard handover (HHO).
Assim, a política de antecipação de handover formaliza uma arquitetura de pré-
autenticação que ao detectar uma desconexão iminente baseado nos dados coletados do
GPS, dispara um processo de antecipação para evitar a necessidade de uma re-conexão e
desta forma, transparentemente estabelecer um novo processo de autenticação para que
a SS já esteja conectada com a BS para a qual migra e evite prejudicar suas aplicações,
sobretudo se estas forem multimídia que necessitam de largura de banda constante por
serem tratadas como aplicações de tempo real.
A união da política em conjunto a implementação do módulo de segurança e ao
FHMIP permite aos usuários móveis WiMAX a capacidade de usufruir de uma
arquitetura de pré-autenticação segura, em cenários de micro e macro mobilidade e com
suporte a QoS/QoE das aplicações.
5.5 Resumo do Capítulo
Este Capítulo apresentou a proposta desta dissertação descrevendo seus
elementos e suas contribuições para a formação da arquitetura de pré-autenticação
segura para as redes WiMAX/IEEE 802.16. Descreveu a definição da Qualidade de
Experiência e suas principais métricas e descreveu a arquitetura proposta explicando
seus principais elementos assim como a implementação para viabilizar a subcamada de
segurança.
O Capítulo 6 avalia a proposta presente neste capítulo com simulações e
resultados pertinentes a pesquisa realizada nesta dissertação. Ele apresenta os resultados
encontrados e os compara aos resultados que não utilizam a arquitetura proposta,
provando as melhorias encontradas.
82
6. Avaliação da Arquitetura de Pré-Autenticação
Este Capítulo avalia a proposta apresentada nesta Dissertação por meio de
modelos de simulação implementados no simulador de redes ns-2 versão 2.31 (Network
Simulator, 2009). O capítulo considera dois cenários para os estudos.
São apresentados o impacto causado pela implementação do módulo de
segurança e os resultados obtidos pela arquitetura pré-autenticação em termos de
métricas de QoS (vazão, perda, atraso) e de QoE (Peak Signal to Noise Radio,
Structural Similarity Index e Video Quality Metric) quando simulados sobre a
incidência do handover em cenários de micro e macro mobilidade.
6.1 Parâmetros de Simulação
Como o simulador ns-2 não possuía suporte para redes WiMAX, fez-se
necessário instalar um patch desenvolvido pelo NIST (National Institute of Standards
and Technology) (Nist, 2007) com a extensão.
Para a execução da simulação, criou-se uma extensão na linguagem de
programação C++ para implementar e aplicar o módulo de segurança inexistente no
simulador e na sua extensão provida pelo patch. Desta forma, tanto as mensagens PKM,
como a máquina de estados finitos de autorização e de TEK para prover o processo de
autenticação, autorização e contabilização, além da criptografia dos dados, foram
totalmente implementadas nesta Dissertação.
Para a criptografia dos dados utilizou-se o algoritmo AES com 256 bits e o
RSA-1024 para o certificado digital X.509. Utilizou-se de uma biblioteca do Crypto++
(Crypto++, 2008) através da qual foi possível o funcionamento das funcionalidades da
criptografia das mensagens envolvidas no processo de autenticação provido pelo
protocolo PKM e da criptografia dos dados envolvidos no canal de comunicação BS-SS
posteriormente a autenticação.
Para se chegar a um tempo médio do processo de criptografia e decriptografia
dos pacotes através da biblioteca utilizada, fez-se uma média de 500.000 simulações
para encontrar o tempo que um pacote utilizando o algoritmo responsável leva para
criptografar e finalizar o processo inverso. Através desse tempo médio, inseriu-se o
tempo correspondente em simulador sempre que o pacote precisava ser criptografado ou
descriptografado e assim obter o resultado final desejado durante o processo.
83
Para as simulações com vídeo utilizou-se a ferramenta Evalvid (Evalvid, 2007)
para inserir o tráfego de vídeo no simulador network simulator e assim garantir
resultados satisfatórios para análise sobre as métricas de QoE.
O Quadro 6 mostra os parâmetros utilizados pelas simulações deste trabalho.
Tabela 2 - Parâmetros de Simulação
Parâmetro de Simulação Valor
Parte Cabeada
Capacidade do
Enlace 4 Mbps
Atraso do Enlace 50 ms
Tamanho da
Buffer 50
Fila CBQ
Área de
Cobertura 1km
WiMAX Frequência 3,5GHz
Padrão IEEE 802.16e
Modulação OFDM
6.2 Cenários
O estudo da arquitetura é realizado considerando-se os dois cenários (Cenário 1
e Cenário 2) descritos a seguir:
� Cenário 1 – Trata-se de um cenário com quatro BSs (BS A, BS B, BS C e BS D)
e uma SS que realiza o handover (inicia na BS A indo em direção a BS D) e ao
término do percurso retorna à segunda BS (BS B). Assim, a SS realiza cinco
procedimentos de handover conforme mostra a Figura 21. Este é um cenário de
macro mobilidade e, portanto, faz uso do MIPv4 ao invés do FHMIP proposto.
O tráfego é CBR (Constant Bit Rate) com 1000 kbps.
84
Figura 21 - Representação gráfica do Cenário 1
� Cenário 2 – Trata-se de um cenário com quatro BSs (BS A, BS B, BS C e BS D)
e uma SS. O cliente possui mobilidade constante e realiza o handover entre as
estações base em ambos os sentidos, partindo da BS A para a BS D e depois
retornando a posição inicial (BS D para BS A) conforme mostra a Figura 22. As
duas primeiras BSs (BS A e BS B) pertencem ao mesmo domínio administrativo
e diferem das duas demais, (BS C e BS D) que possuem domínios diferentes.
Para prover o handover entre todas elas, utiliza-se do protocolo FHMIP em
substituição ao MIPv4, para assim, usufruir do procedimento tanto em cenários
de micro quanto macro mobilidade. O tráfego gerado pela SS é vídeo através da
ferramenta Evalvid (Evalvid, 2007), com características descritas na Tabela 3.
Tabela 3 - Parâmetros de simulação de tráfego de vídeo
Parâmetro de Simulação Valor Resolução 352 x 288
Taxa de Frame 30 Frame/seg Modo de Cores Y, U, V
Tamanho do Pacote 1052 Fragmentação Máxima do Pacote 1024
85
Figura 22 – Representação gráfica do Cenário 2
6.3 Análise das Simulações
6.3.1 Cenário 1
No primeiro cenário, a SS permanecerá pouco tempo dentro da área das BSs
devido a sua alta mobilidade e, por isso, realizará 5 procedimentos de handover.
As simulações comprovaram que sem o emprego da arquitetura de pré-
autenticação, o nó móvel faz hard handover, ou seja, durante o processo de handover há
a quebra de conexão e, portanto, o nó móvel não recebe pacotes nesse período de
mudança de BSs, ficando sem conectividade e perda de pacotes.
Porém, as simulações com o emprego da arquitetura comprovaram que em
nenhum instante há quebra de conexão ou período sem recebimento de pacotes, pois
nesse caso a SS móvel realizou o seamleass handover, permitindo que o cliente
continue a usufruir de seus serviços normalmente independente da mudança de BS,
86
proporcionando QoS máxima e caracterizando um cenário ideal. A Figura 23 apresenta
a eficiência da política de predição de handover quando em comparação a não utilização
dela.
Figura 23 - Comparação da vazão da rede com a política e sem a política
Além de prover QoS, a antecipação do handover otimiza o funcionamento da
rede e fornece de forma transparente ao seu assinante móvel, viabilizando a
continuidade de seus serviços.
Diante de um cenário real com implementação da subcamada de segurança e da
política de antecipação de handover, além das vantagens acima citadas, a proposta
também diminuiria o impacto causado pelo processo de autenticação e criptografia, que
produz certo atraso devido ao tempo gasto para autenticar e autorizar um cliente e
proteger seus dados.
Desta forma, a técnica de antecipação compensa este tempo com o ganho sobre
o tempo que seria perdido sempre que a SS precisasse se re-autenticar quando migrasse
de uma BS à outra.
-200
0
200
400
600
800
1000
0 6
12
18
24
30
36
42
48
54
60
66
vazão
(kb
ps)
tempo (s)
Com Política
Sem Política
87
6.3.2 Cenário 2
No segundo cenário, prioritário nas simulações desta dissertação, verifica-se o
impacto causado pela implementação da política de antecipação, da subcamada de
segurança, da criptografia e do FHMIP sobre o tráfego de vídeo, mostrando a qualidade,
as melhorias e o atraso em um processo autenticado, seguro e antecipado quando se
transmite dados desta magnitude. A Figura 24 mostra a visualização do cenário 2 no
NAM (visualizador gráfico do network simulator).
Figura 24 - Visualização do Cenário 2 no NAM do NS-2
Os resultados apresentados pela Figura 25 e pela Figura 26 transcrevem
respectivamente a vazão e o número de seqüencia sem a arquitetura proposta e com a
arquitetura proposta por esta dissertação.
Os resultados (vermelho) apresentados pela Figura 25 e pela Figura 26 mostram
as quedas de conectividade junto as BSs correspondentes durante o procedimento de
handover.
88
Figura 25 – Comparação da vazão do Cenário 2 com e sem a arquitetura
Figura 26 – Comparação do número de seqüência do Cenário 2 com e sem a arquitetura
Como não fazem uso da arquitetura proposta de pré-autenticação, as quedas de
conectividade acontecem sempre que o usuário móvel desloca-se entre as células de
cobertura das BSs envolvidas, fazendo desta forma cinco procedimentos de hard
handover, conforme notado nas quedas de vazão do resultado de simulação provido
pelo gráfico.
-500
0
500
1000
1500
2000
2500
3000
3500
1 7
13
19
25
31
37
43
49
55
61
67
vazão
(kb
ps)
tempo (s)
Com Política
Sem Política
-5000
0
5000
10000
15000
20000
25000
30000
35000
1 7
13
19
25
31
37
43
49
55
61
67
nú
mero
de s
eq
uên
cia
tempo (s)
Com Política
Sem Política
89
Já com a inclusão da arquitetura de pré-autenticação, nota-se resultados de
simulações diferentes. A vazão apresentada (azul) graficamente pela Figura 25 e pela
Figura 26 mostra que devido à utilização da política pré-autenticação proposta não há
quebra de conexão quando a SS móvel se locomove através das células de cobertura das
BSs envolvidas no cenário. Dessa forma, a solução proporciona conexão com
continuidade de serviço reforçando a QoS das redes de comunicação modernas. A
Figura 27 mostra individualmente a vazão sob a ação da arquitetura.
Figura 27 - Vazão do Cenário 2 com a arquitetura proposta
Após essa avaliação, apresenta-se também outro gráfico de simulação resultado
da coleta do número de seqüência para o mesmo cenário e com o uso da arquitetura de
pré-autenticação e apresentado pela Figura 28. Nota-se a continuidade do número de
seqüência ao longo do tempo mesmo quando inerente a ocorrência de handover, desta
vez antecipados pela política e, portanto, sem quedas de conexão (sem o hard
handover).
A continuidade de serviços, conexão e conectividade é uma das métricas mais
importantes de Qualidade de Serviço, sobretudo nos sistemas sem fio modernos como
redes metropolitanas móveis que oferecem a possibilidade a clientes móveis migrarem
constantemente entre células de BSs e mantendo seus serviços constantes.
0
500
1000
1500
2000
2500
3000
3500
1 8,
16
23
31
38
46
53
61
68
tempo (s)
vazão (kbps)
Vídeo
90
Figura 28 - Número de Seqüência do Cenário 2 com a arquitetura proposta
Em comparação aos primeiros resultados deste cenário apresentados em
vermelho nas figuras anteriores (Figura 25 e Figura 26), é possível notar claramente a
diferença favorável provida pela arquitetura de pré-autenticação segura proposta.
É importante ressaltar, que ambos os resultados apresentados com a política de
antecipação já possuíam também a subcamada de segurança agindo sobre suas conexões
e sua autenticação provida pelo protocolo PKM. Embora os atrasos provenientes da
inclusão desta subcamada não sejam notados nestes gráficos, eles existem e serão
notados nos próximos resultados, onde se verifica o atraso causado por essas inserções.
Primeiramente, nota-se o atraso correspondente ao cenário 2, sem as
implementações, onde a ocorrência do atraso verificado é decorrente apenas das
mensagens default da rede, sejam elas pertencentes ao processo de entrada ou durante a
execução do tempo de conexão do usuário com a BS.
Como verifica-se na Figura 29, existe a ocorrência de atraso durante a execução
deste cenário no simulador. Verifica-se que em um cenário sem a implementação da
arquitetura de pré-autenticação e do módulo de segurança, não são detectados atrasos
superiores a 0,14 s (segundos), possibilitando desta forma, um tráfego de vídeo transitar
0
5000
10000
15000
20000
25000
30000
35000
40000
1 9
17
25
33
41
49
57
65
tempo (s)
nú
mero
de s
eq
uên
cia
Vídeo
91
entre usuários ou redes sem qualquer processo de autenticação na camada MAC e/ou
criptografia para proteger os mesmos.
Figura 29 - Atraso no Cenário 2 sem a arquitetura proposta (Atraso/Frame)
No entanto, com a implementação do módulo de segurança e da arquitetura de
pré-autenticação, nota-se no gráfico demonstrado pela Figura 30 que existem picos de
atraso durante os processos de autenticação envolvidos por este cenário. Esses picos são
notados quando a estação assinante cliente sai da área de cobertura de uma BS e adentra
em outra estabelecendo uma re-autenticação.
Figura 30 - Atraso no Cenário 2 com a arquitetura proposta (Atraso/Frames)
Conforme a proposta da arquitetura de pré-autenticação, sempre que uma SS
móvel incide sobre uma determinada probabilidade de executar o procedimento devido
à intensidade de o sinal cair e baseado na política de antecipação com auxílio de um
Atraso
0
0,02
0,04
0,06
0,08
0,1
0,12
0,14
0,16
1 113 225 337 449 561 673 785 897 1009 1121 1233 1345 1457 1569 1681 1793 1905 2017
Frames
Atr
as
o (
s)
Atraso
Atraso
0
0,02
0,04
0,06
0,08
0,1
0,12
0,14
0,16
0,18
0,2
1 116 231 346 461 576 691 806 921 1036 1151 1266 1381 1496 1611 1726 1841 1956 2071
Frames
Atr
as
o (
s)
Atraso
92
GPS, um processo de autenticação prévio começa a ser executado, incidindo desta
forma nos cinco picos de atraso detectados na Figura 30. Vale ressaltar que os atrasos
são sempre inferiores a 0,2 s (segundos), mesmo quando estão sobre a ação dos maiores
picos.
A Figura 30 mostra que os atrasos com a inclusão da autenticação e da
criptografia em relação à Figura 29 sem a arquitetura são maiores, embora, devido à
antecipação do handover, os intervalos de tempo sejam menores.
Colocando-se um vídeo para ser executado sobre o cenário dois, pode-se notar
visualmente a diferença a favor das propostas deste trabalho. Conforme mostra a Figura
31, pode-se verificar que no instante do frame 1042 ocorre um handover e o vídeo que
não utiliza a arquitetura de pré-autenticação proposta perde pacotes transmitidos
naquele momento (frame). Com isso, o vídeo que é transmitido perde qualidade e
alguns pixels de imagem da imagem original daquele momento, nesse caso
correspondentes a um pássaro que sobrevoava o local e ao barco que se encontra mais a
frente do que demonstra a Figura.
Figura 31 - Vídeo transmitido sem a arquitetura de pré-autenticação
No entanto, com a utilização da arquitetura proposta é possível ter a visualização
real do vídeo em tempo real e de forma segura e autenticada. Através da arquitetura
proposta, o mesmo vídeo transmitido no mesmo frame chega de forma totalitária ao
93
cliente móvel mesmo quando sob a incidência de um handover, sem haver perda de
pacotes ou de dados da imagem real conforme nota-se na Figura 32.
Figura 32 - Vídeo transmitido com a arquitetura de pré-autenticação
Verificando-se as duas figuras nota-se claramente que a arquitetura de pré-
autenticação permite um vídeo real sem perdas. Graças à arquitetura proposta, pode-se
notar a presença do pássaro que sobrevoa o local no momento do frame 1042 e o real
local da embarcação que se encontra mais a frente quando em relação ao mesmo vídeo
sem a utilização da arquitetura.
Logo, sem a utilização da arquitetura, nota-se que há falhas na recepção de
pacotes indicadas pela ausência do pássaro durante um frame ocorrido diante de um
procedimento de hard handover onde houve queda de conexão e perda de pacotes.
Mais adiante, no mesmo vídeo, desta vez registrado no frame 1664, pode-se
notar que a Figura 33 apresenta uma qualidade inferior devido a não utilização da
arquitetura de pré-autenticação quando em comparação ao mesmo frame que utiliza a
arquitetura proposta e é apresentado pela Figura 34.
Além de ganhos de QoE providos pela melhora na qualidade do vídeo e pela
manutenção das conectividades e conexões provendo QoS no procedimento de
handover durante as alternâncias de BSs, a SS móvel possui um vídeo adequado, seguro
e pode trocar informações de forma autenticada e sem atrasos que venham a dificultar
94
um acesso prejudicial ou qualquer forma de roubo de informação que seja trafegado na
rede, seja em forma de tráfego multimídia (vídeo) ou em tráfego de dados (CBR),
fornecendo assim uma canal de conexão seguro a estação assinante móvel e seguindo a
padronização do padrão IEEE 802.16e/WiMAX.
Figura 33 - Vídeo transmitido sem a arquitetura de pré-autenticação
Figura 34 - Vídeo transmitido com a arquitetura de pré-autenticação
95
Além de averiguar a qualidade e o desempenho dos vídeos sob a implementação
da técnica de pré-autenticação e com a inclusão da camada de segurança e criptografia
do tráfego multimídia, o trabalho preocupa-se também com a verificação dos
conhecimentos de QoE a fim de delimitar e respaldar tal qualidade segundo suas
principais métricas.
Os resultados mostrados até o momento verificam a vazão, o número de
seqüência e o atraso, descrevendo e delimitando conceitos aos resultados
correspondentes das métricas de QoS e a segurança.
No entanto, tais resultados não são suficientemente fortes para afirmar com
relevância suficiente que a qualidade do tráfego multimídia aqui apresentado é de boa
qualidade, pois não o verifica sob a perspectiva do usuário.
Dessa forma, as métrica de QoE verificam e analisam tal tráfego baseado em
termos da experiência humana, o que reforça os resultado apresentados até o momento e
tornam esta adição diferencial sobre a perspectiva da avaliação de qualidade de um
tráfego multimídia criptografado e pré-autenticado.
As métricas de QoE foram estabelecidas pelo ITU-T (ITU-T, 2009) e são
definidas como a relação do ponto de vista do usuário sobre as aplicações multimídia,
no caso deste trabalho, o tráfego de vídeo.
Para prover os resultados diferenciais aos já mostrados e fechar uma
comprovação que demonstre melhor a qualidade do vídeo apresentado por este trabalho,
o mesmo foi jogado em um simulador de qualidade de vídeo junto as inserções de pré-
autenticação e criptografia e avaliado segundo as principais métricas de QoE para
fornecer resultados quantitativos e qualitativos a respeito da qualidade do vídeo
utilizado sobre a introdução das propostas.
O simulador MSU Video Quality Measurement Tool (Compression Project,
2008) foi utilizado para medir e demonstrar graficamente os resultados resultantes do
teste de qualidade de vídeo e foi baseado em três principais métricas: PSNR (Peak
Signal to Noise Radio), SSIM (Structural Similarity Index) e VQM (Video Quality
Metric) (Winkler, 2005).
Os resultados obtidos com a avaliação do vídeo são demonstrados
quantitativamente na Tabela 4 e demonstrados nas Figuras a seguir a partir da métrica
utilizada em sua medição e comparado os valores quanto à utilização ou não da
arquitetura de pré-autenticação e segurança proposta neste trabalho:
96
Tabela 4 - Resultados obtidos diante das métricas de QoE
Com Pré-Autenticação
Sem Pré-Autenticação
PSNR 34 dB 28 dB
SSIM 0,87 0,86
VQM 1,40 1,70
6.3.2.1 PSNR
Trata-se um dos métodos de avaliação de qualidade de vídeo mais aceito na
comunidade acadêmica e científica atual (Malkowski & Claben, 2008). Baseia-se na
relação entre o máximo de potência de um sinal pela potência do ruído e é representado
em decibel (dB). Quanto maior o valor, melhor qualidade o vídeo possui.
Sob a avaliação da métrica de PSNR, o vídeo proposto apresenta uma resultante
de 34 dB quando utiliza a arquitetura de pré-autenticação e 28 dB quando não utiliza a
arquitetura proposta conforme mostra a Figura 35. Com isso, pode-se afirmar que sob a
avaliação da métrica PSNR, o vídeo utilizado possui uma melhor resultando quando
utiliza a arquitetura proposta por esta dissertação.
Figura 35 - Comparação dos resultados do PSNR com e sem a arquitetura proposta
0
5
10
15
20
25
30
35
40
45
1 241 481 721 961 1201 1441 1681 1921
PS
NR
frame
Com Política
Sem Política
97
6.3.2.2 SSIM
Sob a avaliação da métrica de SSIM, o vídeo proposto apresenta uma resultante
de 0,87 quando utiliza a arquitetura pré-autenticação e 0,86 quando não utiliza a
arquitetura proposta conforme demonstra a Figura 36. Portanto, sob a avaliação da
métrica SSIM pode-se afirmar que o vídeo que não utiliza a arquitetura proposta possui
uma distorção superior quando comparado ao vídeo trafegado com a arquitetura de pré-
autenticação.
Figura 36 - Comparação dos resultados do SSIM com e sem a arquitetura proposta
6.3.2.3 VQM
Essa métrica compara o vídeo recebido pelo usuário com a presença da
arquitetura de pré-autenticação em relação ao vídeo original com a ausência da política
proposta, aproximando-se desta forma ao SVH (sistema visual humano) e colhendo
resultados satisfatórios, comparando entre outros dados, o brilho e o contraste.
Sob a avaliação da métrica de VQM, o vídeo proposto apresenta uma resultante
de 1,40 quando utiliza a arquitetura de pré-autenticação enquanto o vídeo sem a
arquitetura apresenta uma resultante de 1,70 conforme apresenta a Figura 37 e, portanto,
uma qualidade inferior ao vídeo que utiliza a proposta desta dissertação.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1 245 489 733 977 1221 1465 1709 1953
SS
IM
frame
Com Política
Sem Política
98
Sendo o VQM uma métrica de avaliação de qualidade de vídeo completa,
afirma-se que o vídeo utilizador da arquitetura de pré-autenticação com criptografia
fornecedor de um tráfego multimídia seguro, apresenta também uma qualidade de vídeo
maior e, dessa forma, melhor do ponto de vista da métrica de Qualidade de Experiência,
baseada no ponto de vista subjetivo do usuário.
Quanto menor o valor encontrado pelo simulador quanto ao VQM, melhor é a
qualidade apresentada pelo vídeo quanto a brilho e contrastes e em relação ao SVH
(Sistema Visual Humano).
Figura 37 - Comparação dos resultados do VQM com e sem a arquitetura proposta
6.4 Resumo do Capítulo
Este capítulo descreveu os cenários utilizados por esta dissertação, assim como,
as ferramentas envolvidas na execução dos testes para as simulações e para uma
verificação completa quanto a qualidade do vídeo, verificando-se a QoS e a QoE do
vídeo demonstrado no trabalho sobre a perspectiva de um processo de pré-autenticação
seguro e criptografado para tráfego multimídia.
Com isso, o trabalho encerra suas simulações sobre as propostas da dissertação
demonstrando os resultados obtidos e os descrevendo.
0
2
4
6
8
10
12
1 222 443 664 885 11061327154817691990
VQ
M
frame
Com Política
Sem Política
99
7. Conclusão
Este trabalho propôs uma arquitetura de pré-autenticação segura com suporte a
QoE/QoS para aplicações móveis multimídia em redes IEEE 802.16e/WiMAX visando
a segurança e a integridade dos dados trafegados em redes deste tipo que abrange um
mercado cada vez maior no cenário global, com um número de usuários aumentando a
cada dia.
Por se tratar de uma rede metropolitana e por trafegar seus dados através de
microondas, esta tecnologia está vulnerável a problemas maiores dos que os problemas
convencionais encontrados em redes fixas e por isso necessita de um protocolo de
autenticação forte contra o roubo de serviço ou de dados e criptografia para proteger o
fluxo de serviços e o trafego dos usuários depois que o processo de autenticação tenha
sido cumprido.
Somente através de um esquema de autenticação e criptografia se pode diminuir
a possibilidade de alguns ataques acontecerem, como masquerading, cloned, replay
attack, entre outros. Por isso, o IEEE 802.16 se utiliza do protocolo PKM e dos
certificados digitais X.509 pra garantir a autenticidade e o processo de autenticação,
provendo uma confidencialidade maior aos seus usuários e a criptografia através do
AES para proteger os dados trafegados após a autenticação.
Visando a qualidade de serviço e a diminuição do tempo gasto com o
procedimento de segurança provido pela implementação do módulo de segurança e
criptografia, o trabalho propôs uma técnica de predição de handover, provendo assim,
uma arquitetura completa de pré-autenticação transparente e segura para redes WiMAX
móveis.
Conforme se notou nas simulações, a arquitetura proposta melhorou o
desempenho da rede assim como viabilizou a obediência da métrica de QoS para a
continuidade dos serviços providos pela rede evitando uma eventual queda ocasionada
pelo procedimento, graças a arquitetura de pré-autenticação, ocasionando desta forma
um procedimento de seamless handover, onde não há queda de conexão ou perda de
pacotes.
Graças à utilização FHMIP, foi possível compreender um procedimento de pré-
autenticação com o gerenciamento de mobilidade acima da camada 2, na camada 3 da
rede, permitindo a mobilidade e ao procedimento de handover uma execução em
100
domínios administrativos diferentes, alcançando cenários de micro e macro mobilidade
e viabilizando desta forma um procedimento mais completo para o funcionamento da
arquitetura de pré-autenticação segura.
Com a utilização da arquitetura de pré-autenticação proposta obteve-se uma
melhora de aproximadamente 25% sobre a vazão e 21,4% sobre a métrica PSNR na
avaliação da qualidade de vídeo final, consolidando percentualmente a melhoria
fornecida pela arquitetura.
Tais resultados validaram a proposta do trabalho, demonstrando a importância
da mesma não apenas no contexto da qualidade de serviço, mas também na qualidade
do vídeo quando avaliado sobre métricas de QoE, levando em consideração a
experiência do usuário para verificar a qualidade do tráfego multimídia sobre a ação da
arquitetura de pré-autenticação.
Através das simulações, notou-se que os resultados que demonstravam a
qualidade do vídeo sobre algumas métricas de QoE quando utilizavam a arquitetura
proposta obtiveram melhores resultados do que as simulações que não faziam uso da
política, favorecendo também a proposta do trabalho.
As simulações provaram que o handover e outros procedimentos da rede são
degradados devido à implementação da subcamada de segurança causando sobrecargas
e atrasos diante da vazão da rede.
A técnica de antecipação melhora o desempenho de tais perdas devido à
antecipação do handover e compensa o tempo que seria gasto sempre que uma SS
móvel necessitasse iniciar uma re-conexão.
Através da arquitetura proposta com a inclusão de autenticação e criptografia
possibilitou-se prover a SS móvel uma arquitetura pré-autenticada com integridade,
confiabilidade e autenticidade, sem perdas, com QoS e QoE e com seamless handover
para as camadas 2/3 das redes WiMAX.
7.1 Trabalhos Futuros
Para trabalhos futuros, propõe-se:
� Incluir novas métricas no algoritmo de pré-autenticação como a distância,
balanceamento de carga;
101
� Incluir as categorias de serviço do WiMAX a fim de avaliar a possibilidade da
nova BS receber muitos clientes;
� Implementar o PKMv2 para prover uma autenticação mais robusta e avaliar o
desempenho do mesmo em relação a versão utilizada por este trabalho;
� Avaliar outros algoritmos de criptografia ou outros modos;
� Criar um protocolo para prover um sistema de pré-autenticação em redes
heterogêneas para garantir a autenticação em tecnologias de redes diferentes.
102
8. Referências Bibliográficas
ABOBA, B. BLUNC, L. VOLLBRECHT, J. CARLSON, J. LEVKOWETZ, H.
“Extensible Authentication Protocol (EAP)”. Network Working Group. (IETF RFC
3748), Junho, 2004.
AHSON, Syed. ILYAS, Mohamed. “WiMAX – Standards and Security”. Editora CRC
Press. 2008.
AKYILDIZ, I. F. XIE, J. MOHANTY, S. “A survey of mobility management in next-
generation all-IP-based wireless systems”. In Wireless Communications, IEEE. Agosto,
2004.
ALEXA, Ron. “Implementing 802.11, 802.16 and 802.20 Wireless Networks –
Planning, Troubleshooting and Operations”. Communications Engineering Series.
Editora Newnes. 2005.
BOGDANOSKI, Mitko. LATKOSKI, Pero. RISTESKI, Aleksandar. POPOVSKI,
Borislav. “IEEE 802.16 Security Issues: A Survey”. 16th Telecommunications Forum
TELFOR. Novembro, 2008.
CARVALHO, Tássio. SOUZA, Válber. JUNIOR, José Jailton. DIAS, Kelvin Lopes.
“Antecipação do Handover em Redes IEEE 802.16 Seguras”. Universidade Federal do
Pará. Conferencia Latino Americana de Informática – Clei 2008. Santa Fe – Argentina.
Setembro, 2008
Crypto++. “Crypto++ Web Site”. Disponível em: http://www.cryptopp.com. Junho,
2008.
CHANDRA, P. “Securing WLAN links: Part 3. Telogy networks”. Disponível em:
http://www.CommsDesign.com. Março, 2008.
103
CP – Compression Project. “MSU Video Quality Measurement Tool”. Disponível em:
http://www.compression.ru/. Dezembro, 2008.
DEININGER, Andreas. KIYOMOTO, Shinsaku. KURIHARA, Jun, TANAKA,
Toshiaki. “Security Vulnerabilities and Solutions in Mobile WiMAX”. IJCSNS
International Journal of Computer Science and Network Security. November, 2007.
DUTTA, Ashutosh. FAMOLARI, David. DAS, Subir. OHBA, Oshihiro. FAJARDO,
Victor. TANIUCHI, Kenichi. LOPEZ, Rafael. “Media-Independent Pre-Authentication
Supporting Secure Interdomain Handover Optimization”. IEEE Wireless
Communications. Abril, 2008.
EVALVID. Disponível em <http://www.tkn.tu-berlin.de/research/evalvid/>. Acesso em
2 de julho de 2007.
IEEE – Institute of Electrical and Electronics Engineers. “IEEE Standard for Local and
Metropolitan Area Network”. IEEE Std 802.16TM-2001. Abril, 2002.
IEEE – Institute of Electrical and Electronics Engineers. “IEEE Standard for Local and
Metropolitan Area Network”. IEEE Std 802.16TM-2004. Junho, 2004.
IEEE – Institute of Electrical and Electronics Engineers. “IEEE Standard for Local and
Metropolitan Area Network”. IEEE Std 802.16eTM-2005. Dezembro, 2005.
FERREIRA, José Jailton Henrique Júnior “Handover Transparente para Tráfego
Multimídia em uma Arquitetura Integrada WiMAX/MIP/MPLS Móvel”. Universidade
Federal do Pará. Webmidia, 2009.
FRATASI, S.; FATHI, H.; FITZEK, F.H.P.; PRASAD, R.; KATZ, M.D. “Defining 4G
technology from the user's perspective”. IEEE Network.Vol. 1 ,pp. 35 – 41. Fevereiro,
2006.
HOUSLEY, R. et al., “RFC 2459 – Internet X.509 Public Key Infrastructure Certificate
and CRL Profile”. Internet RFC Archives, January 1999.
104
HSIEH, Robert. ZHOU, Zhe Guang. SENEVIRATNE, Aruna. “S-MIP: A Seamless
Handoff Architecture for Mobile IP”. IEEE, 2003.
HUANG, Chen-Jung. CHUANG, Yi-Ta. GUAN, Chih-Tai. YANG, Dian-Xiu. CHEN,
You-Jia. “A Self-Adaptive Bandwidth Reservation Scheme for 4G Mobile WiMAX”.
IEEE Wireless Communications Magazine. 2007.
HUR, Junbeom. SHIM, Hyeongseop. KIM, Pyung. YOON, Hyunsoo. SONG, Nah-Oak.
“Security Considerations for Handover Schemes in Mobile WiMAX Networks”. IEEE
Communications Society, WCNC, 2008.
JAIN, R. “Quality of experience”. IEEE Multimidia. Volume 11, p. 90 – 98. 2004.
JUNG, Heeyoung, SOLIMAN, Hesham, KOH, Seokjoo, TAKAMIYA, Noriaki. “Fast
Handover for HMIPv6”. Internet Draft. Outubro, 2005. Disponível em:
http://tools.ietf.org/wg/mipshop/draft-jung-mipshop-fhmipv6-00.txt.
JUNIOR, José Jaílton. PONTES, Allan Borges. RODRIGUES, Otávio. SILVA, Diego
dos Passos. DIAS, Kelvin Lopes. “Gerenciamento de Mobilidade Transparente em
Redes IEEE 802.16e utilizando o MPLS Móvel”. WGRS. 2008.
KALISKI, B. STADDON, J; RIVEST, Ron. SHAMIR, Adi. ADLEMAN, Len. “RSA
Cryptography Specifications Version 2 – RSA Data Security”. Network Working
Group. (IETF RFC 2437), Outubro, 1998.
KUROSE, James F. ROSS, Keith W. “Redes de Computadores e a Internet – Uma
Abordagem top-down”. Editora Pearson. 3ª Edição.
LAMBRECHT, C., VERSCHEURE, O. “Perceptual Quality Measure using a Spatio –
Temporal Model of the Human Visual System”. Digital Video Compression:
Algorithms and Technologies. Vol. 2668, p. 450-461. 1996.
105
LI, Peng. PAN, Yan. YI, XIAOXIN. “A Seamless Handover Mechanism for IEEE
802.16e Systems”. IEEE Wireless Communications Magazine. 2006.
LOPEZ, German Gonzalez. WANG, Qi. RGHEFF, Mosa Ali Abu. AKRAM, Ammad.
“A MIP-SIP Macro-Mobility Management Schemefor VoIP Across Wired and Wireless
Domains”. Março, 2004.
MAHESHWARI, Abhishek. “Implementation and Evaluation of a MAC Scheduling
Architecture for IEEE 802.16 WirelessMANs”. Maio, 2006.
MANNER, J. KOJO, M. “Mobility Related Terminology”. Network Working Group.
IETF RFC 3753. Junho, 2004.
MARKS, R. STANWOOD, K. CHANG, D. “IEEE Standard for Local and
Metropolitan Area Networks”. IEEE Std 802.16e-2005. Fevereiro, 2006.
MARKS, Roger B., STANWOOD, Kenneth L., WANG, Stanley “IEEE Standard
802.16: A Technical Overview of the WirelessMAN™ Air Interface for Broadband
Wireless Access”. IEEE 802.16-02/05. IEEE Communications Magazine. Junho 2002.
MIP, “IP Mobility Support for IPv4”. Internet IETF RFC 3344. 2002
MOTOROLA. WiMAX Security for Real-World Network Service Provider
Deployments”. 2007.
NAGAMUTA, Vera. “Protocolos de Micro Mobilidade IP”. 2005.
NIRANJAN et al. “Image Quality Assessment Based on a Degradation Model,” IEEE
Transaction on Image Processing. Vol. 9, abr 2000.
NIST – National Institute of Standards and Technology. “The Network Simulator NS-2
Nist add-on”. IEEE 802.16 model (MAC + PHY). Junho, 2007.
106
NIST – National Institute of Standards and Technology – NIST. “NIST Web Site”.
Disponível em: http://www.antd.nist.gov. Abril, 2008.
Network Simulator (ns-2). “Ns Web Site”. Disponível em:
http://www.isi.edu/nsnam/ns/. Março, 2009.
PELAEZ, Juan C., Eduardo B. Fernandez, Michael VanHilst. “Patterns for WiMAX
Security”. Florida Atlantic University – Boca Raton, FL, USA, 2007.
PINSON, M., WOLF, S. “A New Standardized Method for Objectively Measuring
Video Quality”. IEEE Transacions on Broadcasting. Volume 50. ISSN: 0018-9316. pp.
312 – 322. 2004.
SAUTER, Martin. “Communication Systems for the Mobile Information Society”.
Editora John Wiley & Sons, Ltd. Nortel Networks, Germany. 2006.
SUN, Hung-Min. LIN, Yue-Hsun. CHEN, Shuai-Min. SHEN, Yi-Chung. “Secure and
Fast Handover Scheme Based on Pre-Authentication method for 802.16/WiMAX
Infrastructure Networks”. IEEE Wireless Communications Magazine. 2007.
ITU – Internacional Telecommunications Union. “ITU-T – Quality of Experience
(QoE)”. Disponível em: http:// http://www.itu.int/ITU-T/. Janeiro, 2009.
ITU – Telecommunication Standarlization Sector of ITU. “ITU-T-X.509”. Information
technology – Open Systems Interconnection – Authentication framework. (IETF RFC
3280), Agosto, 1998.
SIKKENS, Bart. “Security issues and proposed solutions concerning authentication and
authorization for WiMAX (IEEE 802.16e)”. 8thTwente Student Conference on IT.
Janeiro, 2008.
SILVA, Diego dos Passos. DIAS, Kelvin Lopes. “Simulando Redes IEEE 802.16
usando o ns-2”. Universidade Federal do Pará, Departamento de Engenharia Elétrica e
de Computação. 2007.
107
UEMURA, S.; FUKUMOTO, N.; YAMADA, H.; NAKAMURA, H. “QoS/QoE
Measurement System Implemented on Cellular Phone for NGN”. IEEE Consumer
Communications and Networking Conference. p. 117 – 121. jan 2008.
VISCAÍNO, Jorge López. “WiMAX: IEEE 802.16”. Tampere Polytechnic,
Telecommunications Engineering. Junho, 2008.
XU, Sen. MATTHEWS, Manton. HUANG, Chin-Tser. “Security Issues in Privacy and
Key Management Protocols of IEEE 802.16”. ACM SE’06. Março, 2006.
WANG, Z., BOVIK, A., LU, L. “Why is Image Quality Assessment So Difficult?”.
IEEE International Conference on Acoustics, Speech, & Signal Processing, May 2002.
WINKLER, Stefan. “Digital Video Quality: Vision Models and Metrics”. John Wiley &
Sons, Ltd. ISBN: 0-470-02404-6, 2005.
WiMAX Forum. “Mobile WiMAX – Part I: A Technical Overview and Performance
Evaluation”. Agosto, 2006.
WiMAX Forum. “WiMAX Forum Web Site”. Disponível em:
http://www.wimaxforum.org/home. Acessado em: Novembro de 2008.
WiMAX Forum. “WiMAX End-to-End Network Systems Architecture - 3GPP/
WiMAX Interworking”. Release 1; 2006.
YANKOV, Svetoslav. WIETHOELTER, Sven. “Handover Blackout Duration of Layer
3 Mobility Management Schemes”. Berlin, Maio, 2006.
108
Anexos //Cenario – Tássio C. – 03/2009 #define debug values Mac/802_16 set debug_ 0 Mac/802_16 set print_stats_ 0 Mac/802_16 set t21_timeout_ 20 #Fix: instead of using the send-scan manually, use a link going down trigger Mac/802_16 set lgd_factor_ 1.8 ;#note: the higher the value the earlier the trigger Mac/802_16 set client_timeout_ 60 ;#to avoid BS disconnecting the SS Mac/802_16 set scan_duration_ 50 ;#Mac/802_16 set scan_duration_ 50 Mac/802_16 set interleaving_interval_ 50 ;#The number of frames interleaved between two scanning iterations. Mac/802_16 set scan_iteration_ 2 ;#Set the number of iterations to perform scanning. Mac/802_16 set nbr_adv_interval_ 0.1 ;#in seconds The interval time between two MOB_NBR-ADV messages Mac/802_16 set scan_req_retry_ 3 ;#Set the number of retransmissions for MOB_SCAN-REQ Agent/WimaxCtrl set adv_interval_ 0.1 Agent/WimaxCtrl set default_association_level_ 0 Agent/WimaxCtrl set synch_frame_delay_ 0.5 Agent/WimaxCtrl set debug_ 0 set opt(chan) Channel/WirelessChannel ;# channel type set opt(prop) Propagation/TwoRayGround ;# radio-propagation model set opt(netif) Phy/WirelessPhy/OFDM ;# network interface type set opt(mac) Mac/802_16 ;# MAC type set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type set opt(ll) LL ;# link layer type set opt(ant) Antenna/OmniAntenna ;# antenna model set opt(ifqlen) 50 ;# max packet in ifq set opt(adhocRouting) AODV ;# routing protocol (use AODV or DSDV) set opt(x) 4500 ;# x coordinate of topology set opt(y) 4500 ;# y coordinate of topology set opt(stop) 200 ;# time to stop simulation # ====================================================================== set max_fragmented_size 1024 #add udp header(8 bytes) and IP header (20bytes) set packetSize 1052 Phy/WirelessPhy set Pt_ 0.032 Phy/WirelessPhy set RXThresh_ 2.0235e-12 ; Phy/WirelessPhy set CSThresh_ [expr 0.9*[Phy/WirelessPhy set RXThresh_]] #Created by Matthias Schneider and Ahmad Saeed
109
proc stop {} { global ns_ tracefd namtrace $ns_ flush-trace close $tracefd close $namtrace exit 0 } # Create simulator instance set ns_ [new Simulator] # Setup hierarchical routing (neccesary for wired-cum-wireless) $ns_ node-config -addressType hierarchical $ns_ node-config -MPLS ON AddrParams set domain_num_ 6 ;# number of domains AddrParams set cluster_num_ {1 2 2 2 3 1} ;# number of clusters in each domain AddrParams set nodes_num_ {1 1 2 1 1 1 2 1 3 2 1} ;# number of nodes in each cluster # Setup tracing set tracefd [open wimax-mpls.tr w] set namtrace [open wimax-mpls.nam w] $ns_ trace-all $tracefd $ns_ namtrace-all-wireless $namtrace $opt(x) $opt(y) $ns_ set-animation-rate 10ms set topo [new Topography] $topo load_flatgrid $opt(x) $opt(y) create-god 6 set node(6) [$ns_ node 4.0.0]; $node(6) set X_ 2500.0; $node(6) set Y_ 2000.0; $node(6) set Z_ 0.0 ; $ns_ add-to-mpls-list $node(6) set node(9) [$ns_ node 3.0.0]; $node(9) set X_ 3500.0; $node(9) set Y_ 2000.0; $node(9) set Z_ 0.0 ; $ns_ add-to-mpls-list $node(9) set node(8) [$ns_ node 3.1.0]; $node(8) set X_ 4000.0; $node(8) set Y_ 1500.0; $node(8) set Z_ 0.0 ; $ns_ add-to-mpls-list $node(8) set node(5) [$ns_ node 4.2.0]; $node(5) set X_ 3000.0; $node(5) set Y_ 1500.0; $node(5) set Z_ 0.0 $ns_ add-to-mpls-list $node(5) set node(12) [$ns_ node 2.0.0]; $node(12) set X_ 2500.0; $node(12) set Y_ 2500.0; $node(12) set Z_ 0.0 $ns_ add-to-mpls-list $node(12) set node(11) [$ns_ node 1.0.0]; $node(11) set X_ 3500.0; $node(11) set Y_ 2500.0; $node(11) set Z_ 0.0 $ns_ add-to-mpls-list $node(11)
110
set node(4) [$ns_ node 4.1.0]; $node(4) set X_ 2000.0; $node(4) set Y_ 1500.0; $node(4) set Z_ 0.0 $ns_ add-to-mpls-list $node(4) set node(13) [$ns_ node 2.1.0]; $node(13) set X_ 2000.0; $node(13) set Y_ 2500.0; $node(13) set Z_ 0.0 $ns_ add-to-mpls-list $node(13) # !!! little hack !!! # Use a wireless node for HomeAgent because wired node's mobileIP # doesn't yet support hierarchical routing $ns_ node-config -mobileIP ON \ -adhocRouting DumbAgent \ -llType $opt(ll) \ -macType Mac/802_16/BS \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channel [new $opt(chan)] \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace OFF \ -routerTrace OFF \ -macTrace OFF set node(10) [$ns_ node 1.1.0]; $node(10) set X_ 4000.0; $node(10) set Y_ 2500.0; $node(10) set Z_ 0.0 $ns_ add-to-mpls-list $node(10) [$node(10) set mac_(0)] set-channel 0 #Fix: add MOB_SCN handler set wimaxctrl [new Agent/WimaxCtrl] $wimaxctrl set-mac [$node(10) set mac_(0)] $ns_ attach-agent $node(10) $wimaxctrl puts "Base Station 0 created" # Set some aliases set HA1 $node(10) ;# HomeAgent set CN1 $node(13) ;# CorrespondingNode # Something for nam $node(12) label "R" $node(11) label "R" $node(4) label "R" $node(5) label "R" $node(8) label "R" $node(9) label "R" $node(6) label "R" $node(13) color red $node(13) label "CN" $node(10) color blue $HA1 label "HA" # Create access point(s)
111
$ns_ node-config -mobileIP ON \ -adhocRouting $opt(adhocRouting) \ -llType $opt(ll) \ -macType Mac/802_16/BS \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channel [new $opt(chan)] \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace OFF \ -routerTrace ON \ -macTrace OFF \ -EotTrace ON set node(7) [$ns_ node 3.1.1]; $node(7) set X_ 4500.0; $node(7) set Y_ 1000.0; $node(7) set Z_ 0.0; $node(7) random-motion 0 $ns_ add-to-mpls-list $node(7) [$node(7) set mac_(0)] set-channel 0 #Fix: add MOB_SCN handler set wimaxctrl7 [new Agent/WimaxCtrl] $wimaxctrl7 set-mac [$node(7) set mac_(0)] $ns_ attach-agent $node(7) $wimaxctrl7 puts "Base Station 7 created" set node(3) [$ns_ node 4.2.1]; $node(3) set X_ 3500.0; $node(3) set Y_ 1000.0; $node(3) set Z_ 0.0; $node(3) random-motion 0 $ns_ add-to-mpls-list $node(3) [$node(3) set mac_(0)] set-channel 0 #Fix: add MOB_SCN handler set wimaxctrl3 [new Agent/WimaxCtrl] $wimaxctrl3 set-mac [$node(3) set mac_(0)] $ns_ attach-agent $node(3) $wimaxctrl3 puts "Base Station 3 created" set node(2) [$ns_ node 5.0.0]; $node(2) set X_ 1500.0; $node(2) set Y_ 1000.0; $node(2) set Z_ 0.0; $node(2) random-motion 0 $ns_ add-to-mpls-list $node(2) [$node(2) set mac_(0)] set-channel 0 #Fix: add MOB_SCN handler set wimaxctrl2 [new Agent/WimaxCtrl] $wimaxctrl2 set-mac [$node(2) set mac_(0)] $ns_ attach-agent $node(2) $wimaxctrl2 puts "Base Station 2 created" set node(1) [$ns_ node 4.1.1]; $node(1) set X_ 2500.0; $node(1) set Y_ 1000.0; $node(1) set Z_ 0.0; $node(1) random-motion 0 $ns_ add-to-mpls-list $node(1) [$node(1) set mac_(0)] set-channel 0 #Fix: add MOB_SCN handler set wimaxctrl1 [new Agent/WimaxCtrl] $wimaxctrl1 set-mac [$node(1) set mac_(0)] $ns_ attach-agent $node(1) $wimaxctrl1 puts "Base Station 1 created"
112
#Fix: Add neighbor information to the BSs $wimaxctrl add-neighbor [$node(1) set mac_(0)] $node(1) $wimaxctrl1 add-neighbor [$node(10) set mac_(0)] $node(10) $wimaxctrl add-neighbor [$node(2) set mac_(0)] $node(2) $wimaxctrl2 add-neighbor [$node(10) set mac_(0)] $node(10) $wimaxctrl add-neighbor [$node(3) set mac_(0)] $node(3) $wimaxctrl3 add-neighbor [$node(10) set mac_(0)] $node(10) $wimaxctrl add-neighbor [$node(7) set mac_(0)] $node(7) $wimaxctrl7 add-neighbor [$node(10) set mac_(0)] $node(10) $wimaxctrl1 add-neighbor [$node(2) set mac_(0)] $node(2) $wimaxctrl2 add-neighbor [$node(1) set mac_(0)] $node(1) $wimaxctrl2 add-neighbor [$node(3) set mac_(0)] $node(3) $wimaxctrl3 add-neighbor [$node(2) set mac_(0)] $node(2) $wimaxctrl3 add-neighbor [$node(7) set mac_(0)] $node(7) $wimaxctrl7 add-neighbor [$node(3) set mac_(0)] $node(3) # Something for nam $node(7) color blue $node(3) color blue $node(2) color blue $node(1) color blue $node(7) label "FA" $node(3) label "FA" $node(2) label "FA" $node(1) label "FA" # Create mobile node(s) $ns_ node-config -MPLS OFF $ns_ node-config -macType Mac/802_16/SS \ -wiredRouting OFF \ -macTrace ON set node(0) [$ns_ node 1.1.1]; $node(0) set X_ 1630.0; $node(0) set Y_ 900.0; $node(0) set Z_ 0.0; $node(0) random-motion 0 [$node(0) set regagent_] set home_agent_ [AddrParams addr2id [$HA1 node-addr]] #$node(0) base-station [AddrParams addr2id [$node(1) node-addr]] ;# optional [$node(0) set mac_(0)] set-channel 0 $node(0) label "MN" $ns_ initial_node_pos $node(0) 10 # Create links $ns_ duplex-link $node(4) $node(2) 10Mb 700ms CBQ $ns_ duplex-link $node(4) $node(1) 10Mb 700ms CBQ $ns_ duplex-link-op $node(4) $node(2) orient left-down $ns_ duplex-link-op $node(4) $node(1) orient right-down $ns_ duplex-link $node(3) $node(5) 10Mb 700ms CBQ $ns_ duplex-link-op $node(5) $node(3) orient right-down $ns_ duplex-link $node(5) $node(6) 10Mb 700ms CBQ $ns_ duplex-link $node(4) $node(6) 10Mb 700ms CBQ $ns_ duplex-link-op $node(6) $node(4) orient left-down $ns_ duplex-link-op $node(6) $node(5) orient right-down
113
$ns_ duplex-link $node(8) $node(9) 10Mb 700ms CBQ $ns_ duplex-link $node(7) $node(8) 10Mb 700ms CBQ $ns_ duplex-link-op $node(9) $node(8) orient right-down $ns_ duplex-link-op $node(8) $node(7) orient right-down $ns_ duplex-link $node(13) $node(12) 10Mb 700ms CBQ $ns_ duplex-link-op $node(13) $node(12) orient right $ns_ duplex-link $node(12) $node(6) 10Mb 700ms CBQ $ns_ duplex-link-op $node(12) $node(6) orient down $ns_ duplex-link $node(11) $node(12) 10Mb 700ms CBQ $ns_ duplex-link-op $node(12) $node(11) orient right $ns_ duplex-link $node(9) $node(11) 10Mb 700ms CBQ $ns_ duplex-link-op $node(11) $node(9) orient down $ns_ duplex-link $node(10) $node(11) 10Mb 700ms CBQ $ns_ duplex-link-op $node(11) $node(10) orient right $ns_ at 5.0 "$node(0) setdest 4400.0 900.0 30.0" $ns_ at 170.0 "$node(0) setdest 1000.0 900.0 30.0" # setup TCP connections between a wired node and the MobileHost $ns_ color 1 red $ns_ color 2 green #################################################################################### set udp1 [new Agent/myUDP] $ns_ attach-agent $CN1 $udp1 $udp1 set packetSize_ $packetSize $udp1 set_filename sd_a01 set null1 [new Agent/myEvalvid_Sink] $ns_ attach-agent $node(0) $null1 $ns_ connect $udp1 $null1 $null1 set_filename rd_a01 set original_file_name st_a01 set trace_file_name video1.dat set original_file_id [open $original_file_name r] set trace_file_id [open $trace_file_name w]
114
set pre_time 0 while {[eof $original_file_id] == 0} { gets $original_file_id current_line scan $current_line "%d%s%d%d%f" no_ frametype_ length_ tmp1_ tmp2_ set time [expr int(($tmp2_ - $pre_time)*1000000.0)] #set time [expr 1000 * 1000/30] if { $frametype_ == "I" } { set type_v 1 set prio_p 0 } if { $frametype_ == "P" } { set type_v 2 set prio_p 0 } if { $frametype_ == "B" } { set type_v 3 set prio_p 0 } if { $frametype_ == "H" } { set type_v 1 set prio_p 0 } puts $trace_file_id "$time $length_ $type_v $prio_p $max_fragmented_size"
115
set pre_time $tmp2_ } close $original_file_id close $trace_file_id set end_sim_time $tmp2_ puts "$end_sim_time" set trace_file [new Tracefile] $trace_file filename $trace_file_name set video1 [new Application/Traffic/myEvalvid] $video1 attach-agent $udp1 $video1 attach-tracefile $trace_file #-------------------------- $ns_ at 0.0 "$video1 start" $ns_ at 280.4 "$video1 stop" $ns_ at 280.4 "$null1 closefile" $ns_ at 280.4 "stop" puts "Starting Simulation..." $ns_ run
116
/** * MAC802_16BS.cc * Auth State Machine * Tássio Carvalho ([email protected]) */ case WimaxPKMAuthWaitTimerID: // SS cansa de esperar e pede uma AK novamente pkm_fsm_auth(FSM_AUTHE_TIMEOUT); break; case WimaxPKMAuthGraceTimerID: // SS pede uma nova AK porque o prazo da atual vai expirar logo pkm_fsm_auth(FSM_AUTHE_GRACETIMEOUT); break; case WimaxPKMReauthWaitTimerID: // SS cansa de esperar e pede uma AK novamente pkm_fsm_auth(FSM_AUTHE_TIMEOUT); break; case WimaxPKMAuthRejWaitTimerID: // vai! - volta ao start pkm_fsm_auth(FSM_AUTHE_TIMEOUT); break; case WimaxPKMAKTimerID: //...remover a AK antiga pkm_ak_timer_->start(macmib_.pkm_ak_timeout); break; /** * TEK State Machine * Tássio Carvalho ([email protected]) */ case WimaxPKMOpWaitTimerID: //... SS cansa de esperar uma nova TEK e pede uma TEK novamente pkm_fsm_tek(FSM_TEKE_TIMEOUT); break; case WimaxPKMTEKGraceTimerID: //... pedir uma nova TEK porque o prazo da TEK para essa SAID vai expirar logo pkm_fsm_tek(FSM_TEKE_GRACETIMEOUT); break; case WimaxPKMRekeyWaitTimerID: //... SS cansa de esperar uma nova TEK e pede uma TEK novamente pkm_fsm_tek(FSM_TEKE_TIMEOUT); break; case WimaxPKMTEKTimerID: //...remover a TEK antiga pkm_tek_timer_->start(macmib_.pkm_ak_timeout); break; default: debug ("Trigger unkown\n"); break; } }
//. //. //. /** * Inicia o processo de autenticação.
117
* * Processo de autenticação: * X.509 Certificate (public key, certified by CA) -----> Auth Request * AK encrypted with a Public Key -----> Auth Reply * Request TEK for User Data -----> Key Request * Get TEK (encrypted with KEK) -----> Key Reply * * Tássio Carvalho ([email protected]) */ void Mac802_16SS::init_authentication () { debug("A %f seg na Mac %d , SS inicia autenticacao\n", NOW, addr()); setMacState(MAC802_16_AUTHORIZE); setFsmAuthState(FSM_AUTHS_START); pkm_fsm_auth(FSM_AUTHE_CE_1); } /** * Pára todos os cronômetros (útil no handover) * Tássio Carvalho ([email protected]) */ void Mac802_16SS::finish_authentication () { debug ("A %f seg na Mac %d , SS pahra todos os cronometros PKM\n", NOW, addr()); //Pára todos os cronômetros if(pkm_ak_timer_ != NULL && pkm_ak_timer_->expire() > 0) pkm_ak_timer_->stop(); if(pkm_tek_timer_ != NULL && pkm_tek_timer_->expire() > 0) pkm_tek_timer_->stop(); if(pkm_auth_wait_timer_ != NULL && pkm_auth_wait_timer_->expire() > 0) pkm_auth_wait_timer_->stop(); if(pkm_auth_grace_timer_ != NULL && pkm_auth_grace_timer_->expire() > 0) pkm_auth_grace_timer_->stop(); if(pkm_reauth_wait_timer_ != NULL && pkm_reauth_wait_timer_->expire() > 0) pkm_reauth_wait_timer_->stop(); if(pkm_auth_rej_wait_timer_ != NULL && pkm_auth_rej_wait_timer_->expire() > 0) pkm_auth_rej_wait_timer_->stop(); if(pkm_op_wait_timer_ != NULL && pkm_op_wait_timer_->expire() > 0) pkm_op_wait_timer_->stop(); if(pkm_tek_grace_timer_ != NULL && pkm_tek_grace_timer_->expire() > 0) pkm_tek_grace_timer_->stop(); if(pkm_rekey_wait_timer_ != NULL && pkm_rekey_wait_timer_->expire() > 0) pkm_rekey_wait_timer_->stop(); setFsmAuthState(FSM_AUTHS_START); setFsmTekState(FSM_TEKS_START); } /** * Envia mensagens de requisição PKM de acordo com o seu código cod * Tássio Carvalho ([email protected]) */ void Mac802_16SS::send_pkm_req(pkm_code cod) { /// Definicao das variaveis Packet *p = getPacket(); mac802_16_pkm_req_frame *pkm_frame; hdr_mac802_16 *wimaxHdr; struct hdr_cmn *ch;
118
PeerNode *peer = getPeerNode_head(); /// Configuracao do cabecalho do pacote ch = HDR_CMN(p); wimaxHdr = HDR_MAC802_16(p); p->allocdata(sizeof(struct mac802_16_pkm_req_frame)); /// Construção da mensagem pkm_frame = (mac802_16_pkm_req_frame*)p->accessdata(); pkm_frame->type = MAC_PKM_REQ; //acessa o membro header do objeto wimaxHdr para configurar o CID dessa SS wimaxHdr->header.cid = peer->getPrimary(OUT_CONNECTION)->get_cid(); ch->size() += PKM_REQ_SIZE; //porque abaixo vamos inserir a mensagem // condições para poder-se incrementar pkm_id if (cod == PKM_AUTH_INF || cod == PKM_AUTH_REJ || cod == PKM_KEY_REJ || cod == PKM_AUTH_INV || cod == PKM_TEK_INV) pkm_id_ = 0; else if(getFsmAuthState() != FSM_AUTHS_AUTH_WAIT && getFsmAuthState() != FSM_AUTHS_REAUTH_WAIT && getFsmTekState() != FSM_TEKS_OP_WAIT && getFsmTekState() != FSM_TEKS_REKEY_WAIT) pkm_id_++; pkm_frame->pkm_id = pkm_id_; pkm_frame->code = cod; debug("\nA %f na Mac %d , SS enfileira requisicao PKM na conexao %f\n", NOW, addr(), peer->getPrimary(OUT_CONNECTION)->get_cid()); //pkm_fsm_func_trans(pkm_fsm_event e); peer->getPrimary(OUT_CONNECTION)->enqueue(p); //encaminhamento da mensagem } /** * Processa mensagens de resposta PKM vindas da BS * Tássio Carvalho ([email protected]) */ void Mac802_16SS::process_pkm_rsp (mac802_16_pkm_rsp_frame* frame) { PeerNode *peer = getPeerNode_head(); debug2("A %f na Mac %d , SS recebe PKM RSP de cod %d na conexao %d da BS %d \n", NOW, addr(), frame->code, peer->getPrimary(OUT_CONNECTION)->get_cid(), peer->getAddr()); //Que tipo de mensagem de resposta PKM é esse? switch(frame->code) { case PKM_AUTH_REP: if (frame->pkm_id != pkm_id_) return; //atraso de simulação na decriptação da AK recebida if(!de_callback) { //parar o cronômetro de espera pkm_auth_wait_timer_->stop(); //... inserir atraso de simulação na decriptação da AK recebida
119
delay_event_ = new Event(); delay_handler_ = new DelayEventHandler(this, FSM_AUTHE_AUTH_REP); *(delay_handler_->frame) = *frame; delay_event_->handler_ = delay_handler_; de_callback = true; Scheduler::instance().schedule(delay_handler_, delay_event_, macmib_.delay_interv_ak_decr); break; } de_callback = false; // se(getMacState() == MAC802_16_REAUTH_WAIT) então tratar de remover e/ou adicionar as novas TEKs //estado resultante da FSM AUTH setFsmAuthState(FSM_AUTHS_AUTHORIZED); //dar inÃcio à máquina de estados TEK pkm_fsm_tek(FSM_TEKE_AUTHORIZED); // Afinal, não é responsabilidade da BS remover a AK? Então, é responsabilidade dela tambem o cronometro para isso //if(pkm_ak_timer_ == NULL) pkm_ak_timer_ = new WimaxPKMAKTimer(this); // pkm_ak_timer_->start(macmib_.pkm_ak_timeout); // A SS só tem a responsabilidade de se manifestar "Auth Grace Timeout" segundos antes da expiração if(pkm_auth_grace_timer_ == NULL) pkm_auth_grace_timer_ = new WimaxPKMAuthGraceTimer(this); pkm_auth_grace_timer_->start(macmib_.pkm_ak_timeout - macmib_.pkm_auth_grace_timeout); break; case PKM_AUTH_REJ: break; case PKM_KEY_REP: if (frame->pkm_id != pkm_id_) return; //atraso de simulação na decriptação da TEK recebida if(!de_callback) { if(getFsmTekState() == FSM_TEKS_OP_WAIT) pkm_op_wait_timer_->stop(); else if(getFsmTekState() == FSM_TEKS_REKEY_WAIT) pkm_rekey_wait_timer_->stop(); //... inserir atraso de simulação na decriptação da TEK recebida delay_handler_ = new DelayEventHandler(this, FSM_TEKE_KEY_REP); *(delay_handler_->frame) = *frame; delay_event_ = new Event(); delay_event_->handler_ = delay_handler_; de_callback = true; Scheduler::instance().schedule(delay_handler_, delay_event_, macmib_.delay_interv_tek_decr); break; } de_callback = false;
120
// Afinal, não é responsabilidade da BS remover a TEK? Então, é responsabilidade dela tambem o cronometro para isso //if(pkm_tek_timer_ == NULL) pkm_tek_timer_ = new WimaxPKMTEKTimer(this); // pkm_tek_timer_->start(macmib_.pkm_tek_timeout); // A SS só tem a responsabilidade de se manifestar "Auth Grace Timeout" segundos antes da expiração if(pkm_tek_grace_timer_ == NULL) pkm_tek_grace_timer_ = new WimaxPKMTEKGraceTimer(this); pkm_tek_grace_timer_->start(macmib_.pkm_tek_timeout - macmib_.pkm_tek_grace_timeout); setFsmTekState(FSM_TEKS_OP); //Faz registro somente na primeira autenticacao //if(!primeira_autenticacao) break; // //primeira_autenticacao = false; //Faz registro somente na primeira autenticação if(getMacState() != MAC802_16_AUTHORIZE) break; //registration must be sent using Primary Management CID setMacState (MAC802_16_REGISTER); nb_reg_retry_ = 0; //first time sending send_registration(); break; case PKM_KEY_REJ: break; case PKM_TEK_INV: break; case PKM_AUTH_INV: break; default: break; } } /** * Função de transição para as máquinas * de estados de autorizacao e TEK. * IMPORTANTE: Para os "eventos" de mensagem * recebida (AUTH REP, TEK REP etc), estas funcoes de * transicao nao sao utilizadas (em seu lugar, e chamado * o metodo process_pkm_rsp); e necessario, entao, * mudar o estado da camada MAC atraves de setMacState() * Tássio Carvalho ([email protected]) */ void Mac802_16SS::pkm_fsm_auth(Pkm_Fsm_Event e) { switch(getFsmAuthState()) { case FSM_AUTHS_START: switch(e) { case FSM_AUTHE_CE_1: send_pkm_req(PKM_AUTH_INF); pkm_fsm_auth(FSM_AUTHE_CE_2); break;
121
case FSM_AUTHE_CE_2: send_pkm_req(PKM_AUTH_REQ); setFsmAuthState(FSM_AUTHS_AUTH_WAIT); if (pkm_auth_wait_timer_ == NULL) pkm_auth_wait_timer_ = new WimaxPKMAuthWaitTimer(this); pkm_auth_wait_timer_->start(macmib_.pkm_auth_wait_timeout); break; default: break; } break; case FSM_AUTHS_AUTH_WAIT: switch(e) { case FSM_AUTHE_AUTH_REJ: setFsmAuthState(FSM_AUTHS_AUTH_REJ_WAIT); break; case FSM_AUTHE_PERM_AUTH_REJ: setFsmAuthState(FSM_AUTHS_SILENT); break; case FSM_AUTHE_TIMEOUT: send_pkm_req(PKM_AUTH_REQ); if (pkm_auth_wait_timer_ == NULL) pkm_auth_wait_timer_ = new WimaxPKMAuthWaitTimer(this); pkm_auth_wait_timer_->start(macmib_.pkm_auth_wait_timeout); break; default: break; } break; case FSM_AUTHS_AUTHORIZED: switch(e) { case FSM_AUTHE_GRACETIMEOUT: send_pkm_req(PKM_AUTH_REQ); setFsmAuthState(FSM_AUTHS_REAUTH_WAIT); if (pkm_reauth_wait_timer_ == NULL) pkm_reauth_wait_timer_ = new WimaxPKMReauthWaitTimer(this); pkm_auth_wait_timer_->start(macmib_.pkm_auth_wait_timeout); break; case FSM_AUTHE_AUTH_INV: send_pkm_req(PKM_AUTH_REQ); setFsmAuthState(FSM_AUTHS_REAUTH_WAIT); if (pkm_reauth_wait_timer_ == NULL) pkm_reauth_wait_timer_ = new WimaxPKMReauthWaitTimer(this); pkm_auth_wait_timer_->start(macmib_.pkm_auth_wait_timeout); break; case FSM_AUTHE_REAUTH: send_pkm_req(PKM_AUTH_REQ); setFsmAuthState(FSM_AUTHS_REAUTH_WAIT); if (pkm_reauth_wait_timer_ == NULL) pkm_reauth_wait_timer_ = new WimaxPKMReauthWaitTimer(this); pkm_reauth_wait_timer_->start(macmib_.pkm_reauth_wait_timeout); break; default: break; }
122
break; case FSM_AUTHS_REAUTH_WAIT: switch(e) { case FSM_AUTHE_AUTH_REJ: pkm_auth_wait_timer_->stop(); pkm_fsm_tek(FSM_TEKE_STOP); setFsmAuthState(FSM_AUTHS_AUTH_REJ_WAIT); break; case FSM_AUTHE_PERM_AUTH_REJ: pkm_auth_wait_timer_->stop(); pkm_fsm_tek(FSM_TEKE_STOP); setFsmAuthState(FSM_AUTHS_SILENT); //...agora, aqui, silenciar a SS break; case FSM_AUTHE_TIMEOUT: send_pkm_req(PKM_AUTH_REQ); if (pkm_reauth_wait_timer_ == NULL) pkm_reauth_wait_timer_ = new WimaxPKMReauthWaitTimer(this); pkm_reauth_wait_timer_->start(macmib_.pkm_reauth_wait_timeout); break; case FSM_AUTHE_AUTH_INV: pkm_fsm_tek(FSM_TEKE_AUTH_PEND); // so pra TEK que gerou o AUTH INV break; default: break; } break; case FSM_AUTHS_AUTH_REJ_WAIT: switch(e) { case FSM_AUTHE_TIMEOUT: setFsmAuthState(FSM_AUTHS_START); pkm_fsm_auth(FSM_AUTHE_CE_1); // pergunta: sera que o evento CE realmente acontecera? // resposta: sim, porque a condicao para que ela aconteca eh que // a negociacao de capacidades basicas tenha sido feita com sucesso break; default: break; } break; case FSM_AUTHS_SILENT: // o que fazer? break; } } void Mac802_16SS::pkm_fsm_tek(Pkm_Fsm_Event e) { switch(getFsmTekState()) { case FSM_TEKS_START: //pedir as chaves TEK send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_OP_WAIT); if(pkm_op_wait_timer_ == NULL) pkm_op_wait_timer_ = new WimaxPKMOpWaitTimer(this);
123
pkm_op_wait_timer_->start(macmib_.pkm_op_wait_timeout); break; case FSM_TEKS_OP_WAIT: switch(e) { case FSM_TEKE_STOP: pkm_op_wait_timer_->stop(); setFsmTekState(FSM_TEKS_START); break; case FSM_TEKE_AUTH_PEND: pkm_op_wait_timer_->stop(); setFsmTekState(FSM_TEKS_OP_REAUTH_WAIT); break; case FSM_TEKE_TIMEOUT: send_pkm_req(PKM_KEY_REQ); if (pkm_op_wait_timer_ == NULL) pkm_op_wait_timer_ = new WimaxPKMOpWaitTimer(this); pkm_op_wait_timer_->start(macmib_.pkm_op_wait_timeout); break; default: break; } break; case FSM_TEKS_OP_REAUTH_WAIT: switch(e) { case FSM_TEKE_STOP: pkm_op_wait_timer_->stop(); setFsmTekState(FSM_TEKS_START); break; case FSM_TEKE_AUTH_COMP: send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_OP_WAIT); if (pkm_op_wait_timer_ == NULL) pkm_op_wait_timer_ = new WimaxPKMOpWaitTimer(this); pkm_op_wait_timer_->start(macmib_.pkm_op_wait_timeout); break; default: break; } break; case FSM_TEKS_OP: switch(e) { case FSM_TEKE_STOP: pkm_tek_timer_->stop(); setFsmTekState(FSM_TEKS_START); //... remover aqui o material de encriptação da SAID break; case FSM_TEKE_TEK_INV: pkm_tek_timer_->stop(); send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_OP_WAIT); if (pkm_op_wait_timer_ == NULL) pkm_op_wait_timer_ = new WimaxPKMOpWaitTimer(this); pkm_op_wait_timer_->start(macmib_.pkm_op_wait_timeout); //... remover aqui o material de encriptação da SAID break; case FSM_TEKE_REFRESH_TIMEOUT:
124
send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_REKEY_WAIT); if (pkm_rekey_wait_timer_ == NULL) pkm_rekey_wait_timer_ = new WimaxPKMRekeyWaitTimer(this); pkm_rekey_wait_timer_->start(macmib_.pkm_rekey_wait_timeout); break; default: break; } break; case FSM_TEKS_REKEY_WAIT: switch(e) { case FSM_TEKE_STOP: pkm_op_wait_timer_->stop(); //... remover aqui o material de encriptação da SAID setFsmTekState(FSM_TEKS_START); break; case FSM_TEKE_AUTH_PEND: pkm_op_wait_timer_->stop(); setFsmTekState(FSM_TEKS_REKEY_REAUTH_WAIT); break; case FSM_TEKE_TEK_INV: pkm_tek_timer_->stop(); send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_OP_WAIT); if (pkm_op_wait_timer_ == NULL) pkm_op_wait_timer_ = new WimaxPKMOpWaitTimer(this); pkm_op_wait_timer_->start(macmib_.pkm_op_wait_timeout); break; case FSM_TEKE_TIMEOUT: send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_REKEY_WAIT); if (pkm_rekey_wait_timer_ == NULL) pkm_rekey_wait_timer_ = new WimaxPKMRekeyWaitTimer(this); pkm_rekey_wait_timer_->start(macmib_.pkm_rekey_wait_timeout); break; default: break; } break; case FSM_TEKS_REKEY_REAUTH_WAIT: switch(e) { case FSM_TEKE_STOP: //... remover aqui o material de encriptação da SAID setFsmTekState(FSM_TEKS_START); break; case FSM_TEKE_AUTH_COMP: send_pkm_req(PKM_KEY_REQ); setFsmTekState(FSM_TEKS_REKEY_WAIT); if (pkm_rekey_wait_timer_ == NULL) pkm_rekey_wait_timer_ = new WimaxPKMRekeyWaitTimer(this); pkm_rekey_wait_timer_->start(macmib_.pkm_rekey_wait_timeout); break;
125
case FSM_TEKE_TEK_INV: //... remover aqui o material de encriptação da SAID setFsmTekState(FSM_TEKS_OP_REAUTH_WAIT); break; default: break; } break; default: break; } }
126
/** * MAC802_16SS.cc * Método de primeira etapa de processamento de mensagem PKM * Tássio C ([email protected]) */ void Mac802_16BS::process_pkm_req_1 (Packet *req) { hdr_mac802_16 *wimaxHdr_req = HDR_MAC802_16(req); gen_mac_header_t header_req = wimaxHdr_req->header; switch(((mac802_16_pkm_req_frame*)req->accessdata())->code) { case PKM_AUTH_REQ: debug ("received AUTH REQ from %d\n", header_req.cid); //...inserir atraso de decriptação de mensagem PKM_AUTH_REQ //...inserir atraso de encriptação de mensagem PKM_AUTH_REP //delay_handler_ = new DelayEventHandler(this, req); delay_handler_ = new DelayEventHandler(this, req->copy()); delay_event_ = new Event(); delay_event_->handler_ = delay_handler_; Scheduler::instance().schedule(delay_handler_, delay_event_, macmib_.delay_interv_ak_decr + macmib_.delay_interv_ak_encr); break; case PKM_KEY_REQ: debug ("received KEY REQ from %d\n", header_req.cid); //...inserir atraso de decriptação de mensagem PKM_KEY_REQ //...inserir atraso de encriptação de mensagem PKM_KEY_REP delay_handler_ = new DelayEventHandler(this, req->copy()); delay_event_ = new Event(); delay_event_->handler_ = delay_handler_; Scheduler::instance().schedule(delay_handler_, delay_event_, macmib_.delay_interv_tek_decr + macmib_.delay_interv_tek_encr); break; default: break; } } /** * Método de segunda etapa de processamento de mensagem PKM * Tássio C ([email protected]) */ void Mac802_16BS::process_pkm_req_2 (Packet *req) { hdr_mac802_16 *wimaxHdr_req = HDR_MAC802_16(req); gen_mac_header_t header_req = wimaxHdr_req->header; // Definicao das variaveis Packet *p; PeerNode *peer; // Definido no mac802_16pkt.h
127
mac802_16_pkm_req_frame *req_frame; mac802_16_pkm_rsp_frame *rsp_frame; hdr_mac802_16 *wimaxHdr; struct hdr_cmn *ch; // Cria pacote para respota p = getPacket (); ch = HDR_CMN(p); wimaxHdr = HDR_MAC802_16(p); p->allocdata (sizeof (struct mac802_16_pkm_rsp_frame)); rsp_frame = (mac802_16_pkm_rsp_frame*) p->accessdata(); rsp_frame->type = MAC_PKM_RSP; req_frame = (mac802_16_pkm_req_frame*)req->accessdata(); switch(req_frame->code) { case PKM_AUTH_REQ: //se tudo estiver certo, então... rsp_frame->code = PKM_AUTH_REP; break; case PKM_KEY_REQ: //se tudo estiver certo, então... rsp_frame->code = PKM_KEY_REP; break; default: break; } rsp_frame->pkm_id = req_frame->pkm_id; peer = getCManager()->get_connection (header_req.cid, IN_CONNECTION)->getPeerNode(); wimaxHdr->header.cid = header_req.cid; ch->size() += PKM_RSP_SIZE; //enqueue packet..must be replaced with second line later peer->getPrimary(OUT_CONNECTION)->enqueue(p); } // Fim do X.509
