© Pedro Veiga / F.C.-U.L. Nível de Transporte na Internet TCP - Transmission Control Protocol...

Post on 21-Apr-2015

104 views 0 download

Transcript of © Pedro Veiga / F.C.-U.L. Nível de Transporte na Internet TCP - Transmission Control Protocol...

© Pedro Veiga / F.C.-U.L.

Nível de Transporte na Internet

TCP - Transmission Control ProtocolNível de transporte orientado à ligação

UDP - User Datagram ProtocolNível de transporte sem ligação

•Ambos funcionam sobre IP

•TCP é semelhante a OSI/TP4

© 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

© Pedro Veiga / F.C.-U.L.

TPDU do UDP

Porta origem Porta destino

Comprimento Checksum

Dados

Não é necessário estabelecer ligaçãoNão há garantia de entrega• Semelhante ao serviço sem ligação do OSI

© Pedro Veiga / F.C.-U.L.

Comparação TP4 versus TCPSemelhanç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

© Pedro Veiga / F.C.-U.L.

Comparação TP4 versus TCPDiferenças

Nº de TPDUs 9 1Colisão ligações 2 1Formato endereços não def. 32 bitsQualidade serviço Muitas opções Opções limitadasDados no TPDU Conn.-request Permitidos Não permitidosDados importantes Expedited UrgentControlo fluxo explícito Por vezes SermpreLibertação ligação Abrupta Ordenada

© Pedro Veiga / F.C.-U.L.

APIs de TransporteNetworking no UNIX

socket Criação de um TSAP de um dado tipo

bind Associa um nome ASCII a um socket já criado

listen Cria uma fila para aceitar pedidos de ligaçãoaccept Retira um pedido de ligação da fila, ou

espera por uma ligação

connect inicia uma ligação com um socket remoto

shutdown termina a ligação de um socket

send envia uma mensagem através de um socket

recv recebe uma mensagem num socket

select verificar, num conjunto de sockets, se podem

ser lidos ou escritos

© 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

© 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

© 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ãoSegurança e privacidade

© 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

© 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

© 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

© Pedro Veiga / F.C.-U.L.

Arquitectura do Sistema

MTA MTA

MTA

UA

AU

UAMS

UA

MTSMHS

Util.Telex

Util.

Util.

Util.

• Transporte store-and-forward

© 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

© 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

© 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

© Pedro Veiga / F.C.-U.L.

Mensagem P2

Cabeçalho P2

Corpo

(Body)

Corpo 1

Corpo 2

Corpo 3

© 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

© 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

© 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

© 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

© 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

© 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)

© 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

© 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

© 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

© Pedro Veiga / F.C.-U.L.

Routing - Exemplo

MTA

MTA

MTA

MTA

MTA

MTAMTA

MTAMTA

© Pedro Veiga / F.C.-U.L.

Correio electrónico na Internet

• Historial

• UUCP

• BITNET mail

• SMTP

• MIME

• sendmail

© 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)

© Pedro Veiga / F.C.-U.L.

Outras Características

Formato das MensagensFormato das Mensagens

• Linhas de texto

• Linhas dos cabeçalhos iniciam-se por palavras reservadas especiais

• Exº From: pedro.veiga@di.fc.ul.pt

Transporte das MensagensTransporte das Mensagens

• Usando o TCP

• porto específico para SMTP

© Pedro Veiga / F.C.-U.L.

RFC 822 - Header Fields

Sender Endereço de quem enviaTo Endereço do destinatárioReceived from Donde veio a mensagemReceived by Quem recebeu a mensagemReceived via Em que meio físico chegouReceived with Que protocolo foi usadoFrom Nome da pessoa que enviou a mensagemReply-to Endereço a quem responderCc Cópias para ...Bcc Cópias ocultas para ...In-Reply-To Referência da mensagem a que se refere a respostaReferences Outras mensagens referenciadasSubject AssuntoKeywords Palavras chaveDate DataMessage-ID Identificação da mensagemComments ComentáriosEncrypted Chave de criptação usada

© 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

PCServidor

login

© 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

© Pedro Veiga / F.C.-U.L.

MIME

Multipurpose Internet Mail ExtensionsDefinido no RFC1341

Suporte ao transporte de mensagens multimedia mas

compatível com o correio SMTP

Headers especiais identificam que se trata de uma

mensagem com codificação MIMEMensagem composta por:

1 cabeçalhovários corpos cada um codificado de modo adequado a ser

transportável por SMTP (I.e., ASCII e linhas até 72 caracteres)

© Pedro Veiga / F.C.-U.L.

Exemplo de Mensagem codificada em MIME em formato de transporte

From pmv@missao-si.mct.pt Sat Nov 23 19:21 WET 1996

Message-Id: <199611232046.UAA05712@futuro.missao-si.mct.pt>

From: "Pedro Veiga" <mvv@missao-si.mct.pt>

To: "Pedro Veiga / FCUL" <pedro.veiga@di.fc.ul.pt>

Subject: Teste de envio de mensagem MIME

Date: Sat, 23 Nov 1996 19:20:00 -0000

X-MSMail-Priority: Normal

X-Priority: 3

X-Mailer: Microsoft Internet Mail 4.70.1155

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="----

=_NextPart_000_01BBD973.52351EA0"

Content-Length: 43739

This is a multi-part message in MIME format.

------=_NextPart_000_01BBD973.52351EA0

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: base64

SXN0byDpIHRleHRvIGNvbSBjYXJhY3RlcmVzIGVzcGVj7WZpY29zIGRhIGztbmd1YSBwb3J0

dWd1ZXNhLg0KDQrjIOIg4CDhIOkg7SDzIPUg+iDnDQoNCi0tcGVkcm8gdmVpZ2 ENCg==

© Pedro Veiga / F.C.-U.L.

------=_NextPart_000_01BBD973.52351EA0Content-Type: application/octet-stream; name="Estimado.doc"Content-Description: Estimado (Microsoft Word Document)Content-Disposition: attachment; filename="Estimado.doc"Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAACQAAAAAAAAAAEAAACwAAAAEAAAD+////AAAAAAoAAAD/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

/* texto apagado */

AAAwADEHAAAAADEAAAMAAAAAMAA0BwAAAAAwAAIDAAAAADEANwcAAAAAMQBeAwAAAAAxADgHAAAAADEAZwMAAAAAMQA5BwAAAAAwAPEDAAAAADAAWQcAAAAAMAD8AwAAAAAwAFoHAAAAADAAdAQAAAAAMABbBwAAAAAxAHoFAAAAADEAXAcAAAAAMQBgBwA=

------=_NextPart_000_01BBD973.52351EA0Content-Type: application/octet-stream; name="25000Juros.xls"Content-Description: 25000Juros (Microsoft Excel Worksheet)Content-Disposition: attachment; filename="25000Juros.xls"Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIAAAAAAAAAAAEAAA/v///wAAAAD+////AAAAAB8AAAD/////////////////////////////////////////////…etc

© 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

© 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-----

© 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: linn@zendia.enet.dec.com,,

Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3

Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,

B70665BB9BF7CBCDA60195DB94F727D3

Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4

Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,

E2EF532C65CBCFF79F83A2658132DB47

LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M

8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk

J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot

dXd/H5LMDWnonNvPCwQUHt==

-----END PRIVACY-ENHANCED MESSAGE-----

© 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

© 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

© 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

© 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

© Pedro Veiga / F.C.-U.L.

DIT - Directory Information Tree

C= FranceC=BrasilC=JapanC=Portugal...

ORG=EuroDisneyORG=TourEiffelORG=Bull...

ORG= NTTORG=ToyotaORG=Sony...

ORG=......

ORG=INESCORG=Univ.LisboaORG=TLP...

Dep=InformáticaDep=Física...

© Pedro Veiga / F.C.-U.L.

DITDep=Informática

Dep=Física...

S=Veiga G=Pedro Tel=4521 X.400=yyyyyyyNome=PintoPaixao Tel=2341...

• 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)

© Pedro Veiga / F.C.-U.L.

Arquitectura X.500

DSA

DSA

DSA

DSA

DUA

DUA

DAP

DAP