Roteamento e Mobilidade Roteiro -...

1

Roteamento e Mobilidade (IP Móvel)

Referências:   J.D. Solomon, MobileIP: The Internet Unplugged   RFC 2002 (Protocolo IP Móvel)   RFC 2003-2004 (Técnicas de Tunelamento)   RFC 2006 (Mobile IP MIB)   D. Johnson and D. Maltz. "Protocols for Adaptive Wireless and Mobile Networking", IEEE Personal Communication, 3(1), February 1996   B. Lancki, A. Dixit, V. Gupta, "Mobile-IP: Supporting Transparent Host Migration on the Internet," Linux Journal, June 1996

© Markus Endler, alterado com autorização do mesmo 2

Roteiro  Motivação  Breve revisão de Roteamento IP  Motivação e Problemas  Funcionamento básico

  Anúncio de Alcançabilidade   Registro de Binding   Tunelamento

 Aspectos de Segurança  O Papel do ARP  Otimização de Rotas  Gerenciamento de Mobilidade no IPv6


Motivação

 Pessoa que quer manter correspondência  Vários destinatários/remetentes

 O envio é um problema ?  Como receber cartas

 Protocolo preciso  Técnica cartão postal  Técnica do faire suivre  Mais ideias ?


As sete camadas OSI

 Camada de Física - bits  Camada de Enlace - datagramas  Camada Rede - roteamento  Camada de Transporte – início, meio (quebra) e

fim  Camada de Sessão  Camada de Apresentação  Camada de Aplicação


Roteamento IP

 Tarefa & Características  Encaminhar datagramas IP até o host destino  Datagramas IP podem ser perdidos, replicados ou

conter erros  Protocolo hop-by-hop: cada roteador escolhe

próximo hop para cada datagrama baseado em sua tabela de roteamento

 Endereços (32 bits) dependem do local (em qual sub-rede o host se encontra)

 Roteamento baseado em prefixo


Datagrama IPv4

VERS: versão do protocolo IP que foi usada para criar o datagrama (4bits) SERVICE-TYPE: este campo especifica como o datagrama deve ser manejado Total Length: Tamanho do cabeçalho, geralmente 5x32bits TTL: Campo que é decrementado ao passar por roteador HEADER CHECKSUM: Verifica se o cabeçalho está OK

2


Datagrama IPv6

Menos informação (não tem checksum: confiança nas camadas inferiores) Version: VERS: versão do protocolo IP que foi usada para criar o datagrama (4bits) Traffic Class: QoS O endereçamento no IPv6 é de 128 bits


Tabela de Roteamento  Cada entrada consiste de

[prefix, pref-length, nexthop, IntfaceID]  Tipos de entrada:

 Host-specific: entrega em 1 hop  Network specific: encaminhamento para outro

roteador  Default

Target Leng nextHop Interface 2.0.0.128 32 direct A 3.0.0.0 8 direct B 1.0.0.0 8 router X B 0.0.0.0 0 router X B

A 2.0.0.128

2.0.0.254

Y B X

3.0.0.253 3.0.0.252

1.0.0.*

1.0.0.254

Tabela de Y

3.0.0.*

Host-specific Host-specific Network-prefix Default


O Algoritmo Escolha interface /próximo hop para pacote destinado a

IP.Dest:   Use interface para a qual existe uma entrada “host-

specific” com target = IP.Dest   Senão escolha entrada “network-prefix” que coincida

com o IP.Dest no maior prefixo possível   Senão escolha qualquer uma das entradas “default”   Senão notifique o host fonte do erro de roteamento

(msg ICMP “Unreacheable”)

Obs: ICMP – Internet Control Message Protocol (é uma componente de IP) e é usado para diagnóstico & notificações de erros


Arquitetura (visão geral)

http://www.gta.ufrj.br/~rezende/cursos/coe727/aulas-coe727/


Address Resolution Protocol (ARP)

Objetivo: descobrir o endereço MAC dado o seu endereço IP

  Mensagens:  ARPRequest(IP) é enviado pelo destinatário (p.ex.

Roteador)  O host com o IP procurado responde com ARPReply

(MAC-Addr) Requisitante guarda a associação (IPAddr, MACAddr) em

um ARPCache durante um tempo de validade Obs:   Um ARPProxy pode responder por um host   Um novo host que é ligado à rede pode enviar um

“ARPReply espontâneo” © Markus Endler, alterado com autorização do mesmo 12

Vantagens do Roteamento IP

 Tabelas de roteamento com menos entradas  Atualização das entradas pode ser feita entre os

roteadores e não requer muitas mensagens  Nem todo roteador precisa ter todos os

possíveis prefixos (# possíveis prefixos de rede em IPv4: ±4 milhões)

Portanto, roteamento baseado em prefixos garante a sua escalabilidade

3


Problemas ligados a mobilidade

Nós na internet são identificados por um endereço IP  Roteamento é feito usando o mesmo endereço IP

(identidade = localização) Possibilidades:  Nó tem que mudar o seu endereço IP a cada vez

que se conecta a um novo ponto de acesso   Requer que protocolos de camadas superiores tenham

que tratar esta mudança  Rotas específicas para cada host precisariam ser

propagadas pela rede  Tornaria tabelas de roteamento imensas não é

escalável


Roteamento IP e Mobilidade Por que roteamento IP não funciona para hosts móveis?   MH irá se conectar a diferentes sub-redes   Roteamento IP é baseado no prefixo, que depende da

localização do host Por que o MH não troca de IP cada vez que se conecta à

rede?   Autenticação e protocolos de camadas superiores

requerem que MH mantenha um endereço IP fixo Mobilidade de hosts vai contra a principal regra do

roteamento IP: “Datagramas IP são encaminhados na direção dos

roteadores que anunciam a presença do prefixo de rede do endereço destino”


Exemplo O que acontece se um MH com pref1 se conecta a uma

sub-rede com pref2.

R1

R2

R3 3.0.0.*

2.0.0.*

4.0.0.*

2.0.0.55

Target Leng nextHop Interface 1.0.0.128 24 direct A 3.0.0.0 24 direct C 2.0.0.0 24 R2 C 4.0.0.0 24 R3 C

A C 1.0.0.*

2.0.0.55


Possíveis Alternativas Tratamento no nível de enlace (transparente para

o nível de rede)   Cellular Digital Packet Data – CDPD

  Serviço IP baseado no AMPS (advanced mobile phone services)

  Cada dispositivo recebe um IP fixo, e entrega de datagramas IP é feita pela operadora celular

  só na área de cobertura   Tarifação por pacote (sempre ligado)   Dispositivo precisa ser CDPD compatível


Possíveis Alternativas 2.  IEEE 802.11

  Usa endereço MAC e SSIDs (service self identifier) para identificar nós e redes

  Hand-off inter-BSS (basic service set) transfere controle de um ponto de acesso para outro (Mobilidade no nível MAC)

  Para funcionar entre subredes, precisa handover inter-ESS (extended service set)

Para ser amplamente utilizável, mobilidade e

roteamento precisam ser tratados no nível de rede!


IP Móvel: Requisitos de Projeto Um MH deve:

 ser capaz de se comunicar com outros nós independente de seu ponto de acesso, mas sem modificar o seu endereço IP

 ser capaz de se comunicar com outros nós que não implementem IP Móvel

 usar autenticação para evitar ataques de redirecionamento

 IP Móvel deve gerar pouco overhead ( economia de largura de banda e energia)

 IP Móvel não deve impor restrições adicionais para a atribuição de endereços IP

 Deve poder ser colocado em ação on the fly

4


Terminologia  Nó móvel (ou MH):: um host ou roteador que

muda o seu ponto de acesso (point of attachement), mas interage com os demais nós usando o seu endereço IP fixo

 Home Agent (HA):: um roteador na rede home (home network) do MH que reencaminha datagramas (tunel) para o MH quando este está conectado em outra rede

 Foreign Agent (FA):: um roteador na rede visitada pelo MH (visited network) que provê os serviços de entrega de datagramas enquanto o MH está registrado


Terminologia

  Care-of-address (coa): um novo endereço IP recebido pelo MH na rede visitada, que é usado para entregar datagramas ao MH. Pode ser   o endereço IP do FA   um endereço IP do próprio MH (co-located)

Portanto, cada MH tem 2 endereços:  IP fixo: para identificação, e entrega quando estiver

na home network  Coa: endereço IP no máximo a 1 hop do MH, para

roteamento quando estiver em visita a uma rede


Funcionamento Básico

Internet

Home Network

A

Home Agent (HA)

Visited Network

A

Foreign Agent (FA)

Source


Overview do Protocolo   Anúncio de Alcançabilidade (Advertisement):

 Agentes de Mobilidade (HA e FA) devem anunciar os seus serviços  Um MH pode solicitar o serviço de um agente de mobilidade

  Registro (Binding):  Quando um MH está em uma rede visitada, deve registrar o seu

coa junto ao seu HA   Entrega de Datagramas (Tunelamento):

 encaminhados do HA para o FA, para que este os entregue ao care-of-address

 mecanismo deve contemplar todos os tipos de datagramas   (incluindo broadcast/multicast)

  para isto, cria-se um túnel


Anúncio e Solicitação   Adaptou-se o protocolo ICMP (para descoberta de

roteadores) para os agentes de mobilidade   Roteadores difundem periodicamente (a cada n

segundos) Anúncios de Alcançabilidade (Agent Advertisements - AA) em todas as subredes das quais fazem parte

  Um MH também pode enviar uma msg de solicitação, que fará com que roteadores próximos difundam AA

  MH obtém um coa (do FA, por DHCP, ou manual)

AA é um pacote ICMP indicando: •  Endereços coa disponíveis •  Validade (lifetime) •  Se é HA ou FA (ou ambos)


Registro (Binding)   MH solicita ao FA que envie uma mensagem

RegistrationRequest (RegRequest) anunciando o coa para o HA  FA pode negar, se coa apresentado não corresponde

a um anunciado, ou se já está tratando muitos MHs   Ao receber do FA um coa (de um MH), o HA cria uma

nova entrada (binding) em uma tabela que associa o home address com o coa do MH; HA confirma a atualização do binding com uma mensagem RegistrationReply

  Cada binding tem um tempo de validade, que precisa ser renovado pelo MH

  Quando volta para o home network, MH deve-se de-registrar (remover o binding)

5


Registro (cont.)

FA oferece o serviço de redirecionamento, que inclui o registro do coa no HA

MH gera RegRequest nas seguintes situações:  Se detecta que está em nova rede  Para renovar a validade do(s) seu(s) binding(s)  Quando FA tiver sido re-inicializado

MH FA RegRequest RegRequest

HA Mh1, coa RegReply RegReply

MH


Registro (cont.)

Campos/Bits do Mobile IP header:   S: criar/remover um binding sem alterar os demais bindings   B: envio tipo broadcast   D: de-tunelamento no MH ou no FA   M/G: Encapsulamento Minimal/ GRE   Home address do MH   Endereço do HA   Care-of-address   ID do Request   Lifetime: solicitação de quanto tempo o binding deve durar (no Request) e

quanto tempo o HA irá manter o binding (no Reply)   Code: se o registro teve sucesso (no Reply) Authentication Extension é usada para a Assinatura Digital

UDP header MobileIP header Mobile Authentication Extension

Estrutura das mensagens Registration Request&Reply:


Registro (cont.) Papel de cada elemento no protocolo de registro:  MH:

 envia o RegRequest para o endereço MAC do FA. Descobre este através dos AA

 FA:  Verifica se Lifetime está OK, se é capaz de prover

tunelamento requisitado, se existem recursos suficientes, etc.

 Atualiza o seu ARPCache com [ha, MACAddr, porta]  HA:

 Verifica autenticidade do RegRequest  Atualiza a tabela de bindings, de acordo com os

campos coa, Lifetime, e bit S © Markus Endler, alterado com autorização do mesmo 28

Registro

Coa Lifetime bit S Efeito ≠ha >0 0 atualiza todos os bindings pelo coa ≠ha >0 1 apenas cria um novo binding ≠ha 0 1 remove binding do coa, deixa demais inalterados =ha 0 ? remove todos os bindings do MH =ha >0 ? notificação de Erro

Obs: Quando o MH retorna para o home network, o RegRequest

vem com (coa=ha, e Lifetime=0), de forma que todos os bindings devem ser removidos.

Campos do RegRequest


Registro e Segurança

  Para evitar ataques de redirecionamento (datagramas são direcionados para um host como se fosse o FA) HA e MH devem ter uma chave secreta comum  Esta define uma “associação de segurança” entre os dois nós  MH usa esta chave para autenticar o pedido de

redirecionamento   isto não é cifragem do canal (criptografia)

  Por isto, cada RegistrationRequest contém um digest (com uma assinatura digital da mensagem),

  em Mobile IP usa-se Hashing Seguro “Keyed MD5”


Hashing Seguro e MD5

  Uma função de hashing seguro é uma codificação “unidirecional” de um documento para um determinado valor de hash.

  Usando a chave, pode-se gerar repetidamente o valor de hash a partir do documento (valor não revela nada sobre o documento)

  Chave garante baixa probabilidade de colisão  MD5 (128 bit hash value)  SHA-1  RIPEMD-160

doc1

doc2

hash1

hash2

MD5

chave

6


Assinaturas Digitais   Uma assinatura digital é uma maneira de “assinar” um

documento de forma que o receptor e remetente sabem que :   só o fonte autêntica poderia ter gerado a assinatura   o conteúdo da mensagem não pode ter sido alterada

  Obs: Note que a mensagem não é criptografada

Message MD5 encrypt md5 Message

smd5

Message

smd5 decrypt

MD5 md5

md5 Destino compara

Fonte assina


Autenticação de RegistrationRequest   IP Móvel usa autenticação baseada em chave privada

HA A Troca de Chaves

HA

A

Datagram key M D 5

key

Datagram md5 ip Datagram md5

Datagram key key

Compara


Entrega de Datagramas

 Uma vez que o MH criou um binding no HA, datagramas devem ser entregues ao coa

 Algumas alternativas para a entrega:  Fazer com que host fonte redirecione datagramas

(source routing)  Reencaminhamento com eventual source routing  Usar túneis de redirecionamento (entre HA e FA)

 Outras Opções:   MH contacta host fonte com novo endereço   Uso de túneis reversos


Alternativas

HA FA

Node Source

Fluxo de Datagramas Notificação de novo endereço


Tunelamento Básico

 HA intercepta datagramas para MH (como um ARP proxy)

 Encapsula o datagrama original como payload de um datagrama IP endereçado ao coa

 Ao receber um datagrama tunelado, FA desempacota e entrega o datagrama original para o MH

 Os endereços IP do HA e o coa são chamados de Tunnel Endpoints.


Tunelamento

Existem várias alternativas para o tunelamento:  Encapsulamento IP em IP  Encapsulamento Minimal  GRE: Generic Routing Encapsulation  PPTP: Point to Point Tunnel Protocol [RFC2637]  L2TP: Layer 2 Tunneling Protocol [RFC2661]

7


Tunelamento IP em IP

IP Header OPTS Inner IP Header Datagram

IP Header Datagram Tunnel Endpoints


Encapsulamento IP em IP

Header IP-in-IP

Header encapsulado

Endpoints

Fonte & destino originais


Encapsulamento IP em IP

 Header externo é do IPv4 e ocupa 20 bytes  O end. fonte e destino do header interno não

são modificados pelo encapsulador e (identificam os hosts fonte/destino originais)

 Outros headers externos podem ser adicionados (para fins de autenticação)

 Alguns campos são copiados do header interno para o externo; outros campos são re-calculados (p.ex. Checksum, length, etc.) de acordo com as características do novo datagrama.


Encapsulamento Minimal

Outer IP Header Minimal Header Datagram

IP Header Datagram Tunnel Endpoints

Dest IP Address

Motivação: evitar a duplicação de dados nos headers internos e externos


Encapsulamento Minimal

Procedimento básico:  Copia header interno  Atualiza campo Protocol55 (Minimal Encapsulation)  Dest.Addr TunnelExitAddr  Se encapsulador for diferente da fonte, substitui

Source.Addr TunnelEntryAddr  Incrementa TotalLength com o tamanho do MH  Re-calcula checksum


Generic Routing Encapsulation  Formato genérico para encapsular datagramas

de protocolo X como payload de protocolo Y (X,Y protocolos de rede)

 Para cada protocolo X define-se:  Encapsulamento de datagrama X em datagrama GRE  Encapsulamento de datagrama GRE em datagrama

de X  Formato genérico permite rotear qualquer

protocolo sobre IP. Exemplos: IP, AppleTalk, IPX, etc.

 GRE é implementado como funcionalidade adicional em diversos roteadores

8


Generic Routing Encapsulation

HeaderX PayloadX

HeaderGRE Datagram

HeaderY HeaderGRE Datagram


Como MH sabe que migrou?  Método 1:

 Cada AA contém campo validade=T  A cada T/3, Agentes de Mobilidade (HA e FA)

difundem um AA  Se MH não recebeu AA nos últimos períodos de

tempo T, então MH sabe que está desconectado

 Método 2:  MH compara o prefixo de rede do coa corrente com o

prefixo de rede do AA: se for diferente, MH sabe que se conectou a uma nova rede

Obs: podem existir vários FAs servindo uma subrede. Se prefixo permanecer igual, MH não precisa solicitar novo coa.


Como MH sabe que migrou?

Como detectar migração entre duas subredes?   Monitorar progresso das conexões TCP

Se estiver sem progresso, isto indica desconexão

  Mudar interface wireless para modo promíscuo, onde pode monitorar todos os datagramas IP trafegando

Se o prefixo de rede de um datagrama for diferente do prefixo do coa, MH sabe que está em outra rede


O Papel do ARP

  Quando um MH está em uma rede visitada, o HA passa a ser o ARPProxy para receber mensagens destinadas ao MH

  Quando um MH deixa a rede home, HA usa ARPReply para atualizar todos os ARPCaches na subrede

  Quando um MH volta para a rede home, usa ARPReply para atrair datagramas para si

  Quando um MH está em uma rede visitada, não consegue transmitir qualquer ARPRequest ou ARPReply

Todo o tráfego na rede visitada para o MH também é re-direcionada pelo HA e FA


Otimização de Rotas Ideia Central:   Fazer com que o roteamento indireto (através do HA)

tenha como efeito colateral uma atualização do binding (Binding Update) no Cache do host fonte

 Abordagem do IP Móvel:  Tolerar inconsistências  Fazer atualizações somente por demanda   Criar um mecanismo para avisar quando um binding está

obsoleto  HA será o elemento autorizado a fazer as atualizações (HA

representa MH)


Otimização de Rotas

...Consiste de duas partes:  Binding Update: Atualização do Cache de

Bindings (CB) nos hosts fonte;

 Handover Suave entre FAs (opcional)

9


Binding Update

  Em resposta ao recebimento de um datagrama de F para o MH ausente (na rede visitada), ou um BindingWarning de um FA, o HA envia uma mensagem para atualizar o binding no CB de F

Internet Home Network

Home Agent (HA)

Visited Network

MH

Foreign Agent (FA)

F


Binding Update

Requer uma associação de segurança entre HA e F  F precisa ser capaz de autenticar o BindingUpdate

Solução: Gerenciamento Assimétrico de Chaves  HA assina BU com sua chave privada (criptografia

assimétrica tipo RSA)  F usa chave pública de HA para reconstruir o texto

cifrado. Se conseguir, saberá que só HA poderia ter cifrado o BU

Binding Updates não são confirmados


Binding Warning

BW é uma mensagem FA → HA:   Em resposta a um datagrama tunelado para um MH

que já não está mais presente, o FA envia ao HA um BindingWarning (para que este esteja ciente de que o coa está desatualizado)

  Este datagrama foi perdido   Espera-se que o MH logo atualize o seu coa no HA

  Binding Warning também não é confirmado, pois não afeta o roteamento IP


Handover Suave

Objetivo:  Minimizar a quantidade de datagramas IP perdidos

devido a migração de hosts (isto é, de coas desatualizados)

Dois cenários:  HA acabou de tunelar um datagrama IP para um coa

obsoleto  F tem uma entrada obsoleta do binding em seu

Cache, e tunela o datagrama para o coa antigo


Handover Suave Ideia Central:  Após migrar para uma nova rede, o RegRequest

requisitado por um MH ao novo FA causa o envio de um BindingUpdate ao FA anterior  O FA anterior cria um forwarding pointer para o novo

FA, ...  ... e pode liberar recursos previamente alocados para

servir o MH

Obs: Handover Suave é uma solicitação especial do RegRequest ao FA atual, que pode ou não prover esta funcionalidade.


Handover Suave

  RegRequest+ é a solicitação com pedido de Handover Suave.

  FA que é capaz de prover Handover Suave anuncia isto através de um AA estendido

  Se MH não receber o BU-Ack, poderá pedir repetidas vezes.

MH FA novo

RegRequest+ RegRequest HA

RegReply RegReply

FA ant.

BindingUpdate BU-Ack

BU-Ack

MH

10


Handover Suave & Segurança   A autenticidade do BU precisa ser garantida, pois senão

poderia haver redirecionamento malicioso de datagramas

  FA anterior precisa saber que MH de fato solicitou o BU Faz-se necessária uma associação de segurança entre o MH e cada FA

  Cada vez que o MH se conecta a um FA, cria-se uma chave secreta temporária compartilhada entre o MH e FA (p.ex. baseada no MAC-Addr do MH, BSS-ID/ESS-ID em 802.11)

  Usando esta chave, FA anterior consegue autenticar o BU (de MH) sem que FA novo possa interferir


Handover Suave

MH FA novo

RegRequest+ RegRequest HA

FA ant.

Warning

MH

F

Update

Alternativas de Encaminhamento se F tem binding obsoleto:   Se FA anterior tem ponteiro para FA novo, redireciona diretamente para

FA novo   Senão, apenas avisa HA de que MH não está mais alcançável   F para HA, que encaminha para FA novo


Suporte à Mobilidade em IPv6  IPv6 incorpora várias ideias & conceitos do IP

Móvel para roteamento e gerenciamento de mobilidade, tais como Otimização de Rota, Binding Updates, etc.

 IPv6 provê três tipos diferentes de endereços:  Unicast – único destino  Multicast – vários destinos  Anycast – vários possíveis destinos


Suporte à Mobilidade em IPv6 Principais diferenças com relação ao IP Móvel:

 quando migra de uma rede para outra, o MH pode manter o seu endereço IP (usado também para roteamento)

 Toda vez que migra, causa também a atualização do binding no nó correspondente (F)

 Um MH pode ter vários Home Agents


Suporte à Mobilidade em IPv6  Principais Diferenças (cont.):

 Não há mais necessidade de usar um FA; o próprio MH detecta em que rede está através das facilidades de descoberta de vizinhos e autoconfiguração do IPv6

 Os HAs também usam descoberta de vizinhos (em vez de ARP), para interceptar datagramas para o MH

 uso de Ipsec (IP Security) para todos os aspectos: autenticação, cheque de integridade, e replay protection)

 em vez de encapsulamento de datagramas para MHs em redes visitadas, usa-se um header IPv6

Roteamento e Mobilidade Roteiro -...

Documents

Transcript of Roteamento e Mobilidade Roteiro -...