Laboratorio#2AnlisisdeProtocolos

Infraestructuradecomunicaciones
AnaMaraCrdenas,AndreaNavas
UniversidaddelosAndes,Bogot,Colombia

Fechadepresentacin:Agosto16de2015

1. Introduccin

1. Introduccin
En el estudio de lainfraestructuradecomunicacionesesesencial comprenderlasreglasque
permiten que el origen y destino puedan comunicarseentres.stas,queenelmundodela

informtica se conocen como protocolos, son establecidas de tal manera que puedadarse
un flujo de mensajes eficaz en el cual se comprenda correctamente el contenido de los
mismos. Existen muchos protocolos que rigen las comunicaciones en una red definiendo
un emisor y receptor especfico, una cierta codificacin de los mensajes, un formato y
encapsulacin, as como el tamao del mensaje entre otras caractersticas del flujo de
informacin.
Los protocolos se agrupan en lo que se conoce como una pila de protocolos y trabajan
juntos. La que de Internet se conoce comoprotocolodecontroldetransmisin/IP(TCP/IP)
e incluye a los protocolos de transferencia de hipertexto (HTTP), de transferencia de
hipertexto seguro (HTTPS), para transferencia simple de correo (SMTP), de transferencia
de archivos (FTP) y el de control de transmisin (TCP) entre otros. Cada uno de ellos
funciona de una manera especial de acuerdo a su definicin y permite que se propicie una
comunicacin efectiva. Laimportanciadeconocerycomprenderlosprotocolosesentonces
esencial para poder entender cmo funciona laredy lacomunicacinquesedaatravsde
lamisma.
El presente laboratorio tiene como objetivo la comprensin de la pila de protocolos que
componen TCP/IP ylainteraccinentreellosparaproveerserviciossobreuna reddedatos
a pequea escala. Asimismo, se pretende identificar los procesos de encapsulacin de
datos, as como establecer las funcionalidades de cada protocolo y de los servicios de red.
Para lograr esta comprensin se realizar un anlisis y monitorizacin de los protocolosy
servicios sobre una topologa de red a pequea escala utilizando Wireshark: una
herramientadeanlisisdepaquetes.
El anlisis de paqueteseselprocesodecapturaeinterpretacinentiemporealdelosdatos
obtenidos cuando los paquetes circulan en una red. Utilizando Wireshark se pueden
visualizar los datos de lospaquetesque secapturan.Ademsde unanlisisadecuadodelos
resultados arrojados por esta herramienta permite comprender cmo funcionan los
protocolosmsutilizadoseninternet.
El laboratorio se compone de varias pruebas de conectividad y de pruebas de conexin
utilizando los protocolos FTP,HTTPS, HTTP, SMTP y deoficinapostal(POP3)utilizando
Wireshark.

2. Pruebasdeconectividad

L
as pruebas de conectividad permiten verificar si se puede realizar una conexin de red

entre dos sistemas finales.Enestecasorealizamospruebascon elprotocolodemensajesde

control deinternet(ICMP)utilizandolaherramienta
pingparaprobarlaconectividadconel

enrutador de clientes, con dos usuarios de la red , con el servidor1 y con el servidor Web.
Para estas pruebas se realiz la conexin utilizando las direcciones IP correspondientes y
para el caso de la conexin con el servidor Web
la prueba tambinserealizconlaurldel
mismo.
El protocolo utilizado para realizar estas pruebas, es decir elICMP, pertenecealacapade
red a la cual pertenecen tambin los protocolos IP y los protocolos de enrutamiento de
Internet. Este protocolo es utilizado para comunicar informacin de la capa de red y
sobretodo parareportarerrores.Aunqueenocasionesseconsideracomopartedelprotocolo
IP en realidad se encuentra por encima de ste, pues los mensajes propios del mismo son
transmitidosdentrodedatagramasdeIP,esdecircomopartedelacarga(payload)delIP.
Los mensajes de este protocolo tienen varios campos: el tipo y el cdigo,unencabezadoy
los primeros 8 bytes del datagrama IP que lo caus (esto ltimo en el casodeserutilizado
para reportar un error). Cuando se utiliza ping se enva un ICMP tipo 8 y cdigo ceroal
sistema final con el que quiere establecerse la conexin. Ante esta peticin, que se conoce
como
echo request
, el sistema final responde con un mensaje tipo 8 y cdigo 0 queesuna
respuestaconocidacomo
echoreply
.
2.1 Pruebas de conectividad con el enrutador local de clientes y con dos usuarios de
red.
Se envan 4 paquetes ICMP al enrutador local y a los dos usuarios de red : en la primera
ocasin se suponeque nolleganlos4sinoslo3delos paquetes enviados.Peroalejecutar
la prueba una segunda vez si llegan los 4 paquetes. En la realizacin de esta prueba, sin
embargo pudimos observar quellegaronlos4paquetesenlasdosoportunidades.Laprueba
deconectividadconelenrutadorlocalseilustraacontinuacin(elsegundointento).
En este caso se aplic en
Wireshark
el filtro
((ip.src==192.168.20.6 and
(ip.dst==192.168.20.1
or
ip.dst==192.168.20.3
or
ip.dst==192.168.20.4))
or
(ip.dst==192.168.20.6
and
(ip.src==192.168.20.1
or
ip.src==192.168.20.3
or
ip.src==192.168.20.4)))como

se muestra en la Figura 2.1.1 para obtener slo los

resultados correspondientes al
ping con el enrutador local de clientes y los dos usuarios
locales (teniendo en cuenta que la direccin IP del equipo que se utiliz es: 192.168.20.6,
la del enrutador local de clientes es: 192.168.20.1 y las de los usuarios son: 192.168.20.3,
192.168.20.4)). En las columnas de la imagen se puede observar, para cada solicitud de
ping
, la IP de origen y destino, el protocolo correspondiente (que es en este caso el
protocolo ICMP), la direccindecontroldeaccesodemedio(MAC)deorigenydestino,el

tiempo y la informacin correspondiente a la comunicacin. Asimismo, se dividen con

lneas de color azul los registros de cada uno de los paquetes enviados a los diversos
destinos. No se incluyeelpuertodeorigennidedestinoenlamedidaenlaqueelprotocolo
ICMPnohaceusodelosmismos.

Figura2.1.1EnvodepaquetesporICMPalenrutadorlocaldeclientesyusuarioslocales

A continuacin, se ilustra la conversacin entre los sistemas finales para este protocoloa
partir de la conversacin para el protocolo de internet versin 4 (IPV4) y Ethernet que
corresponde al envo de
ping
.SepresentaestailustracinporqueICMPalencontrarseen la
capa de red utiliza la capa de enlace alaqueperteneceEthernetyseencuentradentrodela
misma capa con IPV4 perosedespliegaporencimadestehaciendouso delosdatagramas
de IP. En ambas visualizaciones se muestran las columnas que corresponden a las
direcciones de origenydedestino,elnmerodepaquetestransmitidos,lacantidad debytes
transmitidos, as como la duracin de tal conversacin.Seespecificaporcadasentidodela
conversacin, a saber de A a B y de B a A, (siendo A siempre el equipo desde donde se
envan los
ping y B el destino) el nmero de paquetes de bytes y la velocidad de
transmisin (bps). Slo se observa una diferencia en la manera en la que se muestra la
direccin de origen y destino considerando que Ethernet va a transmitir utilizando las
direcciones MAC y en IPV4 se utilizan lasdireccionesIP.Noexistenotrasdiferentes,pues
ambas visualizaciones ilustran las mismas conversaciones que dan cuenta de los
pings
enviados.


Figura2.1.2Conversacionesentresistemasfinales(Ethernet)

Figura2.1.3Conversacionesentresistemasfinales(IPV4)

Los mensajes que se envan utilizando el protocolo ICMP para esta prueba se ilustran a
continuacin en las Figuras 2.1.4 y 2.1.5 que corresponden a la peticin y a la respuesta
respectivamente. Como se mencion anteriormente corresponden a un
echorequesty
echo
reply. Estos mensajes correspondenalprimerpaqueteenviadoalenrutadorlocaldeclientes
y la respuesta recibida por el mismo, los dems mensajes son bastantesimilaresporloque
slosemuestrasteamododeilustracin.

Figura2.1.4Mensaje
echorequest(ping)
.

Figura2.1.5.Mensaje
echoreply(ping)
.

Para estas pruebas de conectividad se muestra a continuacin un resumen de las capturas

realizadas en la Figura 2.1.6. En este se muestra una relacin con todas las capturas
obtenidas y las que corresponden a los
pings las cuales slo son el 6.87% del total de
capturasrealizadas.

Figura2.1.6.Resumendecapturastomadas

En las figuras 2.1.8 y 2.1.9 se ilustran las conexiones con otros sistemas finales que
corresponden a IPV4 y Ethernet por la misma razn que se incluyeron en las
conversaciones (es decir, porque ICMPutilizalacapadeenlacealaqueperteneceEthernet
yseencuentradentroyhaceusodelosdatagramasdeIP.)

Figura2.1.8Conexionesconsistemasfinales(IPV4)

Figura2.1.9Conexionesconsistemasfinales(Ethernet)

Adicionalmente se ilustra en la figura 2.1.10 cmo se distribuye el trfico en estas

capturas. Se filtra por ICMP para poder ver cmo flucta este trfico y cmo se relaciona
conrespectoalafluctuacindeltrficoengeneral.

Figura2.1.10Trficodecapturas

2.2Pruebasdeconectividadconelservidor1.
Se realiza una prueba de conectividad con el servidor1 utilizandosuIPyacontinuacinse
ilustra todoelproceso.Seenvan4paquetesICMP sesuponeque nolleganlos4sinoslo
3delospaquetesenviados,sinembargopudimosobservarquellegaronlos4paquetes.
En este caso se aplic en
Wireshark
el filtro
(icmp.type and
((ip.src==192.168.20.6
and
ip.dst==192.168.40.2)
or
(ip.src==192.168.40.2 and ip.dst==192.168.20.6)))como

se muestra en la
Figura 2.2.1 para obtener slo los resultados correspondientes al
ping con elservidor1que
corresponde al servidorDNS (teniendo en cuenta que la direccin IP del equipo que se
utiliz es: 192.168.20.6 y la del servidorDNS es 192.168.40.2)). En el filtro se incluye
icmp.typeparaqueslosemuestrenlascapturascorrespondientesal
ping
,enestecasoes
necesario teniendo en cuenta que se envan al servidorDNSyduranteeltiempodecaptura
tambin se envan solicitudes detipoDNS aesteservidor.stasltimasnosonpertinentes
para la evaluacin de las pruebas de conectividadyportantonose incluyen.Lascolumnas
delaimagensonlasmismasqueseutilizanenlapruebadeconectividadanterior.

Figura2.1.1EnvodepaquetesporICMPalservidorDNS

Las figuras 2.2.2 y 2.2.3 corresponden a la conversacin que se ilustra nuevamente desde
IPV4 y ethernet respectivamente. stasincluyenlamismainformacinquelasde laprueba
anterior.

Figura2.2.2.Conversacinentresistemasfinales(IPV4)

Figura2.2.3.Conversacinentresistemasfinales(Ethernet)

En estecasolosmensajestienen lamismaestructuraqueenlapruebaanteriorporloqueno
se considera necesario incluirlos. Se muestra a continuacin un resumen de las capturas
realizadas en la Figura 2.2.4. En este resumen se muestra una relacin con todas las
capturas obtenidas respecto a las que corresponden alos
pingslascualesslosonel4,73%
deltotaldecapturasrealizadas.

Figura2.2.4Resumencapturasparapruebadeconectividadconservidor1.

En las figuras 2.2.5 y 2.2.6 se ilustran las conexiones con otros sistemas finales que
corresponden a IPV4 y Ethernet respectivamente por la misma razn que se incluyeron en
las conversaciones (es decir, porque ICMP utiliza la capa de enlace a la que pertenece
EthernetyseencuentradentroyhaceusodelosdatagramasdeIP.)

Figura2.2.5Conexionesconsistemasfinales(IPV4)

Figura2.2.6Conexionesconsistemasfinales(Ethernet)

A continuacin se muestra cmo flucta el trfico en estas capturas en la Figura 2.2.7: se

realizaunafiltracinporelprotocoloICMPparavisualizarcmoeseltrficoqueinvolucra

aesteprotocolo.Sepuede observarascmoserelacionanlos
pings contodoeltrficoque
pasaporlared.

Figura2.2.7Trficodelascapturas

2.3PruebasdeconectividadconelservidorWeb.
Se realizan en este caso dos pruebasdeconectividadconel servidor:laprimerautilizando
su URL y la segunda haciendo uso de su direccin IP, a continuacin se ilustra todo el
proceso.Seenvan4paquetesICMPencadacaso.
Para la prueba realizadaconlaURLseobservaqueprimeroesnecesario obtenerlaIPpara
que puede llevarse a cabo la comunicacin con el servidor Web. El servicio de directorio
para traducir el
hostname
, que es lo que se obtiene de la URL, en una direccin IP es
ofrecido por el sistema de nombres de dominio(DNS)porloqueseobservaenestaprueba
de conectividad una peticin de este tipo. El DNS es una base de datos distribuida
implementada en servidores y un protocolo en la capa de aplicacin que permite hacer
queries a dicha base de datos. El protocolo DNS corre sobre el protocolo de datagrama de
usuario (UDP), es decir que las
queries
as como los mensajes de respuesta son enviados
con datagramasUDPal puerto53.EsesencialtenerencuentaqueDNSagregaun
delayen
estecaso.
El DNS utiliza ungrannmero deservidoresorganizadosdeformajerrquicaalrededordel
mundo: no existe un solo servidor DNS. Estos servidores guardan registros de recursos
(RRs) algunos de los cuales tienen el
mapping entre el
hostname y la direccin IP. Los
mensajes de respuesta de DNS contienen uno o ms de estos registros los cuales se
componen de cuatro campos a saber: nombre, valor, tipo y el tiempo de vida (TTL) (este
ltimo determina cuando debe retirarse un recurso del cach). El nombre y el valor
dependen del tipo de registro: existen cuatrotiposelA,elNS,elCNAMEyelMX.Eltipo
A ese el que resulta pertinente analizar en este caso pues corresponde al caso en que el

nombre es el
hostname
y el valor es ladireccinIP. Encuantoalosmensajesderespuesta
y
query (existen otros tipos de mensajes DNS, pero estos son los que se utilizan en este
caso) tienen la primero una encabezado con varios campos. Entre ellos se identifican uno
que tiene un nmero de identificacin de la
query
, un campo de banderas que contiene
varios tipos de banderas entre las que se destaca una tipo query/reply ( indica si es una
query o un reply, en el primer caso es un 0ydelocontrarioesun1).Enelheadertambin
se encuentran cuatro campos que indican elnmerodeocurrenciasdecuatroseccionesque
siguen al encabezado. As despus de ste se encuentra una seccin de pregunta que
contiene la informacin de la query realizada, o los registros de recurso de ser una
respuesta. Adems hay otras dos secciones que incluyen informacin correspondiente a
registrosparaotrosservidoresyotrainformacinadicional.
Teniendo esto en cuenta se aplic en
Wireshark
el filtro
((ip.src==192.168.20.6or
ip.src==192.168.10.3)or
ip.src==192.168.40.2)
and
((ip.dst==192.168.20.6
or
ip.dst==192.168.10.3)or
ip.dst==192.168.40.2)
como se muestra en la Figura 2.3.1 para obtener slo los
resultados correspondientes al
ping con el servidorWeb as como la solicitud DNS
(teniendo en cuenta que la direccin IP del equipo que se utiliz es: 192.168.20.6, la del
servidorDNS es 192.168.40.2 y la del servidorWeb es 192.168.10.3)). Utilizando tal filtro
an se muestran resultados que no corresponden a la prueba de conectividad, estos se
ignoran pues pertenecen a otras solicitudes DNS que se dan durante el tiempo de captura
por lo tanto no se incluyen en la figura. Las columnas de la imagen son lasmismasquese
utilizan en la prueba de conectividad anterior ms los puertos de origen y destino para
ilustrarelusodelosmismosenDNS.

Figura2.3.1.EnvodepaquetesporICMPalservidorWebconURL

A continuacin se ilustra la conversacin entre los sistemas finales en este caso

observamos tambin la conversacin en UDP que correspondealapeticin DNS. Tantoen
la conversacin de Ethernet y de IPV4 se observa que hay 2 paquetes ms que
corresponden a la peticin DNS realizada. Las figuras 2.3.2, 2.3.3 y 2.3.4 corresponden a
lasconversacionesUDP,IPV4yEthernetrespectivamente.

Figura2.3.2.Conversacinentresistemasfinales(UDP)

Figura2.3.3.Conversacinentresistemasfinales(IPV4)

Figura2.3.4.Conversacinentresistemasfinales(Ethernet)

En este caso los mensajes del ICMP tienen la misma estructura que en la prueba anterior
por lo que no se considera necesario incluirlos. Se incluyen entonces los mensajes de la
peticin DNS cuya estructura ya fue precisada anteriormente. Las figuras 2.3.5 y 2.3.6
correspondenala
query
yalarespuestaparalamismarespectivamente.

Figura2.3.5.
Query
DNS


Figura2.3.6.
Reply
DNS

Se muestra a continuacin un resumen delascapturasrealizadasenlaFigura2.3.7.Eneste

resumen se muestra una relacin con todas las capturas obtenidas respecto a las que
corresponden a los pings y la peticin DNS las cuales slo son el 7,58% del total de
capturasrealizadas.


Figura2.3.7.ResumencapturaspruebadeconectividadconURL

En las figuras 2.3.8, 2.3.9 y 2.3.10 se ilustran las conexiones con otros sistemas finales
quecorrespondenaUDP,IPV4yEthernetrespectivamente.

Figura2.3.8.Conexionesconsistemasfinales(UDP)

Figura2.3.9.Conexionesconsistemasfinales(IPV4)


Figura2.3.10.Conexionesconsistemasfinales(Ethernet)

A continuacin se muestra cmo flucta el trfico en estas capturas en laFigura2.3.11:se

realiza una filtracin por el protocolo ICMP y DNS para visualizar cmo es el trfico que
involucra a este protocolo(teniendo en cuenta que aqu se requiere realizar peticiones al
servidor DNS como parte del proceso del
ping
). Se puede observar as cmoserelacionan
los
pings
contodoeltrficoquepasaporlared.

Figura2.3.11Trficodelascapturas

En la prueba de conectividad con el servidor Web desde la IP nicamente hay diferencias

con respecto a la peticin DNS, pues no hay necesidad de realizarla
.
En este sentido se
considera pertinente incluir slo la Figura 2.3.12 que ilustra el proceso. El filtro utilizado
para la misma fue:
(ip.src==192.168.20.6 or ip.src==192.168.10.3) and
(ip.dst==192.168.20.6 or ip.dst==192.168.10.3)
.

Figura2.3.12EnvodepaquetesporICMPalservidorWebconIP

3. AnlisisdeprotocoloFTP
El protocolo FTP que se encarga de la transferencia de archivos se encuentra incluidoen
la pila TCP/IP : la que se pretende explorarycomprenderatravsdelpresentelaboratorio.
Para el anlisis de este protocolo se realizaron dos conexiones a travs de un navegador
web utilizando en un caso la IP y en el otro la URL (
ftp://192.168.10.4 ,
ftp://ftp.labredes.com
respectivamente). El navegador acto como cliente FTP
solicitando la autenticacin y listando los archivos disponibles para la descarga.
Posteriormenteserealizelprocesodedescargadeunodelosarchivosanteslistados.
Este protocolo, que pertenece a la capa de aplicacin dentro de la pila TCP/IP, funciona a
grandes rasgos de la siguiente manera: en primera instancia es necesario que el usuario
pueda acceder a lacuentaremotaporloquedebeproporcionarlosdatosdeautenticacinlo
que le permite transferir archivos desde y hacia el sistema de archivos remoto. El usuario
debe proporcionar el
hostname del cliente remoto lo que permite que se establezca una
conexin TCPconelclienteremotoespecficamenteconelproceso delservidordeFTPde
ste ltimo. El usuario adems debe proporcionar su identificacin y contrasea que se
envan a travs de la conexin antes establecida. El servidor autoriza al usuario y ya se
puedeiniciarlatransferenciadearchivos.
Es importanteresaltarque enelprotocoloFTPseutilizandosconexionesparalelasde TCP:
una de control y otra de datos. La primera permite enviar informacin relacionada con el
proceso de conexin como tal, del usuario,y comando
GET y PUT
.Ladedatosesatravs
de la cual se realiza latransferenciade archivos.Laconexindecontrolseiniciaprimeroy
se da a travs del puerto21:esatravsdeellaqueseenvan losdatosdeidentificacin.El
servidor inicia la conexin de datos: sta se cierra tras enviar un archivo y se abre una
nuevaconexinencasodequerertransferirotroarchivo.
Los mensajes que se envan por la conexin de control incluyen comando FTP entre los
cuales se incluyen
USER, PASS, LIST, STR y RETR
. Estospermitenalusuarioenviar
su nombre de usuario , su contrasea , solicitar la lista de archivos, obtener un archivo , y
enviar unarchivo.Elusuarioesquienenvaestoscomandosalosqueobtieneunarespuesta
porpartedelservidor:lacualestestructuradacomounnmerodetresdgitos.
3.1EstablecimientodeconexinFTP
A continuacin se ilustra el proceso que se lleva a cabo antes de poder iniciar la
transferencia de archivos a travs del protocolo FTP. El mismo proceso se realiz

utilizando la IP y la URL pero slo se muestra el realizado con la IP. La diferencia radica
en que al utilizar la URL existe la necesidad de crearunapeticinDNS,lacualyahasido
explicadademaneracompletaenlaseccinanterior.
En este caso se aplic en
Wireshark
el filtro
(ip.src==192.168.20.6 and
ip.dst==192.168.10.4)
or
(ip.src==192.168.10.4
and
ip.dst==192.168.20.6)como

se muestra en la Figura 3.1.1 para obtener slo los

resultados correspondientes a la conexin FTP (teniendo en cuenta que la direccin IP del
equipo que se utiliz es: 192.168.20.6yladelservidorFTPes192.168.10.4).Las columnas
de la imagen son las mismas que se utilizan en las pruebas de conectividadincluyendolos
puertosdeorigenydestino.

Figura3.1.1ConexinFTPysolicituddelistadearchivos.

Las figuras 3.1.2 , 3.1.3 y 3.1.4 corresponden a la conversacin que se ilustra desde TCP
IPV4 y Ethernet respectivamente. Se puede observar que hay tres conexiones TCP:estose
debe a que el primer intento de login fall (primera conexin). Las otras dos conexiones
correspondenaladedatosylacontrolquefueronmencionadasanteriormente.Laconexin


exitosa de control se establece entrelospuertos55221y21yladedatosseestableceentre
55223 y 32584 en las cuales el primer puerto corresponde al servidor y el segundo al
cliente.

Figura3.1.2Conversacinentresistemasfinales(TCP)

Figura3.1.3Conversacinentresistemasfinales(IPV4)

Figura3.1.4Conversacinentresistemasfinales(Ethernet)

A continuacin se ilustra el flujo de mensajes entre cliente y servidor por FTP. El primer
flujo se da una vez se ha logrado establecer la conexin TCP y corresponde al flujo que
falla (Figura 3.1.5). Se cierra la conexin y se debe establecer una nueva para iniciar el
segundo flujo que se da de manera adecuada a travs delaconexindecontrol,sesolicita
la lista de archivos y seenva (estoocurreporotraconexinTCP:laquecorrespondealos
datosysecierraaltransmitir)(Figura3.1.6).

Figura3.1.5FlujodemensajesFTPfallido.
En este flujo se ilustra que el servidor responde que est listo, el usuario enva su nombre
deusuario,elservidorloacepta ysolicitalacontrasea.Elusuariola envaperoelservidor
respondequeelloginesincorrecto.

Figura3.1.6Flujodemensajesinicioysolicituddelistadearchivos.

Se observa en este flujo que el login se realiza de manera satisfactoria.Posteriormente(la

lnea punteada indica que ha pasada un tiempo que no se documenta) se realiza una
solicitud de cambio de directorioporpartedelusuarioqueelservidorrealizaeinformaque
ha realizado. El cliente solicita una lista dearchivosdeldirectorioyelservidorleresponde
que los enviara: esto suceder en un flujo de mensajes por una conexin TCP diferente.
Finalmente el servidor informa que ha cerrado tal conexin y que se ha enviado
exitosamentelalistadearchivos.
Se muestra a continuacin un resumen de las capturas realizadas enlaFigura3.1.7Eneste
resumen se muestra una relacin con todas las capturas obtenidas respecto a las que
correspondenalaconexinFTPlascualessonel46,156%deltotaldecapturasrealizadas.

Figura3.1.8ResumencapturasconexinFTP

En las figuras 3.1.9, 3.1.10 y 3.1.11 se ilustran las conexiones con otros sistemas finales
quecorrespondenaTCP,IPV4yEthernetrespectivamente.

Figura3.1.6Conexionesconsistemasfinales(TCP)

Figura3.1.7Conexionesconsistemasfinales(IPV4)

Figura3.1.8Conexionesconsistemasfinales(Ethernet)
.

A continuacin se muestra cmo flucta el trfico en estas capturas en la Figura 3.1.9: se

realiza una filtracin por el protocolo TCP y FTP para visualizar cmo es el trfico que
involucra a estos protocolos(teniendo encuentaqueaquserequieredelasconexionesTCP
para poder llevar a cabo la transferencia de archivos). Adicionalmente, se hace un filtro
sobre FTP que se conoce como FTPDATA que corresponde a la conexin de datos por
mediodelacualsetransmitenlosarchivos.

Figura3.1.9Trficodecapturas

3.2TransferenciadearchivosporFTP
A continuacin seilustra elprocesoquesellevaacaboparadescargarunarchivodelalista
de archivos. En este caso se aplic en
Wireshark
el filtro
(ip.src==192.168.20.6
and
ip.dst==192.168.10.4) or (ip.src==192.168.10.4 and
ip.dst==192.168.20.6)como

se muestra en la Figura 3.2.1 para obtener slo los

resultados correspondientes a la conexin FTP (teniendo en cuenta que la direccin IP del
equipo que se utiliz es: 192.168.20.6 y la del servidorFTP es 192.168.10.4)). Las
columnasdelaimagensonlasmismasquelasqueseutilizanenlaseccinanterior.

Figura3.2.1TransferenciadearchivosvaFTP.

Las figuras 3.2.2 , 3.2.3 y 3.2.4 corresponden a la conversacin que se ilustra desde TCP
IPV4 y Ethernet respectivamente. Se puede observar que hay dos conexiones TCP: la de
control se establece entre los puertos 54746 y 21 y la de datos se establece entre 54757 y
25307enlascualeselprimerpuertocorrespondealservidoryelsegundoalcliente.

Figura3.2.2Conversacinentresistemasfinales(TCP)

Figura3.2.3Conversacinentresistemasfinales(IPV4)

Figura3.2.3Conversacinentresistemasfinales(Ethernet)

A continuacin se ilustra el flujo de mensajes entre cliente y servidor por FTP para la
transferenciadelarchivo.

Figura3.2.4FlujodemensajesparatransmisindearchivosporFTP

En esteflujodemensajeselclientesolicitaalservidorqueacepteunaconexindedatos en
un nuevo puerto TCP: utilizando el comando
PASV
. El servidor acepta con el cdigo 227.
El cliente solicita al servidor a travs del comando
SIZE
que le proporciona informacin
sobre el tamao del archivo que desea descargar. El servidor responde y el cliente
utilizando el comando
MDTMsolicita

la fecha de la ltima modificacin de tal archivo a lo

que responde el servidor. Posteriormente con el comando RETRel
cliente solicita al
servidor el archivo deseado y el servidor le indica que iniciar la transmisin. El archivo
empieza adescargarseatravsdelaconexindedatos (otraconexinTCP)enpaquetesde
1460 bytes hasta que termina ( en la figura solo se muestra una vez cmo se enva este
mensaje pero en realidad se enva hasta que finaliza la descarga). Finalmente el servidor
indicaquehafinalizadolatransmisinycierralaconexindedatos.
Se muestra a continuacin un resumen delascapturasrealizadasenlaFigura3.2.5.Eneste
resumen se muestra una relacin con todas las capturas obtenidas respecto a las que
correspondenalaconexinFTPlascualessonel98,614%deltotaldecapturasrealizadas.

Figura3.2.5ResumendecapturastransmisindearchivoFTP

En las figuras 3.2.6, 3.2.7 y 3.2.8 seilustran lasconexionesconotrossistemasfinalesque

correspondenaTCP,IPV4yEthernetrespectivamente.

Figura3.2.6Conexionesconsistemasfinales(TCP)

Figura3.2.7Conexionesconsistemasfinales(IPV4)

Figura3.2.7Conexionesconsistemasfinales(Ethernet)

A continuacin se muestra cmo flucta el trfico en estas capturas en la Figura 3.2.8: se

realiza una filtracin por el protocolo TCP y FTP para visualizar cmo es el trfico que
involucra a estos protocolos(teniendo encuentaqueaquserequieredelasconexionesTCP
para poder llevar a cabo la transferencia de archivos). Adicionalmente, se hace un filtro
sobre FTP que se conoce como FTPDATA que corresponde a la conexin de datos por
mediodelacualsetransmitenlosarchivos.Sepuedeobservaraqucmocreceeltrficode
FTPDATAconrespectoalejercicioanterior,puesaqusetransfiereunarchivopesado.

Figura3.2.8Trficodecapturas

4. Anlisisdeprotocolosdecorreoelectrnico:SMTPyPOP3

En esta seccin se documentar el anlisis de intercambio de paquetes en el protocolo

SMTP y POP3 a travs de la herramienta de anlisis de paquetes Wireshark. Se

documentar elintercambiodepaquetesenmomentosclavedelosprotocolos, siendoestos:

autenticacinalserviciodecorreoelectrnico,envoyrecepcindecorreoselectrnicos.

4.1. Procesodeconfiguracindecorreo
En este caso se aplic en
Wireshark
el filtro
((ip.src==192.168.20.6 and
ip.dst==192.168.10.5)
or
(ip.dst==192.168.20.6
and
ip.src==192.168.10.5))
comosemuestraenlaFigura4.1.5paraobtenerslo
los resultados correspondientes al intercambio con el servidor de correo. Se
utilizaronlascredencialesdeusuario6@labredes.comycontraseausuario6
A continuacin se presenta el proceso general de autenticacin que establece la
conexin con el servidor de correo y enva los datos de autenticacin. En las
columnas de la imagen se puede observar, para cada mensaje, la IP de Origen y
Destino el protocolo correspondiente, MAC de destino, MAC de origen, puerto
origen,puertodedestinoeinformacinadicional.
.

Figura4.1.1PaquetesintercambiadosenautenticacindecorreoatravsdePOP3.

Figura4.1..2.ConversacinentreendpointsTCP

Descripcin del protocolo en autenticacin : La Figura 4.1.1 contiene los ltimos

mensajes intercambiados durante la etapa de autenticacin. En esta etapa se
establece una conexin a travs de TCP tras la cual por medio de POP se solicita
inicialmente el
set of initial capabilities
(1) que lista los comandos USER, UIDL y
TOP como se muestra en la Figura 4.1.3. El cliente procede a utilizar el comando
USER y el nombre de usuario completo (de lo contrario falla este paso como se
observa en la Figura 4.1.1 ). Tras este paso el servidor solicita la contrasea conlo
que el servidor responde con OK. En la grfica de conversacin entre endpoints se
puede observar que las conversaciones entre endpoints que se dan en el puerto110
sonaquellasquecorrespondenalprotocoloPOP(2)
Estructurademensajedeautenticacin:Comosepuedeobservarenlasfiguras4.1.3
y 4.4 los mensajes no estn encriptados(son enviadosyrecibidosenelpuerto110).
En el caso del cliente se componen de comandos y parmetros y en el caso del
servidorunindicadordeOKoERRORyelrestodelarespuesta.

Figura4.1.3.MensajesdeautenticacinPOPdesdeelservidor

Figura4.1.4.MensajesdeautenticacinPOPdesdeelcliente

Figura4.1.5.Resmendelacapturacorrespondientealaautenticacinylasconexionesconotrossistemas
finalesparalacaptura

4.2. Procesodeenvodecorreo
Paraelcasodeenvoseredactuncorreoquetenacomoremitenteelusuario6y
destinatarioelusuario1.Seaplicen
Wireshark
elmismofiltrodelprocesoanterior.

Figura4.2.1.Paquetesintercambiadosenelenvodecorreo.

Figura4.2.2.ConversacinentreendpointsTCP

Descripcin del protocolo en envo de correo: Como se puede observar en la Figura

4.2.2 todalaconexinsellevaacaboenelpuerto587queeselpuertopordefectopara
el protocolo SMTP. Los mensajes que llegan a este puerto se entienden como
submissions aunque en algunos casos se encuentra el servidor de correo configurado
para escuchar enelpuerto25(3).Despusdeestablecerla conexinpormediodeTCP
el servidor enva un mensaje al cliente indicando que el servicio est listo por medio
delprotocoloSMTP.Seguidamenteelcliente envaelcomandoEHLOque
indicaque
el cliente es capaz de procesar las extensiones de servicio y pide que el servidor
proporcione una lista de las extensiones que soporta
(4). El cliente responde con el
comando AUTH y tras autenticarse usa el comando MAIL para enviar un correo. Por
ltimo un mensaje con formato IMF es enviado desde el cliente.
Cuando SMTP es
equivalente al sobre del mensaje, el FMI es equivalente a la carta dentro del sobre.
Contieneelautor,destinatarios,asuntoyfechas
(5).


Figura4.2.3.MensajesdeenvodecorreodeSMTPdesdeelservidor

Figura4.2.4.MensajesdeenvodecorreodeSMTPdesdeelcliente

Figura4.2.5.MensajesdeenvodecorreoconformatoIMFdesdeelcliente

Estructura de los mensajes : En este caso la estructura de los mensajes es ms

interesante ya que al momento de la autenticacin nos encontramos con elementos
como que el nombre de usuario y contrasea ya no se encuentran en el mensaje
como texto plano. Del mismo modo el IMF es el formato enviado por SMTP para
poder intercambiar el correo entre el cliente y el servidor y enviarlo a su
destinatario.


Figura4.2.6.Resmendelacapturacorrespondientealaautenticacin,Trficosegnprotocoloylas
conexionesconotrossistemasfinalesparalacaptura

4.3. Procesoderecepcindecorreo
Paraelcasoderecepcindecorreoelusuarioremitentefueelgrupo3.Seaplicen
Wireshark
elmismofiltrodelprocesoinicial.

Figura4.3.1.PaquetesintercambiadosenautenticacindecorreoatravsdePOP3.


Figura4.3.2.Endpointspresentesenelprocesoderecepcindecorreo..

Descripcin del proceso de recepcin de un correo: Como se puede observar en la

Figura 4.3.1 el proceso de recepcin de correo inicia con un proceso de
autenticacin similar al observado al momentodeconfigurarlacuenta.Seestablece
inicialmente una conexin a partir de TCP. Todas las comunicaciones a travs de
TCP y POP son recibidas en el servidor en el puerto 110 que es el puerto estndar
para elprotocoloPOP.Unavezseinicialaconexinentrelos2servidores.Despus
de utilizar elcomandoCAPAyelservidorlistalosposiblescomandoselclienteusa
el comando USER y PASS para autenticarse. Despus de que el servidor responde
OK el cliente enva el comando STAT que esvlidoenelestadodetransaccindel
servidor y solo puede ser respondido como OKoERRjuntoconelnmerode
mensajes en el
mailbox
y sutamaoenbytes(2).Posteriormenteelclienteutilizael
comando LIST con el cual el servidor retorna una lista de resmendelosmensajes
presentes en el
mailboxdondeestalneasellamauna"listadeexploracin"paraese
mensaje (2). Luego el cliente utiliza el comando RETR pasando un id del mensaje
que busca obtener y el servidor
Despus del + OKinicial,elservidorPOP3enva
elmensajecorrespondienteal iddemensajedado,teniendocuidadodebytestuffel
caracter de terminacin
(2). Finalmente se cierra la conexin entre el cliente y el
servidor.

Figura4.3.3.Estructuradepaquetesenviadosporelservidor.


Figura4.3.4.Estructuradepaquetesenviadosporelcliente

Estructura de los mensajes : Enestecasoresultaninteresanteslosnuevoscomandos

utilizados por parte del cliente para obtener los mensajes que no se observaron
durante el proceso de autenticacin, en este caso particular LIST que le permite
obtener un resmen de los mensajes presentes en el
mailbox y el comando RETR
que le permite obtener un correo con un id determinado. Observamos que en este
proceso el servidor usa de nuevo el formatoIMF,enestecasoparaenviarellistdel
mailbox
para el caso de el correo consultado con el comando RETR el servidor
responde por medio del protocolo POP donde todo el contenido del correo
solicitadoseenvaatravsdelmensajedePOP.

5. ProtocoloHTTPyHTTPS
Lainteraccinconlapginaweb
www.facebook.com
sellevacabodelasiguiente
manera:
1. Trasborrarelcachderesolucin
DNS
seingresatravsde
Google
Chrome
alapgina
www.facebook.com
2. Comoyasetenaregistradalapginanosellegalapginadeloginsino
directamentealnewsfeedde
facebook.
3. EnlabarradebsquedasseingresSemana
4. SeaccedialperfildelarevistaSemana
5. SeaccedialasfotosdelarevistaSemana
6. Senavegatravsdelasfotografas.
7. Seaccedialmendevideos.

Figura5.0.1.ResmendelacapturasinFiltrosygrficodeTrficosegnProtocolo

5.1. Protocolosderedqueparticipanenelintercambiodedatosgeneradoalingresaral
sitiowebFacebook:

Figura5.1.1.Protocolosinvolucradosenlacaptura

Dentrodelosprotocolosinvolucradosenlacapturaseobservanprotocolosya
tratadosalolargodeestelaboratorioydellaboratorioanteriorcomo
TCP,UDP,
DNS,ARP,ICMPv6.
Nuevosprotocolosobservadosenelintercambiodepaquetesson:
SSL
:
Elobjetivoprincipaldelprotocolo
SSL
esproporcionarprivacidady
fiabilidadentredosaplicacionesquesecomunican.Elprotocoloescompuestode
doscapas.Enelnivelmsbajo,sobrealgnprotocolodetransportefiable(por
ejemplo,
TCP[RFC0793])
,estelprotocoloderegistro
SSL
.Elprotocolo
SSL
de
registroseutilizaparalaencapsulacindediferentesprotocolosdenivelsuperior.
Unodetalesprotocolosencapsulados,elProtocolodehandshake
SSL
,permiteque

elservidoryelclienteseautentiquenentresynegocienunalgoritmodecifradoy
llavescriptogrficasantesdequeelprotocolodeaplicacintransmitaorecibasu
primerbytededatos.Unaventajade
SSL
esqueesindependientedelprotocolode
aplicacin.Unprotocolodenivelsuperiorpuedeubicarseenlapartesuperiordel
protocolo
SSL
deformatransparente.
Elprotocolo
SSL
proporcionaunaconexindeseguridadquetienetrespropiedades
bsicas:
1.Laconexinesprivada.Elcifradoseutilizadespusdeunhandshakeinicial
paradefinirunaclavesecreta.Seutilizalacriptografasimtricaparaelcifradode
datos(porejemplo,
DES,3DES,RC4
).
2.Laidentidaddelgrupopuedeserautenticadautilizandounaclaveasimtrica,o
pblica(porejemplo,
RSA,DSS
).
3.Laconexinesfiable.Transportedemensajesincluyeunmensajede
comprobacindeintegridadmedianteunmensajeconllaveCdigodeautenticacin
(
MAC
)[
RFC2104
].Funcionesdehashseguras(porejemplo,SHA,MD5)seutiliza
paraclculos
MAC
.(7)
QUIC
:
Esunprotocoloexperimentaldestinadoareducirlalatenciawebsobrela
deTCP.Enlasuperficie,
QUIC
esmuysimilara
TCP
+
TLS+SPDY
implementado
en
UDP
.Debidoaque
TCP
esimplementadoenlosncleosdelsistemaoperativoy
middleboxfirmware
,hacercambiossignificativosa
TCP
escasiimposible.Sin
embargo,dadoque
QUIC
seconstruyeenlapartesuperiordela
UDP
,carecede
taleslimitaciones.Lasprincipalescaractersticasde
QUIC
sobreunexistente
TCP+
TLS+SPDY
incluyen:
Reduccindramticadeltiempodeestablecimientodeconexin,mejoradelcontrol
decongestin,multiplexacinsinlacabezadelalneadebloqueo,correccinde
erroresdereenvo,migracindeconexin(8).
TLS
:
ElobjetivoprincipaldelProtocoloTLSesproporcionarprivacidade
integridaddelosdatosentredosaplicacionesquesecomunican.Elprotocoloesta
compuestopordoscapas:El
TLSRegisterProtocol
yel
TLSHandshakeProtocol
.
Enelnivelmsbajo,sobrealgnprotocolodetransporteconfiable(porejemplo,
TCP
)estel
TLSRegisterProtocol
.Esteproporcionaseguridaddeconexinque
tienedospropiedadesbsicas:
1.Laconexinesprivada.Criptografasimtricaseutilizaparaelcifradodedatos.
Lasclavesparaestecifradosimtricosegenerannicamenteparacadaconexiny

sebasaenunsecretonegociadoporotroprotocolo(comoel
TLSHandshake
Protocol
).El
Recordprotocol
tambinsepuedeutilizarsincifrado.
2.Laconexinesfiable.Eltransportedemensajesincluyeunmensajede
comprobacindeintegridadusandoun
MAC
conllave.(9)
HTTP
:
ElProtocolodetransferenciadehipertexto
(HTTP)
esunprotocolodenivel
deaplicacinparasistemascolaborativosdistribuidosdeinformacinhipermedia.
HTTPhaestadoenusoporel
WorldWideWebglobalinformationinitiative
desde
1990.LaprimeraversindeHTTP,referidocomoHTTP/0.9,fueunprotocolo
simpledetransferenciadedatossinprocesaratravsdeInternet.HTTP/1.0,tal
comosedefineenel
RFC1945
,mejoraelprotocolopermitiendoquelosmensajes
estnenunformatosimilaral
MIME
,quecontienemetainformacinacercadelos
datostransferidosymodificadoresdelasemnticadepeticin/respuesta.(10)
SSDP
:
ProtocoloSimplededescubrimientodeservicios.Consisteenun
HTTP
request
conlainstruccin
NOTIFY
paraanunciaro
MSEARCH
parabuscarun
servicio..
5.2. TrficodeHTTPSgeneradoalingresaraFacebook:

Figura5.2.1.Grficaderesmendecapturaconelfiltrotcp.port=443

Enlagrficaderesmendelacapturasepuedeobservarqueel93.615%deltrfico
capturadocorrespondeaunintercambiohechocon
TCP
enelpuerto443,esdecir
quemsdel90%deltrficogeneradodurantelainteraccincorrespondea
HTTPS
.

Mecanismosofiltrosde
Wireshark
paraestudiarlascomunicaciones
HTTPS
:
Elpuerto443estdefinidopordefectoparalascomunicacionesde
HTP
sobre
TLS/SSL
(esdecir
HTTPS
).Deestamanerapodemosfiltraren
Wireshark
eltrfico
de
HTTPS
conelfiltro
TCP.port == 443

5.3. TrficodeHTTPidentificado:

Figura5.3.1.Grficaderesmendecapturaconelfiltrohttp

Comoseobservaenlagrfica5.3.1eltrficocorrespondientealprotocolohttp
dentrodelacapturaessloel1.73%deltrficototalcapturado.Estohacequeel
trficodeHTTPnoseasignificativocomparadoalporcentajedetrficoHTTPS
(msdel90%).
LamayoradeltrficoHTTPestabaconformadopormensajes
MSEARCH
quese
utilizanenespaciosresidenciales(enestecasolaspruebasserealizaronenel
domiciliodeunadelasintegrantesdelequipo)conelfindedescubrirserviciosde
red.

Figura5.3.1.EjemplosdemensajesHTTPparaMSEARCHyNOTIFY

SeidentificaronciertosrequestdeHTTPrelacionadosal
Windowsmediaplayer
en
elcualsehacaunapeticingetsobreelconodedichaaplicacinsinembargono
nosresultposibleasociardichasaplicacionesconeldesarrollodelainteraccin1

Elrequestfuerealizadoalsiguiente
LINK
http://[fe80::9405:f44:fdac:c5e4]:2869/upnphost/udhisapi.dll?content=uuid:70c7c061912347bd874724bb5
071dfbb

5.4. ProcesodeHandshake:
EnelcasodelanlisisdelprocesodeHandshakeparaunprotocolode
TLS
se
observaqueesteprocesosellevaacaboconelservidordelacompaa
Akamai
que
seencargadealmacenaryproveercontenidomultimediaparadiversascompaas
entreellas
Facebook
locualexplicaraelintercambioconlosservidoresdeakamai
paraunainteraccinconcontenidoscomofotografasovideosdesde
Facebook.
Duranteelprocesode
Handshake
seobservanlassiguientesetapasprincipales:El
mensajede
Hello
delCliente,mensajede
Hello
delServidor,envodellavespor
partedelservidor,
ServerHelloDone
,intercambiodellavesporpartedelClientey
envodeApplicationData.Enlafigura5.4.1sepuedeobservarlosdistintospasos
aqudescritosencuantoaintercambiodepaquetesascomosuabstraccinterica
enlaFigura5.4.2.

Figura5.4.1.SnapshotdelospaquetesintercambiadosenSSL

Figura5.4.2.OverviewtericodelprocesodeSSL/TLS2

TomadodeMicrosofttechNetartculoSSL/TLSindetaildisponibleen:
https://technet.microsoft.com/enus/library/cc785811(v=ws.10).aspx

ClientHelloMessage
:ElclienteinicialasesinenviandounmensajedeHelloal
servidor.ComosepuedeobservarenlaFigura5.4.3,elmensajecontieneunnmero
randomqueserutilizadojuntoconelnmerorandomdelservidorparagenerarel
mastersecret
conelcuallasllavessernenviadas(11),un
sessionID
,
CipherSuites
disponiblesenelclienteyelalgoritmodecompresin.

Figura5.4.3.
ClientHelloMessage

ServerHelloMessage
:ElservidorenvaunmensajedeHelloquecontienedatos
aleatorios,elciphersuiteseleccionadodelosdisponiblesenelclienteyelalgoritmo
decompresin.SepuedeobservarlosdetallesenlaFigura5.4.4

Figura5.4.4.
ServerHelloMessage

ServerCertificate:
Elservidorenvasucertificadoalcliente.Loscertificadosson
visiblesdebidoaquestossonpblicos.Elclienteverificaelcertificadopara
cerciorarsedequetengaelmismonombreconelqueelclienteseconect.Unpaso
adicionalasteesunasolicitudparaelcertificadodelclientesinembargoenla
capturasloelservidorenvasucertificadoyaquequienrealmenteestenviando
informacinsensibleyquiereverificarlaautoridaddesucontraparteeselcliente.

Figura5.4.5.
ServerCertificate

ServerKeyExchange:
ElServidorenvaunaclavetemporalalClientequeesusado
porelClienteparaencriptarel
KeyExchangeMessage.
Estepasoesslonecesario
cuandoelalgoritmodellavepblicanopermiteencriptarelmensajede
Key
Exchange
delCliente.

Figura5.4.6.
ServerKeyExchange

ServerHelloDone:
Seenvaestemensajeparaindicarqueelservidorestala
esperaderespuestaporpartedelcliente.

Figura5.4.7.
ServerHelloDone

ClientKeyExchange:
Elclienteutilizalosnmerosrandomenviadosporlypor
elservidorparacrearel
premastersecret
elcualencriptautilizandoelcertificado
enviadoporelservidor.Encasodequeelservidorpuedadesencriptarla
informacinelclientepuedeestarsegurodequeseestcomunicandoconeldueo
delcertificado,delcualyaverificcorrespondealservidorconelquedesea
comunicarse.

Figura5.4.7.
ClientKeyExchange

ServerClientChangeCipherSpec:
Mensajequenotificaquelosmensajes
siguientesvanaestarencriptadosconlasllavesnegociadas.


Figura5.4.7.
ChangeCipherSpecmessage

5.5. Mensajesde
ApplicationData
Losmensajesdeapplicationdatasonmensajesqueseencuentranencriptadosde
acuerdoalosparmetrosqueseestablecieronduranteelhandshake.Sepuede
observarunejemplodeunmensajeenviadodesdeelservidorhastaelclienteenla
Figura5.5.1:

Figura5.5.1.Mensajede
DataApplication

6. Preguntas
1. Puede encontrarse informacin adicional sobre los servicios prestados en la
topologa usando la captura de paquetes? Por ejemplo, sera posible encontrar
laubicacindelosrecursosdecontenido?Explicar.
Utilizando la captura de paquetes se pueden generar anlisis interesantes que
permiten comprender mejor lascomunicacionesqueseestablecen. Podervisualizar
la estructura de cada uno de los mensajes de cadaprotocoloyelcaminoquesiguen
es informacin que permite entender los servicios que se prestan utilizando una
determinadatopologa.
Tal y como se expone en la pregunta nmero 4 las capturas en
Wireshark
slo
permiten visualizar la informacin de ladireccinMACparaloscomponentesdela
misma red lo que impide ubicar fsicamente a hosts o enrutadores que no
pertenezcanasta.

Dentro de los paquetes capturados, hay frames cuya direccin IP no sea la

direccin del cliente a la que corresponde la interfaz de red? Si es as, Por qu
sucedeesto?

Como se observa en la captura de la Figura 6.2.1 estos casos si se dan. Para el

ejemplo mostrado en la captura la IP no correspondiente se debe a que se est
llevando a cabo un proceso de Broadcast el cual la capa de red proporciona un
servicio de entrega de unpaqueteenviadodesdeunnododeorigenatodos losotros
nodosenlared(12).

En este casoseobservaunprocesodemultidifusinqueutilizaunrangoespecialde
direcciones IP que no identifican puntos dentro de una red sino redes como tal. En
este caso la IP es 192.168.20.255 que no corresponde a la de la interfaz de red
Usuario1(192.168.20.6)sinoatodalaredlocal.

Figura6.2.1IPnocorresponditealainterfazderes

2. Para capturas de un mismo protocolo, hay diferencias significativas entre los

paquetes respecto a su estructura? Explicar y mostrar capturas que respalden la
respuestas.

El objetivoprincipaldeunprotocoloesestablecerciertasreglasyacuerdosparaque
la comunicacin se pueda llevar a cabo. Es por esto que las estructuras
correspondientes a los paquetes dentro de un mismo protocolo deben ser iguales
pues siguenunosestndarespreviamentedefinidosparaquesepuedacomprenderel
mensaje. Es precisamente por esto que a lo largo del laboratorio no se incluyeron
mensajes de los mismos protocolos, sino que se ejemplifico con un mensaje como
era la estructura de uno de ellos. A continuacin se ilustra esta idea desde los
mensajescapturadosenlosdiferentes
pings
.

Figura6.3.1
Ping
aunservidorDNS

Figura6.3.2Respuestaa
ping
desdeunusuario.

En estos mensajes se puede ver que apesardequeunoprovienedeunusuariolocal

y otra de unservidoryademsunoesunarespuestayelotroun
request
.Seobserva
la misma estructura: tipo, cdigo, un checksum, un identificador, un nmero de
secuencia,yunosdatos.

3. Por qu Wireshark muestra la direccinMACvigentedelenrutadorlocal,pero

no la direccin MAC vigente de los servidores remotos al realizar una
comunicacindirectaaellos?
nicamente se puede averiguar la direccin MAC de los computadores que estn
la misma red y tambin la del enrutador local en la medida en la que existe una
conexin con este ltimo. As WireShark puede mostrar la MAC del enrutador
local. Pero cuando se atraviesa una enrutadorcomoeselcasocuandoserealizauna

comunicacin con un servidor remoto no se puede averiguar tal direccin MAC

porque no pertenece a la misma red. Para obtener una direccin MAC a partir de
una IP se hace uso del protocolo ARP , pero este slo puede traducir una IP en
direccin MAC si sta pertenece a un router o equipo que pertenezca a la misma
red: desde all tambin se explica porque no se muestra la direccin MAC de los
servidoresremotosaunqueexistacomunicacinentreellos.
Cuando se desea crear una comunicacin con un servidor que no pertenecealared
el proceso es diferente. Al tener en cuenta que ARP slofuncionaenlamisma red
no se puede utilizar este para obtener la MAC. Para comprender el proceso quese
lleva a cabo cuando se intenta crear comunicacin con un servidor remoto es
necesario comprender que los enrutadores tienen una IP , un mdulo ARP y un
adaptador para cada una de sus interfaces. As los enrutadores pueden tener varias
direcciones MAC en la medida en la que cada adaptador tiene una. Para poder
enviar un mensaje se requiere que se leindiquealadaptadorunadireccinMACde
destino. Sin embargo la MAC que se le debe indicar es la que corresponde a su
enrutador local y esto si lo puede obtener a travs de ARP. Una vez llega al
enrutador este puede determinar la interfaz a la cual el datagrama debe dirigirse y
esta lo pasa a su adaptador el cual lo encapsula y lo manda a la otra red. All la
direccin MACsiesladeldestinolacual hasidoobtenidaporelenrutadordedicha
redatravsdeARP.

4. Por qu el computador enva un mensaje de tipo ARP antes de enviar la

primera solicitud de ping? Explique cmo opera este protocolo con respecto a
loobservadoenlascapturasrealizadas?

El computador enva un mensaje tipo ARP antes de iniciar la primera solicitud de

ping
porque buscaaveriguar ladireccinMAC deldestinatariodel
pingparapoder
enviar all la solicitud esto en la medida en la que para enviar un datagrama la
fuentenecesitadarlealadaptadornosololadireccinIPsinotambinlaMAC.

Cuando por el contrario el

ping
se dirige a un servidor remoto se solicita la MAC
del enrutador local no del servidor al que lo enva como ya se especific en la
preguntaanterior.

ARP es el protocolo que permite le brinda al

host que desea comunicarse a la
direccin MAC que necesita a partir de una IP. En estesentidoesunprotocoloque

se parece al DNS aunque este ltimo siempre puede traducir el

hostname
en una
direccin IP, mientras que en ARP slo puede llevarse a cabo la traduccinsilaIP
pertenece a una interfaz de
host
o enrutador que pertenezca a la misma red que la
del
sendinghost
.

El protocolo funciona de la siguiente manera: cada sistema final o enrutador tiene

una tabla ARP enlamemorialacualcontieneelmapeoentredireccionesIPyMAC
aunque no necesariamente tiene un registro para todas las direcciones IP de su red.
Esta tabla tambin contiene un valor TTL que indica cundo se debe borrar un
registro de la tabla. As que cuando se desea enviar un datagrama dentro de la
mismaredloqueseenprimerainstanciaesconsultarlatablasielregistronoexiste
se procede a utilizar el protocolo ARP. Se enva una peticin que tiene como
propsito consultar con todos los hosts y enrutadores que pertenecenalaredpara
determinar la direccin MAC que corresponde a la IP enviada como parte de la
peticin.Estapeticinseenvahaciendousodeun
broadcastframeporquesebusca
que llegue a todos los adaptadores de la red para consultar si su direccin IP es la
misma que la enviada en la peticin. Cada adaptador pasa el paquete al mdulo
ARPparaqueverifiqueyenvaladireccinMACsicoincideconlaIPbuscada.

El computador enva un mensaje ARP slo la primera vez porque como no

encuentraelregistroqueestbuscandoenlatabla,enlassiguientesocasionesnoes
necesariohacerloporqueyaestdichoregistroall.

7.Bibliografa
1. J.Kurose&K.Ross,
Computernetworking
.6.Ed.UnitedStates:Pearson,2013.
2. R.Gellens&C.Newman&L.Lundblade.RequestforComments:2449.POP3Extension
Mechanism.[Enlnea][Citadoel:13deAgostode2015.]
https://www.ietf.org/rfc/rfc2449.txt
.
3. M.Rose.RequestforComments:1081.PostOfficeProtocolVersion3.[Enlnea]
[Citadoel:13deAgostode2015.]
https://tools.ietf.org/html/rfc1081
4. R.Gellens&J.Klensin.RequestforComments:2476.MessageSubmission.[Enlnea]
[Citadoel:13deAgostode2015.]
https://www.rfceditor.org/rfc/rfc2476.txt
5. J.Klensin.RequestforComments:2821.SimpleMailTransferProtocol.[Enlnea]
[Citadoel:13deAgostode2015.]
https://www.ietf.org/rfc/rfc2821.txt

6. WiresharkWiki.InternetMessageFormat(imf).[Enlnea][Citadoel:13deAgostode
2015.]
https://wiki.wireshark.org/IMF
7. A.Freier&A.Karlton&P.Kocher.RequestforComments:6101.TheSecureSockets
Layer(SSL)ProtocolVersion3.0[Enlnea][Citadoel:16deAgostode2015.]
https://www.ietf.org/rfc/rfc2821.txt
8. TheChromiumProject.QUIC,amultiplexedstreamtransportoverUDP.[Enlnea]
[Citadoel:16deAgostode2015.]
https://www.chromium.org/quic
9. T.Dierks&C.Allen..RequestforComments:2246.TheTLSProtocolVersion1.0[En
lnea][Citadoel:16deAgostode2015.]
https://www.ietf.org/rfc/rfc2246.txt
10. R.Fielding&J.Gettys&J.Mogul&H.Frystyc&L.Masinter&P.Leach&T.Berners
Leev.RequestforComments:2616.HypertextTransferProtocolHTTP/1.1[Enlnea]
[Citadoel:16deAgostode2015.]
http://tools.ietf.org/html/rfc2616
11. MicrosoftTechNet.SSL/TLSinDetail.[Enlnea][Citadoel:16deAgostode2015.]
https://technet.microsoft.com/enus/library/cc785811(v=ws.10).aspx
12. Kurose,J.&Ross,K.(2011)BroadcastandMulticast.EnComputerNetworking,a
topdownapproach(pp.230).AddisonWesley,6thEd.