A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

© Pedro Veiga / F.C.-U.L. Nível de Transporte na Internet TCP - Transmission Control Protocol Nível de transporte orientado à ligação UDP - User Datagram.

Apresentações semelhantes


Apresentação em tema: "© Pedro Veiga / F.C.-U.L. Nível de Transporte na Internet TCP - Transmission Control Protocol Nível de transporte orientado à ligação UDP - User Datagram."— Transcrição da apresentação:

1 © Pedro Veiga / F.C.-U.L. Nível de Transporte na Internet TCP - Transmission Control Protocol Nível de transporte orientado à ligação UDP - User Datagram Protocol Nível de transporte sem ligação Ambos funcionam sobre IP TCP é semelhante a OSI/TP4

2 © Pedro Veiga / F.C.-U.L. TCP Nível de transporte recebe mensagens arbitrárias para transmitir e: Fragmenta-as em pedaços inferiores a 64k Trata de retransmissões de pacotes Trata de reordenações de pacotes Trata de tempos expirados (timeouts) Controlo de fluxo (janela de 16 bits - número de bytes) TCP numera as mensagens com 32 bits

3 © Pedro Veiga / F.C.-U.L. TPDU do UDP Porta origemPorta destino ComprimentoChecksum Dados Não é necessário estabelecer ligação Não há garantia de entrega Semelhante ao serviço sem ligação do OSI

4 © Pedro Veiga / F.C.-U.L. Comparação TP4 versus TCP Semelhanças Protocolos com ligação Fase de estabelecimento de ligação Fase de transferência de dados Fase de libertação de ligação Ligação fiável entre 2 sistemas sobre uma rede não fiável

5 © Pedro Veiga / F.C.-U.L. Comparação TP4 versus TCP Diferenças Nº de TPDUs91 Colisão ligações21 Formato endereçosnão def.32 bits Qualidade serviçoMuitas opçõesOpções limitadas Dados no TPDU Conn.-requestPermitidosNão permitidos Dados importantesExpeditedUrgent Controlo fluxo explícitoPor vezesSermpre Libertação ligaçãoAbruptaOrdenada

6 © Pedro Veiga / F.C.-U.L. APIs de Transporte Networking no UNIX socketCriação de um TSAP de um dado tipo bindAssocia um nome ASCII a um socket já criado listenCria uma fila para aceitar pedidos de ligação acceptRetira um pedido de ligação da fila, ou espera por uma ligação connectinicia uma ligação com um socket remoto shutdowntermina a ligação de um socket sendenvia uma mensagem através de um socket recvrecebe uma mensagem num socket selectverificar, num conjunto de sockets, se podem ser lidos ou escritos

7 © Pedro Veiga / F.C.-U.L. Pontes de Transporte Fornecer um serviço de transporte OSI sobre a pilha TCP/IP RFC-1006 (Transport Bridge) Aplicação Apresentação Sessão Transporte IP TCP

8 © Pedro Veiga / F.C.-U.L. Nível de Apresentação Fornece serviços ao nível de Aplicação Usa os serviços do nível de Sessão Este nível trata do significado da informação trocada entre os 2 sistemas envolvidos na comunicação Os computadores envolvidos podem ter diferentes modos de representar a informação

9 © Pedro Veiga / F.C.-U.L. Funções do Nível Dar às aplicações um modo de acesso às sessões Disponibilizar um modo de especificar estruturas de dados complexas Gerir o conjunto de estruturas de dados em uso Converter os dados entre formatos internos e externos Representação (diferentes códigos) Compressão Segurança e privacidade

10 © Pedro Veiga / F.C.-U.L. Gateways de Aplicação Telnet ftp SMTP DNS VT FTAM X.400 X.500 Gateway realiza sempre o mínimo comum aos 2 serviços homólogos Gateway

11 © Pedro Veiga / F.C.-U.L. X.400 Designação X.400 refere-se a um conjunto de normas que definem a aplicação OSI de correio electrónico X.400, X.402, X.409,... Normas MOTIS (Message-Oriented Text Interchange Systems) do ISO são equivalentes Normas X.400 têm evoluído X.400/84, X.400/88, X.400/92 Infelizmente (mas tradicional no mundo OSI) há incompatibilidades entre as diversas versões que dificultam interoperabilidade

12 © Pedro Veiga / F.C.-U.L. X.400 Normas definem –Arquitectura de rede de troca de mensagens –Elementos envolvidos na troca e preparação das mensagens –Formato das mensagens –Interação com outros serviços Filosofia subjacente à arquitectura foi modelada segundo o modo de trabalhar dos operadores de telecomunicações Sistema complexo, se bem que poderoso

13 © Pedro Veiga / F.C.-U.L. Arquitectura do Sistema MTA UA AU UAMS UA MTS MHS Util. Telex Util. Transporte store-and-forward

14 © Pedro Veiga / F.C.-U.L. Componentes MTA - Message Transfer Agent UA - User Agent AU - Access Unit Telex Fax Entrega física MS - Message Store

15 © Pedro Veiga / F.C.-U.L. Papel do MTA Aceita mensagens submetidas por UAs e transmite-as para outros UAs ou para outros MTAs Aceita mensagens vindas de outros MTAs e entrega-as a um UA ou a outro MTA Efectua funções de encaminhamento de mensagens (routing) Gera DNs (delivery notifications) quando entrega alguns tipos de mensagens a um UA Se não consegue resolver um endereço gera um NDN (non-delivery notification) Implementa os protocolos de comunicação adequados

16 © Pedro Veiga / F.C.-U.L. Papel do UA Ajuda o utilizador a preparar a mensagem e codifica-a de modo a ser entregue ao MTA Mensagem P2 (Mensagem inter-pessoal) Aceita mensagens do MTA, descodofoca-as e exibe-as ao utilizador Tem facilidades de apoio ao armazenamento e organização das mensagens recebidas e/ou enviadas Podem ser MTAs co-residentes ou remotas Protocolo de comunicação P3 para comunicação entre um MTA e um UA remoto UA pode usar facilidades de armazenamento associadas ao MTA (Message-store) Protocolo de comunicação é P7

17 © Pedro Veiga / F.C.-U.L. Mensagem P2 Cabeçalho P2 Corpo (Body) Corpo 1 Corpo 2 Corpo 3

18 © Pedro Veiga / F.C.-U.L. Elementos de Serviço do cabeçalho P2 IPMessageId originator primary Recipients copyRecipients blindCopyRecipients inReplyTo authorizingUsers crossReferences obsoletes expiryDate replyBy replyToUsers importance sensitivity autoforwarded

19 © Pedro Veiga / F.C.-U.L. Mensagem P1 Envelope P1 (Message Transfer Envelope) Conteúdo (mensagem P2) Elementos do Envelope P1 Endereços O/R do originador e destinatário(s) Prioridade Identificação da mensagem Informação de percurso

20 © Pedro Veiga / F.C.-U.L. Message Store Apareceu nas normas de 1988 Quando um MTA tem uma mensagem para um UA servido por uma Message Store (MS) entrega-a ao MS em vez de a guardar se o UA não está disponível O UA recupera a mensagem a partir do MS O UA submete as mensagens ao MS e este ao MTA MTA MS UA P7

21 © Pedro Veiga / F.C.-U.L. P3 Protocolo para comunicação entre um MTA e um UA não co- residente Definido nas normas X.411 (84) Definido nas normas X.419 (88) - MTS access protocol Nunca foi muito popular e foi praticamente substituído pelo conceito do Message Store + Protocolo P7, que acabámos de ver

22 © Pedro Veiga / F.C.-U.L. Domínios de Gestão ADMD - Administration Domain PRMD - Private Management Domain Organizações Unidades organizacionais Pessoas / aplicações Modelo demasiado adaptado à filosofia dos operadores de telecomunicações

23 © Pedro Veiga / F.C.-U.L. Nomes e Endereços Alterações significativas entre o conteúdo das normas em 1984 e 1988 Nas normas de 1988 pode-se usar um directory name para endereçar uma mensagem Destinatário pode ser uma lista de distribuição Originadores e destinatários são identificados através de um O/R address (Originator/Recipient address)

24 © Pedro Veiga / F.C.-U.L. Endereços O/R Modo de identificar os originadores ou destinatários das mensagens Formados por sequências não ordenadas de atributos e valores Solução intercalar enquanto não há sistema de directório Atributos C, ADMD, PRMD, O, OU, S, G, I Exº C=pt/ADMD=goldmail/PRMD=inesc/O=inesc/OU=redes /G=pedro/S=veiga

25 © Pedro Veiga / F.C.-U.L. Atribuição de endereços C, Country ADMD, Administration Domain PRMD, Private Management Domain O, Organization OU, Organizational Unit

26 © Pedro Veiga / F.C.-U.L. Routing - Encaminhamento Trata do problema de como os MTAs levam as mensagens de uma origem a um destino Algoritmos de encaminhamento, em cada MTA, analisam o destinatário de uma mensagem e decidem, de entre os MTAs a que estão ligados, para qual vão fazer seguir a mensagem Routing pode ser: –Estático –Dinâmico

27 © Pedro Veiga / F.C.-U.L. Routing - Exemplo MTA

28 © Pedro Veiga / F.C.-U.L. Correio electrónico na Internet Historial UUCP BITNET mail SMTP MIME sendmail

29 © Pedro Veiga / F.C.-U.L. Normas actuais RFC 821 e RFC-822 (SMTP - Simple Mail Transfer Protocol) Sistema orientado a texto simples de implementar sobre muitos mecanismos de transporte não há distinção entre cabeçalhos e corpo das mensagens, a não ser em identificadores especiais dos campos do cabeçalho só ASCII linhas até 72 caracteres Endereços simples e compactos (mas no formato básico)

30 © Pedro Veiga / F.C.-U.L. Outras Características Formato das Mensagens Linhas de texto Linhas dos cabeçalhos iniciam-se por palavras reservadas especiais Exº From: Transporte das Mensagens Usando o TCP porto específico para SMTP

31 © Pedro Veiga / F.C.-U.L. RFC Header Fields SenderEndereço de quem envia ToEndereço do destinatário Received fromDonde veio a mensagem Received byQuem recebeu a mensagem Received viaEm que meio físico chegou Received withQue protocolo foi usado FromNome da pessoa que enviou a mensagem Reply-toEndereço a quem responder CcCópias para... BccCópias ocultas para... In-Reply-ToReferência da mensagem a que se refere a resposta ReferencesOutras mensagens referenciadas SubjectAssunto KeywordsPalavras chave DateData Message-IDIdentificação da mensagem CommentsComentários EncryptedChave de criptação usada

32 © Pedro Veiga / F.C.-U.L. POP - Post Office Protocol Agente num PC ou sistema cliente de POP Servidor num sistema central Servidor faz login no servidor e recebe/envia o mail PC Servidor login

33 © Pedro Veiga / F.C.-U.L. Gateways de Correio Electrónico Gateways - interligam sistemas de correio electrónico que usam protocolos diferentes Funcionalidade do sistema é o mínimo comum aos 2 sistemas Sistemas tem de dispôr de um mecanismo de transporte de bits comum Níveis 3 ou 4 são os mais vulgares Exº Gateway X.400 / SMTP definido no RFC-987 Define transformações a aplicar aos endereços (ou O/R names) Define equivalência entre Elementos de serviço / Palavras reservadas

34 © Pedro Veiga / F.C.-U.L. MIME rMultipurpose Internet Mail Extensions rDefinido no RFC1341 rSuporte ao transporte de mensagens multimedia mas compatível com o correio SMTP rHeaders especiais identificam que se trata de uma mensagem com codificação MIME rMensagem composta por: r1 cabeçalho rvários corpos cada um codificado de modo adequado a ser transportável por SMTP (I.e., ASCII e linhas até 72 caracteres)

35 © Pedro Veiga / F.C.-U.L. Exemplo de Mensagem codificada em MIME em formato de transporte From Sat Nov 23 19:21 WET 1996 Message-Id: From: "Pedro Veiga" To: "Pedro Veiga / FCUL" Subject: Teste de envio de mensagem MIME Date: Sat, 23 Nov :20: X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BBD EA0" Content-Length: This is a multi-part message in MIME format =_NextPart_000_01BBD EA0 Content-Type: text/plain; charset=ISO Content-Transfer-Encoding: base64 SXN0byDpIHRleHRvIGNvbSBjYXJhY3RlcmVzIGVzcGVj7WZpY29zIGRhIGztbmd1YSBwb3J0 dWd1ZXNhLg0KDQrjIOIg4CDhIOkg7SDzIPUg+iDnDQoNCi0tcGVkcm8gdmVpZ2 ENCg==

36 © Pedro Veiga / F.C.-U.L =_NextPart_000_01BBD EA0 Content-Type: application/octet-stream; name="Estimado.doc" Content-Description: Estimado (Microsoft Word Document) Content-Disposition: attachment; filename="Estimado.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAACQAAAAAAAAAA EAAACwAAAAEAAAD+////AAAAAAoAAAD///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// /* texto apagado */ AAAwADEHAAAAADEAAAMAAAAAMAA0BwAAAAAwAAIDAAAAADEANwcAAAAAMQBeAwAAAAAxADgHAAAA ADEAZwMAAAAAMQA5BwAAAAAwAPEDAAAAADAAWQcAAAAAMAD8AwAAAAAwAFoHAAAAADAAdAQAAAAA MABbBwAAAAAxAHoFAAAAADEAXAcAAAAAMQBgBwA= =_NextPart_000_01BBD EA0 Content-Type: application/octet-stream; name="25000Juros.xls" Content-Description: 25000Juros (Microsoft Excel Worksheet) Content-Disposition: attachment; filename="25000Juros.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIAAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAB8AAAD///////////////////////////////////////////// …etc

37 © Pedro Veiga / F.C.-U.L. PEM Privacy Enhanced Mail Norma de correio electrónico que oferece: –confidencialidade –autenticação –integridade Norma define modo de transformar mensagens RFC- 822 para garantir os serviços de segurança RFC1421, 1422, 1423 e 1424 Usa dois tipos de chaves –Chaves de cifração de dados –Chaves de troca

38 © Pedro Veiga / F.C.-U.L. Tratamento das mensagens em PEM Pre-Encapsulation Boundary (Pre-EB) -----BEGIN PRIVACY-ENHANCED MESSAGE----- Encapsulated Header Portion Blank Line Encapsulated Text Portion Post-Encapsulation Boundary (Post-EB) -----END PRIVACY-ENHANCED MESSAGE-----

39 © Pedro Veiga / F.C.-U.L. Exemplo PEM -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,ENCRYPTED Content-Domain: RFC822 DEK-Info: DES-CBC,F8143EDE5960C597 Originator-ID-Symmetric: Recipient-ID-Symmetric: Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A, B70665BB9BF7CBCDA60195DB94F727D3 Recipient-ID-Symmetric: Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26, E2EF532C65CBCFF79F83A DB47 LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== -----END PRIVACY-ENHANCED MESSAGE-----

40 © Pedro Veiga / F.C.-U.L. Tipos de serviços de segurança em PEM "ENCRYPTED" –confidencialidade, autenticação, integridade, não repudiação de origem "MIC-ONLY" –todos os anteriores excepto confidencialidade –specifier signifies that all of the security services "MIC-CLEAR" –não faz criptação mas faz os outros serviços –a mensagem pode ser lida por quem não tem PEM; quem tem pode saber que mensagem está integra e assinada

41 © Pedro Veiga / F.C.-U.L. Chaves públicas Depositadas numa autoridade de certificação Autoridade de certificação –entidade responsável por gerar e disponibilizar chaves a utilizadores –funciona como "notário electrónico" Chaves distribuídas sobre a forma de certificados E chaves comprometidas? –Validade de um certificado –Listas de revogação

42 © Pedro Veiga / F.C.-U.L. PGP  Pretty Good Privacy  Começou como um conjunto de programas escritos por Phil Zimmermann para se poder usar correio electrónico seguro  Usa RSA tendo por base chave públice/privada  IDEA para cifrar a mensagem - usa uma chave de 128 bits de comprimento  MD5 para gerar sumário de 128 bits  Programa mais popular de correio electrónico seguro na Internet  Debilidade no modo de distribuir chaves

43 © Pedro Veiga / F.C.-U.L. Directório O directório OSI está definido na norma X.500 Ideia inicial +Permitir aos utilizadores obter nomes a partir de atributos Ter um serviço tipo páginas telefónicas (white pages) Sistema acessível universalmente para permitir pesquisas a partir de um conjunto de atributos Ideia inicial foi estendida e hoje o directório pode ser usado para guardar informações muito diversas Exº informação de como aceder a um MTA, características do um agente utilizador de um sistema X.400

44 © Pedro Veiga / F.C.-U.L. DIT - Directory Information Tree C= France C=Brasil C=Japan C=Portugal... ORG=EuroDisney ORG=TourEiffel ORG=Bull... ORG= NTT ORG=Toyota ORG=Sony... ORG=... ORG=INESC ORG=Univ.Lisboa ORG=TLP... Dep=Informática Dep=Física...

45 © Pedro Veiga / F.C.-U.L. DIT Dep=Informática Dep=Física... S=Veiga G=Pedro Tel=4521 X.400=yyyyyyy Nome=PintoPaixao Tel= Cada entrada é um conjunto de atributos Cada atributo tem: Tipo Interpretação (maiúsculas/minúsculas) Qualificador (herdado, obrigatório,...) Lista de controlo de acesso (ACL)

46 © Pedro Veiga / F.C.-U.L. Arquitectura X.500 DSA DUA DAP


Carregar ppt "© Pedro Veiga / F.C.-U.L. Nível de Transporte na Internet TCP - Transmission Control Protocol Nível de transporte orientado à ligação UDP - User Datagram."

Apresentações semelhantes


Anúncios Google