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
© 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
Comprimento
Porta destino
Checksum
Dados
Não é necessário estabelecer ligação
Não há garantia de entrega
• Semelhante ao serviço sem ligação do OSI
© 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
© Pedro Veiga / F.C.-U.L.
Comparação TP4 versus TCP
Diferenças
Nº de TPDUs
Colisão ligações
Formato endereços
Qualidade serviço
Dados no TPDU Conn.-request
Dados importantes
Controlo fluxo explícito
Libertação ligação
© Pedro Veiga / F.C.-U.L.
9
2
não def.
Muitas opções
Permitidos
Expedited
Por vezes
Abrupta
1
1
32 bits
Opções limitadas
Não permitidos
Urgent
Sermpre
Ordenada
APIs de Transporte
Networking no UNIX
socket
Criação de um TSAP de um dado tipo
bind
Associa um nome ASCII a um socket já criado
listen
accept
connect
Cria uma fila para aceitar pedidos de ligação
Retira um pedido de ligação da fila, ou
espera por uma ligação
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
TCP
IP
© 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ão
Segurança e privacidade
© Pedro Veiga / F.C.-U.L.
Gateways de Aplicação
• Telnet
• VT
• ftp
• FTAM
Gateway
• SMTP
• X.400
• DNS
• X.500
Gateway realiza sempre o mínimo comum aos 2
serviços homólogos
© 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
Util.
UA
MTA
MTA
MS
UA
Util.
AU
Util.
Telex
MTA
UA
MTS
MHS
• Transporte store-and-forward
© Pedro Veiga / F.C.-U.L.
Util.
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 1
Corpo
Corpo 2
(Body)
Corpo 3
© Pedro Veiga / F.C.-U.L.
Elementos de Serviço
do cabeçalho P2
•
IPMessageId
• replyBy
•
originator
• replyToUsers
•
primary Recipients
• importance
•
copyRecipients
• sensitivity
•
blindCopyRecipients
•
inReplyTo
•
authorizingUsers
•
crossReferences
•
obsoletes
•
expiryDate
© Pedro Veiga / F.C.-U.L.
• autoforwarded
Mensagem P1
Elementos do Envelope P1
•
Endereços O/R do originador
e destinatário(s)
•
Prioridade
•
Identificação da mensagem
•
Informação de percurso
Envelope P1
(Message Transfer Envelope)
Conteúdo
(mensagem P2)
© Pedro Veiga / F.C.-U.L.
Message Store
Apareceu nas normas de 1988
• Quando um MTA tem uma
UA
mensagem para um UA
servido por uma Message
P7
Store (MS) entrega-a ao MS
em vez de a guardar se o UA
MS
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
© Pedro Veiga / F.C.-U.L.
MTA
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
MTA
MTA
MTA
© Pedro Veiga / F.C.-U.L.
MTA
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 Mensagens
• Linhas de texto
• Linhas dos cabeçalhos iniciam-se por palavras reservadas especiais
• Exº
From: [email protected]
Transporte das Mensagens
• Usando o TCP
• porto específico para SMTP
© Pedro Veiga / F.C.-U.L.
RFC 822 - Header Fields
Sender
To
Received from
Received by
Received via
Received with
From
Reply-to
Cc
Bcc
In-Reply-To
References
Subject
Keywords
Date
Message-ID
Comments
Encrypted
© Pedro Veiga / F.C.-U.L.
Endereço de quem envia
Endereço do destinatário
Donde veio a mensagem
Quem recebeu a mensagem
Em que meio físico chegou
Que protocolo foi usado
Nome da pessoa que enviou a mensagem
Endereço a quem responder
Cópias para ...
Cópias ocultas para ...
Referência da mensagem a que se refere a resposta
Outras mensagens referenciadas
Assunto
Palavras chave
Data
Identificação da mensagem
Comentários
Chave de criptação usada
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
login
Servidor
© Pedro Veiga / F.C.-U.L.
PC
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 Extensions
 Definido 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 MIME
Mensagem composta por:
 1 cabeçalho
 vá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 [email protected] Sat Nov 23 19:21 WET 1996
Message-Id: <[email protected]>
From: "Pedro Veiga" <[email protected]>
To: "Pedro Veiga / FCUL" <[email protected]>
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.52351EA0
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_01BBD973.52351EA0
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
© 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 RFC822 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: [email protected],,
Recipient-ID-Symmetric: [email protected],ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: [email protected],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= France
C=Brasil
C=Japan
C=Portugal
...
ORG=EuroDisney
ORG=TourEiffel
ORG=Bull
...
ORG=INESC
ORG=Univ.Lisboa
ORG=TLP
...
ORG=
...
...
ORG= NTT
ORG=Toyota
ORG=Sony
...
Dep=Informática
Dep=Física
...
© Pedro Veiga / F.C.-U.L.
DIT
Dep=Informática
Dep=Física
...
• 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)
S=Veiga G=Pedro Tel=4521 X.400=yyyyyyy
Nome=PintoPaixao Tel=2341
...
© Pedro Veiga / F.C.-U.L.
Arquitectura X.500
DUA
DAP
DSA
DSA
DAP
DSA
DSA
DUA
© Pedro Veiga / F.C.-U.L.