SIP Complemento. Telefonia IP MAB 618. Paulo Aguiar Tel. (0xx21) Departamento de Computação /IM da UFRJ

Transcrição

1 SIP Complemento Telefonia IP MAB 618 Paulo Aguiar Tel. (0xx21) Departamento de Computação /IM da UFRJ

2 Servidores de Redirecionamento Usado durante a inicialização de uma sessão Determina o(s) endereço(s) (URI) onde se encontra o dispositivo sendo chamado, retornando esta informação ao UAC chamador. Não gera requisições SIP (se não atuar como proxy) Usado para encaminhamento de chamadas e siga-me Redirect Server 1 REQUEST fulano@empresa.br 2 Contact fulano@casa.br 3 ACK 4 REQUEST fulano@casa.br 5 RESPONSE chamador@provedor.br fulano@casa.br 2

3 Servidores Proxy Atua como UAS e UAC Função principal: roteamento da chamada Encaminhamento da sinalização Autenticação e autorização Interpreta a requisição, podendo alterar parte da mensagem Encaminha a mensagem 1 REQUEST fulano@empresa.br 2 REQUEST fulano@casa.br 4 RESPONSE 3 RESPONSE chamador@provedor.br SIP Proxy Server fulano@casa.br 3

4 Servidores Proxy As requisições podem percorrer vários servidores proxies vindo do chamador para o usuário chamado (multi-hop) Cada proxy : recebe e analisa as requisições checa se o domínio na URI da requisição é o seu próprio, caso contrário repassa para o servidor SIP do domínio correspondente (consulta DNS) Se o domínio da URI da Requisição coincidir : Invoca o serviço de localização Obtém informações de registro do usuário Verifica a parte HOST do endereço SIP no DNS Redireciona para o próximo HOP Recebe as respostas Redireciona as respostas 4

5 Servidores Proxy Podem fazer requisições FORK para múltiplos servidores, e criar uma árvore de busca Servidores SIP são registrados no DNS através registros SRV ou NAPTR SRV (RFC 2782) "_Service._Proto.Name TTL Class SRV Priority Weight Port Target "_sip._udp.ufrj.br IN SRV sip.ufrj.br." NAPTR (RFC 3403) "domain-name TTL Class NAPTR order preference flags service regexp target "bigu.edu IN NAPTR "s" "SIP+D2U" "" _sip._udp.bigu.edu." 5

6 FluxosSIP Via Proxy User A Proxy MIT.EDU User B Calls INVITE: sip:dbaron@mit.edu Trying Ringing INVITE: sip:dbaron@ Ringing Rings OK OK Answers ACK Talking RTP Talking Hangs up BYE OK Fonte: Dennis Baron (MIT) 6

7 FluxosSIP Via Gateway User A Proxy MIT.EDU Gateway Calls INVITE: sip:joe@mit.edu INVITE: sip:38400@ Trying Rings Ringing Ringing Answers OK OK ACK ACK Talking RTP Talking Hangs up BYE BYE OK OK Fonte: Dennis Baron (MIT) 7

8 SIP Trapezoid DNS Server Outgoing Proxy DNS SIP Location Server Incoming Proxy Registrar SIP SIP SIP Originating User Agent SIP RTP Terminating User Agent Fonte: Dennis Baron (MIT) 8

9 SIP Triangle? DNS Server Location Server DNS Registrar Incoming Proxy SIP SIP SIP Originating User Agent SIP RTP Terminating User Agent Fonte: Dennis Baron (MIT) 9

10 SIP Peer to Peer! Originating User Agent SIP RTP Terminating User Agent Fonte: Dennis Baron (MIT) 10

11 P2P SIP Skype phenomenon has caused rethinking of need for proxy/registrar 100% P2P SIP is on the way Basic idea: clients REGISTER to join DHT, which is then used for routing Node A Node-ID Node B 1. REGISTER 2. REGISTER 200 OK Node B Node-ID 245 Alice-> Alice s Node Fonte: Node C Node-ID 520 Alice s Node Node-ID

12 DNS RFC3263 especifica o DNS como o mecanismo preferencial para determinar o endereço IP, porta e transporte do hospedeiro para o qual a requisição SIP é enviada O transporte deve ser determinado pois requisições SIP podem ser enviadas via UDP, TCP, SCTP ou TLS sobre TCP para sessões seguras e codificadas, diferentemente de outros protocolos mais limitados 12

13 Registro SRV (RFC 2782) Entrada no DNS para cada protocolo de transporte e servidor associado "_Service._Proto.Name TTL Class SRV Priority Weight Port Target" "_sip._udp.bigu.edu IN SRV sipserver.bigu.edu." Transporte é UDP. Outros valores possíveis: TCP, SCTP ou TLS. O tempo em cache é de 12 horas (43,200 segundos.): qualquer inteiro positivo de 32 bits. A classe é IN (sempre verdadeiro) e o tipo do registro é SRV. Prioridade = 10. Valores mais baixos são consultados primeiro. Peso = 10. Determina a freqüência com que um registro é consultado proporcionalmente entre registros de mesma prioridade. Valores mais altos indicam uma freqüência maior. A porta é 5060 e o servidor proxy FQDN (fully qualified domain name) é sipserver.bigu.edu (e, como requisitado em DNS, o FQDN termina com ponto) ns.bigu.edu IN A sipserver1.bigu.edu IN A sipserver2.bigu.edu IN A ; sip._udp.bigu.edu IN SRV sipserver1.bigu.edu. sip._udp.bigu.edu IN SRV sipserver2.bigu.edu. sip._tcp.bigu.edu IN SRV sipserver1.bigu.edu. sip._tcp.bigu.edu IN SRV sipserver2.bigu.edu. _sips._tcp.bigu.edu IN SRV sipserver1.bigu.edu. _sips._tcp.bigu.edu IN SRV sipserver2.bigu.edu. 13

14 Registro NAPTR (RFC 3403) Permite ao domínio especificar preferencialmente qual transporte SIP deve usar, mapeando entre o domínio e o registro SRV (RFC 3263) "domain-name TTL Class NAPTR order preference flags service regexp target" "bigu.edu. IN NAPTR "s" "SIP+D2U" "" _sip._udp.bigu.edu. O nome do domínio é bigu.edu (a direita em user@host)) O tempo em cache é de 12 horas (43,200 segundos). A classe é IN (sempre verdadeiro) e o tipo do registro é NAPTR. A ordem em que os registros são lidos é 60. A preferência é 50. Valores mais baixos são mais prioritários. O flag é s e depende da aplicação (no caso SIP?). O serviço é SIP+D2U (SIP sobre UDP). Possíveis valores: SIP+D2T (para SIP sobre TCP), SIP+D2S (para SIP sobre SCTP) e SIPS+D2T (para SIP seguro sobre TLS sobre TCP). TLS sobre UDP não é definido. A expressão regular regexp está vazia. O target é _sip._udp.bigu.edu. A expressão regular e o campo target juntos formam o campo de substituição. Somente um pode ser usado e o outro deve estar vazio. 14

15 Saindo das Fronteiras do Proxy É possível enviar uma requisição para um proxy vizinho sem realizar um procedimento de verificação no DNS Isto pode acontecer caso o proxy receba uma requisição cujo domínio não é o seu próprio e caso ele tenha uma tabela própria de redirecionamento Também é possível realizar pesquisa a servidores DNS para redirecionar a chamada para fora da rede 15

16 Servidores de Registro REGISTRAR server Recebe requisições to tipo REGISTER e armazena a informação endereço IP x endereço SIP Acionados pelos servidores de redirecionamento ou servidores proxy para localização de um usuário na rede SIP Permite criar o conceito de mobilidade 16

17 Localização O resultado final da localização de endereços é um mapeamento de um SIP URI para outro Ex.: sip:cesar@voip.nce.ufrj.br para sip:cesar@rio.voip.nce.ufrj.br Opcionalmente serviços de diretórios com localização de usuários podem ser utilizados LDAP [RFC 2251] whois 17

18 Forking através do Proxy Um proxy pode ter mais do que um endereço para um certo usuário Isso acontece quando mais do que uma URL SIP é registrada para um usuário Pode acontecer também baseado em configuração de roteamento estática Nestes casos, o proxy pode realizar o fork, enviando a requisição para mais de um proxy de uma só vez (fork paralelo) Como alternativa ao envio simultâneo, o proxy pode operar de forma seqüencial, enviando para um novo destino apenas se receber uma resposta negativa do desatino anterior 18

19 Forking através do Proxy Primeiro 200 OK que for recebido é o caminho a ser usado pelo redirecionamento Todas as outras requisições não respondidas são canceladas, enviando requisições CANCEL Entre os benefícios do proxy Permite uma rápida pesquisa em vários lugares O telefone pode tocar em mais de um lugar ao mesmo tempo 19

20 Proxies: Stateful vs Stateless Definição de Proxy Stateless Recebe requisições, acessa os serviços de localização, redireciona as requisições Não salva nenhuma informação depois que a requisição for redirecionada (sem memória) Quando a resposta voltar, usa o cabeçalho Via para saber qual o próximo hop a ser enviado 20

21 Proxies: Stateful vs Stateless Definição de Proxy Stateful O proxy pode lembrar do pedido, mesmo após ter redirecionado a requisição Pode aplicar lógica adicional após a resposta chegar (CGI) Um proxy deve ser stateful quando Realiza fork (para descobrir a melhor resposta) Envia a requisição usando multicast Usa TCP 21

22 Proxies: Stateful vs Stateless Stateful vs. Stateless Stateless escalona bem para milhares de requisições simultâneas Não tem grandes requisitos de memória Os requisitos de sockets são pequenos Stateful é melhor para serviços No projeto da rede de telefonia IP, é preciso verificar as necessidades para apropriadamente decidir qual proxy instalar 22

23 Detecção de Loop Requisições podem acessar o mesmo proxy duas vezes! É necessário prover mecanismos para prevenir o loop Servidor Proxy Servidor Proxy Detecção de Loop Servidor Proxy Servidor Proxy Cliente SIP 23

24 Detecção de Loop SIP provê dois mecanismos de detecção Max-Forwards Contador decrementa de 1 para cada hop visitado Descarta a requisição quando chega em zero Prevenção e detecção de loop com cabeçalho Via Cada proxy insere endereço e checa se já existe Quebra a corrente se loop detectado 24

25 Autenticação 25

26 Registrando no SIP Proxy precisam conhecer onde os usuários estão localizados num certo momento A mensagem SIP REGISTER permite que os clientes se autentiquem com os servidores proxy Propriedades do REGISTER Contém uma lista de endereços de localização do usuário em cabeçalhos Contact O servidor Registrar que será usado é identificado na Request URI 26

27 Registrando no SIP Propriedades do REGISTER Identifica usuário registrado no campo To Identifica a pessoa que esta realizando o registro no campo From (normalmente igual ao campo To) Cabeçalho Expires indica o tempo de vida desejado deste registro Pode ser diferente para cada Contact 27

28 Respostas do Registrar Comportamento do Registrar na recepção de mensagem REGISTER Verifica se o domínio recebido é o dele próprio Autentica usuário do cabeçalho From Adiciona a associação entre endereços (campo To) ->> (campo Contact) Tempo de vida grande é diminuído Pode retornar, na resposta, a lista de todos os registros correntes Pode retornar, na resposta, a lista de todos os tempos de vida de todos os registros 28

29 Autenticação e Autenticação Segura 29

30 Fluxos SIP Processo de Registro User B Registrar MIT.EDU Location MIT.EDU REGISTER: sip:dbaron@mit.edu Unauthorized REGISTER: (add credentials) OK sip:dbaron@mit.edu Contact Fonte: Dennis Baron (MIT) 30

31 Registro autenticado Autenticação básica Passa senha em claro Autenticação HTTP Digest (RFC 2617) Realiza hash em campos da mensagem e desafio enviado pelo servidor 31

32 Autenticação Básica Ao receber uma requisição sem autenticação, servidor responde com cabeçalho Www-Authenticate: Basic realm = informação do domínio Cliente reenvia a requisição repetindo o mesmo CALLID, enviando usa identificação (ID) e senha, separadas por vírgula e codificada com base64 usando o cabeçalho Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Como senha passa em claro, esse método não é aconselhável 32

33 Autenticação digest HTTP digest com uso de MD-5 para realizar hash sobre vários campos e desafio enviado pelo servidor URI da requisição Nome do usuário (Username) Desafio único (NONCE number once) Domínio (realm) Senha do usuário (password) qop= auth, mas opcionalmente, o corpo da mensagem pode ser usado para garantir a integridade junto com a autenticação especificando qop = auth-int 33

34 SIP MD5 Digest Obtido em etapas #1 = MD5(username:realm:password) invariável dependente da senha secreta Este hash pode ser armazenado em diretório ou banco #2 = MD5(method:URI) para qop= auth ou MD5(method:URI:MD5(corpo)) para qop = auth-int executado a cada primitiva HASH resposta: MD5(#1:NONCE:#2) 34

35 Autenticação digest Uso de digest informado em resposta 401 (Unauthorized) no cabeçalho WWW-Authenticate WWW-Authenticate = Digest realm="domínio", qop="auth,auth-int", nonce="od1128f deac4e01029b7c96b3", stale=false, algorithm=md5, opaque="5ccc069c403ebaf9f0171e9517f40e41" Cliente reenvia requisição, adicionando cabeçalho Authorization = Digest username=" fulano@domínio", realm= domínio", nonce="0d1128f deac4e01029b7c96b3", uri="destination.test.org", qop=auth, response="2923fb70ddfdf57f7ffe5cc436ab4889 opaque="5ccc069c403ebaf9f0171e9517f40e41 algorithm=md5 35

36 SIP REGISTER 36

37 SIP REGISTER 401 Response 37

38 SIP REGISTER com Credenciais 38

39 Transporte SIP As mensagens SIP são enviadas via UDP ou TCP Preferível o uso do UDP Mais rápido Nenhum estado da conexão é necessário para o kernel Possível o suporte a multicast 39

40 Transporte SIP Existe transporte seguro TLS sobre TCP (RFC 2246, RFC 3546) Existem mecanismos de confiabilidade adicionais para UDP Para suporte à sinalização SS7 na interação com PBX é preferível o uso de SIP sobre SCTP (Stream Control Transmission Protocol), orientado a mensagem Limitações do TCP Seqüenciamento na entrega orientado a fluxo (e não a mensagens) pode causar causa atrasos desnecessários Falta de suporte a transferências a múltiplos hosts Vulnerabilidade a ataques de SYNC RFC 2960, IETF Sigtran 40

41 Desconexão Como desconectar depende de quando esta é feita Após a chamada ter sido configurada cada uma das partes envolvidas pode enviar uma requisição BYE Desconexão vinda do chamador (emissor) antes da chamada ter sido aceita Pelo envio de CANCEL Se a chamada for aceita após o CANCEL, então é preciso usar o BYE 41

42 Segurança Através de mecanismos legados como: HTTP Basic authentication Digest authentication CHAP (Challenge Handshake Authentication Protocol) PGP (Pretty Good Privacy) PKI Relativo à sinalização TLS - Transporte DTLS Transporte S/MIME Relativo à mídia SRTP ZRTP 42