Analisis de Trafico

Curso: Analisis de traIico
Alejandro Corletti Pgina 1 de 85

CURSO DE ANALISIS DE TRAFICO
Por Alejandro Corletti (acorlettihotmail.com)

1. INTRODUCCION:

1.1. Presentacin de modelo de capas.

Son varios los protocolos que cooperan para gestionar las comunicaciones, cada uno de ellos cubre
una o varias capas del modelo OSI (Open System interconnection), la realidad, es que para
establecer la comunicacion entre dos ETD se emplea mas de un protocolo, es por esta razon que se
suele hablar no de protocolos aislados, sino que al hacer mencion de alguno de ellos, se sobre
entiende que se esta hablando de una 3,/$ de protocolos, la cual abarca mas de un nivel OSI, son
ejemplo de ello X.25, TCP/IP, IPX/SPX, ISDN, etc.
Una Iorma de agruparlos es como se encuentran cotidianamente los siete niveles del modelo OSI en
tres grupos que tienen cierta semejanza en sus Iunciones y/o servicios:

OSI Generalizado
Aplicacion
Presentacion
Sesion

APLICACION
Transporte TRANSPORTE
Red
Enlace
Fisico

RED

La ISO (International Standard Organization), establecio hace 15 aos este modelo OSI que hoy
lleva la denominacion ISO 7498 o mas conocida como X.200 de ITU.

1.2. Modelo OSI y DARPA (TCP/IP).

El modelo OSI es, sin lugar a dudas el estandar mundial por excelencia, pero como todo esquema
tan amplio presenta una gran desventaja, el enorme aparato burocratico que lo sustenta. Toda
determinacion, protocolo, deIinicion o reIerencia que este proponga debe pasar por una serie de
pasos, en algunos casos reuniendo personal de muchos paises, que demoran excesivo tiempo para la
alta exigencia que hoy impone Internet. Hoy al aparecer un nuevo dispositivo, protocolo, servicio,
Iacilidad, etc. en Internet, el mercado si es util, automaticamente lo demanda, como ejemplo de
esto hay miles de casos (chat, IRC, SMS, WAP, etc). Si para estandarizar cualquiera de estos se
tardara mas de lo necesario, los Iabricantes, se verian en la obligacion de oIrecer sus productos al
mercado, arriesgando que luego los estandares se ajusten a ello, o en caso contrario, los clientes
Iinales suIririan el haber adquirido productos que luego son incompatibles con otros. Hoy no se

puede dar el lujo de demorar en una red cuyas exigencias son cada vez mas aceleradas e
imprevisibles.
Para dar respuesta a esta nueva REVOLUCION TECNOLOGICA (Internet), aparecen una serie de
recomendaciones agiles, con diIerentes estados de madurez, que inicialmente no son un estandar,
pero rapidamente oIrecen una guia o recomendacion de como se cree que es la Iorma mas
conveniente (segun un pequeo grupo de especialistas) de llevar a cabo cualquier novedad de la red.
Se trata aqui de las RFC (Request For Commentaries), que proponen una mecanica veloz para que
el usuario Iinal no suIra de los inconvenientes anteriormente planteados, dando respuesta a las
necesidades del mercado eIicientemente.
Se produce aqui un punto de inIlexion importante entre el estandar mundial y lo que se va
proponiendo poco a poco a traves de estas RFC, las cuales en muchos casos hacen reIerencia al
modelo OSI y en muchos otros no, apareciendo un nuevo modelo de reIerencia que no ajusta
exactamente con lo propuesto por OSI. Este modelo se lo conoce como Pila, stack o Iamilia
TCP/IP o tambien como modelo DARPA por la Agencia de Investigacion de proyectos avanzados
del DoD (Departamento de DeIensa) de EEUU, que es quien inicialmente promueve este proyecto.
Este modelo que trata de simpliIicar el trabajo de las capas, y por no ser un estandar, se ve reIlejado
en la interpretacion de los distintos autores como un modelo de cuatro o cinco capas, es mas,
existen IilosoIicos debates acerca de como debe ser interpretado.
En este texto, se va a tratar el mismo como un modelo de cinco capas, solamente por una cuestion
practica de como ajustan las mismas a los cuatro primeros niveles del modelo OSI, tratando de no
entrar en la discusion Bisantina del mismo, y dejando en libertad al lector de Iormar su libre opinion
sobre el mejor planteo que encuentre.
Si se representan ambos modelos, sin entrar en detalles de si las distintas capas coinciden
exactamente o no (pues este es otro gran tema de discusion, que no sera tratado en este texto), se
pueden graIicar mas o menos como se presenta a continuacion:

OSI DARPA o TCP/IP
Aplicacion
Presentacion
Sesion

Aplication
Transporte Transport
Red Internetwork
Enlace Medium Access
Fisico Phisical

1.3. Conceptos de: Primitivas, servicios y funciones, SAP, UDP y UDS.

1.3..1. Ente: Elemento activo que ejerce Iunciones o proporciona servicios a sus niveles
adyacentes.. El ente puede ser SoIt (Ej: Compresion de datos) o Hard (Ej:
Microprocesador para armado de paquetes).

1.3.2. SAP (Service Access Point): Punto situado en la interIaz entre dos capas. En dicho
punto estaran disponibles los Servicios requeridos y las Respuestas. Me signiIica
explicitamente hacia que protocolo se dirige a traves de esa interIaz. A traves del SAP
se puede multiplexar procesos, pues es el que me indica hacia que proceso se reIiere un
determinado Header.
1.3.3. Primitivas: Los mensajes entre entes se llevan a cabo a traves de cuatro primitivas:
- Solicitud.
- Respuesta.
- ConIirmacion.
- Indicacion.
1.3.4. SDU (Service Data Unit): Datos que se mantienen inalterados entre capas pares y se van
transmitiendo en Iorma transparente a traves de la red.
1.3.5. PDU (Protocol Data Unit): UDS mas la inIormacion de control (Header) de ese nivel.
1.3.6. IDU (InterIace Data Unit): Unidad de inIormacion que se transmite a traves de cada
SAP.
1.3.7. ICI (InIormation Control InterIace): InIormacion que el ente N1 transIiere al ente N
para coordinar su Iuncionamiento y queda en ese nivel (No pasa al siguiente).
GraIicos Resumen:
UDP UDS + Header.
PDU (N+1)
PDU (N)
PDU (N-1)

En cada capa se ~Encapsula el PDU recibido de la capa superior y se agrega un Header (En la
capa 2 tambien una cola).

1.4. Funciones y/o servicios.

Sin entrar en detalles especiIicos de diIerencias entre servicios y/o Iunciones, en este punto, se
tratara de desarrollar cuales son las tareas que se pretende que realice un esquema de
comunicaciones para poder transmitir inIormacion en Iorma transparente a un usuario. Una vez
analizadas estas tareas, se dividiran en un enIoque de niveles que es el que propone OSI, entrando
en el detalle de cual de ellos desempea cada una de las Iunciones y/o servicios.

1.4.1. Segmentacin y reensamble:
Esta tarea trata de ajustar el tamao de los datos a transIerir al optimo a colocar en el canal de
comunicaciones. Este tamao dependera de varias causas:
HEADER (N1) SDU (N1)
HEADER (N) SDU (N)
HEADER (N-1) SDU (N-1)

- Determinados protocolos solo aceptan un tamao maximo o exacto de inIormacion (Ej
ATM 53 Bytes, Ethernet 1526 Bytes, etc).
- Control de errores mas eIiciente.
- Equilibrado uso del canal (Evitar monopolios).
- Empleo de buIIer mas pequeos.
- DESVENTAJAS: Mayor inIormacion de control. Genera mas interrupciones.

1.4.2. Encapsulamiento:
Se entiende por encapsulamiento al agregado de inIormacion de control a las unidades de datos
y al tratamiento de ese bloque como un todo llamado UDP (Unidad de datos del Protocolo), el
cual es entregado al nivel inIerior como una 'Caja Negra pues es totalmente transparente para
el nivel inIerior todo lo que existe alli adentro, tomandolo completo como una Unidad de datos
para ese nivel. Esta inIormacion de control que se adiciona, puede incluir alguno de los
siguientes items:
- Direccion.
- Codigos de deteccion de errores.
- InIormacion de control del protocolo.

1.4.3. Control de la conexin:
Esta tarea comprende todos los pasos necesarios para el establecimiento de la conexion, la
transIerencia de datos y el cierre de la conexion en los casos en que esta secuencia sea
necesaria.

1.4.4. Entrega ordenada:
A medida que la inIormacion va descendiendo de nivel en el modelo, como asi tambien cuando
es colocada en el canal de comunicaciones y transIerida a traves del mismo, va suIriendo
transIormaciones yo viaja por caminos diIerentes. Acorde al nivel responsable de estas
transIormaciones, existiran tareas que se encargaran por distintas tecnicas, de entregar al nivel
superior, las unidades de datos en la misma secuencia con que Iue recibido en su nivel par en
el ETD origen.

1.4.5. Control de flujo:
Esta actividad consiste en la posibilidad de regular la corriente de inIormacion a traves del
canal de comunicaciones. El control de Ilujo va desde la tecnica mas simple: Parada y
espera, Hasta la de ventana deslizante, que permite tener hasta 'n tramas en el canal
pendientes de ser entregadas o recibidas.

1.4.6. Control de errores:
El control de errores es la actividad que permite asegurar la conIiabilidad de los datos en cada
uno de los niveles pares de cada ETD. Como se tratara mas adelante, el control de errores de
un nivel, no exime de efecutar esta tarea a cualquier otro, pues cada uno abarcara

determinados tramos dentro de la red, pudiendo ocurrir que el error no se produzca en el de su
responsabilidad, ante lo cual no seria detectado, excepto que otra capa tambien lo este
haciendo. Para esta actividad se pueden emplear dos tecnicas, FEC (Forward Error Control) y
BEC (Backward Error Control).

1.4.7. Direccionamiento:
El concepto de direccionamiento es muy amplio, abarcando de alguna u otra Iorma, mas de un
nivel del modelo.
Si se hace una analogia con un envio postal, para un usuario Iinal, la unica direccion que le
interesa, es la del domicilio postal al que desea enviar su carta. Detras del mismo, existe todo
un sistema diseado y puesto en Iuncionamiento que permite que la carta que es depositada en
un Buzon, sea colocada en una determinada bolsa (y no otra) cuyo codigo de identiIicacion
solo conocen los empleados de las sucursales de correo: esta bolsa se dirigira hacia un avion,
Ierrocarril, camion etc, cuya identiIicacion de vuelo, anden, etc; solo conocera el nivel de
empleados del Ierrocarril, aeropuerto o transporte automotor, este proceso se puede desglosar
hasta el minimo detalle Iormando parte de un conjunto de direccionamiento absolutamente
desconocido para un usuario Iinal. No puede caber duda que quien diseo el sistema de
distribucion de correo, conoce este detalle, y lo Iue Iraccionando por niveles de distribucion
para justamente lograr este eIecto de transparencia.
Al reIerirse a un sistema de transIerencia de datos ahora, es diIicil luego de este ejemplo pensar
que con una sola direccion el mismo Iuncionaria. Este planteo es el necesario para detallar
todos los tipos de direccionamiento existentes, los cuales se pueden clasiIicar en cuatro
categorias:
- Direccionamiento de nivel:
Cada una de los distintos tipos de direcciones que se emplean en cada nivel, acorde al
protocolo que se esta empleando en ese nivel (Ej : X.25, Frame Relay, Ethernet, etc).
- Espacio de direcciones:
Se puede tratar como: Local ('Mi Red) o Global (Todos los ETD a los que se puede tener
acceso Iuera de la Red Local).
- IdentiIicador de conexion:
A que tipo de protocolo se esta accediendo.
- Modo de direccionamiento:
Se trata del tipo de destinatario del mensaje, este puede ser: Unicast Multicast
Broadcast.

1.4.8. Multiplexado:
El concepto de multiplexado Iisico, a traves de las distintas tecnicas (TDM, PDM, FDM, etc)
permite compartir un mismo canal Iisico por varios canales logicos. Bajo este mismo
concepto varias aplicaciones pueden estar ejecutandose durante una misma sesion (Ej: En una
conexion a Internet, se puede estar consultando una pagina Web HTTP}, enviando un correo
SMTP}, transIiriendo un archivo FTP}, etc). Estos son ejemplos donde un mismo nivel
permite operar con mas de un nivel superior, entendiendose como multiplexion logica.


1.4.9. Servicios de transmisin:
Los distintos tipos de servicios de transmision oIrecen las opciones de optimizar la relacion
costo/beneIicio en el esquema de comunicaciones, por medio de este se puede establecer las
siguientes opciones:
- Prioridades (Se basa en que ciertos mensajes necesitan ser transmitidos con menor demora
que otros, como pueden ser los de control o servicios de red).
- Grado de Servicio (Distintas opciones de calidad de Servicio QoS} ).
- Seguridad ( Permite implementar estrategias de seguridad, en cuanto a la conIiabilidad de
datos, descarte de tramas, recuperacion, Iallas, etc).

1.5.Presentacin de la familia (pila) de protocolos TCP/IP.

En 1973 , los investigadores Vinton CerI de la Universidad UCLA y Robert Kahn del MIT,
elaboran la primera especiIicacion del protocolo de comunicaciones TCP. Y es en 1983 cuando se
abandona el protocolo de comunicaciones anterior NPC y se sustituye por el actual protocolo
TCP/IP.
En 1987 la red dedicada a las news USENET , se integra en Internet . Usenet Iue creada por tres
estudiantes de Duke y Carolina del Norte en 1979 , Tom Truscott , Jim Ellis y Steve Bellovin . En
cuanto al WWW (World Wide Web) , todo empezo en 1980 en el CERN (Consejo Europeo para la
investigacion Nuclear), Suiza. El investigador Tim Berners-Lee implemento una aplicacion que
establecia enlaces entre una serie de nodos y permitia ir avanzando por ellos. Diez aos mas tarde
Iormo un equipo junto con Robert Cailliau y realizaron el primer prototipo sobre una maquina
NEXT. La conexion se realizaba haciendo TELNET a una maquina , ejecutando en esta ultima el
navegador.
En 1993 Berners-Lee crea junto a Eric Bina en el NCSA el primer navegador graIico Mosaic , y un
ao mas tarde Iunda la compaia Netscape Communications.
Esta breve introduccion historica, es la que va dando origen a los primeros protocolos de esta
Iamilia, a los cuales se van sumando muchos mas que permiten al dia de hoy implemantar todos los
servicios que oIrece esta arquitectura.

1.6.Fuentes de informacin (RFC).

Como se menciono anteriormente, la velocidad de avance de Internet, no soporta un burocratico
sistema de estandarizacion como se venia haciendo con otras Iamilias de protocolos, nace asi la idea
de las RFC (Request For Commentaries). Estas recomendaciones, no buscan estandarizar
rigurosamente esta Iamilia, sino que a medida que aparece una nueva Iuncionalidad, servicio,
implementacion, protocolo, etc. Inmediatamente se puede describir la mejor Iorma de llevarla a
cabo mediante una RFC, la cual tiene diIerentes "Estados de madurez" y rapidamente sienta un
precedente. En la actualidad superan holgadamente las tres mil.

1.7. Breve descripcin de protocolos que sustentan a TCP/IP (PPP, ISDN, ADSL, Ethernet,
X.25, Frame Relay y ATM).

Como se vera mas adelante, el protocolo IP puede ser implementado sobre una gran cantidad de
protocolos que le permitan transportar (llevar) la totalidad de la inIormacion que este encapsula,
es por esta razon que se trata aqui de dar una muy breve descripcion de los mas importantes de
ellos.


a. PPP:

El Point to Point Protocol, es la implementacion mas simple del nivel de enlace para
acceder a redes, por medio de lineas de teleIonia conmutada, estableciendo como su nombre
lo indica un enlace punto a punto con un nodo de acceso a la red, a traves de un modem y
por medio de los protocolos de la Iamilia HDLC (High Level Data Link Connection), mas
especiIicamente LAP-M (Link Access Procedure - Modem).

b. ISDN:

ISDN es una tecnologia de acceso en el rango de las telecomunicaciones y particularmente a
los servicios de circuito virtual por conmutacion de paquetes. ISDN pretende crear un
sistema completo que permita abastecer cualquier servicio actual y Iuturo al usuario
Existen dos tipos de servicios ISDN: Basico o BRI (Basic Rate InterIaz) y PRI (Primary
Rate InterIaz).
El BRI oIrece como servicio dos canales de 64 Kbps (Canal B: Bearer) y uno de 16 Kbps
(Canal D: Delta) por eso es comunmente llamado 2B D, sumando un ancho de banda
utilizable de 144 Kbps, si bien se debe tomar en cuenta que existen 48 Kbps empleados para
separacion de bandas y balanceo, que imponen un ancho de banda total de 192 Kbps siendo
estos ultimos transparentes y no utilizables para el usuario.
El cliente se encuentra representado por el CPE (Equipamiento del lado del Usuario),
accediendo a una central teleIonica llamada CO (Central OIIice), la cual es la encargada de
la conmutacion para lo cual emplea el sistema de sealizacion Nro 7 (SS 7) dentro de la red
ISDN y el sistema de sealizacion DSS1 (Digital subscriber signalling) con el usuario por
medio del canal D.
El PRI oIrece dos posibilidades, segun la norma Europea se constituye con 30 B D,
posibilitando un ancho de banda disponible de 2,048 Mbps y segun la norma de EEUU 23 B
D haciendo posible 1,544 Mbps. La union de varios PRI puede hacerse bajo el esquema
de ATM que de hecho constituye la base de B - ISDN (Broadband) o ISDN de banda ancha.
El ISDN mantiene las caracteristicas de discado, es decir, se paga por su uso y en relacion a
las lineas dedicadas suele ser mas economico hasta un maximo de 2 o 3 horas diarias de uso
(que se corresponderian a unos 100 Mb diarios).

c. XDSL:

La DSL usa modernas tecnicas de procesamiento digital para aprovechar la inIraestructura
de cobre instalada y crear lazos digitales remotos de alta velocidad en distancias de hasta
5.400 metros sin hacer conversiones de digital a analogico.
En un ediIicio grande o en un campus universitario, una DSLAM (DSL Access Multiplexer)
se conecta a los cables teleIonicos de cobre existentes que corren por las subidas del ediIicio
hasta las computadoras de los usuarios.
Las PC del usuario se conectan a un mdem DSL via conexiones Ethernet estandar y el
DSLAM, usado en lugar de conmutadores teleIonicos de voz, transmite por sistema
multiplex el traIico de datos desde las lineas DSL a una interIaz ATM.
Esta transmision de datos punto a punto en Iorma digital a elevada anchura de banda -hasta
7 Mbps o 8 Mbps- le da a la DSL una signiIicativa ventaja sobre los sistemas ISDN y los
modem de 56 Kbps. La transmision analogica usa solo una pequea porcin de la
capacidad del alambre de cobre de transmitir inIormacion y por esta razon la velocidad
maxima es de 56 Kbps. Aunque el ISDN es un buen sistema para transmision a 64 Kbps -
2,048 Mbps- su tecnologia no puede manejar las demandas de aplicaciones que requieren
gran ancho de banda.

DSL crea conexiones mas rapidas que ambos con grandes canales de datos y mayores
anchos de banda. Estos grandes anchos de banda le permiten a la DSL manejar las
demandas de aplicaciones que consumen mucho ancho de banda: videoconIerencias en
tiempo real, telemedicina y educacion a distancia, por ejemplo.
Ademas del mayor ancho de banda, la DSL es en muchos aspectos una tecnologia ms
barata que la ISDN.

Variantes de DSL

Las diIerentes implementaciones de DSL sirven como canales de alta velocidad para
conexiones remotas, pero tienen diIerentes velocidades y caracteristicas de operacion.

- ADSL (Asymmetric Digital Subscriber Line): siendo esta variante es la mas Ilexible,
dado que proporciona numerosas velocidades ascendentes y descendentes,
probablemente la ADSL llegara a ser la variante mas popular en las pequeas
empresas y los usuarios en el hogar.
Velocidad maxima ascendente: 2 Mbit/segundo.
Velocidad maxima descendente: 64 Mbit/segundo.
Distancia maxima: 5.400 m.

- HDSL (High bit-rate DSL): Esta es la mas vieja de las variantes de las tecnologias
DSL. Se usa para transmision digital de banda ancha dentro de instalaciones de
empresas y compaias teleIonicas que requieren dos cables entrelazados y que usan
lineas T1.
Velocidad ascendente maxima: velocidad de T1.
Velocidad descendente maxima: velocidad de T1.

- (ISDL) ISDN DSL: Esta variante esta mas proxima a las velocidades de transIerencia
de datos de ISDN y puede ser activada en cualquier linea ISDN.
Velocidad maxima ascendente: 128 kbits/s.
Velocidad maxima descendente: 128 kbits/s.

- RADSL (Rate-Adaptive DSL): Esta variante soporta soItware que automatica y
dinamicamente ajusta la velocidad a la cual pueden transmitirse las seales en la linea
teleIonica de determinado cliente.
Velocidad maxima ascendente: 1 Mbit/s.
Velocidad maxima descendente: 12 Mbit/s.

- SDSL (Single-Line DSL): Esta variante es una modiIicacion de HDSL.
Velocidad maxima ascendente: 768 kbit/s
Velocidad maxima descendente: 768 kbit/s.

- VDSL : Es lo ultimo en DSL y es una tecnologia todavia en desarrollo.
Velocidad maxima ascendente: 2,3 Mbit/s.
Velocidad maxima descendente: 52 Mbit/s.


d. Ethernet: Se tratara en detalle mas adelante.

e. X.25:

En 1974, el CCITT emitio el primer borrador de X.25. Este original seria actualizado cada
cuatro aos para dar lugar en 1985 al 'Libro Rojo ampliando e incorporando nuevas
opciones y servicios, que posteriormente siguieron siendo ajustadas.
El concepto Iundamental de X.25 es el de Red de Conmutacin de paquetes, siendo la
precursora de este tipo de tecnologias. Por nacer muy temprano, su desarrollo Iue pensado
sobre redes de telecomunicaciones de la decada del 70, teniendo en cuenta nodos de
conmutacion electromecanicos o hibridos, lineas exclusivamente de cobre, equipos
terminales de datos de muy poca 'Inteligencia y baja velocidad de procesamiento. Basado
en estos parametros es que hace especial hincapie en la deteccion y control de errores, que
como se puede esperar, se logra mediante una enorme redundancia en la transmision. Para
lograr este objetivo es que implementa un esquema de tres niveles asociados directamente a
los equivalentes del modelo OSI.
En X.25 se deIinen los procedimientos que realizan el intercambio de datos entre los
dispositivos de usuario y el nodo de ingreso a la red X.25 (no deIine lo que sucede dentro de
la misma).

f. Frame Relay:

Es una de las tecnicas de Iast packet switching, llamada habitualmente conmutacion de
tramas. Es empleado Iundamentalmente para el reemplazo de lineas punto a punto. Esta
tecnica opera sobre lineas de alta calidad, pues reduce sensiblemente la importancia que
X.25 le da a la deteccion de errores, dejando esta tarea unicamente a los extremos. Por lo
tanto, si las lineas son de baja calidad se debera transmitir las tramas de extremo a extremo,
bajando el rendimiento, incluso hasta ser peores que X.25 si el canal es muy malo.
Las estaciones terminales son responsables de:
Cobertura de errores.
Control de secuencia.
Control de Ilujo.
Sus saracteristicas son:
- Alta velocidad y baja latencia.
- Basado en circuitos virtuales de nivel 2.
- Se reemplaza el termino canal logico por DLCI (Data Link Connection IdentiIier).
- Este DLCI identiIica al circuito virtual en cualquier punto de la red (Igual que el canal
logico en X.25).
- Cada DLCI tiene signiIicado local.
- La conmutacion se produce a nivel trama.
- Orientado al traIico por raIagas.
- Comparte puertos.
- Permite el uso dinamico de ancho de banda.


g. ATM:

Primera solucion capaz de eliminar la barrera entre LAN y WAN. Aplica el concepto de
conmutacion rapida de paquetes (llamados celdas).
Es un concepto, no un servicio que emplea nuevas tecnicas de conmutacion con muy bajo
retardo. Se emplea un minimo de retardo en cada nodo, dejando el control de errores y de
Ilujo en los extremos. Asume que los enlaces son digitales, por lo tanto posee un muy bajo
indice de errores. Integra voz, datos y en algunos casos video.
Emplea la transmision en banda ancha (Broadband).
Por que B ISDN?
La conmutacion de circuitos se adapta perIectamente a los servicios Isocronicos (Sincronico
pero continuo en su retardo, Ej: Voz).
La conmutacion de paquetes se adapta perIectamente a la transIerencia de datos.
ATM es una solucion de compromiso: Una conmutacion de paquetes que puede asegurar
una entrega rapida y continua de voz e imagenes.
El ATM Forum se crea porque las normas ITU salen con demoras de cantidad de aos, y la
dinamica de los avances tecnologicos no puede soportar tanto tiempo. El ATM Forum Iue
Iundado en octubre de 1991, es un consorcio internacional Iormado para acelerar el uso de
los productos y servicios ATM a traves de una rapida convergencia y demostracion de las
especiIicaciones. No es un instituto de estandarizacion sino que trabaja en colaboracion con
instituciones como ITU y ANSI.
- Nace en los laboratorios Bell a Iines de los 80`.
- Las Unidad de transIerencia de inIormacion es llamada celda la cual es de tamao Iijo
(53 Byte) y son 'relevadas (Relay) entre cada nodo ATM por eso su concepto de Cell
Relay.
EEUU propone 64 Byte 5 Byte (Necesita cancelar eco en TE).
Europa propone 32 Byte 4 Byte (Era baja la eIiciencia de datos por celda).
Se adopta : 64 32 96; 96 / 2 48 + 5 ( Max valor sin cancelar eco).
- Premisas de ATM: Red altamente conIiable y de alta velocidad, nodos inteligentes para
tratar errores.
- Reune conceptos de conmutacion de paquetes y de circuitos.
- Se lo denomina asincrono por la discontinuidad entre celdas a nivel de usuario, pero a
nivel Iisico es estrictamente sincronico pues lo soporta SDH (Jerarquia Digital
Sincronica).
- Es Orientado a la Conexion, tecnica que logra mediante el empleo de circuitos virtuales
(VPI y VCI).
- Tecnologia capaz de conmutar millones de unidades por segundo a traves de los nodos
introduciendo retardos muy bajos, para lograrlo:
Reduce las Iunciones en los nodos: Se le quita a estos toda la carga de
procesamiento que no sea estrictamente imprescindible para el encaminamiento
exitoso de la llamada.

Delega Iunciones en los extremos: ConIiando en la inteligencia que se posee hoy
en los equipos terminales de datos, conIia en estos muchas de las tareas.

1.8. Presentacin de protocolos TCP, UDP e IP.

Dentro de esta pila de protocolos, como el modelo de reIerencia lo trata de mostrar, existen dos
niveles bien marcados. Hasta el nivel cuatro (transporte) inclusive. "miran" hacia la red, por lo
tanto todas las actividades que aqui se desarrollan tienen relacion con el canal de
comunicaciones y los nodos por los que pasa la inIormacion. Dentro de esta division, se
encuentra el corazon de esta Iamilia, se trata del protocolo IP de nivel 3 (red) y de los dos
protocolos de nivel 4 (transporte) UDP y TCP. Sobre estos tres cae toda la responsabilidad de
hacer llegar la inIormacion a traves de la red, es por esta razon que se los trata de remarcar con
esta presentacion, y sub-clasiIicarlos de alguna Iorma respecto al resto.

1.9. Presentacin de protocolos: FTP, Telnet, ARP y R_ARP, SMTP, POP3, IMAP, MIME,
SNMP, HTTP, ICMP, IGMP, DNS, NetBIOS, SSL y TLS.

El resto de esta Iamilia "miran" hacia el usuario. Se debe contemplar aqui las dos excepciones
que son "ARP, RARP e ICMP-IGMP", que en realidad participan tambien en las tareas de red,
pero como un complemento de la misma. Con estas excepciones salvadas, todo lo demas que
se vera tiene como Iuncion principal cierta interaccion con el usuario Iinal para oIrecer servicios
y/o Iunciones.

1.9. Protocolo Ipv6.

Ante varios problemas que Iueron apareciendo durante la larga vida del protocolo IP version 4,
desde hace varios aos se esta estudiando, y en la actualidad ya implementando en laboratorio y
troncales de Internet, una nueva version del mismo llamada IP version 6 (Ipv6) o IP Next
Generation (IPNG), el cual ya ha llegado a un importante nivel de madurez, pero aun no se ha
lanzado al mercado.
En virtud de la importancia que este revista, se tratara con mas detalle en el punto 3.

2. PRINCIPIOS DE ANALISIS:

2.5.Trafico: Broadcast, multicast y dirigido:

El traIico que se produce en una red se puede clasiIicar desde dos puntos de vista: Por su sentido y
Por su Iorma de direccionamiento.

2.1.1. Por su sentido:
La direccion en que las seales Iluyen en la linea de transmision es un Iactor clave que aIecta a
todos los sistemas de comunicaciones de datos. Existen tres tipos de Ilujo de la inIormacion:

- Simplex:
La transmision entre dos equipos se realiza en un unico sentido (por ejemplo la TV).
- HalI-Duplex:

La transmision se realiza en los dos sentidos, aunque no simultaneamente (por ejemplo los
walkie talkies).
- Duplex:
Transmision simultanea e independiente en ambos sentidos (por ejemplo el teleIono).

2.1.2. Por forma de direccionamiento:
- Unicast:
Se trata de una transmision de un ETD a solo un ETD.
- Multicast:
Se trata de una transmision de un ETD hacia un determinado grupo.
- Broadcast:
Es el tipo de transmision de un ETD hacia absolutamente todos los ETD que
escuchen la misma.

2.6.Sniffers y analizadores de protocolos:

Qu es un analizador de protocolos?
Un analizador de protocolos, captura conversaciones entre dos o mas sistemas o dispositivos.
No solamente captura el traIico, sino que tambien lo analiza, decodiIica e interpreta, brindando
una representacion de su escucha en lenguaje entendible; por medio de la cual se obtiene la
inIormacion necesaria para el analisis de una red y las estadisticas que el analizador nos
proporciona.
Esencialmente, un analizador de protocolos es una herramienta que provee inIormacion acerca
del Ilujo de datos sobre una LAN, mostrando exactamente que es lo que esta sucediendo en ella,
detectando anomalias, problemas o simplemente traIico innecesario. Una vez que un problema
es aislado, se pueden analizar las causas que lo producen y tomar las medidas para evitarlo.
Un analizador de protocolos deberia proporcionar tres tipos de inIormacion sobre una LAN:
a. Estadsticas sobre traIico de datos, estado de los dispositivos y lineas de errores en la LAN.
Esta inIormacion ayuda a identiIicar tramas y condiciones generales que pueden sealar un
problema inesperado o causar un bajo rendimiento en la red. Permite tambien determinar
nuevas necesidades de Hardware para segmentar o crear subredes dentro de la LAN como
podria ser el empleo de Switch o router y la ubicacion y conIiguracion correcta de los
mismos.
b. Captura de paquetes y decodificacin de los mismos en los distintos protocolos de cada
nivel. Deberia permitir tambien el Iiltrado correspondiente, que posibilite especiIicar en el
mayor grado de detalle lo que se desea estudiar, dejando de lado la inIormacion innecesaria.
Se suele Iiltrar por Direccion MAC, IP, Nombre NetBIOS, puertos, tipo de protocolo,
secuencias de bit, etc.

c. Representacin de informacin histrica en lapsos diarios, semanales, mensuales o en
periodos establecidos por el usuario. Esta inIormacion provee una perspectiva historica para
cualquier nuevo problema o indica un problema potencial antes que este suceda.
Las estadisticas de estaciones de trabajo o servidores permiten identiIicar el traIico generado por
cada uno de ellos y el porcentaje de ancho de banda que consumen. Con esta inIormacion se
puede determinar cual es la que hace mayor uso del canal Iisico y cuales son los recursos mas
usados. Por ejemplo si una estacion genera un alto porcentaje de traIico, esto puede estar
indicando una Ialla en su tarjeta de red, permitiendo tomar las medidas correspondientes, basadas
en observaciones reales de la red, y no por prueba y error.
Un concepto importante es que un analizador de protocolos no emplea SNMP; esta herramienta
cuenta con la inIormacion especiIica que le permite identiIicar las diIerentes secuencias de bit, y
por medio de los Header establecidos para cada protocolo, los que responden a estos patrones los
asocia a uno de ellos, 'desarmando las cadenas binarias en la inIormacion contenida en ellas.
Por ejemplo SNMP no podria brindar inIormacion, sobre sesiones Telnet, TCP/IP, uso de ancho
de banda, que tipos de paquetes se emplean, etc. Un SNMP se debe considerar como un muy
buen COMPLEMENTO de un analizador de protocolos.
Por ultimo, en sus inicios, existia una notable diIerencia entre los sniffers y estos dispositivos,
pues los primeros, solo se dedicaban a capturar el traIico de la red y representarlo en su Iorma
hexadecimal, sin desempear ninguna de las tareas recientemente descriptas que realiza un
analizador de protocolos, un ejemplo aun vigente podria ser el 'comando nmap de Linux. En
la actualidad, muchos de estos sniIIers Iueron incorporando mas y mas Iuncionalidades, pues una
vez que esta capturada la inIormacion, es muy simple realizar estadisticas, comparaciones,
presentaciones graIicas de la misma, etc. Por lo tanto hoy, es muy conIusa la denominacion que
se emplea para estos productos, pero siendo estrictos conceptualmente, un sniffer solo captura
traIico y lo presenta de manera mas o menos amigable (y nada mas). Un analizador de
protocolos, realiza esta tarea y a su vez procesa esta inIormacion para obtener todas las posibles
necesidades de usuario con la misma.

2.7.Deteccin de sniffers.

Las tecnicas de deteccion de sniIIers que se emplean son varias y todas se basan en poder
determinar si la interIaz de red se encuentra en modo promiscuo, lo cual es un claro sintoma que
desea recibir todo el traIico que pasa por ella, actividad no necesaria para ningun host que preste
servicios en una red:
a. La mas simple de estas es enviar un mensaje ARP a una direccion MAC Ialsa, si responde, es
que se encuentra en modo promiscuo. La masa de los sniIIers o analizadores de protocolos ya
preveen esta tecnica y simplemente anulan todo tipo de respuesta a nivel MAC.
b. Test especiIico del Sistema Operativo: Es muy similar al anterior, pero se envian mensajes
ICMP de eco (Tipo 8), con la direccion MAC no existente en la red, se emplean tambien con
mensajes que pueden ser Unicast, Multicast o Broadcast, y basado en el tipo de respuesta se
determinara tambien que sistema operativo posee el host (Linux: responde ante unicast |este es
un bugs que la mayoria de los sistemas linux hoy tienen resuelto, pero existe un error en la pila
TCP/IP de este S.O. con el cual responderan siempre a una direccion IP real, aunque la MAC
sea Ialsa|, BSD: responde ante multicast, NT: Lo hace analizando solo el primer octeto MAC

contra la direccion IP cuyo primer octeto sea Broadcast, independientemente del resto de la
direccion MAC.
c. Test DNS: Esta tecnica envia inIormacion acerca de un direccion IP y escucha por cualquier
solicitud de resolucion DNS desde un host hacia el servidor correspondiente.
d. Test de latencia del sistema: Este es el mas complejo pero tambien el mas eIiciente. Se trata de
enviar paquetes ICMP y medir los tiempos de respuesta. Si se incrementa el traIico en la red,
una interIaz en modo promiscuo ira tardando cada vez mas tiempo en responder que el resto de
las interIaces, pues esta debera procesar la totalidad de las tramas, mientras que el resto solo lo
hara con las tramas dirigidas a estas.

2.8. Introduccin al Microsoft Network Monitor (Como herramienta de anlisis y captura).
Como ya se menciono con anterioridad, un analizador de protocolos es una herramienta que permite
capturar, Iiltrar y analizar el traIico de una red. Los datos capturados pueden ser guardados para un
analisis posterior o analizados inmediatamente despues de la captura. Esta herramienta puede ser
una combinacion de Hardware y SoItware, o simplemente SoItware como es el caso de Network
Monitor de MicrosoIt. Este SoItware permite lo siguiente:
- Capturar tramas directamente desde la red.
- Mostrar y Iiltrar las tramas capturadas.
- Editar las tramas y transmitirlas por la red.
- Capturar tramas desde una computadora remota.
- Generar traIico.
La version simple del Network Monitor 1.2. esta incluido con el Windows NT 4.0 y la version
completa con el MicrosoIt System Managment Server. Esta ultima puede ser instalada sobre
Windows 3.1, Windows 95 y Windows NT Server y Workstation. En la actualidad ya existe la
version 2.0 que se emplea con la plataIorma Windows 2000, y tambien viene la version estandar
con Windows 2000 y la Enterprise con el SMS 2.0.
Network Monitor consiste en dos componentes, Network Monitor application y Network Monitor
Agent.
Network Monitor Application muestra estadisticas y datos de las capturas, permitiendo
guardarlos.
Network Monitor Agent permite la captura de traIico local o remoto. El cliente corriendo
Network Monitor Agent captura y almacena en buIIer el traIico localmente; cuando el
Network Monitor Application intenta mostrar el traIico, el Agent se lo envia a traves de la
red para su estudio.
Es muy importante el concepto de MODO PROMISCUO, cuyo signiIicado es que el adaptador de
red permite el ingreso ('escucha) absolutamente todas las tramas que pasan por el cable. En el
manual de compatibilidades de Windows NT existe una lista de los adaptadores de red que operan
de esta Iorma. Se debe tener en cuenta que un adaptador que trabaja en modo promiscuo signiIica
que delega todo el trabajo en la CPU por lo tanto representa una sobrecarga de tareas al ETD que se

le instala, no siendo asi en el que opera NO en modo promiscuo, que posee mecanismos de Iiltrado
que liberan de las actividades de nivel 2 al ETD.
La pantalla del Network Monitor esta dividida en cuatro partes:
a. GraIica: Muestra la actividad que se produce en la red por medio de barras en
porcentajes de tramas y byte por segundo, como asi tambien Broadcast y
Multicast por segundo.
b. Estadisticas de sesion: Muestra el resumen de traIico entre dos host, y cual de
ellos inicia broadcast y multicast.
c. Estadisticas totales: Resumen de la totalidad de la actividad en la red.
d. Estadisticas de estaciones: Muestra el resumen de la totalidad de tramas
enviadas y recibidas por cada host.
2.4.1. Captura, filtrado y anlisis de tramas.
El analisis de datos comienza con la vista de los datos capturados, esta pantalla muestra la
totalidad de las tramas capturadas, las cuales pueden ser Iiltradas con anterioridad a la captura
o luego de ella, para seleccionar las que se desee analizar.
La presentacion de esta pantalla se divide en tres partes:
a. Panel resumen: Muestra la totalidad de las tramas presentando en columnas la siguiente
inIormacion:
1) Trama: Numero de trama capturada, en el orden que Iue capturada.
2) Tiempo: Permite identiIicar el tiempo en el que inicio la captura de esta trama o puede
ser conIigurado para identiIicar la hora del dia en que Iue capturada.
3) Direccion MAC origen: Muestra la direccion de hardware del ETD que emitio la trama.
4) Direccion MAC destino: Muestra la direccion de hardware del ETD que recibio la trama.
5) Protocolo: El protocolo usado para transmitir la trama.
6) Descripcion: Resumen del contenido de la trama.
7) Otra direccion origen: IdentiIicador adicional de ETD que origina la trama (Por Ej: IP o
IPX).
8) Otra direccion destino: IdentiIicador adicional de ETD que recibe la trama (Por Ej: IP o
IPX).
9) Tipo de direccion adicional: EspeciIica que tipo de direccion adicional se empleo.
b. Panel de detalle: Muestra todo el grado de detalle de la trama seleccionada en el panel
anterior, desplegando la totalidad de los protocolos incluidos en esa trama.

c. Panel hexadecimal: Muestra en Iormato hexadecimal la totalidad de los Byte que Iueron
capturados en la trama seleccionada en el panel resumen.

2.9.Presentacin de otras herramientas (Ethereal, Iris):

Estas dos herramientas se veran brevemente en Iorma practica durante el curso, para contar con
un espectro mayor de analizadores de protocolos y veriIicar que el empleo de los mismos es
siempre el mismo, variando solamente el aspecto de su presenatcion.

2.10. Captura, filtrado y anlisis de tramas.

Como ya se menciono, la gran diIerencia entre un sniIIer y un analizador de protocolos, pasa
por los servicios que este ultimo oIrece, los cuales en general van orientados hacia una mejor
interpretacion de la inIormacion capturada.
Para poder mejorar la visualizacion de la inIormacion , es muy importante "Pulir el bosque", es
decir, poder filtrar lo que no se desea para clariIicar la inIormacion que se esta buscando.
Todos los analizadores de protocolos poseen dos Iiltros:
- Filtro de captura: Permite seleccionar que es lo que se desea ingresar a la memoria de la
herramienta y que no. Esta Iuncionalidad es de suma importancia, pues en redes de alto
traIico, es muy Iacil que se desborde la memoria del PC donde se ejecuta el analizador de
protocolos, y en el caso de desear capturar unicamente una determinada direccion,
protocolo, puerto, etc. De que sirve almacenar el resto del traIico?. Este Iiltro, permite
registrar (Capturar) solo lo que se desea, descartando el resto de la inIormacion que viaja
por el cable.
- Filtro de visualizacin: En este caso, se trata de presentar una "mejor vista" de lo que ya
ha sido capturado. Este Iiltro se emplea, una vez que se detuvo la captura, para poder elegir
que se desea visualizar dentro de toda la inIormacion que ya se encuentra en memoria.

2.11. Presentacin hexadecimal, binaria y decimal.

2.7.1. BIT: estado logico equivalente a 1 o 0.

2.7.2. Byte u Octeto: Agrupacion de 8 bit.

Esta deIinicion es la que realmente se universalizo para el tratamiento de la inIormacion y
la palabra octeto es hoy una de las bases de la transmision de inIormacion, la razon de ser
de esta convencion radica en:

- La capacidad suIiciente de codiIicacion que posee un octeto, es decir 256
posibilidades diIerentes.

Si se plantea el conjunto de posibilidades este ira desde: 0000 0000, 0000 0001 ,
0000 0010 , 0000 0011 , 0000 01000.............1111 1111.
Ante lo cual permite hasta 256 codigos diIerentes.

- El Iacil pasaje entre el sistema decimal, hexadecimal y binario.


Suma
Decimal 128 64 32 16 8 4 2 1 256
Peso
Decimal 128 64 32 16 8 4 2 1

Binario b b B b b b b b
Peso
hexadecimal
8 4 2 1 8 4 2 1
Suma
hexadecimal
8 4 2 1 F 8 4 2 1 F FF
E1EMPLO
Suma
Decimal 128 32 2 1 163

Peso
Decimal 128 0 32 0 0 0 2 1

Binario 1 0 1 0 0 0 1 1
Peso
hexadecimal
8 0 2 0 0 0 2 1
Suma
hexadecimal
8 2 A 2 1 3 A3
Hexadecimal: Conjunto de16 simbolos (0, 1, 2, 3, 4 , 5 , 6, 7, 8, 9, A, B, C, D, E ,F).

2.7.3. CARACTER: Es la unidad de inIormacion a nivel alIabeto humano, representa
cualquier simbolo del alIabeto usado como alIabeto normal. Se los clasiIicara en:

a. Alfabticos: Letras en mayusculas y minusculas.
b. Numricos: digitos de 0 a 9.
c. Especiales: Puntuacion, Parentesis, operaciones aritmeticas y logicas, comerciales,
etc.
d. De operacin y control: Destinados al control de la transmision de InIormacion
(Retorno de carro, nulo, SYN, ACK, DLE, EOT, SOH, etc)

2.7.4. Bloque, Mensaje, Paquete, Trama: Son distintas Iormas de agrupamiento de Byte, y se
deIinen acorde a las distintas tecnicas de transmision de inIormacion o Protocolos de
Comunicaciones.

3. ANALISIS DE TRAFICO POR PROTOCOLOS.

3.2. Anlisis de tramas Ethernet (IEEE 802.3):

El Iuncionamiento de una red LAN a nivel dos (enlace) que opere por medio de CSMA/CD
(Carrier sence multiple access/colition detect) se implementa por medio del protocolo Ethernet u
802.3 (la minima diIerencia entre ellas se vera en breve). Su Iuncionamiento es basicamente
simple, si el canal esta libre entonces se puede transmitir, caso contrario no. Como existe la
posibilidad que un ETD escuche el canal, al estar este libre comience la transmision, y antes de

llegar esta seal a cualquiera de los otros ETD de la LAN alguno de estos haga lo mismo, es que
se analizan las colisiones. Una colision se produce cuando dos ETD por tener el canal libre
inician su transmision, la cual no es otra cosa que un estado de tension que oscila entre
0,85Volt y - 0,85 Volt (o ausencia de ella) que se propaga por canal Iisico, al encontrarse dos
seales dentro del mismo medio Iisico se produce una alteracion en los niveles de tension, la cual
al llegar a cualquier ETD de la red se determina como una colision. Los ETD que transmitieron
pasan a un algoritmo de espera aleatorio (Llamado disminucion exponencial binaria) e intentan
transmitir nuevamente al cumplirse el plazo determinado por el algoritmo (son multiplos de un
valor muy especial que se llama tiempo de ranura), si durante 51,2 microsegundos (Tiempo de
ranura) no se detecta ninguna colision, este se ha APROPIADO del canal y se asegura que
ningun otro ETD pueda transmitir, por lo cual continuara con el resto de su trama (tamao
maximo 1518 Byte) y luego entrara nuevamente en compulsa por el medio Iisico.

a. Formato de las direcciones MAC.
Las Direcciones MAC son reguladas por IEEE y estan Iormadas por 6 octetos,
representados como pares de numeros hexadecimales (hh-hh-hh-hh-hh-hh).
Los primeros tres octetos identiIican al Iabricante de la tarjeta. Estos tres octetos son
asignados por un grupo de IEEE llamado RAC (Registration Authority Commitee) y
pueden ser consultados en www.standars.iee.org, existe una metodologia para solicitarlos y
por ser 24 bit, se pueden asignar en el orden de 16.000.000 de valores. Estos tres
primeros octetos se los denomina "OUI (Organizationally Unique IdentiIier) o
"company_id", de estos 3 Byte, los dos primeros bit tienen un signiIicado especial:
- bit 0: Individual (valor 0), establece que este valor pertenece a una sola
direccion MAC. Grupal (Valor 1), Iorma parte de un conjunto de direcciones
MAC.
- Bit 1: Universal (valor 0), deIine que esta direccion es unica en el mundo.
Local (val or 1) tiene signiIicado solamente en el ambito local.
Estos primeros 3 octetos, una vez asignados a una determinada empresa, se deja a
criterio de la misma como asignara los valores de los 3 octetos siguientes denominados
"Extension identifier", para que no puedan repetirse, pero IEEE-RAC no se
responsabiliza ni establece ninguna pauta sobre los mismos. Es logico pensar que un
gran Iabricante de tarjetas, complete la totalidad de los posibles numeros a emitir, IEEE-
RAC establece que recien al haber completado el 90 de las asignaciones podra
solicitar otro OUI para continuar Iabricando (en la actualidad ya existen varias empresas
en esta situacion).
La concatenacion de "OUI + Extension identifier EUI (Extended Unique
Identifier", conocido como "EUI-48", que es la verdadera denominacion teorica de una
direccion MAC.
Ejemplo de Representacin grfica de una EUI-48
OUI (company_id) Extension Identifier
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5
AC DE 48 23 45 67
10101100 11011110 01001000 00100011 01000101 01100111

bit mas
signiIicativo

bit menos
signiIicativo



b. Ethernet y 802.3:

El Iuncionamiento de este protocolo tiene sus origenes en otro conocido como ALOHA
(saludo de los Hawaianos, que es donde nacio), al principio se creyo muy poco probable
que esta logica de compulsa por un medio de comunicaciones Iuera eIiciente, pero en el
muy corto plazo se descubrio que si lo era. Digital, Intel y Xerox, se unen para ponerlo
en Iuncionamiento sobre cable coaxil a 10 Mbps, y como inicialmente se lo empleo en
enlaces satelitales que transmitian al "Ether", se lo llamo Ethernet (y se lo conocia como
Ethernet DIX). En el ao 1980 (80) y en el mes de Iebrero (2), IEEE toma cartas en el
tema y crea el subcomite que estudiaria el tema de LAN y MAN y por la Iecha en que
entra en Iuncionamiento se lo llamo 802.x (xdistintas areas), y sera el responsable hasta
la actualidad de regular el Iuncionamiento de estas redes.
Este grupo deIine todos los aspectos hoy conocidos como Iamilia 802.x, de los cuales
solamente en este texto se desea dejar claro algun aspecto de 802.3.
Lo mas relevante aqui es que, si se recuerda el aspecto mas importante del nivel de
enlace (nivel 2) del modelo OSI, este "establece la comunicacion con el nodo
inmediatamente adyacente". En una topologia LAN Cual es el nodo inmediatamente
adyacente?. Ante esta cuestion IEEE, propone subdividir el nivel de enlace del modelo
OSI en dos subniveles:
- MAC (Medium Acces Control): Responsable de todo lo reIerente al
Hardware de red.
- LLC (Logical Link Control), 802.2 : Responsable de la comunicacion con
los protocolos superiores.

Modelo OSI (Ethernet) IEE (802.x)
LLC
Enlace (nivel 2)
MAC

La propuesta es muy coherente, pues Iacilita esta compleja actividad caracteristica de las
LAN. Pero desde ya, que esta propuesta no es reconocida por OSI, marcando una
diIerencia entre estos dos protocolos. Aparecen aqui estos dos estandares de mercado,
que se recalca "NO SON IGUALES", si bien son muy parecidos. En el caso de
CSMA/CD, que es el que interesa en este texto, todo hardware y software de red
soporta ambos protocolos y acorde a la trama que se trate aplica uno u otro.
La diIerencia mas importante se encuentra en dos octetos del encabezado (que se trataran
a continuacion). Cuando se trata de tramas IEEE 802.3, el encabezado MAC tendra
siempre encima de el el subnivel LLC, por esta razon no necesita deIinir a quien le debe
entregar los datos, pues solo existe una opcion (LLC); en esta situacion los dos octetos
reIeridos establecen la longitud del campo de datos y se llaman "Length". Cuando la
trama es Ethernet (el nivel de enlace de OSI, no se encuentra subdividido) se debe
aclarar a que protocolo entregara los datos en el nivel 3 (Red), por ejemplo IPX, IP, etc.
en este caso estos dos octetos se denominan "Ethertype", y se emplean justamente para
deIinir que tipo de protocolo se encuentra arriba de Ethernet.
La Iorma de distinguir de que trama se trata es mediante el valor en hexadecimal de estos
dos octetos: todo valor inIerior a 0550h se corresponde a una trama IEEE-802.3; por
encima de este se trata de una trama Ethernet.


c. Algoritmo de disminucin exponencial binaria:
Como se menciono en la introduccion, al producirse una colision, los ETD responsables
de la misma dejan de transmitir (en realidad se envia una seal de atasco para avisar a
todos los ETD de la red de este hecho). Automaticamente estos equipos generan un
numero aleatorio entre 0 y 1. Este numero es motivado por el algoritmo de disminucion
exponencial binaria que propone generar un numero aleatorio acorde a la siguiente
Iormula:
n cantidad de colisiones detectadas en esta compulsa.

Al tratarse de la primera colision: Nro Rand 2
1
-1 1 ~ (Nro Random entre 0 y 1).
Este valor (0 o 1) establece la cantidad de tiempos de ranura que esperara el ETD para
volver a transmitir la trama que ocasiono la colision, siendo el tiempo de ranura 51,2 s.
Si los dos ETD generan el mismo valor, colisionaran nuevamente, pero si obtienen
valores diIerentes, uno de los dos emitira primero, y cuando pasen los 51,2 s del
segundo ETD y este desee transmitir, encontrara el canal ocupado y no podra hacerlo (es
decir que el primero gano la compulsa).
Si hubiesen generado el mismo valor, es decir: los 2 ETD 1 o los 2 ETD 0, se
producira la segunda colision, por lo tanto:
Nro Rand 2
2
-1 3 ~ (Nro Random entre 0, 1, 2 o 3)
Si ambos equipos obtuvieran el mismo valor, colisionarian nuevamente y entonces seria:
Nro Rand 2
3
-1 8 ~ (Nro Random entre 0, 1, 2, 3 ,4, 5, 6, 7 u 8).
Si siguieran generando iguales numeros, esta situacion se mantendria hasta:
Nro Rand 2
10
-1 1023 ~ (Nro Random entre 0 y 1023).
Si aun asi esto continuara, se ejecutaria el mismo algoritmo con exponente 10, durante
seis veces mas, y luego se comienza nuevamente.
Esto que parece muy poco probable, si bien es poco Irecuente, no es tan asi, pues se debe
tener en cuenta que en una red donde existen varios ETD conectados a un mismo
dominio de colisin, en cualquier momento de esta secuencia, puede entrar en juego
otro ETD, caso en el cual, este ultimo comenzaria a tratar el algoritmo como su primera
colision, y los anteriores seguirian con su rutina de disminucion de probabilidades, y asi
tambien puede ingresar un cuarto, quinto, etc.
El ultimo concepto que aun queda por tratar es el de tiempo de ranura (51,2 s). Este
valor nace de la deIinicion misma de Ethernet, y aparece en los inicios de este protocolo,
cuando estas redes se implementaban con topologia Bus sobre cable coaxil grueso, con
el cual se podian unir hasta cinco segmentos de 500m a traves de cuatro repetidores
regenerativos (y solo 3 de ellos cargados; se la conocia como norma 5-4-3). La
distancia maxima que alcanzaba esta red era de 2.500m. Teniendo en cuenta el tiempo
de latencia de los repetidores, una seal electrica tardaba en recorrer esta distancia ida y
vuelta, aproximadamente este tiempo: 51,2 s. El tema de Iondo aqui radica en que si se
tiene en cuenta dos ETD separados a esta distancia (el peor de los casos), suponiendo
que uno de ellos comienza la transmision, y un instante antes de llegar al segundo, este
escucha el canal y por estar desocupado, comienza a transmitir; entonces se producira
Nro Rand 2
n
-1

una colision muy proxima al segundo ETD. El que inicio la transmision tomara
consciencia de la colision, cuando este estado anormal de tension regrese a el, es decir,
cuando haya recorrido los 2500m de ida y los 2500m de vuelta , que coincide con estos
51,2 s. Si se supone que el segundo ETD no inicio ninguna transmision, al cabo de
estos 51,2 s ningun ETD de esta red podria transmitir, pues al escuchar el medio, lo
encontraria ocupado. Esto se llama Apropiarse del canal.
Basado en estos conceptos es que se deIine que el tamao minimo de una trama Ethernet
no puede ser menor de 64 Byte, pues 64 Byte 512 bit y 512 bit transmitidos a
10.000.000 de bit por segundo (10 Mbps) 51,2 s. Tambien se deIine que no podra
tener mas de 1518 Byte, para evitar que el apropiado del canal sea eterno, evitando asi
monopolios del medio.

d. Armado de tramas:
Las tramas Ethernet son armadas en el subnivel MAC y responden a 14 octetos de
encabezado y a 4 octetos de cola que es donde se realiza el CRC y entre estos campos
van los datos.
Se debe tener en cuenta que para que todos los ETD de la red se sincronicen y sepan que
se esta por recibir una trama, antes de la misma se envian 7 octetos de preambulo
(10101010) y luego un octeto de inicio (10101011). Algunos autores lo consideran
parte del encabezado Ethernet y otros no, en este texto no se consideraran parte del
mismo.
El Iormato de una trama Ethernet es el que se detalla a continuacion:
8 7 6 5 4 3 2 1
Direccion destino (6 Byte)
Direccion Origen (6Byte)
Tipo o longitud (2 Byte)
Datos (Variable entre 46 y 1500 Byte)
.............
CRC (4 Byte)
- Direccion destino: EspeciIica la direccion del host a alcanzar a nivel MAC.
- Direccion origen: EspeciIica la propia direccion a nivel MAC.
- Tipo o longitud: Si se trata del protocolo Ethernet el tipo de protocolo de nivel
superior (Ethertype). Si es protocolo 802.3 especiIica la longitud del campo
de datos
- CRC: Control de redundancia ciclica, emplea el concepto de polinomio
generador como divisor de la totalidad de la trama, el resto de esta operacion

se enmascara con una secuencia determinada de bit y se envia en este campo.
Se trata entonces de una division binaria, en la cual se emplea como polinomio
generador justamente el CRC-32, que Iigura abajo, por lo tanto el resto de esta
division SIEMPRE sera una secuencia de bit de longitud inIerior a 32 bits, que
sera lo que se incluye en este campo. Los Iormatos estandarizados de estos
CRCs son los que se presentan a continuacion:
CRC-12: X
12
X
11
X
3
X
2
X 1
CRC-16: X
16
X
15
X
2
1
CRC CCITT V41: X
16
X
12
X
5
1 (este codigo se utiliza en el procedimiento
HDLC)
CRC-32 (Ethernet): X
32
X
26
X
23
X
22
X
16
X
12
X
11
X
10
X
8
X
7

X
5
X
4
X
2
X 1
CRC ARPA: X
24
X
23
X
17
X
16
X
15
X
13
X
11
X
10
X
9
X
8
X
5
X
3
1

- Preambulo: No esta representado en la graIica anterior, pues no es considerado
como parte de la trama pero se trata de 7 byte que indican que comienza una
trama y permite sincronizar relojes y 1 Byte de inicio.

e. Relacin de Ethernet con Hub y Switch:
Las redes Ethernet, Iueron diseadas con topologia "Bus fsico", y posteriormente se
incorpora la idea de interconectar varios ETD a un solo dispositivo, que en deIinitiva
cumplia con las mismas Iunciones de un conector "T" del tipo BNC, pero en vez de
biIurcar la seal por dos caminos (como lo hace una "T"), lo hace por "n" caminos.
Esto da origen a los Hub, los cuales literalmente "Explotan" la seal recibida por
cualquiera de sus puertos por todos los restantes (menos el que ingreso). La nueva
Iorma que adoptan estas redes es mas parecida a una estrella, pero como la logica sigue
siendo la misma, es decir, que la seal que emite un ETD sea escuchada por todos los
conectados, es que tambien se la suele llamar "Bus lgico". Mas adelante estos Hubs
incorporan mas Iunciones, de las cuales la mas importante es la de regenerara la seal,
actuando como un repetidor regenerativo de multiples puertos.
Teniendo en cuenta lo tratado anteriormente sobre las colisiones, es muy logico pensar
que a medida que aumenta el numero de ETD, aumentan las colisiones. Esta es una
realidad en estas redes, si bien no depende directamente de la cantidad de host
conectados, sino mas bien del tipo de traIico que estos generen. No se trata de una ley
matematica ni de algo Iacilmente calculable, estos datos se obtienen mas bien mediante
mediciones de traIico de red (analisis de traIico).
Lo que se debe tener en cuenta es que a medida que se necesitan mas puestos de trabajo,
se pueden agregar mas Hubs e interconectarlos entre ellos, esta es una de las grandes
ventajas que posee esta red: su Ilexibilidad. Cada nuevo puesto incorporado generara
mas y mas colisiones, produciendo una baja paulatina en el rendimiento general de la
red. Recordar aqui que la unica Iuncion de un Hub es explotar la seal. Por lo tanto si
se poseen n Hubs, y un ETD emite una trama, esta sera explotada por todas las bocas de
los n Hubs.

Al detectar esta baja perIormance (mediante analisis de traIico), la primer medida es
segmentar la red en dominios de colision. Esta actividad la lleva a cabo un dispositivo
que trabaja a nivel 2 del modelo OSI, denominado Switch, el cual, no se describira en
este texto, pero basicamente posee tablas dinamicas por cada uno de sus puertos, donde
va almacenando las direcciones MAC Iuente de cada trama que pasa por el, y a medida
que va "aprendiendo" las mismas, comienza a poder conmutar una trama acorde a la
puerta en la que la tiene almacenada. Con este principio, si dos ETD se encuentran en
la misma puerta, y un Switch recibe una trama Ethernet con MAC origen y destino en
ese segmento de red, no lo reenviara por ningun otro puerto; si recibiera una trama con
destino en otro segmento de red, unicamente lo conmutaria por el puerto en el que tiene
almacenado ese segmento. Como se puede apreciar, si dialogan dos ETD de un mismo
segmento, esto no inhabilita a hacerlo a otros dos de otro segmento, cosa que no se
podria lograr con Hubs pues estos explotarian la seal por todas sus bocas y el postulado
rector de esta metodologia es que si se escucha ruido en el canal no se puede transmitir.
El objetivo entonces de un Switch es armar diIerentes dominios de colision,
posibilitando que mas de un ETD pueda transmitir a la vez.
La gran salvedad que se debe analizar aqui es que si el Switch no posee elementos de
Juicio para poder determinar que hacer con una trama, opera exactamente igual que un
Hub, es decir, explota la seal por todas sus bocas. Esto es de vital importancia si se
tiene en cuenta que una red mal diseada (y en la gran mayoria de los casos, por Ialta de
optimizacion de traIico) genera una enorme cantidad de Broadcast a nivel MAC. Si se
estudia este detalle, es Iacil deducir que hara el Switch al recibir una trama con
direccion destino Broadcast? Lo explotara por todas sus bocas igual que un Hub.
Por lo tanto en el analisis de traIico es trascendente prestar atencion a la generacion de
Broadcast que se produce en una red. Mas adelante se seguira analizando este tipo de
traIico (y tambien el Multicast), pues se produce tambien en otros niveles con igual
impacto.

f. Spoof de direcciones MAC:
Cuando se trabaja en entornos LAN, el nivel de enlace toma como identiIicador de un
ETD su direccion MAC, la cual por encontrarse impresa en la tarjeta de red (y en teoria
ser unica en el mundo), inicialmente deberia ser diIicil de IalsiIicar. La realidad hace
que no sea tan diIicil, e incluso el propio SO Linux permite modiIicarla a traves del
comando iIconIig. Cuando la inIormacion es recibida en una red LAN, el primer
identiIicador de direcciones que aparece es esta direccion, y en base a esta, el ETD
decide si la entrega al nivel de red o no. Por ser la puerta de entrada a un host destino,
se ha trabajado mucho por distintas opciones de engao, cualquiera de ellas son lo que se
denomino MAC spooIing, lo cual implica IalsiIicar una direccion MAC.

g. Fast y Giga Ethernet:
Las redes dia a dia van exigiendo un mayor ancho de banda. En la actualidad las
necesidades de voz e imagenes hacen que los 10Mbps de Ethernet sean insuIicientes.
Para dar solucion a este problema se comienzan a estudiar nuevas opciones dando origen
a Fast Ethernet.
Se plantearon inicialmente dos propuestas:

- Mantener el protocolo CSMA/CD en todos sus aspectos, pero aumentar en un Iactor
10 la velocidad de la red. Al mantener el tamao de trama minimo (64 bytes) se
reduce en diez veces el tamao maximo de la red, lo cual da un diametro maximo de
unos 400 metros. El uso de CSMA/CD supone la ya conocida perdida de eIiciencia
debida a las colisiones.
- Aprovechar la revision para crear un nuevo protocolo MAC sin colisiones mas
eIiciente y con mas Iuncionalidades (mas parecido en cierto modo a Token Ring),
pero manteniendo la misma estructura de trama de Ethernet.
La primera propuesta tenia la ventaja de acelerar el proceso de estandarizacion y el
desarrollo de productos, mientras que la segunda era tecnicamente superior. El
subcomite 802.3 decidio Iinalmente adoptar la primera propuesta, que siguio su camino
hasta convertirse en lo que hoy conocemos como Fast Ethernet, aprobado en junio de
1995 como el suplemento 802.3u a la norma ya existente.
Los objetivos Iundamentales son:
- Mantener el CSMA/CD.
- Soportar los esquemas populares de cableado. (Ej. 10BaseT ).
- Asegurar que la tecnologia Fast Ethernet no requerira cambios en los protocolos de
las capas superiores, ni en el soItware que corre en las estaciones de trabajo LAN.
Para acelerar el proceso se utilizo para el nivel Iisico buena parte de las especiIicaciones
ya desarrolladas por ANSI para FDDI. Los medios Iisicos soportados por Fast Ethernet
son Iibra optica multimodo o monomodo, cable UTP categoria 3 y categoria 5 y cable
STP (Shielded Twisted Pair).
Los partidarios de la segunda propuesta, considerando que sus ideas podian tener cierto
interes, decidieron crear otro subcomite del IEEE, el 802.12, que desarrollo la red
conocida como 100VG-AnyLAN. Durante cierto tiempo hubo competencia entre ambas
redes por conseguir cota de mercado; hoy en dia la balanza se decanta ampliamente
hacia Fast Ethernet.
Giga Ethernet se aprueba por IEEE en el ao 1998 como estandar 802.3Z (zeta, por ser
la ultima letra del alIabeto y pensar que sera la ultima de esta Iamilia). Tambien se lo
conoce hoy como 1000 Base-X.
Para su implementacion sobre pares de cobre, se creo lanorma 802.3ab, que deIine el
Iuncionamiento de este protocolo sobre cables UTP (Unshielded twisted pair) categorias
5, 5e o 6 y por supuesto para Iibra optica, de esta Iorma paso a llamarse 1000 base-T.
En el 2002, IEEE ratiIico una nueva evolucion de este estandar para operar a 10 Gbps
como 802.3ae, hoy solo Iunciona sobre Iibra optica, pero ya existe la propuesta para
cables de cobre. Mantiene aun la IilosoIia CSMA/CD (Carrier Sense Multiple Access /
Colision detection).

3.3. Anlisis de datagramas (IP):


Se trata de un protocolo de nivel 3 no orientado a la conexion, permitiendo el intercambio de
datos sin el establecimiento previo de la llamada. Una caracteristica Iundamental es que soporta
las operaciones de Iragmentacion y deIragmentacion, por medio de las cuales un datagrama se
subdivide y segmenta en paquetes mas pequeos para ser introducidos a la red, y luego en
destino se reconstruyen en su Iormato original para entregarlos al nivel superior. La otra
operacion que revista importancia es el ruteo, el cual implementa por medio de un esquema de
direccionamiento que se trata a continuacion. En la actualidad se emplea la version 4 de este
protocolo, pero esta en estudio y muy proxima a implementarse la Version 6 o Next Generation
por razones que se trataran al Iinal de esta seccion, pero en estos parraIos se explicara lo reIerido
a la version 4.

a. Direcciones IP (rfc 791):
Internet por medio del empleo del campo de direcciones de un datagrama, solo puede
identiIicar en cada uno de los bit dos elementos:
HOST (H).
NET (N).
Este campo de direcciones, esta constituido por cuatro octetos, los cuales se pueden
presentar en binario (bbbbbbbb.bbbbbbbb.bbbbbbbb.bbbbbbb), en hexadecimal
(hh.hh.hh.hh) o en decimal (d.d.d.d). Es importante habituarse a la correspondencia entre
binario y decimal para un agil manejo de estas direcciones que como ya puede apreciarse,
oscilaran entre 0/255.0/255.0/255.0/255 en sistema decimal. Dentro de este espectro en los
cuatro octetos, existen varias direcciones RESERVADAS, las dos mas comunes son:

00000000 (en binario) o 0 (en decimal): que especiIica ' La red donde me encuentro.
11111111 (en binario) o 255 (en decimal): que especiIica un mensaje de 'Broadcast.

Acorde al primer octeto, se pueden clasiIicar distintos tipo de redes:
0xxxxxxx Tipo A: Como el primer bit es 0, este tipo de redes solo podran abarcar el rango
de direcciones entre 0 y 127.
10xxxxxx Tipo B: Como el primer bit es 1 (ya pesa 128) y el segundo obligatoriamente 0,
este tipo de redes solo podran abarcar el rango de direcciones entre 128 (0 a 63) a 192.
110xxxxx Tipo C Como los dos primeros bit son 11 (ya pesa 192) y el tercero
obligatoriamente 0, este tipo de redes solo podran abarcar el rango de direcciones entre 192
(0 a 31) a 223.
1110xxxx Tipo D Como los tres primeros bit son 111 (ya pesa 224) y el cuarto
(0 a 15) a 239. Este tipo de direcciones estn reservadas para empleo de multicast.
11110xxx Tipo E Como los cuatro primeros bit son 1111 (ya pesa 240) y el quinto
(0 a 7) a 247. Este tipo de direcciones estn reservadas para uso experimental por
parte de los organismos de Internet.


Al diIerenciar estos tipo de redes, a su vez por medio de un concepto denominado
MASCARA DE RED que se tratara mas adelante, en particular las tipo A, B y C determinan
ciertos limites entre Host y Net que se detallan a continuacion:

Tipo A: (0 a 127), el primer octeto identiIica a Net y los otros tres a Host. Por lo tanto
existiran 127 posibles redes A y cada una de ellas podra contener tres octetos de
Host lo que equivale a 2
24
16.777.214 Host, (N.H.H.H).
Tipo B: (128 a 191) Los dos primeros octetos identiIican a Net y los otros dos a Host. Por
lo tanto existiran 2
14
Net 16.384 posibles redes B y cada una de ellas podra
contener dos octetos de Host lo que equivale a 2
16
65.534 Host, (N.N.H.H).
Tipo C: (192 a 223) Los tres primeros octetos identiIican a Net y el ultimo a Host. Por lo
tanto existiran 2
21
Net 2.097.152 posibles redes C y cada una de ellas podra
contener un octeto de Host lo que equivale a 2
8
254 Host, (N.N.N.H).
Las cantidades mencionadas numericamente son las reales si bien pueden no coincidir con
algunas potencias pues dentro de los rangos establecidos, tambien existen determinadas
direcciones reservadas.

b. Mscara de Red y Subred:
Dentro de una red IP, se pueden crear distintas subredes, empleando el concepto de
'Mascara. Estas subredes 'piden prestado bit de los campos identidad de Host, y por
medio del empleo de AND logico se solapan con el bit correspondiente a esa posicion de la
Mascara de subred, Si este ultimo es un uno, se correspondera a un bit que identiIica a una
direccion de red (N), caso contrario sera una direccion de Host.

Ej:

decimal Binario
Direccin IP 193.66.66.240 11000001.01000010.01000010.11110000
Mscara 255.255.255.0 11111111.11111111.11111111.00000000
Identificacin de Host o Net
NNNNNNNN. NNNNNNNN. NNNNNNNN. HHHHHHHH

En este ejemplo se identiIica el Host numero 240 perteneciente a la red tipo C numero
193.66.66. Si se deseara poder crear dos subredes dentro de esta misma red, para
segmentar distintos grupos logicos de nivel 3, se deberia cambiar uno de los bit
correspondientes al cuarto octeto de la mascara, de manera tal que permitiera solaparse con
su correspondiente bit de la direccion IP. Cualquiera de los ocho bit de este ultimo octeto
podria ser elegido, y tecnicamente se crearian dos subredes, pero el mejor planteo para el
diseo 'entendible humanamente es el de comenzar a enmascarar de izquierda a derecha, lo
que permitira identiIicar por el valor decimal de ese octeto a que subred se reIiere (Pues el
ser humano piensa en decimal y no en binario). Para aclarar este planteo se propone el
siguiente ejemplo en la creacion de dos subredes dentro de la misma red anteriormente
descripta:

Ej:

decimal Binario
Direccin IP 193.66.66.240 11000001.01000010.01000010.11110000
Mscara caso 1 255.255.255.128 11111111.11111111.11111111.10000000
NNNNNNNN. NNNNNNNN. NNNNNNN . NHHHHHHH

Mscara caso 2 255.255.255.8 11111111.11111111.11111111.00001000
NNNNNNNN. NNNNNNNN. NNNNNNNN. HHHHNHHH

Para el caso 1, se crearon dos subredes (**Hasta ahora, pues aun Ialta un detalle mas**),
identiIicadas por el primer bit del cuarto octeto cuyo peso es de 128. Bajo este esquema
logico (humano), se identiIican dos subredes cuyos limites estan dados por el valor
numerico (humano) del cuarto octeto, es decir que se plantea la subred 193.66.66.1 a 127 y
la subred 193.66.66.128 a 254, por lo tanto todo Host que en su cuarto octeto tenga un valor
menor a 128, pertenecera univocamente a la primera subred y caso contrario a la segunda.

Ej:
Direccion IP 193.66.66.24 ------------ Subred 1
193.66.66.200 ------------ Subred 2
193.66.66.129 ------------ Subred 2
193.66.66.4 ------------ Subred 1
193.66.66.167 ------------ Subred 2
193.66.66.211 ------------ Subred 2

Para el caso 2, tambien se crearon dos subredes, identiIicadas por el quinto bit del cuarto
octeto cuyo peso es 8, tecnicamente podria Iuncionar (al igual que el caso 1), pero la
identiIicacion de esas dos subredes solo sera pensando en binario, lo cual para ninguna PC o
router sera una limitacion, pero si lo es en gran medida para cualquier ser humano.

Ej:
Direccion IP 193.66.66.24 ------------ Subred ?
193.66.66.200 ------------ Subred ?
193.66.66.129 ------------ Subred ?
193.66.66.4 ------------ Subred ?
193.66.66.167 ------------ Subred ?
193.66.66.211 ------------ Subred ?

Por ultimo Ialta aclarar (**...**) un detalle mas. En el Caso 1 recientemente analizado (Dir
IP : 193.66.66.240 Mascara: 255.255.255.128), como se menciono, se crearon dos
subredes:
subred 193.66.66.1 a 127 (es decir su ultimo octeto comienza con el primer bit 0)
subred 193.66.66.128 a 254 (es decir su ultimo octeto comienza con el primer bit 1)
Recordando un concepto ya descripto, en un octeto la direccion de red no pueden ser todos
unos (Broadcast), ni todos ceros (Mi red); en este caso el primer bit del ultimo octeto sera
siempre 'Todos unos o 'Todos ceros pues es el unico. Siguiendo este principio, NO SE
PUEDEN REALIZAR DOS SUBREDES EMPLEANDO UN SOLO BIT, por lo tanto, si se
deseara implementar dos subredes en este ejemplo, la mascara sera 255.255.255.192, no
pudiendo emplear el rango 00 ni 11 de los consecuentes primeros dos bit del octeto.
Si se desea implementar tres subredes, la mascara sera 255.255.255.224, la que tambien
permitiria implementar hasta seis subredes (Pues no se podrian asignar los rangos 000 y 111
de los tres primeros bit del ultimo octeto). Siguiendo este razonamiento cabe esperar que
para siete subredes, la mascara deberia ser 255.255.255.239 lo que tambien permitiria hasta
catorce, y asi sucesivamente.


c. Classless Interdomain Routing (CIDR) (RFC: 1518/1519):
Ante el inesperado crecimiento de Internet, se produce una saturacion del rango de
direcciones clase B, dejando libres algunas direcciones clase A y C, y presentando la
particular caracteristica que muy pocas empresa (o casi ninguna), puede cubrir una clase A, y
muchas necesitan mas de una clase C. Ante este hecho, se van tomando una serie de
medidas por medio de las cuales se ajusta la distribucion, se restringe la asignacion de
direcciones a empresas que lo justiIiquen con mucho grado de detalle, se distribuyen
direcciones en tres zonas mundiales (RIPE, ARIN, y APNIC), pero esto comienza a provocar
cada vez mayores tablas en los router con el consiguiente cuello de botella. Para presentar
una solucion a este problema (momentanea, pues la deIinitiva recien aparece con Ipv6), nace
CIDR o tambien llamado 'Supernetting. Este concepto permite combinar subredes que
comparten mas de una clase C o subdividir redes clase A o B. El concepto de Supernetting se
atribuya a la diIerencia con Subnetting. En este ultimo, para crear subredes, se emplea mayor
cantidad de bit en la mascara de red. En el caso de Supernetting, es justamente lo contrario (y
de ahi su nombre), pues se emplearan menos bit de mascara de la que corresponderia a su
clase.
Estas direcciones de red deben compartir los bit de mas alto orden de la mascara de red, sin
respetar el concepto clasico de 'clase. A continuacion se presenta un ejemplo:
NET 192.168.5 (1100 0000.1010 1000.0000 0101.0000 0000)
NET 192.168.6 (1100 0000.1010 1000.0000 0110.0000 0000)
NET 192.168.7 (1100 0000.1010 1000.0000 0111.0000 0000)
MASK 255.255.252.0 (1111 1111.1111 1111.1111 1100.0000 0000)
En este ejemplo se aprecian tres rangos de direcciones de red que clasicamente se deIinirian
como clase C, el empleo de CIDR, se pone de maniIiesto a traves de la mascara de red, la cual
reduce dos bit, colocando en su tercer octeto el valor 252 en vez del clasico que deberia ser
255. Si se analiza la combinacion de bit de direccion con los de host, se trataria aqui de la
red 192.168.4, y el broadcast de red deberia ser 192.168.127.255 (1100 0000.1010
1000.0000 0111.1111 1111). Las siguiente RFC hacen reIerencia a CIDR:

RFC 1467 - DiIusion de CIDR en Internet
RFC 1517 - Condiciones de aplicabilidad de CIDR
RFC 1518 - Una arquitectura para la distribucion de direcciones IP con CIDR
RFC 1519 - CIDR: asignacion de direcciones y estrategia de agregacion
RFC 1520 - Intercambiando inIormacion de encaminamiento a traves de las Ironteras de
los proveedores en el entorno CIDR

d. Tablas de ruta:

Cada datagrama tiene solo tres posibilidades:

- Ser pasado al nivel superior.
- Encaminarlo hacia alguna de las interIaces de red.
- Ser descartado.


Las tablas de rutas mantienen cuatro tipos de las mismas:

- host (Se trata de una ruta a una simple y especiIica direccion IP).
- Subnet (Ruta hacia una subred).
- Network (Ruta hacia toda una red).
- DeIault (Cuando ninguna de las anteriores coincide).

Ejemplo:
C:\>route print

Network Address Netmask Gateway Address Interface Metric
0.0.0.0 0.0.0.0 192.168.40.1 192.168.40.123 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.40.0 255.255.255.0 192.168.40.123 192.168.40.123 1
192.168.40.123 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.40.255 255.255.255.255 192.168.40.123 192.168.40.123 1
224.0.0.0 224.0.0.0 192.168.40.123 192.168.40.123 1
255.255.255.255 255.255.255.255 192.168.40.123 192.168.40.123 1

En este ejemplo de tabla de ruteo, se aprecia una direccion privada clase C con un host cuya
direccion es 192.168.40.123 y contiene siete entradas

- La primera entrada (0.0.0.0) contiene la ruta por deIecto.
- La segunda (127.0.0.0) es la direccion de loopback.
- La tercera (192.168.40.0) es la direccion de esta red.
- La cuarta (192.168.40.123) es la ruta para el local host, se debe prestar atencion, que esta hace
reIerencia luego al loopback, es decir que todo datagrama hacia esta direccion debera ser
tratado internamente.
- La quinta (192.168.40.255) especiIica el broadcast de subred.
- La sexta especiIica la direccion multicast.
- La ultima indica la direccion de broadcast.

Esta tabla de rutas en la mayoria de los casos es mantenida automaticamente, y muchas de estas
direcciones las obtendra al iniciar el host, de datos locales y a traves de inIormacion obtenida
desde servidores de la red, tambien pueden ser adicionadas en Iorma manual, y especiIicar que
sean permanentes o transitorias.

Deteccin de direcciones IP duplicadas:

Al iniciarse un host, envia una solicitud ARP particular, pues lo hace solicitando la direccion
MAC que se corresponde a su propia direccion IP, si alguien contesta este mensaje es que
esta direccion IP ya esta en uso.

Multihomed:

Este termino se reIiere al caso que un host se encuentre conIigurado con mas de una
direccion IP, esta conIiguracion se puede presentar de tres maneras:


- Multiples IP por NIC.
- Multiples NIC.
- Multiples IP y NIC.

e. IP Multicasting:
El IP Multicasting es la transmision de un datagrama IP a un cierto grupo de cero a 'n host
identiIicados por una unica direccion IP. Los miembros de este grupo son dinamicos, es
decir que pueden unirse y dejar grupos en cualquier momento, sin existir ninguna restriccion
de ubicacion o cantidad de miembros. Un host puede ser miembro de mas de un grupo y no
necesita ser miembro de un grupo para enviar datagramas a el.
Existen grupos deIinidos como permanentes, que son los que tienen asignada una direccion IP
'Bien conocida, esta permanencia se reIiere a su direccion, no a sus miembros, los cuales
pueden incorporarse y dejarlo dinamicamente en cualquier momento.
El empleo de IP multicast esta controlado por los router que pueden o no coexistir con los
Gateway
En el mapa de rutas de cada host, para soportar multicast, se agrega una linea adicional:

Network Address Netmask Gateway Address Interface Metric
224.0.0.0 224.0.0.0 192.35.129.1 192.35.129.1 1
En este ejemplo, la direccion 192.35.129.1 es la propia direccion del host (no la del gateway
de la red), es decir que si este host desea enviar cualquier mensaje multicast, lo hara a traves
de su interIaz de red y no lo encaminara al gateway por deIault.
Un tema de especial interes es que para poder enviar un datagrama, siempre debe ser resuelta
la direccion MAC, este tema lo trata la RFC 1112 y se implementa de la siguiente manera:
Ethernet identiIica multicast colocando a uno el primer bit del primer octeto de su direccion
MAC, es decir que este primer octeto adoptara el valor 01h, ademas IANA reserva (en
acuerdo con IEEE que es quien asigna las direcciones MAC) el rango 00-00-5E-00-00-00
hasta 00-00-5E-7F-FF-FF, por lo tanto, los tres primeros octetos de la direccion MAC para
multicast IP en redes Ethernet sera siempre 01-00-5E. El grupo de direcciones IP es mapeado
a una direccion multicast Ethernet, por reemplazo de los 23 bit de menor orden de la direccion
IP a los 23 bit de menor orden de la direccion MAC, por ejemplo si un host con direccion
MAC 01-22-A2-34-67-E1 deseara enviar un datagrama a la direccion multicast 224.0.0.3, la
direccion MAC se Iormaria con los tres primeros octetos MAC multicast (01-00-5E),
anexandole los ultimos 23 bit de la direccion IP multicast (0.0.3 00-00-03 en hexadecimal),
quedaria 01-00-5E-00-00-03. Un problema cierto que se plantea es que la direccion IP posee
cuatro octetos, es decir 32 bit, en el caso de multicast, los cuatro primeros bit estan impuestos
y siempre son 1110, por lo tanto quedan disponibles veintiocho bit, de los cuales solo se
mapean 23, es decir que se puede presentar el caso que dos direcciones multicast IP sean
mapeadas a la misma direccion MAC, en este caso, sera descartado el datagrama a nivel IP,
al descubrir en destino que no va dirigido al grupo correspondiente.
Por deIecto los datagramas IP Multicast son generados con TTL1, y por convencion, los
router multicast emplean los valores de TTL para determinar cuan lejano deben encaminar los
datagramas, estos valores de TTL estan deIinidos y son los siguientes:

TTL 0 se reIieren al mismo host.
TTL 1 se reIieren a la misma subred. Los routers multicast al recibir un datagrama
multicast con TTL1, lo decrementan a cero, pero a diIerencia de un datagrama

unicast, no envia ningun mensaje ICMP de TTL agotado, pues lo considera un
evento normal.
TTL 32 se reIieren a la misma Site.
TTL 64 se reIieren a la misma region.
TTL 128 se reIieren al mismo continente.
TTL 255 sin restricciones de ambito.

La direccion multicast tambien oIrece inIormacion sobre las rutas, pues por ejemplo el rango
comprendido entre 224.0.0.0 a 224.0.0.255 se emplea para un solo salto, es decir que ningun
router multicast retransmitira ningun datagrama con estas direcciones.
A continuacion se presentan las direcciones multicast deIinidas por la RFC 1112:

224.0.0.0 Reserved
224.0.0.1 All Hosts on this Subnet
224.0.0.2 All Gateways on this Subnet (proposed)
224.0.0.3 Unassigned
224.0.0.4 DVMRP Routers(Distance Vector Multicast Routing Protocol, RFC 1075)
224.0.0.5 OSPFIGP OSPFIGP All Routers
224.0.0.6 OSPFIGP OSPFIGP Designated Routers
244.0.0.7-244.0.0.255 Unassigned
224.0.1.0 VMTP Managers Group (Versatile Message Transaction Protocol, RFC
1045).
224.0.1.1 NTP Network Time Protocol
224.0.1.2 SGI-DogIight
224.0.1.3 Rwhod
224.0.1.4 VNP
244.0.1.5-244.0.1.255 Unassigned
224.0.2.1 "rwho" Group (BSD) (unoIIicial)
232.x.x.x VMTP transient groups

f. Fragmentacin IP:

Como se vera en el Header de IP, uno de los puntos Iuertes de este protocolo es la
Iragmentacion, si bien en la actualidad no es muy empleado porque TCP puede
determinar los tamaos de la inIormacion a transmitir por el canal para que justamente
no sea necesario tener que Iragmentar y deIragmentar inIormacion en nodos
intermedios. Igualmente este aspecto se expresa particularmente en este parraIo para
marcar la importancia de esta tarea pues es de las tecnicas mas empleadas para evadir
sistemas de seguridad en las redes TCP/IP.

g. Formato del datagrama IP:

Version Longitud de cabecera
precedencia D T R Reservado
Longitud total

IdentiIicador

IdentiIicadores Desplazamiento de Iragmentacion


Tiempo de vida (TTL)
Protocolo
Checksum de cabecera

Direccion Fuente

Direccion Destino

Opciones y Relleno (Variable)

Datos (Variable)

Versin: 4 bits
Siempre vale lo mismo (0100). Este campo describe el Iormato de la cabecera
utilizada. En la tabla se describe la version 4.

Tamao Cabecera: 4 bits

Longitud de la cabecera, en palabras de 32 bits. Su valor minimo es de 5 para una
cabecera correcta, y el maximo de 15.

Tipo de Servicio: 8 bits

Indica una serie de parametros sobre la calidad de servicio deseada durante el transito
por una red. Algunas redes oIrecen prioridades de servicios, considerando
determinado tipo de paquetes "mas importantes" que otros (en particular estas redes
solo admiten los paquetes con prioridad alta en momentos de sobrecarga). Estos 8
bits se agrupan de la siguiente manera. Los 5 bits de menos peso son independientes
e indican caracteristicas del servicio:

Bit 0: sin uso, debe permanecer en 0.
Bit 1: 1 costo minimo, 0 costo normal.
Bit 2: 1 maxima Iiabilidad, 0 Iiabilidad normal.
Bit 3: 1 maximo rendimiento, 0 rendimiento normal.
Bit 4: 1 minimo retardo, 0 retardo normal.

Los 3 bits restantes estan relacionados con la precedencia de los mensajes, un
indicador ajunto que indica el nivel de urgencia basado en el sistema militar de
precedencia (vease Message Precedence) de la CCEB, un organizacion de
comunicaciones electronicas militares Iormada por 5 naciones. La urgencia que estos
estados representan aumenta a medida que el numero Iormado por estos 3 bits lo
hace, y responden a los siguientes nombres.

000: De rutina.

001: Prioritario.
010: Inmediato.
011: Relampago.
100: Invalidacion relampago.
101: Procesando llamada critica y de emergencia.
110: Control de trabajo de Internet.
111: Control de red.

Longitud Total: 16 bits

Es el tamao total, en octetos, del datagrama, incluyendo el tamao de la cabecera y
el de los datos. El tamao maximo de los datagramas usados normalmente es de 576
octetos (64 de cabeceras y 512 de datos). Una maquina no deberia enviar datagramas
mayores a no ser que tenga la certeza de que van a ser aceptados por la maquina
destino.

En caso de Iragmentacion este campo contendra el tamao del Iragmento, no el del
datagrama original.

Identificador: 16 bits

IdentiIicador unico del datagrama. Se utilizara, en caso de que el datagrama deba ser
Iragmentado, para poder distinguir los Iragmentos de un datagrama de los de otro. El
originador del datagrama debe asegurar un valor unico para la pareja origen-destino
y el tipo de protocolo durante el tiempo que el datagrama pueda estar activo en la
red.

Indicadores: 3 bits

Actualmente utilizado solo para especiIicar valores relativos a la Iragmentacion de
paquetes:

bit 0: Reservado; debe ser 0
bit 1: 0 Divisible, 1 No Divisible
bit 2: 0 Ultimo Fragmento, 1 Fragmento Intermedio (le siguen mas
Iragmentos)

La indicacion de que un paquete es indivisible debe ser tenida en cuenta bajo
cualquier circunstancia. Si el paquete necesitara ser Iragmentado, no se enviara.

Posicin de Fragmento: 13 bits

En paquetes Iragmentados indica la posicion, en unidades de 64 bits, que ocupa el
paquete actual dentro del datagrama original. El primer paquete de una serie de
Iragmentos contendra en este campo el valor 0.

Tiempo de Vida (TTL): 8 bits

Indica el maximo numero de direccionadores que un paquete puede atravesar. Cada
vez que algun nodo procesa este paquete disminuye su valor en, como minimo, un
direccionador. Cuando llegue a ser 0, el paquete no sera reenviado.


Protocolo: 8 bits

Indica el protocolo de siguiente nivel utilizado en la parte de datos del datagrama.
Vea Numeros de protocolo IP para comprender como interpretar este campo.

Suma de Control de Cabecera: 16 bits

Suma de Contol de cabecera. Se recalcula cada vez que algun nodo cambia alguno
de sus campos (por ejemplo, el Tiempo de Vida). El metodo de calculo
(intencionadamente simple) consiste en sumar el complemento a 1 de cada palabra
de 16 bits de la cabecera y hacer el complemento a 1 del valor resultante.

Direccin IP de origen: 32 bits

Direccin IP de destino: 32 bits

Opciones: Variable

Aunque no es obligatoria la utilizacion de este campo, cualquier nodo debe ser capaz
de interpretarlo. Puede contener un numero indeterminado de opciones, que tendran
dos posibles Iormatos:

Formato de opciones simple

Se determina con un solo octeto indicando el Tipo de opcion, el cual esta dividido en
3 campos.

* Indicador de copia: 1 bit. En caso de Iragmentacion, la opcion se copiara o no a
cada nuevo Iragmento segun el valor de este campo:

0 no se copia
1 se copia.

* Clase de opcion: 2 bits. Las posibles clases son:

0 control
1 reservada
2 depuracion y mediciones
3 reservada.

* Numero de opcion: 5 bits. IdentiIicador de la opcion.

Formato de opciones compuesto

Un octeto para el Tipo de opcion, otro para el Tamao de opcion, y uno o mas
octetos conIormando los Datos de opcion.

El Tamao de opcion incluye el octeto de Tipo de opcion, el de Tamao de opcion y
la suma de los octetos de datos.


La siguiente tabla muestra las opciones actualmente deIinidas:
Clase Numero Tamao
Descripcion
0 0 - Final de lista de opciones. Formato simple.
0 1 - Ninguna operacion (NOP). Formato simple.
0 2 11 Seguridad.
0 3 variable Enrutado desde el Origen, abierto (Loose Source
Routing).
0 9 variable Enrutado desde el Origen, estricto (Strict Source
Routing).
0 7 variable Registro de Ruta (Record Route).
0 8 4 IdentiIicador de Ilujo (Stream ID).
2 4 variable Marca de tiempo (Internet Timestamping).

Final de Lista de Opciones:

Se usa al Iinal de la lista de opciones, si esta no coincide con el Iinal de la
cabecera IP.

Ninguna Operacion (NOP):

Se puede usar para Iorzar la alineacion de las opciones en palabras de 32 bits.

Seguridad:

EspeciIica niveles de seguridad que van desde "No ClasiIicado" hasta "Maximo
Secreto", deIinidos por la Agencia de Seguridad de la DeIensa (de EE.UU.).

Enrutado desde el Origen (abierto) y Registro de Ruta (LSSR):

Esta opcion provee el mecanismo para que el originador de un datagrama pueda
indicar el itinerario que ha de seguir a traves de la red y para registrar el camino
seguido.
Los Datos de Opcion consisten en un puntero (un octeto) y una lista de
direcciones IP (4 octetos cada una) que se han de alcanzar ("procesar"):

El puntero indica la posicion de la siguiente direccion de la ruta, dentro de la
Opcion; asi, su valor minimo es de 4.
Cuando un nodo de Internet procesa la direccion de la lista apuntada por el
puntero (es decir, se alcanza esa direccion) incrementa el puntero en 4, y redirige el
paquete a la siguiente direccion. Si el puntero llega a ser mayor que el Tamao de
Opcion signiIica que la inIormacion de ruta se ha procesado y registrado
completamente y se redirigira el paquete a su direccion de destino.
Si se alcanza la direccion de destino antes de haber procesado la lista de
direcciones completa (el puntero es menor que el Tamao de Opcion) la siguiente
direccion de la lista reemplaza a la direccion de destino del paquete y es a su vez
reeemplazada por la direccion del nodo que esta procesando el datagrama ("Ruta
Registrada"), incrementando, ademas, el puntero en 4.

Utilizando este metodo de sustituir la direccion especiIicada en origen por la
Ruta Registrada se asegura que el tamao de la Opcion (y de la cabecera IP) no varia
durante su recorrido por la red.

Se considera que la ruta especiIicada por el originador es "abierta" porque
cualquier nodo que procesa el paquete es libre de dirigirlo a la siguiente direccion
siguiendo cualquier otra ruta intermedia.

Solo puede usarse una vez en un datagrama, y, en caso de Iragmentacion, la
opcion se copiara a los paquetes resultantes.

Enrutado desde el Origen (estricto) y Registro de Ruta (SSRR):

Exactamente igual que LSSR, excepto en el tratamiento que los nodos haran de
este datagrama. Al ser la ruta especiIicada "estricta", un nodo debe reenviar el
paquete directamente a la siguiente direccion, es decir, no podra redireccionarlo por
otra red.

Registro de Ruta:

Mediante el uso de esta Opcion se puede registrar el itinerario de un datagrama.
Los Datos de Opcion consisten en un puntero (un octeto) y un espacio relleno de
ceros que contendra la Ruta Registrada para el paquete.
Cuando un nodo recibe un paquete en el que esta presente esta opcion, escribira
su direccion IP en la posicion indicada por el puntero, siempre que esta sea menor
que el Tamao de Opcion, e incrementara el puntero en 4.
Es preciso que el espacio reservado para la Ruta Registrada tenga una longitud
multiplo de 4; si al intentar grabar su direccion un nodo detecta que existe espacio
libre pero es menor de 4 octetos, el paquete no se reenvia (se pierde) y se notiIica el
error, mediante ICMP, al originador del datagrama.
Esta Opcion no se copia en caso de Iragmentacion, y solo puede aparecer una
vez en un paquete.

Relleno: Variable

Utilizado para asegurar que el tamao, en bits, de la cabecera es un multiplo de 32. El
valor usado es el 0.

h. IP Spoof:

Esta tecnica se emplea para IalsiIicar un verdadera direccion IP a traves de la colocacion
de una Ialsa, la cual puede hacer uso de una existente en la red o nueva. Presenta
especial peligrosidad cuando los dispositivos de seguridad emplean el campo direccion IP
para la implementacion de las medidas de sus medidas, como pueden ser: control de
accesos, permisos, ambito interno o externo, validacion o generacion de alarmas,
establecimiento de sesiones, reglas, etc.


3.4. TCP (Transport Control Protocol) (RFC 793 , 812, 813, 879, 896 y 1122).

Se trata del protocolo responsable de establecer y gestionar sesiones (conexiones logicas)
entre usuarios locales o remotos. Es tambien quien se encarga de la Iiabilidad, control de
Ilujo, secuenciamiento, aperturas y cierres. Es un protocolo orientado a la conexion, por lo
tanto es el responsable de la transmision de extremo a extremo. Emplea ACK,
temporizadores, N(s) y N(r) con segmentos de longitud variable.
Una caracteristica de su empleo es que el control de Ilujo lo realiza el receptor, el cual envia
un valor de ventana (al emisor). El Transmisor puede enviar un numero maximo de
ventanas no mayor a ese valor, y al llegar al mismo interrumpe la transmision hasta recibir
los ACK correspondientes, que liberen posiciones en su cola circular de envio ( N(s) ).
El TCP permite multiplexar varias sesiones en una misma computadora por medio del
concepto de socket (explicado en terminologia).

a. Establecimiento y cierre de conexiones.
Al establecerse una sesion TCP, se produce un triple Handshake, el cual se establece por
medio de los bit S y A (Caracteristica de un protocolo orientado a la conexion), envio del
primer segmento solicitando establecer una sesion y colocando su numero de ventana en
un cero relativo (Numero generado pseudoaleatoriamente que establece el envio de la
primer ventana) (bit A 1), respuesta aceptando y enviando tambien su numero de
secuencia (bit S y A 1) y por ultimo establecimiento de la sesion TCP (bit A 1); se
inicia el calculo del RTT (Round Trip Time), tiempo que le permite a TCP establecer el
control de Ilujo calculando el promedio que tardan los segmentos enviados con sus
correspondientes respuestas.
El cierre de una sesion TCP se produce al enviar el bit F 1 ante lo cual se respondera
con el bit A 1 quedando Iinalizada la sesion
La ventana de recepcion de TCP en redes Ethernet normalmente se conIigura a 8769
bytes, que equivale a seis segmentos de 1460 bytes, que sumados a los 20 byte del
encabezado TCP, 20 de IP y 18 de Ethernet, hacen 1518 byte que es el tamao maximo
de la trama Ethernet. El tamao de esta ventana se ajusta automaticamente acorde a
una mecanismo de tiempos de recepcion y esta regulado por la RFC 1323.

b. Control de flujo
La RFC 1122 deIine los mecanismos de control de Ilujo de TCP, basados en los
acknowledgments (ACK) de recepcion. Este mecanismo permite al receptor de
segmentos, regular el tamao de ventana del emisor, para impedirle el envio de
volumenes de inIormacion que no este en capacidad de procesar.

c. PMTU (Path Maximun Unit Discovery)
Este mecanismo esta descripto por la RFC 1191 y permite determinar el MSS
(Maximun Segmenet Size) de una determinada conexion.
El concepto esta basado en el empleo del protocolo ICMP, por medio del cual, cuando
se establece una conexion a traves de una red no local, el bit Don`t Fragment (DF) del
encabezado IP es conIigurado a uno, es decir que no permite la Iragmentacion de ese
datagrama. Si a lo largo de su trayectoria, este datagrama se encuentra con una red que

no soporta este tamao (como seria el caso, por ejemplo, de un datagrama generado en
una red Token ring, de 4000 Byte, que debe pasar por otra Ethernet), el router que lo
recibe, al no poder Iragmentar, descartara este datagrama, generando un mensaje ICMP
de destino no alcanzable por Iragmentacion requerida y no permitida a la direccion
origen del datagrama descartado, en el encabezado ICMP generalmente incluira tambien
el tamao maximo permitido en esa red (dentro de un campo 'no empleado de 16 bit).
El que origino el datagrama inicial, al recibir el mensaje ICMP, ajustara la MTU al
tamao indicado.

d. Retransmisin
TCP con cada segmento saliente inicia un timer de retransmision (por deIecto es 3
segundos al establecer la conexion, y se ajusta dinamicamente, RFC: 793), si ningun
ACK es recibido al expirar este tiempo, entonces el segmento es reenviado, hasta llegar
al TcpMaxDataRetransmision, que por deIecto es cinco, luego de lo cual no vuelve a
retransmitir ese segmento.
En el siguiente ejemplo se puede ver una secuencia de segmentos TCP, en los cuales
luego del primero de ellos, se desconecto el host destino, por lo tanto no recibia el ACK
de respuesta, en la primera columna el incremento Iue duplicando su tiempo de envio
entre cada segmento, y al llegar al ultimo si no recibiera respuesta, abortaria la
transmision.
delta source ip dest ip prot flags description
0.000 10.57.10.32 10.57.9.138 TCP ...A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
1.001 10.57.10.32 10.57.9.138 TCP .. A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760

e. Velocidad de transferencia
TCP Iue designado para optimizar su rendimiento sobre condiciones de enlace
variables, dependiendo de varios Iactores:
- Velocidad del vinculo.
- Demora del vinculo.
- Tamao de ventana.
- Congestion en los routers.
La capacidad de un vinculo esta dada por lo que se conoce como el 'producto ancho de
banda/demora (I * RTT |Round Trip Time|). Si el enlace es de buena calidad, el
tamao de la ventana deberia ser mayor o igual que la capacidad del mismo (65535 es el
maximo), por el contrario, si el enlace posee mucho ruido o congestiones, el empleo de
ventanas grandes no es conveniente, pues se aumentara la congestion o se reenviaran
muchos paquetes.

f. Formato del segmento TCP.


Puerto Iuente

Puerto destino

Numero de secuencia N(s)

Numero de aceptacion N(r)

Desplazamiento de datos Reservado
Reservado URG ACK PSH RST SYN FIN
Ventana

Checksum

Puntero de urgente

Opciones y relleno (Variable)

Datos (Variable)

Puerto Iuente y destino: (16), especiIican los procesos de nivel superior que utilizan la
conexion TCP.
Numero de secuencia y de aceptacion: (32), indican la secuencia o posicion de los
octetos de datos dentro del modulo completo de transmision. Concatenado a esto,
dentro de este campo tambien va el numero de ventana deslizante.
Desplazamiento de datos: (4), cantidad de palabras de 32 bit que contiene la cabecera.
Reservado: (6), no se permite su empleo, quedan reservados para uso Iuturo.
URG: (1), indica si es un segmento urgente.
ACK: (1), acknowledgement.
PSH: (1), Entregar los datos al recibir este segmento.
RST: (1), reset.
SYN: (1), sincronismo.
FIN: (1), ultimo segmento.
Ventana: (16), cantidad maxima de segmentos que puede enviar el transmisor.
Checksum: (16), CRC de cabecera y datos.
Puntero de urgente: (16), si el bit URG esta puesto a 1, identiIica la posicion del
primer octeto donde los datos son urgentes. TCP no dice que hay que hacer con los
datos urgentes, solo los marca.
Opciones: Son de la Iorma (Tipo-longitud-valor). Hoy solo existen deIinidas 3. O
Fin de lista de opciones. 1 No operacion. 2 Tamao maximo de segmento
(MSS).
Relleno: completa a multiplo de 32 bit de la cabecera.
Datos: UDP de nivel superior.


Un detalle interesante de TCP es la inclusion de un 'Pseudo encabezado, el cual se emplea
al realizar el checksum (CRC). La mecanica del mismo es tomar datos del nivel de red (IP),
en particular la direccion origen y destino, Iormar con estos otro encabezado adicional para
realizar el calculo teniendo en cuenta estos datos dentro del checksum de TCP. Estos datos
adicionales, no son tenidos en cuenta en la longitud de TCP, ni tampoco se transmiten, pues
luego estaran incluidos en el encabezado IP. El objetivo principal de este Pesudo
encabezado es proporcionar a TCP la garantia de entrega en el destino correcto de su
inIormacion, pues al llegar a destino el segmento TCP, nuevamente el host receptor tomara
estos campos del nivel inIerior y calculara su CRC, si el destino Iuera incorrecto, este
segmento seria descartado. Esta implementacion rompe un poco el concepto de
independencia de niveles, pero tambien sucede con otros protocolos y no es lo habitual.
Los protocolos mas comunes que emplean TCP son los que se detallan a continuacion:
Puerto Protocolo
7 Eco
13 Fecha
20 y 21 FTP (File TransIer Protocol)
23 Telnet
25 SMTP (Single Mail TransIer Protocol)
80 HTTP (Hiper Text TransIer Protocol
137,138 y
139
NetBIOS

3.5. UDP (User datagram Protocol) (RFC 768).

Dentro de la pila de protocolos TCP/IP, existen dos opciones de protocolos de transporte. El
TCP que se acaba de tratar y el UDP (que lamentablemente se abrevia igual que unidad de
datos de protocolo, pero no se trata de esta sino de un protocolo de capa 4) el cual es un
Protocolo NO ORIENTADO A LA CONEXION, y se lo emplea con la masa de los
protocolos de nivel superior cuando se opera sobre redes LAN. Esta regulado por la RFC
768, y conIia en la baja tasa de errores de una LAN y en los protocolos de nivel de
aplicacion, siendo por lo tanto un protocolo no conIiable pero con la gran ventaja de la
reduccion de su cabecera a menos de 8 octetos.

a. Formato de la cabecera de UDP.

Puerto Origen

Puerto destino

Longitud

Checksum (Opcional)

Datos (Variable)

Puerto origen y destino: (16), SAP de nivel de aplicacion. El puerto origen es
opcional, si no se emplea se colocan todos sus bit a cero.
Longitud: (16), total de cabecera y datos.

Checksum: (16), puede o no estar presente, si lo esta es un CRC 16 de cabecera,
datos y Pseudo cabecera cono TCP. Este campo tambien es opcional, y de no
usarse tambien se rellena con ceros.
Datos: (Variable), UDP (Unidad de datos de protocolo) de nivel superior.

Los protocolos mas comunes que emplean UDP son los que se detallan a continuacion:

Puerto Protocolo
7 Eco
13 Fecha
53 DNS (Sistema de Nombres de Dominio)
67 y 68 BOOT cliente y Servidor
69 TFTP (Trivial File TransIer Protocol)
123 NTP (Network Time Protocol)
161 y 162 SNMP (Single Noetwork Monitor Protocol)

b. El peligro de los protocolos no orientados a la conexin:

Los protocolos no orientados a la conexion, como ya se vio, no establecen ni cierran la
misma, sino que pasan directamente a la transIerencia de datos, conIiando que la
inIormacion llegara al destino deseado.
Al generar este tipo de traIico, no se realiza ningn seguimiento del estado de esa
conexion, por eso tambien se los suele llamar sin estado. No existen numeros de
secuencia, por lo tanto si se desea realizar un analisis de lo que esta sucediendo se torna
muy diIicultoso. Por otro lado, no se puede definir el "Sentido" en el que se realiza la
conexion, pues esta no existe, y sin ella tampoco se determinara quien desempea el rol
de cliente y quien el de servidor. Estos protocolos en particular son de especial interes
en cuanto a las reglas de un Iirewall, justamente por las dos caracteristicas que se acaban
de mencionar.

3.6. ARP (Address Resolution Protocol) (RFC 826, 1293, 1390):

a. Funcionamiento
Para que se puede establecer la transIerencia de datos entre dos ETD en la Iamilia TCP/IP, estos
deberan conocer obligatoriamente las direcciones IP y las de Hardware (MAC),del emisor y
receptor; hasta que estas cuatro no se encuentren perIectamente identiIicadas, no se podra iniciar
ninguna transIerencia de inIormacion. Bajo este esquema es Iacil de pensar que si un ETD A
desea envia inIormacion, conozca su Direccion MAC e IP, tambien es razonable que pueda
conocer la direccion IP destino; el responsable de descubrir la direccion MAC Ialtante es el
protocolo ARP. El mecanismo que emplea es el de mantener una tabla dinamica en memoria
en cada ETD llamada cache ARP (La cual se puede analizar por medio del archivo ARP.exe), en
la misma se van guardando todas las asociaciones de MAC-IP que escucha el ETD en la red. Al
intentar transmitir inIormacion, analizara primero en su cache ARP si esta asociacion existe, de
no encontrarla generara un mensaje ARP.

b. Tipos de mensajes:

ARP trabaja por medio de una solicitud y una respuesta. La Solicitud es un broadcast de nivel 2
(FF.FF.FF.FF.FF.FF), el cual sera escuchado por todas los ETD de la red con el Iormato que se
graIicara a continuacion. Por ser Broadcast, todos los niveles 2 de todos los ETD de la red lo
reconoceran como propio, entregando la UDP correspondiente al nivel 3 en todas los ETD. El
unico nivel 3 que lo tomara como suyo sera el que identiIique su propia direccion IP en esta
cabecera quien respondera (respuesta ARP) colocando en la direccion MAC Ialtante la propia,
pero ya no por medio de broadcast sino dirigida al ETD que genero la solicitud ARP, pues
poseera todos los datos necesarios. Al llegar a destino se completa toda la inIormacion
necesaria para iniciar la transIerencia de inIormacion, y se incluira esta nueva asociacion MAC-
IP en la cache ARP.
Un caso obvio es cuando el ETD no pertenece a la propia red, por lo cual jamas sera alcanzado
por un broadcast de nivel 2 (pues un router lo Iiltraria). En esta situacion, el router que si
escucha el broadcast (o puntualmente la solicitud ARP dirigida a el) reconoce que no se trata de
una direccion de la red propia, y opera en Iorma similar a un ETD pero a traves de tablas
llamadas cache PROXY ARP, en las cuales mantiene asociaciones MAC-IP por cada puerto que
posea, si en esta no se encuentra la direccion MAC buscada, generara un nuevo Iormato ARP por
la puerta hacia la cual identiIique la red IP correspondiente (este ultimo paso puede variar acorde
al tipo de protocolo que emplee el router), esto se repetira a lo largo de toda una cadena de router
hasta identiIicar la red IP correspondiente a la direccion buscada, donde se generara un broadcast
que si encontrara a la direccion IP deseada, la cual respondera la solicitud ARP, y por el camino
inverso, y en Iorma dirigida llegaran la direccion MAC solicitada a destino, completando de esta
Iorma las cuatro direcciones necesarias.
La ultima de las posibilidades existentes ocurre cuando un ETD no conoce su propia direccion
IP, circunstancia que puede presentarse cuando bootea un ETD y solicita una asignacion
dinamica de direccion IP o tambien al inicializar un ETD que no poseen disco rigido. Ante este
tipo de sucesos existe el Protocolo RARP (Reverse) (RFC 903), el cual genera un mensaje con
Iormato semejante al ARP pero sin contener tampoco su propia direccion IP, la condicion
imprescindible para este protocolo es la existencia de un servidor RARP el cual recibira este
mensaje, resolviendo el direccionamiento IP del ETD que lo requiera. Los pasos de este
protocolo son analogos a los del ARP. En el encabezado Ethernet, el campo identiIicador de
protocolo de capa superior (SAP) llevara el valor 8035h que identiIica RARP.

c. Formato del Header ARP.

Tipo de Hardware

Tipo de protocolo

Longitud de direcciones de Hardware
Longitud de direcciones de Protocolo
Codigo de operacion

Direccion de Hardware del transmisor

Direccion IP del transmisor


Direccion de Hardware de receptor

Direccion IP de receptor

Tipo de hardware: (16), interIaz de hardware empleado (Valor 1 para Ethernet).
Tipo de protocolo: (16), identiIicador del protocolo que se emplea (Valor 0800 para IP).
Longitud de direccion de Hardware y Protocolo: (8), limitan los campos posteriores a la cantidad
de octetos que emplee cada uno de ellos.
Codigo de operacion: (16), (opcode), solo se encuentran deIinidos 2 tipos, 1 Solicitud, 2
Respuesta (En realidad tambien estan deIinidos 3 y 4 pero son para solicitud y respuesta de
RARP) .
Direcciones: (48) (32), especiIican el tipo necesario para ser resuelto por ARP.

a. Ataque ARP:
Este ataque tiene sentido unicamente en redes LAN (No debe olvidarse que el 80 de los
ataques suceden en este entorno), se trata de una actividad verdaderamente peligrosa, pues
redirecciona el traIico hacia el equipo deseado. Su implementacion es la siguiente:
- Se debe escuchar el traIico ARP.
- Al detectar una solicitud ARP, se espera la respuesta correspondiente.
- Se capturan ambas.
- Se modiIica el campo direccion MAC de la respuesta, colocando la direccion MAC de la
maquina que desea recibir el traIico IP, IalsiIicando la verdadera MAC de la respuesta.
- Se emite la respuesta ARP Ialsa y ya esta.
Que se logra con esto?.
Si se supone que la solicitud ARP la emitio el host A y la respuesta ARP la emitio el host B, el
resultado de estos mensajes es que el host A, al recibir la respuesta de B, almacena en su
memoria cache ARP la dupla IP(B) MAC(B). Si a continuacion de este dialogo, el host A
recibe otra respuesta ARP que le asocia la IP(B) con una nueva MAC, supongase MAC (X), el
host A, automaticamente sobreesacribira su memoria cache ARP con la nueva inIormacion
recibida: IP(B) MAC(X). A partir de este momento cada vez que emita inIormacion hacia
la direccion IP del host A, la direccion MAC que colocara sera la MAC(X), ante lo cual, el nivel
Etehernet del host A descartara esa inIormacion, la cual si sera procesada por el protocolo
Ethernet del host X, el cual por ser el intruso, sabra como procesarlo.

3.7. DNS (Domain Name System) (RFC 1706, 1591, 1034 y 1035):


a. TLD (genricos y geogrficos).
Este servicio es quien determina el Iormato de los nombres que se emplean en Internet y permite
su asociacion con la direccion IP correspondiente, queda establecido por la RFC 1591. Al nacer
Internet, se implemento este servicio de nombres, a traves de bases de datos de caracteristicas
planas, las cuales por el exponencial crecimiento de esta red, rapidamente obligo a estructurarse
como un sistema jerarquico de archivos, residente en los servidores de nombres de dominio
distribuidos en todo el mundo. El NIC (Network InIormation Center) lleva el registro mundial
de todas las direcciones IP, y a que nombre se corresponde.
Dentro de esta jerarquia de nombres, el primer nivel se denomina Top Level Domain (TLD) y
puede ser de dos Iormas, genericos que se caracterizan por tres o cuatro caracteres, ellos son:
com, mil, edu, net, gov, org y arpa o geograIicos que identiIica al Pais de dos caracteres, por
ejemplo ar, us, uk, br, etc, este responde a los codigos internacionales de dos caracteres
estandarizados por la norma ISO 3166 .
El 16 de noviembre del 2000 ICANN aprobo siete nuevos TLD genericos, los cuales ya estan
todos en Iuncionamiento y son:
- aero: Para industrias de transporte aereo (www.nic.aero).
- biz: Para empresas (www.nic.biz).
- coop: Para cooperativas (www.nic.coop).
- inIo: ProIesionales de inIormatica (www.nic.inIo).
- museum: Para museos (www.nic.museum).
- name: Para registrar nombres individuales (www.nic.name).
- pro: Para proIesionales.
Todos ellos menos .pro ya se encuentran operacionales y comenzando a recibir registros.
La jerarquia se establece de derecha a izquierda, separada por puntos, avanzando en este orden
de lo general a lo particular, llegando a identiIicar por ejemplo al usuario que pertenece al
departamento de una empresa comercial de un determinado Pais
(aperez.produccion.perezsa.com.ar), se estila el empleo del caracter si bien su uso no es
obligatorio. Existen tambien niveles menores (regulados por la RFC 1480) que establecen
subdominios como pueden ser localidades, colegios, librerias, agencias Iederales, etc.
Dentro de este sistema es que cuando se desea conectar con un determinado ETD, supongamos
una Web, es probable que se conozca su nombre DNS pero casi seguro que no su direccion IP.
En estos casos es que entra en juego el Sistema DNS, en el cual el primer Servidor DNS al cual
el ETD se encuentra conectado, podra conocer o no la direccion IP a la que se desea llegar, si la
conoce, directamente la asocia por medio del sistema llamado 'Solucionador de nombres, caso
contrario elevara su solicitud en Iorma jerarquica al servidor de nombres de dominio
inmediatamente superior a este, el cual procedera en Iorma analoga, hasta llegar al que posea
esta inIormacion. El conjunto de nombres administrados por un servidor se llama ZONA, y por
cada una de ellas existe un servidor primario y uno secundario (El cual resulta evidente al
conIigurar un ETD para ingresar a Internet, pues obligatoriamente el Internet Service Provider al
cual se llama debera haberlos notiIicado para conIigurar el ETD correspondiente).
Acorde a la solicitud del cliente, un servidor DNS opera en Iorma recursiva o iterativa
(deIinidas a traves de un Flag en la solicitud cliente), La primera de ellas se produce cuando un
servidor no conoce la direccion IP solicitada, entonces envia la misma a su Root, el cual operara
de la misma Iorma hasta resolver la solicitud. Una solicitud Iterativa, es aquella en la cual ante

la ausencia de respuesta, el servidor devuelve la misma al cliente pudiendo indicarle a que otro
servidor recurrir o no, y es el cliente el responsable de ir iterando este pedido hasta encontrar
solucion.

b. Zonas:
Cada servidor de nombres tiene autoridad para cero o mas zonas. Hay tres tipos de servidor de
nombres:
primario
Un servidor de nombres primario carga de disco la inIormacion de una zona, y tiene
autoridad sobre ella.
secundario
Un servidor de nombres secundario tiene autoridad sobre una zona, pero obtiene la
inIormacion de esa zona de un servidor primario utilizando un proceso llamado transferencia
de :ona. Para permanecer sincronizado, los servidores de nombres secundarios consultan a
los primarios regularmente (tipicamente cada tres horas) y re ejecutan la transIerencia de
zona si el primario ha sido actualizado. Un servidor de nombres puede operar como primario
o secundario para multiples dominios, o como primario para unos y secundario para otros.
Un servidor primario o secundario realiza todas las Iunciones de un servidor cache.
cache
Un servidor de nombres que no tiene autoridad para ninguna zona se denomina servidor
cache. Obtiene todos sus datos de servidores primarios o secundarios. Requiere al menos un
registro NS para apuntar a un servidor del que pueda obtener la inIormacion inicialmente.

c. Formato de su Header:
El Iormato de un mensaje DNS es el siguiente:
16 bit 16 bit
IdentiIicacion Parametros
Numero de Solicitud Numero de respuesta
Numero de autoridad Numero adicional
Seccion Solicitud
Seccion respuesta
Seccion autoridad
Seccion de inIormacion adicional

- IdentiIicacion: IdentiIica al mensaje, se emplea para llevar la correspondencia entre
solicitudes y respuestas.
- Parametros:
* bit 1 (Q): Valor 0 solicitud, valor 1 respuesta.
* bit 1 a 4 (OpCode) Tipo de consulta: Valor 0 estandar, valor 1 Inversa, valor 2
solicitud de estado de servidor, (existen valor 3 y 4 en desuso).
* bit 5 (A): Seteado si la solicitud es autoritativa (Flag de Autoritativo).
* bit 6 (T): Seteado si el mensaje es truncado, es mas largo de lo que permite el canal.
* bit 7 (R): Seteado si se requiere recursion (Flag de recursividad).

* bit 8 (V): Seteado si la recursion esta disponible el servidor soporta recursion.
* bit 9 a 11 (B): Reservados para uso Iuturo, su valor debe ser cero.
* bit 12 a 15 (Rcode): (Tipo de respuesta) valor 0 sin error, valor 1 Error de Iormato en
solicitud, valor 2 Ialla en servidor, valor 3 nombre inexistente, valor 4 tipo de
consulta no soportada, 5 consulta rechazada.
- Numero de...: Lleva la cuenta del numero de mensajes que se cursan en las secciones que
le siguen en el Iormato.
- Seccion solicitud: contiene las consultas deseadas, consta de tres sub-campos: Nombre de
Dominio (longitud variable), Tipo de consulta (Host, mail, etc) y Clase de consulta
(permite deIinir otros objetos no estandar en Internet).
- Seccion respuesta, autoridad e inIormacion adicional: consisten en un conjunto de
registros que describen nombres y sus mapeos correspondientes.

d. Conexiones UDP y TCP:
Los mensajes DNS se transmiten sobre UDP o sobre TCP, en ambos sobre el puerto 53, y la
mecanica a seguir es la siguiente:
Los mensajes transportados por UDP se restringen a 512 bytes. En el caso de TCP el
mensaje va precedido de un campo de 2 bytes que indica la longitud total de la trama.
Un "resolver" del DNS o un servidor que envia una consulta que no supone una
transIerencia de zona debe enviar una consulta UDP primero. Si la seccion "answer" de la
respuesta esta truncada y el solicitante soporta TCP, deberia intentarlo de nuevo usando
TCP. Se preIiere UDP a TCP para las consultas porque UDP tiene un Iactor de carga mucho
menor, y su uso es esencial para un servidor Iuertemente cargado. El truncamiento de
mensajes no suele ser un problema dados los contenidos actuales de la base de datos del
DNS, ya que tipicamente se pueden enviar en un datagrama 15 registros, pero esto podria
cambiar a medida que se aaden nuevos tipos de registro al DNS.
TCP debe usarse para actividades de transIerencia de zonas debido a que el limite de 512
bytes de UDP siempre sera inadecuado para una transIerencia de zona.
Los servidores de nombres deben soportar ambos tipos de transporte.

e. Inundacin recursiva e iterativa:
La metodologia de esta debilidad es la de aprovechar la potencia que tiene este protocolo para
obtener inIormacion de algun nombre, para generar mayor cantidad de taIico en la red. Si se
alcanzan volumenes importantes, se habla de inundacion, pues puede llegar a dejar Iuera de
servicio a una red o servidor, ocupandose unicamente de esta actividad. Todo aquel que haya
desarrollado programas que implementen tecnicas recursivas sabe bien la potencia que estas
poseen (y seguramente los desbordamientos de memoria que sin lugar a dudas alguna vez le
ocasiono por error). En el caso de la iteracion, el problema es similar, pues se plantean casos en
los cuales por Ialta de resolucion se produce la "Iteracion eterna", es decir que nunca dejara de
soicitar un determinado nombre.

f. Vulnerabilidades de DNS.
Las vulnerabilidade sde este protocolo, pueden clasiIicarse en cuatro grandes Iamilias:


- UDP: Entre los servidores se transIieren grandes volumenes de inIroamcion a traves del
puerto UDP 53, el cual por ser no orientado a la conexion lo hace especialmente diIicil de
controlar y Iiltrar, aprovechandose esta debilidad.
- Obtencion de InIromacion: Los servidores DNS almacenan inIormacion importante, la
cual es muy buscada y Iacilmente obtenible por un intruso.
- Texto plano: Toda la inIromacion viaja en texto plano.
- Falta de autenticacion: El protocolo no oIrece ninguna tecnica de autenticacion.
Las siguientes son algunas de lar RFC reIeridas a DNS:
RFC 1032 - Guia de administrador de DNS
RFC 1033 - Guia de las operaciones de administrador de DNS
RFC 1034 - Nombres de dominio - Conceptos y servicios
RFC 1035 - Nombres de dominio - Implementacion y especiIicacion
RFC 1101 - CodiIicacion DNS de nombres de red y de otros tipos
RFC 1183 - Nuevas deIiniciones del DNS RR
RFC 1706 - Registros de recursos DNS NSAP

3.8. ICMP (Internet Control Messaging Protocol) (RFC: 792).
Este protocolo es quizas uno de los mas importantes de esta pila pues es el que se encarga de la
supervision y control de la red. Un datagrama viaja entre router a traves de la red hasta alcanzar su
destino, si ocurre algun error o para controlar esta travesia es que se generan estos mensajes. Este
sistema de reportes, es tratado por la red como cualquier otro datagrama (Nivel 3), pero el SoItware
de la capa 3 los interpreta de manera distinta. ICMP no especiIica las acciones a tomar, solamente
sugiere la misma.
Todas las cabeceras de ICMP comienzan con tres campos:
TIPO: (8), especiIica el mensaje ICMP.
CODIGO: (8), Brinda un poco mas de inIormacion sobre el error.
CHECKSUM (16), CRC 16.
Los campos que continuan a estos tres, varian acorde al tipo de error, pero en la mayoria de ellos se
encuentra incluido el encabezado del datagrama que genero el mensaje ICMP y tambien los 64
primeros octetos de este para dejar univocamente establecido la identiIicacion del error.
El estudio del Iuncionamiento del protocolo ICMP se puede entender basicamente desarrollando el
signiIicado del campo TIPO, el cual representa los distintos tipos de mensajes.

a. Tipos y cdigos de los mensajes ICMP:
0 y 8: Eco de solicitud y de respuesta: No es ni mas ni menos que el comando PING, que
genera una solicitud y una respuesta (conIigurable), para determinar la continuidad del
recorrido de un datagrama a lo largo de una red, su cantidad de saltos y el tiempo demorado.
3: Destino no alcanzable: Se genera cuando un datagrama no encuentra la direccion IP
destino. Tambien ocurre cuando el bit de no Iragmentar de la cabecera IP esta puesto en 1, y
la red destino no soporta bloques del tamao de ese datagrama, por lo cual no podra ser

entregado a esa red, causando la no llegada a destino. Dentro de este tipo es interesante tener
en cuenta el campo Codigo, pues brinda inIormacion adicional sobre las causas por las cuales
no se llega a destino, en particular si lo que se desea es obtener inIormacion sobre ese extremo
(Extremadamente usado para ataques a redes). Los valores que toma son:
- 0: Red inalcanzable.
- 1: Host inalcanzable.
- 2: Protocolo inalcanzable.
- 3: Puerto inalcanzable.
- 4: Fragmentacion requerida y bit de no Iragmentar puesto a 1 en el datagrama origen.
- 5: Falla en la ruta.
- 6: Red desconocida.
- 7: Host desconocido.
- 8: Host origen aislado.
- 9: Acceso a la red administrativamente prohibido.
- 10: Acceso al Host administrativamente prohibido.
- 11: Red inalcanzable por tipo de servicio.
- 12: Host inalcanzable por tipo de servicio.
4: Fuente agotada: Sirve para regular el Ilujo de inIormacion. Implica un buIIer lleno, causa
por la cual seria conveniente que el Host transmisor dejara de hacerlo hasta que deje de recibir
estos mensajes.
11: Tiempo de vida excedido: El campo TTL llego a 0.
5: Se requiere redireccionamiento: Existe una ruta mejor.
12: Problemas con el parametro: Error semantico o sintactico en el encabezamiento IP.
13 y 14: Solicitud y respuesta de marcador de tiempo: Permite la sincronizacion de clock
entre nodos, a traves de la hora GMT (Greenwich Mean Time).
15 y 16: Solicitud y repuesta de inIormacion: Permite obtener inIormacion de un nodo. Este
Iue originariamente pensado para los protocolos BOOTP y RARP.
17 y 18: Solicitud y respuesta de mascara de direccion: Permite determinar las mascaras de
las redes con que esta conectada un nodo. Se emplea para el ruteo hacia esas redes.

3.9. IGMP ( Internet Group Messaging Protocol) (RFC 1112).
Este protocolo es muy similar al anterior, pero esta pensado para mensajes entre grupos de host
empleando tambien los datagramas IP para transportar su inIormacion.

a. Multicast IP sobre Ethernet:

Los primeros cuatro bit de una direccion IP si se encuentran como 1110 identiIican una direccion
Tipo D o Direccion de multicast, los restantes 28 bit identiIicaran a que grupo se reIiere, dentro

de este esquema se deberia comenzar con 224.0.0.0 la cual no se emplea por ser reservada. La
siguiente es 224.0.0.1 que deIine a todos los grupos de host y router que participan en multicast.
Una direccion multicast, se debe aclarar que jamas puede deIinir una direccion origen, siempre
se reIerira a una destino.
Dentro de un esquema Ethernet, para que una direccion de multicast de nivel IP pueda ser
entregado a los equipos deseados, es imprescindible que el nivel 2 sepa identiIicarlos para que de
alguna manera no los descarte en ese nivel. Para que esto suceda, una solucion podria ser un
Broadcast de nivel 2, ante lo cual todas los Host de esa LAN lo reconocerian como propio, lo
desencapsularian y entregarian el datagrama al nivel 3 (IP). Esta opcion desde ya desperdicia
bastante el esquema de direccionamiento de Ethernet, pues lo ideal seria que solo sea tenido en
cuenta por los Host que integran el grupo de multicast de nivel IP. Para implementar este
procedimiento Ethernet ubica los ultimos tres octetos de la direccion IP en los mismos ultimos
tres de la direccion NIC o MAC de este nivel en una direccion grupal especiIica que es 01-00-
5E-00-00-00.
Ej: Si el multicast IP Iuera 224.0.0.1 la direccion Ethernet es 01-00-5E-00-00-01
Los Host que participan de un esquema de multicast IP, pueden desempear tres niveles
diIerentes:
- Nivel 0: El Host no puede recibir ni enviar IP Multicast.
- Nivel 1: El Host no puede recibir pero puede enviar IP Multicast.
- Nivel 2: El Host puede recibir y enviar IP Multicast.

b. Fases de IGMP:
IGMP posee dos Iases:
- Fase 1: Cuando un Host se incorpora a un grupo de multicast enviando un mensaje a todos
los Host del Grupo, anunciandose como miembro. Los router locales reciben este
mensaje y lo propagan al resto de los miembros.
- Fase 2: Como los grupos son dinamicos, los router locales periodicamente sondean (Poll)
los host para mantener el estado de los grupos.

c. Formato del mensaje IGMP:
4 4 8 16
Version Tipo Reservado CRC
Direcciones de Grupo

- Version: La version actual es la 1.
- Tipo: Posee dos valores, Consulta de un router (1), y respuesta enviada por un host (2).
- Reservado: Debe estar puesto a cero.
- CRC: Control de error de los 8 octetos.
- Grupo de direcciones: Reporte de los miembros de un grupo multicast. Si es una consulta
debe ir puesto a cero.

Existe un protocolo para transmitir inIormacion de ruteo entre grupos multicast que emplea el
algoritmo de vector distancia y se llama DVMRP (Distance Vector Multicast Routing Protocol).
Empleos de multicast.


3.10. Telnet (Terminal remota)(RFC 854, 855 y 857):

a. Conceptos:
Este protocolo es el que hace posible el acceso a terminales remotas, operando las mismas como
si Iueran locales. Los comandos Telnet los usa el protocolo, no los usuarios debido a que el
papel de Telnet es conectar al usuario, y que este se comunique en Iorma directa. Estos
comandos se envian en un paquete llamado command que contiene 2 o 3 octetos, y son los que
establecen la conexion. Una vez realizada la misma, habitualmente se solicitara un nombre de
usuario y una contrasea, pues se esta disponiendo el uso de los recursos de ese equipo. Es muy
comun su empleo para consultas BBS, a terminales en Internet y tambien para la administracion
remota de dispositivos de hardware como suelen ser Hub, Switch, Router, etc.
TELNET es un protocolo basado en tres ideas:
El concepto de NJT(Network Jirtual Terminal) (NJT). Una NVT es un dispositivo
imaginario que posee una estructura basica comun a una amplia gama de terminales reales.
Cada host mapea las caracteristicas de su propia terminal sobre las de su correspondiente
NVT, y asume todos los demas hosts haran lo mismo.
Una perspectiva simetrica de las terminales y los procesos.
Negociacion de las opciones de la terminal. El protocolo TELNET usa el principio de
opciones negociadas, ya que muchos host pueden desear suministrar servicios adicionales,
mas alla de los disponibles en la NVT. Se pueden negociar diversas opciones. El cliente y el
servidor utilizan una serie de convenciones para establecer las caracteristicas operacionales
de su conexion TELNET a traves de los mecanismos "DO, DON'T, WILL, WON'T"("hazlo,
no lo hagas, lo haras, no lo haras")

b. Negociacin:
Como se menciono con anterioridad, este protocolo trabaja sobre TCP, es decir que primero se
establece una sesion TCP y luego la conexion TELNET. Una vez realizada la misma, el cliente
entra en una Iase de negociacion dinamica que determina las opciones de cada lado de la
conexion, que justamente por ser dinamicas es que en cualquier momento pueden ser
modiIicadas. Esta negociacion se lleva a cabo por un conjunto de comandos TELNET, los
cuales son precedidos por un caracter interprete de comando (IAC) que es un octeto compuesto
por todos unos (FF hex) y luego sigue el codigo de comando, y en el caso que este posea opcion
continuara un tercer octeto de opcion negociada:

IAC Command Code Option Negotiated

c. Comandos y cdigos:

A continuacion se incluye la lista de codigos de comandos:

Comando Dec Hex Descripcin
End subNeg 240 FO End oI option subnegotiation command
No Operation 241 F1 No operation command

Data Mark 242 F2 End oI urgent data stream.
Break 243 F3 Operator pressed the Break key or the Attention key.
Int process 244 F4 Interrupt current process
Abort output 245 F5 Cancel output Irom current process.
You there? 246 F6 Request acknowledgment
Erase char 247 F7 Request that operator erase the previous character.
Erase line 248 F8 Request that operator erase the previous line.
Go ahead! 249 F9 End oI input Ior halI-duplex connections.
SubNegotiate 250 FA Begin option subnegotiation
Will Use 251 FB Agreement to use the speciIied option
Won`t Use 252 FC Reject the proposed option.
Start use 253 FD Request to start using speciIied option.
Stop Use 254 FE Demand to stop using speciIied option
IAC 255 FF Interpret as command.

En el caso que los comandos posean opciones negociables, las mismas son identiIicadas por una
Option ID, la cual sigue inmediatamente despues del comando. Las Option ID son las que se
detallan a continuacion:

Dec Hex Codigo
de opcion
Descripcion
0 0 Binary Xmit Allows transmission oI binary data.
1 1 Echo Data Causes server to echo back all keystrokes.
2 2 Reconnect Reconnects to another TELNET host.
3 3 Suppress GA Disables Go Ahead! command.
4 4 Message Sz Conveys approximate message size.
5 5 Opt Status Lists status oI options.
6 6 Timing Mark Marks a data stream position Ior reIerence.
7 7 R/C XmtEcho Allows remote control oI terminal printers.
8 8 Line Width Sets output line width.
9 9 Page Length Sets page length in lines.
10 A CR Use Determines handling oI carriage returns.
11 B Horiz Tabs Sets horizontal tabs.
12 C Hor Tab Use Determines handling oI horizontal tabs.
13 D FF Use Determines handling oI Iorm Ieeds.
14 E Vert Tabs Sets vertical tabs.
15 F Ver Tab Use Determines handling oI vertical tabs.
16 10 LI Use Determines handling oI line Ieeds.
17 11 Ext ASCII DeIines extended ASCII characters.
1 12 Logout Allows Ior Iorced log-oII.
19 13 Byte Macro DeIines byte macros.
20 14 Data Term Allows subcommands Ior Data Entry to be sent.
21 15 SUPDUP Allows use oI SUPDUP display protocol.
22 16 SUPDUP Outp Allows sending oI SUPDUP output.
23 17 Send Locate Allows terminal location to be sent.
24 18 Term Type Allows exchange oI terminal type inIormation.
25 19 End Record Allows use oI the End oI record code (0xEF).
26 1A TACACS ID User ID exchange used to avoid more than 1 log-in.
27 1B Output Mark Allows banner markings to be sent on output.
2 1C Term Loc# A numeric ID used to identiIy terminals.
29 1D 3270 Regime Allows emulation oI 3270 Iamily terminals.
30 1E X.3 PAD Allows use oI X.3 protocol emulation.
31 1F Window Size Conveys window size Ior emulation screen.
32 20 Term Speed Conveys baud rate inIormation.
33 21 Remote Flow Provides Ilow control (XON, XOFF).
34 22 Linemode Provides linemode bulk character transactions.
255 FF Extended options list Extended options list.


d. Vulnerabilidades:

Si bien posee otras de menor magnitud, la que jamas se debe olvidar es que absolutamente todo
bajo este protocolo va como Texto Plano, es decir, que se lee con total libertad.

3.11. FTP (File Transfer Protocol) (RFC 959).
Este protocolo permite la transIerencia remota de archivos sin establecer una sesion Telnet.

a. Establecimiento de la conexin y empleo de puerto de comando y puerto de datos.:
Una caracteristica particular de su Iuncionamiento es que emplea dos puertos (dos canales TCP),
el puerto 20 por medio del cual transIiere datos, llamado Data TransIer Process (DTP), y el
puerto 21 por medio del cual transmite las instrucciones de comando llamado Protocol
Interpreter (PI). Al igual que telnet, los comandos los usa el protocolo y no el usuario; estos
comandos son secuencias en ASCII de cuatro caracteres (QUIT, PASS, PORT, DELE, LIST,
ABORT, etc). Las conexiones FTP se inician de manera similar a Telnet con el nombre o
direccion del Host destino (Ej: Itp 205.29.24.11), luego se debe registrar como usuario valido (en
algunos se suele emplear la cuenta anonymous o guest) y generalmente como cortesia se emplea
como contrasea la cuenta de correo electronico, para permitirle al administrador llevar un
registro de accesos. Luego se deIine un directorio de inicio, un modo de transIerencia de datos
(ASCII o binario), se inicia la transIerencia y por ultimo se detiene.
Las tramas de control FTP, son intercambios TELNET y contienen los comandos y opciones de
negociacion mencionadas en el punto anterior, sin embargo la mayoria de los mismos son
simples textos en ASCII y pueden y pueden ser clasiIicados en comandos y mensajes FTP, los
cuales se detallan a continuacion:

b. Comandos:
Comando Descripcin
ABOR Abort data connection process.
ACCT account~ Account Ior system privileges.
ALLO bytes~ Allocate bytes Ior Iile storage on server.
APPE Iilename~ Append Iile to Iile oI same name on server.
CDUP dir path~ Change to parent directory on server.
CWD dir path~ Change working directory on server.
DELE Iilename~ Delete speciIied Iile on server.
HELP command~ Return inIormation on speciIied command.
LIST name~ List inIormation iI name is a Iile or list Iiles iI name is a
directory.
MODE mode~ TransIer mode (Sstream, Bblock, Ccompressed).
MKD directory~ Create speciIied directory on server.
NLST directory~ List contents oI speciIied directory.
NOOP Cause no action other than acknowledgement Irom server.
PASS password~ Password Ior system log-in.
PASV Request server wait Ior data connection.
PORT address~ IP address and two-byte system port ID.
PWD Display current working directory.
QUIT Log oII Irom the FTP server.
REIN Reinitialize connection to log-in status.
REST oIIset~ Restart Iile transIer Irom given oIIset.

RETR Iilename~ Retrieve (copy) Iile Irom server.
RMD directory~ Remove speciIied directory on server.
RNFR old path~ Rename Irom old path.
RNTO new path~ Rename to new path.
SITE params~ Site speciIic parameters provided by server.
SMNT pathname~ Mount the speciIied Iile structure.
STAT directory~ Return inIormation on current process or directory.
STOR Iilename~ Store (copy) Iile to server.
STOU Iilename~ Store Iile to server name.
STRU type~ Data structure (FIile, Rrecord, Ppage).
SYST Return operating system used by server.
TYPE data type~ Data type (AASCII, EEBCDIC, Ibinary).
USER username~ User name Ior system log-in.

c. Mensajes (Son las respuestas a los comandos):

Codigo
Descripcion
110 Restart marker at MARK yyyymmmm (new Iile pointers).
120 Service ready in nnn minutes.
125 Data connection open, transIer starting.
150 Open connection.
200 OK.
202 Command not implemented.
211 (System status reply).
212 (Directory status reply).
213 (File status reply).
214 (Help message reply).
215 (System type reply).
220 Service ready.
221 Log oII network.
225 Data connection open.
226 Close data connection.
227 Enter passive mode (IP address, port ID).
230 Log on network.
250 File action completed.
257 Path name created.
331 Password required.
332 Account name required.
350 File action pending.
421 Service shutting down.
425 Cannot open data connection.
426 Connection closed.
450 File unavailable.
451 Local error encountered.
452 InsuIIicient disk space.
500 Invalid command.
501 Bad parameter.
503 Bad command sequence.
504 Parameter invalid Ior command.
530 Not logged onto network.
532 Need account Ior storing Iiles.
550 File unavailable.
551 Page type unknown.
552 Storage allocation exceeded.
553 File name not allowed.

d. T_FTP:


Existe un protocolo de transIerencia de archivos diseado para operar en modo No Orientado a
la Conexion que es el TFTP (Trivial) (RFC: 783, 1350), el cual diIiere del FTP en que no se
registra en la maquina remota y que opera sobre UDP en lugar de TCP. Se deIine en el puerto
numero 69, y es comun su empleo en ETD que no poseen disco rigido para cargar aplicaciones o
programas Iuente. Posee un conjunto de comandos y parametros que se detallan a continuacion:

Comando Descripcin
Read Request Request to read a Iile.
Write Request Request to write to a Iile.
File Data TransIer oI Iile data.
Data Acknowledge Acknowledgement oI Iile data.
Error Error indication

Parmetro Descripcin
Filename The name oI the Iile, expressed in quotes, where the
protocol is to perIorm the read or write operation.
Mode
Datamode
The Iormat oI the Iile data that the protocol is to
transIer.

e. Vulnerabilidades:
FTP, es uno de los primeros protocolos de la Iamilia y por esta razon, nace en una epoca en la
cual la seguridad no era un problema. Este origen lo hace particularmente vulnerable.
Toda la comunicacion, al igual que Telnet, viaja en texto plano, desde la cuenta de usuario, la
contrasea, hasta los comandos y los datos.
La mejor y mas practica alternativa en la actualidad es su empleo por medio de SSL/TLS, como
se vera mas adelante.
Como medidas a tomar en el servidor, siempre se debe:
- Revisar permanentemente la conIiguracion del servidor y de ser posible, emplear soItware
de veriIicacion de archivos (tipo Tripware).
- No colocar contraseas encriptadas en el archivo etc/passw en el area Itp anonimo.
- Prestar especial atencion a la conIiguracion anonimo.
- Actualizar permanentemente el servidor.
- Nunca colocar archivos del sistema en el directorio ~Itp/etc.
- Que nunca cincidan los nombres de cuentas del directorio ~/Itp/etc/passwd con el
/etc/passwd.
- No activar TFTP si no es estrictamente necesario.

3.12. SMTP (Simple Mail Transfer Protocol) (RFC: 821, 822):

a. Funcionamiento:
Es el metodo deIinido por Internet para transIerencia de correo electronico. Emplea el puerto
TCP 25. Trabaja por medio del empleo de colas o spooler donde va almacenando los mensajes
recibidos en los servidores hasta que un usuario se conecte y transIiera su correspondencia, si
esto no sucede en un determinado tiempo (Programable), los mensajes son descartados o

devueltos a su origen. Debe quedar perIectamente claro que su operatoria no es en tiempo real,
sino que dependera de la voluntad de sus corresponsales. Una caracteristica particular es que
todo el texto se transIiere en caracteres ASCII de 7 bit. Su conexion se produce por medio de
tramas de comando y respuesta que incluyen instrucciones como mail, RCPT, OK, Texto, etc.
La RFC 821 especiIica el protocolo empleado para la transIerencia de correo, y la RFC 822
describe la sintaxis que deben seguir las cabeceras y su correspondiente interpretacion, otra RFC
que es conveniente tener en cuenta es la 974 que es la que deIine el estandar a seguir para el
encaminamiento de correo a traves de DNS.

b. Texto plano y extensiones:
Como se menciono, el protocolo SMTP trabaja con texto plano (ASCII de 7 bit), lo cual en la
actualidad no es suIiciente para las aplicaciones que requieren imagenes, caracteres especiales,
Iicheros ejecutables, etc. Para este proposito es que se disearon las RFC 1521 y 1522 que
deIinen MIME (Multipropose Internet Mail Extension), el cual transIorma cadenas de 8 bit en
grupos de siete que son los que viajaran por el canal de comunicaciones, y realizara el proceso
inverso del lado receptor.

c. Mensajes (cabecera y contenido):
Cada mensaje tiene:
Una cabecera (o sobre) con estructura RFC 822. La cabecera termina con una linea nula
(una linea con solo la secuencia CRLF~).
Contenido: Todo lo que hay tras la linea nula es el cuerpo del mensaje.
La cabecera es una lista de lineas de la Iorma:
field-name. field-value
Algunos campos habituales son:
To. Receptores primarios del mensaje.
Cc. Receptores Secundario("carbon-copy") del mensaje.
From. Identidad del emisor.
replv-to. El buzon al que se han de enviar las repuestas. Este campo lo aade el
emisor.
return-path. Direccion y ruta hasta el emisor. Lo aade el sistema de transporte
Iinal que entrega el correo.
Subfect. Resumen del mensaje. Suele proporcionarlo el usuario.

d. Comandos y cdigos:
Todos los comandos, replicas o datos intercambiados son lineas de texto, delimitadas por un
CRLF~. Todas las replicas tienen un codigo numerico el comienzo de la linea. La secuencia
de envio y recepcion de mensajes es la siguiente:


1) El emisor SMTP establece una conexion TCP con el SMTP de destino y espera a que el
servidor envie un mensaje "220 Service readv" o "421 Service not available" cuando el
destinatario es temporalmente incapaz de responder.
2) Se envia un HELO (abreviatura de "hello"), con el que el receptor se identiIicara
devolviendo su nombre de dominio. El SMTP emisor puede usarlo para veriIicar si
contacto con el SMTP de destino correcto.
Si el emisor SMTP soporta las extensiones de SMTP deIinidas en el RFC 1651, puede
sustituir el comando HELO por EHLO. Un receptor SMTP que no soporte las extensiones
respondera con un mensaje "500 Svntax error, command unrecogni:ed". El emisor SMTP
deberia intentarlo de nuevo con HELO, o si no puede retransmitir el mensaje sin
extensiones, enviar un mensaje QUIT.
Si un receptor SMTP soporta las extensiones de servicio, responde con un mensaje multi-
linea 250 OK que incluye una lista de las extensiones de servicio que soporta.
3) El emisor inicia ahora una transaccion enviando el comando MAIL al servidor. Este
comando contiene la ruta de vuelta al emisor que se puede emplear para inIormar de
errores. Notese que una ruta puede ser mas que el par bu:obnombre de dominio del host.
Ademas, puede contener una lista de los hosts de encaminamiento. Si se acepta, el receptor
replica con un "250 OK".
4) El segundo paso del intercambio real de correo consiste en darle al servidor SMTP el
destino del mensaje(puede haber mas de un receptor). Esto se hace enviando uno o mas
comandos RCPT TO:forward-path~. Cada uno de ellos recibira una respuesta "250 OK"
si el servidor conoce el destino, o un "550 No such user here" si no.
5) Cuando se envian todos los comandos rcpt, el emisor envia un comando DATA para
notiIicar al receptor que a continuacion se envian los contenidos del mensaje. El servidor
replica con "354 Start mail input, end with CRLF~.CRLF~". Notese que se trata de la
secuencia de terminacion que el emisor deberia usar para terminar los datos del mensaje.
6) El cliente envia los datos linea a linea, acabando con la linea CRLF~. CRLF~ que el
servidor reconoce con "250 OK" o el mensaje de error apropiado si cualquier cosa Iue mal.
7) Ahora hay varias acciones posibles:
El emisor no tiene mas mensajes que enviar; cerrara la conexion con un comando QUIT,
que sera respondido con "221 Service closing transmission channel".
El emisor no tiene mas mensajes que enviar, pero esta preparado para recibir mensajes(si
los hay) del otro extremo. Mandara el comando TURN. Los dos SMTPs intercambian
sus papelees y el emisor que era antes receptor puede enviar ahora mensajes empezando
por el paso 3 de arriba.
El emisor tiene otro mensaje que enviar, y simplemente vuelve al paso 3 para enviar un
nuevo MAIL.
Una Iacilidad que oIrece SMTP es la uniIicacion de mensajes con destino multiple, los cuales
son grabados como un solo mensaje en los servidores, los que se encargan de distribuirlos a los
n corresponsales. Se detallan a continuacion los comandos y respuestas:
Comando Descripcin
DATA Begins message composition.
EXPN string~ Returns names on the speciIied mail list.
HELO domain~ Returns identity oI mail server.
HELP command~ Returns inIormation on the speciIied command.
MAIL FROM host~ Initiates a mail session Irom host.

NOOP Causes no action, except acknowledgement Irom server.
QUIT Terminates the mail session.
RCPT TO user~ Designates who receives mail.
RSET Resets mail connection.
SAML FROM host~ Sends mail to user terminal and mailbox.
SEND FROM host~ Sends mail to user terminal.
SOML FROM host~ Sends mail to user terminal or mailbox.
TURN Switches role oI receiver and sender.
VRFY user~ VeriIies the identity oI a user.

Cdigo de
respuesta
Descripcin de la respuesta
211 (Response to system status or help request).
214 (Response to help request).
220 Mail service ready.
221 Mail service closing connection.
250 Mail transIer completed.
251 User not local, Iorward to path~.
354 Start mail message, end with CRLF~CRLF~.
421 Mail service unavailable.
450 Mailbox unavailable.
451 Local error in processing command.
452 InsuIIicient system storage.
500 Unknown command.
501 Bad parameter.
503 Bad command sequence.
504 Parameter not implemented.
550 Mailbox not Iound.
551 User not local, try path~.
552 Storage allocation exceeded.
553 Mailbox name not allowed.
554 Mail transaction Iailed.

e. Pasarelas SMTP:
Una pasarela SMTP es un host con dos conexiones a redes distintas. Las pasarelas SMTP se
pueden implementar de Iorma que conecten distintos tipos de redes. Se puede prohibir el
acceso a la pasarela a determinados nodos de la red, empleando la sentencia de conIiguracion
RESTRICT. Alternativamente, la seguridad se puede implementar con un Iichero de
autorizacion de accesos, que es una tabla en la que se especiIican de quien y a quien se puede
enviar correo por la pasarela.

f. Terminologa:
e Algo de terminologia reIerida al correo electronico:
Agente de usuario (UA, user agent): programa que se usa como interIaz de usuario para el
correo electronico (leer, componer, enviar, gestionar, etc.)
Agente de transIerencia de mensajes (MTA, message transIer agent): se encarga del
encaminamiento y almacenamiento de los mensajes de correo hasta su destino Iinal.
Protocolo de acceso al correo electronico: lo usa un UA para acceder a un MTA, y recoger
el correo para un usuario. Ejemplo: POP, IMAP.

Protocolo de envio de correo electronico: lo usa un MTA para enviar correo a otro MTA
(tambien puede usarlo un UA para enviarlo a un MTA). Ejemplo: SMTP.

3.13. POP (Post Office Protocol) (RFC:1082, 1725, 1734, 1939):
Este protocolo permite a un usuario conectarse a un sistema y entregar su correo usando su nombre
de usuario y contrasea (muy usado en UNIX) a traves del puerto TCP 110.
La metodologia a seguir para descargar correo es la explicada en SMTP, lo cual implica que cuando
un servidor recibe un mail, establece la sesion SMTP con este destino y entrega su mensaje, esto
exigiria que el destino Iinal se encuentre siempre encendido y disponga de los recursoso necesarios
para desempear la tarea de cliente y Servidor SMTP. Ninguna de las dos caracteristicas son
exigibles a un PC personal (Recursos y no apagado). Un metodo intermedio es descargar la Iuncion
de servidor SMTP de la estacion de trabajo del usuario Iinal, pero no la Iuncion de cliente. Es decir,
el usuario envia correo directamente desde la estacion, pero tiene un buzon en un servidor. El
usuario debe conectar con el servidor para recoger su correo.
El POP describe como un programa que se ejecuta en una estacion de trabajo Iinal puede recibir
correo almacenado en sistema servidor de correo. POP usa el termino "maildrop" para reIerirse a un
buzon gestionado por un servidor POP.
Existe una gran variedad de clientes de correo que emplean POP cuya ultima version es la 3 (RFC
1725). Cuando estos clientes emplean POP3, tienen la opcion de dejar sus mensajes a un servidor
y verlos remotamente (modo en linea), o transIerir sus mensajes a un sistema local y consultarlos
(modo fuera de linea). Cada uno tiene sus ventajas y desventajas, en el modo en linea,
independientemente de la ubicacion Iisica en la que se encuentre el usuario podra consultar su mail
pues este se encuentra almacenado en un servidor, se debe tener en cuenta que cada vez que se
conecte al servidor le seran transIerido la totalidad de los mensajes (si la conexion es lenta, puede
demorar mucho); desde el punto de vista del Administrador, permite centralizar los backup de toda
la inIormacion almacenada, pero tiene la desventaja que de no controlarse puede llenar Iacilmente
un disco rigido (inclusive este es un tipo de ataque de negacion de servicio). El modo Iuera de
linea permite organizar en carpetas locales la inIormacion historica acorde a la preIerencia del
cliente, y este al conectarse al servidor solamente bajara los mail nuevos, reduciendo el tiempo de
conexion.
POP - 3 no soporta el uso de carpetas globales o compartidas, como tampoco el uso de listas
globales de direcciones, por lo tanto no existe Iorma de ver la totalidad de las cuentas de una
organizacion automaticamente (Lo debe organizar manualmente el Administrador).
Una mejora que aparece a POP son las extensiones MIME, ya mencionadas (Multimedia Internet
Mail Extension), las cuales estan estandarizadas por las RFC: 2045 a 2049 y su tarea principal
es extender el contenido de los mensajes de correo para poder adjuntar datos de tipo genericos.
DeIine 5 tipos de cabeceras:
MIME-version: La actual es 1.0
Content-Description: Una descripcion en texto plano del objeto del cuerpo, suele ser de
utilidad cuando el objeto es no legible.
Content-Id: Un valor univoco especiIicando el contenido de esta parte del mensaje.
Content-TransIer-Encoding: Indica como codiIicar y decodiIicar los datos.
Content-Type: Indica con que aplicacion se trataran los datos


Tambien propone 8 tipos: Text, Image, Audio, Video, Application, Message, Model y Multipart.
y varios subtipos: Text: html, plain o richtext; Image: giI, jpeg; ...

3.14. IMAP 4 (Internet Message Access Protocol Versin 4) (RFC: 1203,1730 a 1733, 2060):
Se trata de la evolucion natural del POP 3, posee las mismas caracteristicas del anterior y agrega
algunas mas que permiten escalar el servicio de correo a entornos de grupo.
Aparte de los modos en linea y Iuera de linea, IMAP - 4 introduce un tercer modo que se llama
Desconexion. En POP - 3, el cliente al conectarse y autenticarse automaticamente comenzaba a
recibir la totalidad de los mail que se encontraban en el Servidor; en IMAP - 4 cuando un cliente
se conecta y autentica en un servidor, este consulta sus "banderas de estado" para todos los
mensajes existentes. Estas banderas permiten identiIicar a cada mensaje como: Leido, borrado o
respondido, por lo tanto, puede ser conIigurado para bajar unicamente los marcados como no
leidos, reduciendo sensiblemente el tiempo de conexion. Este modo Iacilita tambien cualquier
anomalia que puede surgir durante la conexion pues el servidor IMAP - 4 entrega al cliente slo
una copia de sus correos, y mantiene el original hasta la sincronizacion completa de su cache, por
lo tanto si se pierde una conexion durante una transIerencia, al producirse la proxima conexion
como primer medida se vera donde se aborto la previa par no reenviar todo, y en segundo lugar no
se perdera ningun mensaje hasta que se sincronice el cliente y el servidor
Introduce tambien el concepto de Jista Previa, con lo cual el cliente puede revisar los encabezados
de todos los mensajes y sobre estos decidir cuales leer o borrar antes de bajarlos pues por ejemplo
en conexiones dial-up es sumamente desagradable perder gran cantidad de tiempo en la recepcion
de avisos publicitarios Iorzados a ser recibidos por "no se sabe quien"
Introduce tambien el concepto de carpetas compartidas las cuales pueden ser consultadas por grupos
de usuarios, y tambien el de pizarrones de noticias (semejante al protocolo NNTP: Network News
TransIer Protocol), en los cuales los usuarios pueden "pinchar" sus carteles de novedades.
(POP-3, IMAP y MIME)

Vulnerabilidades del correo electrnico:
Las dos grandes vulnerabilidades que suIre el correo electronico son reIeridas a su privacidad y
su seguridad, dentro de ellas existen debilidades concretas que se tratan a continuacion:
La privacidad es Iacilmente vulnerable pues el correo viaja como texto plano, es decir, que si no
se emplea algun algoritmo criptograIico, cualquiera puede tener acceso al mismo. En este tema,
la mejor analogia es la del correo postal, en el cual a nadie se le ocurre enviar una carta sin el
sobre.
La seguridad es atacada con dos tecnicas puntuales: las bombas de correo (varias copias de un
mismo mail a un solo destino) y el Spam (Correo no autorizado).
Las herramientas con que se cuenta para deIenderse de estas vulnerabilidades son:
- S/MIME: Desarrollado por RSA el cual es una especiIicacion para obtener autenticacion
por medio de Iirmas digitales. Se lo considera uno de los mas seguros
- PGP: Pretty Good Privacy, el cual es un producto completo desarrollado por Phillip
Zimmerman que oIrece que dentro de sus muchas Iunciones oIrece tambien
autenticacion, no repudio y criptograIia siendo soportado por la mayoria de los clientes de
correo.

- PEM: Privacy Enhanced Mail, el cual es una norma para permitir la transIerencia de
correo seguro. Con cualidades similares a PGP, siendo el estandar mas reciente de los tres.

3.15. SNMP (Single Network Monitor Protocol).
Este es el protocolo que habilita las Iunciones que permiten administrar redes no uniIormes. Esta
regulado por la RFC 1155, 1156 y 1157, y basicamente separa dos grupos: Administradores y
Agentes. Los Administradores (NMS: Network Managment Station) son los responsables de la
administracion del dominio ejecutando un determinado SoItware de monitoreo. Los agentes tienen
a su vez un SoItware residente que responde a las solicitudes del administrador con la inIormacion
guardada en sus bases de datos locales (MIB: Managment InIormation Base). Estas consultas en
realidad pueden ejecutarse por dos metodos:
Poll (Sondeo): La estacion administradora sondea uno por uno a los agentes cada un determinado
periodo de tiempo, y estos van inIormando si apareciera alguna novedad en su MIB desde el
ultimo sondeo.
Interrupcion: Los Agentes al aparecer alguna novedad en su MIB, envian un mensaje
interrumpiendo los procesos del Administrador para notiIicar sus cambios.
Como puede deducirse cada uno de ellos tiene sus ventajas y desventajas; si una novedad apareciera
inmediatamente despues que un sondeo Iue realizado a un agente, el Administrador tomaria
conocimiento de este suceso recien en el proximo sondeo, lo cual por ejemplo en una red de Terapia
Intensiva de un Hospital no seria muy saludable. Por el contrario, si se produjera alguna anomalia
en el canal de comunicaciones en un sistema por interrupcion, el Administrador nunca volveria a
detectar novedades en un Agente que se encuentre sobre ese vinculo. Estos son algunos ejemplos,
pero en virtud de la cantidad de posibilidades que existen es que se suelen implementar estrategias
mixtas de monitoreo de red, que permitan superar estas contingencias.
Otro tema de especial interes en SNMP es la relacion costo / beneIicio de mantener la
Administracion absoluta de la red hasta los ultimos recursos, lo cual genera un gran volumen de
traIico en la misma. Se suelen establecer limites sobre el nivel de importancia de los agentes a
monitorear para reducir la carga que impone este protocolo.

a. Formato del encabezado:
Versin Comunidad PDU

- Version: Indica el numero de version, los valores admitidos son 1, 2 y 3.
- Comunidad: Este nombre indica el grupo al cual pertenece el mensaje y es empleado para
la autenticar al administrador antes que pueda ingresar al agente.
- PDU (Protocol Data Unit): Existen cinco tipos de PDU: GetRequest, GetNextRequest,
GetResponse, SetRequest y Trap.
La PDU tiene a su vez un Iormato que es el siguiente:

PDU Type Request ID Error
Status
Error
Index
Objeto 1
Valor 1
Objeto 2
Valor 2
..
..

PDU type: EspeciIica el tipo de PDU, sus valores son:
0 GetRequest.
1 GetNextRequest.
2 GetResponse.
3 SetRequest.

Request ID: Valor entero que controla la correspondencia entre agente y
administrador.
Error status: valor entero que indica operacion normal o cinco tipos de error:
0 noError.
1 tooBig: El tamao de la GetResponse PDU requerida, excede lo permitido.
2 noSuchName: El nombre del objeto solicitado no tiene correspondencia
con los nombres disponibles en la MIB.
3 badValue: La SetRequest contiene un tipo inconsistente, longitud o valor
para la variable.
4 readOnly: No deIinido en la RFC1157.
5 genErr: Otros errores, los cuales no estan explicitamente deIinidos.
Error index: IdentiIica la entrada en la lista que ocasiono el error.
Object/value: DeIine el objeto con su valor correspondiente.

Existe tambien otro Iormato de PDU, que es el de Trap PDU, el cual tiene los siguientes
campos:

PDU
Type
Enterprise Agent
Address
Gen
Trap
Spec
Trap
Time
Stamp
Objeto 1
Valor 1
Objeto 2
Valor 2
..
..

PDU Type: Valor 4.
Enterprise: IdentiIica al administrador de la 'empresa que deIinio la trap.
Agent Address: Direccion IP del agente.
Generic Trap Type: Campo que describe el evento que esta siendo reportado, los
siguientes siete valores estan deIiniIdos:
0 coldStart: La entidad ha sido reinicializada, indicando que la
conIiguracion pudo ser alterada.
1 warmStart: La entidad ha sido reinicializada, pero la conIiguracion no
Iue alterada.
2 linkDown: El enlace ha Iallado.
3 linkUp: El enlace ha conectado.
4 authenticationFailure: El agente ha recibido una autenticacion SNMP
indebida desde el administrador.
5 egpNeighborLoss: Un EGP vecino esta caido.
6 enterpriseSpeciIic: Un trap no generico ha ocurrido, el cual es
identiIicado por los campos SpeciIic Trap Type y Enterprise.

SpeciIic Trap Type: Empleado para identiIicar un Trap no generico.
Timestamp: Representa el tiempo transcurrido entre la ultima reinicializacion y la
generacion del presente trap.
Combinacion de la variable con su valor.

b. SNMP Versin 3:

En el mes de enero del ao 1998 IETF propone un conjunto de RFC desde la 2271 a la 2275 las
cuales deIinen un conjunto de medidas para implementar las tres grandes Ialencias que poseia el
protocolo SNMP, estas son:
- Autenticacion.
- Seguridad.

- Control de acceso.

Estos nuevos estandares propuestos son los que deIinen la nueva version de este protocolo
denominada version 3. El proposito es deIinir una arquitectura modular que de Ilexibilidad hacia
Iuturas expansiones.

Luego de un tiempo, en el mes de abril de 1999 aparecen ya como borrador estandar los mismos
conceptos con algunas mejoras, dejando obsoletos los anteriores. Estas son las recomendaciones
2571 a la 2575, las cuales sientan deIinitivamente el Iuncionamiento de SNMPv3. Estas son:

2571 An Architecture Ior Describing SNMP Management Frameworks. B. Wijnen, D.
Harrington, R. Presuhn. April 1999. (Format: TXT139260 bytes) (Obsoletes
RFC2271) (Status: DRAFT STANDARD)
2572 Message Processing and Dispatching Ior the Simple Network Management Protocol
(SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. April 1999. (Format:
TXT96035 bytes) (Obsoletes RFC2272) (Status: DRAFT STANDARD)
2573 SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999. (Format:
2574 User-based Security Model (USM) Ior version 3 oI the Simple Network Management
Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April 1999. (Format: TXT190755
bytes) (Obsoletes RFC2274) (Status: DRAFT STANDARD)
2575 View-based Access Control Model (VACM) Ior the Simple Network Management
Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. April 1999. (Format:
En estas nuevas RFC aparecen una serie de conceptos que son los que se deIinen a continuacion.

Entidad:

El concepto de entidad es una conjunto de modulos que interactuan entre si, cada entidad
implementa una porcion de SNMP y puede actuar como los tradicionales nodo AGENTE, nodo
GESTOR, o combinacion de ambos.

Cada entidad incluye un MOTOR SNMP, siendo este el encargado de implementar las Iunciones
de:
- Envio de mensajes.
- Recepcion de mensajes.
- Autenticacion.
- Encriptado y desencriptado de mensajes.
- Control de acceso a los objetos administrados.
Estas Iunciones son provistas como servicios a una o mas aplicaciones.

El conjunto de motor y aplicaciones son deIinidas como los modulos de esta entidad.


Gestor tradicional SNMP:

Un Gestor tradicional SNMP interactua con los agentes SNMP a traves del envio de comandos
(get,get next y set) y recepcion de respuestas. Este incluye 3 categorias de Aplicaciones:

- Aplicaciones Generadoras de Comandos: Monitorean y controlan la administracion de
datos de un agente remoto.
- Aplicacion Generadora de NotiIicaciones: Inicia mensajes asincronicos.
- Aplicacion Receptora de NotiIicaciones: Procesa mensajes entrantes asincronicos.
Estas tres aplicaciones hacen uso de los servicios del motor SNMP.

Este motor debe contener:
1) Un Despachador: Encargado de administrar el traIico. Para mensajes salientes, recibe
las PDU (Unidad de datos de Protocolo) de las aplicaciones, determina el tipo de
procesamiento requerido (Ej: SNMPv1, SNMPv2 o SNMPv3) y entrega estos datos al
modulo de procesamiento de mensajes correspondiente. Para mensajes entrantes, acepta
mensajes del nivel de transporte y lo deriva al modulo de procesamiento de mensajes
correspondiente. Consecuentemente al recibir los mensajes procesados desde el
modulo, los entregara hacia la aplicacion apropiada o hacia el nivel de transporte segun
corresponda.
2) Un Subsistema de Procesamiento de Mensajes: Es el responsable del armado y
desarmado de la PDU de este nivel. Recibe y entrega los mensajes del despachador. Si
es necesario luego de armar la PDU (mensaje saliente) o antes de desarmarla (mensaje
entrante), pasaria la misma al Subsistema de Seguridad

3) Un Subsistema de Seguridad: Es quien ejecuta las Iunciones de autenticacion y
encriptado. Recibe y entrega los mensajes al Subsistema de Procesamiento de
Mensajes. Este subsistema soporta uno o mas modelos distintos de seguridad llamado
User-Based Security Model (USM) y esta deIinido por la RFC- 2574.

Agente Tradicional SNMP:
El agente contiene tambien 3 tipos de aplicaciones:
- Aplicaciones Respondedoras de Comandos: Provee acceso a los datos administrados.
- Aplicacion Generadora de NotiIicaciones: Inicia mensajes asincronicos.
- Aplicacion Encaminadora Proxy: Encamina mensajes entre entidades.
El Agente tiene los mismos componentes que el Administrador e incluye uno mas denominado:
- Subsistema de Control de Acceso: Es el encargado de proveer servicios de autorizacion
para controlar el acceso a las MIBs.Un Agente soporta uno o mas modelos de Control de
Accesos diIerentes llamado View-Based Access Control Model (VACM) y se
encuentra deIinido por la RFC-2575.



Subsistema de procesamiento de mensajes:
Este modelo recibe PDU desde el despachador, tanto salientes como entrantes, las encapsula o
desencapsula y acorde a la existencia de mecanismos de seguridad la entrega o no al USM para el
tratamiento de los parametros de seguridad (agregado, criptograIiado o decriptograIiado) y
Iinalmente las devuelve al despachador para que este las entregue al nivel correspondiente.
Este modelo opera sobre los cinco primeros campos del encabezado SNMP, el cual se detalla a
continuacion:
Msg Version
Msg ID
Msg Max Size
Msg FLAGS
Msg Security Model
Modelo de
Procesamiento de
Mensajes
Msg Autoritative Engine ID
Msg Autoritative Engine Boot
Msg Autoritative Engine Time
Msg User Name
Msg Autentication Parameters

Msg Privacy Parameters
Modelo de
seguridad de
usuario
(USM)
Context Engine ID
A

u
t
e
n
t
i
c
a
c
i
E
n
Context Name
Espacio de PDU


PDU (Aplication)

Msg Jersion. Corresponde el Nro 3.
Msg ID. IdentiIicador entre las dos entidades para coordinar solicitudes y respuestas
Msg Max Si:e. Expresa el tamao maximo en octetos que soporta el emisor.
Msg FLAGS. Estan deIinidos los tres primeros bit y signiIican lo siguiente:
Bit 1 (bit de reporte): Si esta en 1 entonces el receptor debe especiIicar bajo que
condiciones este puede causar un reporte. Tambien es empleado en toda solicitud
Get o Set.
Bit 2 (Priv Flag): Indica que se emplea criptograIia.
Bit 3 (Aut Flag): Indica que se emplea autenticacion.
Msg Securitv Model. Indica que modelo de seguridad se emplea (1 SNMPv1, 2 SNMPv2, 3
SNMPv3).

Subsistema de seguridad:
El subsistema de seguridad ejecuta Iunciones de autenticacion y encriptado, para las mismas deIine
uno o mas distintos Modelos de seguridad de Usuario (USM). EspeciIicamente la RFC-2574
establece que este modelo protege contra lo siguiente:
ModiIicacion de InIormacion.
FalsiIicacion de entidad.
ModiIicacion de mensaje.
DiIusion de inIormacion.
Tambien aclara que no protege contra ataques de negacion de servicio ni analisis de traIico.
Este modelo se emplea para proveer autenticacion y privacidad, para esto deIine dos claves, una
clave privada (PrivKey) y otra clave de autenticacion (AutKey). El valor de estas claves no es
accesible via SNMP y se emplean de la siguiente Iorma:
Autenticacion:
Se deIinen dos alternativas para esta tarea, HMAC-MD5-96 y HMAC-SHA-96.

La mecanica de esta Iuncion es que a traves de una cadena de bit de entrada de cualquier
longitud Iinita, generara un unico resumen de salida de longitud Iija. Que en el caso de esta
norma es de 20 Byte para SHA o 16 Byte para MD5.

Esta Iuncion es llamada 'One Way' pues no es posible a traves del resumen de salida obtener
el texto de entrada, tambien resultara computacionalmente imposible obtener un valor de salida
igual a traves de otro valor de entrada, como asi tampoco desde un valor de salida ya calculado,
obtener otro valor de entrada diIerente al verdadero.

La aplicacion aqui propuesta toma los datos y la clave y produce un resumen:

- Resumen H (clave, datos).


En cualquiera de los dos casos, se toman como validos los primeros 96 bit, descartando el resto.

Esta especiIicacion soporta el protocolo HMAC |RFC-2104| con la opcion SHA1 (Hash
Message Autentication-Secure Hash Standard Version 1) |RFC-2404| y MD5 (Messge Digest
Verion 5) |RFC-2403|.

CriptograIia:

Para esta actividad USM emplea el algoritmo DES (Data encryptation Standard) |ANSI
X3.106| en el modo ciIrado encadenado de bloques (CBC). La clave privada (PrivKey) antes
mencionada de longitud 16 byte es empleada aqui dividiendola en dos, los primeros 8 Byte, es
decir 64 bit son empleados como clave para DES, el cual solo tendra en cuenta 56, dejando 8
para control de paridad. Los ultimos 8 Byte son empleados como Vector de Inicializacion (IV)
para comenzar con el ciIrado en cadena.

Esta tecnica CBC, se basa en tomar el primer bloque de texto plano, y realizar una operacion
XOR con un Vector de inicializacion y luego de esta operacion recien se pasara al ciIrado de
ese bloque. En el segundo bloque se realizara nuevamente la operacion XOR, pero esta vez
sera el texto plano de este bloque con el bloque ciIrado anteriormente, y luego se ciIrara. Esta
mecanica se ira realizando en los sucesivos bloques, es decir XOR con el bloque ciIrado
anterior y luego ciIrado.
El desciIrado se realiza en Iorma inversa.

- ciIrado E (clave, texto).
- D (clave, ciIrado) texto.

Campos del encabezado de USM:
Antes de tratar los campos de este modelo se debe tener en cuenta al concepto de autoritativo:
- Caso 1: Cuando un mensaje SNMP contiene datos que esperan una
respuesta (Get, GetNext, Get Bulk, Set o InIormes), entonces el receptor
de ese mensaje es Autoritativo.
- Caso 2: Cuando un mensaje SNMP contiene datos que no imponen
respuesta (Trap, Respuestas o Reportes), entonces el emisor de ese
mensaje es Autoritativo.
Acorde a la graIica anterior del encabezado SNMPv3, se puede apreciar que USM emplea los
seis campos siguientes al Modelo de Procesamiento de Mensajes. Estos campos se detallan a
continuacion:
Msg Autoritative Engine ID. IdentiIicador de la entidad Autoritativa.
Msg Autoritative Engine Boot. Este valor es un contador monotono creciente que
identiIica la cantidad de veces que la entidad autoritativa Iue inicializada o reinicializada
desde su conIiguracion inicial.
Msg Autoritative Engine Time. Este valor es un entero que describe el tiempo
transcurrido en segundos desde el momento en que la entidad autoritativa incremento el
Msg Autoritative Engine Boot (es decir el tiempo desde la ultima vez que inicio o
reinicio). Las entidades autoritativas llevan su tiempo exacto en segundos y las no
autoritativas llevaran por cada entidad autoritativa con la que se comuniquen una
apreciacion del mismo, que servira para compararlos en el momento oportuno (como se
vera a continuacion). Este valor son 32 bit, en el caso de no reinicializarse una entidad
se ira acumulando y al llegar al valor maximo volvera a cero (En realidad como es un

valor de 32 bit, 2
32
segundos son en el orden de 68 aos, por lo tanto el sistema deberia
ser extremadamente solido para no detenerse nunca en este lapso)
Msg User Name. Nombre del usuario de este mensaje.
Msg Authentication Parameters. Aqui es donde va el codigo de autenticacion es decir el
valor obtenido por HMAC. En el caso de no emplear autenticacion es nulo.
Msg Privacv Parameters. El valor aqui expuesto es el que se empleara para obtener el
Vector de Inicializaciin (VI) para el algoritmo DES. En el caso de no emplear
criptograIia es nulo.
La secuencia de pasos a seguir con estos campos para la transmision de un mensaje en este
modelo es:
1) Como primera actividad se criptograIian los datos en caso de implementar esta
Iuncion.
2) Si se realizo el paso a. entonces se coloca en el campo Msg Privacv Parameters
el valor correspondiente para generar el IV.
3) Si se emplea autenticacion, la totalidad del mensaje se ingresa para obtener el
resumen HMAC y su resultado es ubicado en el campo Msg Authentication
Parameters.
En el caso de la recepcion seria:
1) Realiza el calculo de HMAC.
2) Compara el valor calculado con el correspondiente al campo campo Msg
Authentication Parameters.
3) Si ambos valores son iguales, entonces toma el mensaje como autentico y no ha
sido alterado.
4) VeriIica si el mismo esta en un tiempo de ventana valido. Esta actividad se
realiza de la siguiente Iorma:
a) Toda entidad no autoritativa guarda tres parametros en Iorma local de cada
entidad autoritativa con la que se comunica, estos son:
- El valor mas reciente de Msg Autoritative Engine Boot recibido en la
ultima comunicacion.
- El valor de tiempo estimado que deberia tener la entidad autoritativa.
- El ultimo valor de tiempo recibido de la entidad autoritativa en el campo
Msg Autoritative Engine Time.
b) Al recibir un mensaje compara los campos del mensaje recibido con estos
parametros almacenados localmente.
c) Las condiciones para que un mensaje sea considerado no autentico son:
- DiIerencia de Msg Autoritative Engine Boot.
- DiIerencia en + 150 segundos entre el valor calculado de Msg
Autoritative Engine Time y el recibido en el mensaje.
d) Si un mensaje es considerado no autentico, una indicacion de error es enviada
al modulo respectivo.
5) Finalmente si esta criptograIiado, desciIra el mismo.

Localizacion de claves:
Una clave localizada es un secreto compartido entre un usuario y un motor SNMP autoritativo.
El problema del empleo de una sola clave por parte del usuario con todos los agentes es que si
se descubriera la misma, seria vulnerable todo el sistema. Si el caso Iuera lo contrario es decir
que se deseara emplear una clave distinta para cada agente, entonces el usuario deberia recordar
todas las contraseas lo cual en la practica no es viable.
Para dar solucion a estos problemas la RFC 2574 propone este proceso por el cual una clave
unica de usuario (o pueden ser dos: una para privacidad y otra para autenticacion) es convertida

a multiples claves unicas tambien, una para cada motor SNMP, este proceso es lo que se
denomina Localizacin de claves. Las caracteristicas Iundamentales que propone este
proceso son:
Cada agente SNMP tiene su propia clave unica para cada usuario autorizado a
administrarlo, por lo tanto si la clave de uno de ellos es comprometida, no lo seran las
del resto.
La clave de un usuario es diIerente en cada agente SSSNMP, por lo tanto si se
compromete la clave de un agente, no comprometera al resto ni a la clave del usuario.
La administracion de la red, puede realizarse en Iorma segura remotamente desde
cualquier punto de la red.
Subsistema de Control de Accesos:
Este subsistema se ejecuta en los agentes tradicionales, permitiendo determinar quien esta
autorizado a acceder a la MIB de los mismos. El unico modelo deIinido para esta actividad se
denomina Modelo de Control de Accesos basado en Jistas (VACM: View-Based Access Control
Model) y esta deIinido en la RFC-2575.
VACM tiene dos caracteristicas Iundamentales:
- Determina si un acceso a la MIB local esta permitido.
- Posee su propia MIB en la cual se deIinen las politicas de acceso y
habilita la conIiguracion remota.
Se deIinen cinco elementos que constituyen la VACM:
1) Grupos: Es un conjunto de cero o mas duplas Modelo de Seguridad, Nombre de
seguridad} que deIinen los Objetos que pueden ser administrados por ese Nombre.
2) Nivel de seguridad: DeIine que tareas seran permitidas (lectura, escritura o
notiIicacion) para cada grupo.
3) Contexto: Es un subconjunto de instancias de objetos en la MIB local. Permite agrupar
objetos con distintas politicas de acceso.
4) Vistas de la MIB: DeIine conjuntos especiIicos de objetos administrados, los cuales se
pueden agrupar en jerarquias de arboles y Iamilias de manera tal que se pueda, por
ejemplo, restringir su acceso a determinados grupos.
5) Politica de acceso: VACM permite a un motor SNMP ser conIigurado para asegurar un
conjunto de accesos correctos, los cuales dependen de los siguientes Iactores:
- Los distintos usuarios pueden tener distintos privilegios de acceso.
- El nivel de seguridad para una determinada solicitud.
- El modelo de seguridad empleado para procesar las solicitudes de mensajes.
- El contexto de la MIB.
- La instancia al objeto para el cual Iue solicitado el acceso.

3.16. DHCP Dynamic Host Configuration Protocol(RFC 1541, 1531, 1533 y 1534).

a. Evolucin de los protocolos dinmicos (ARP, BOOTP):
Este protocolo es una evolucion natural del BOOTP (BOOTstrap Protocol) que Iue la primera
implementacion de protocolos de inicio para maquinas que no poseen disco rigido, las cuales al
ser encendidas, deben primero hacerse presentes en la red y luego cargar el sistema operativo.
Para automatizar este proceso IETF desarrollo este nuevo protocolo conocido como DHCP.
Este ultimo introduce dos grandes mejoras respecto al anterior:
- Primera: Permite a una maquina obtener toda la inIormacion necesaria en un solo
mensaje.
- Segunda: Permite obtener una direccion IP rapida y dinamicamente.


b. Pasos de la asignacin dinmica:
Todo cliente DHCP puede encontrarse en seis estados diIerentes:
- Inicializacion: Aun no posee ninguna direccion IP, para lo cual debera contactar a
todos los servidores DHCP en su red local. Para hacer esto generara un mensaje de
descubrimiento DHCP.
- Seleccion: Espera una respuesta (OIerta DHCP) del primer servidor y lo elige.
- Solicitud: Ingresa a este estado cuando envia al servidor seleccionado un mensaje de
solicitud DHCP.
- Enlace: Al recibir el ACK del servidor con la direccion solicitada, la cual ya queda
asignada en Iorma deIinitiva por el lapso correspondiente.
- Renegociacion: Al generar un mensaje de renegociacion.
- Reenlace: Al generar un mensaje de reenlace.
Al ingresar una maquina al estado de enlace, inicia tres Timer de control de asignacion, que en
general son asignados por el servidor durante la asignacion de direcciones:
- Renegociacion: Por deIecto es la mitad del intervalo de duracion de la direccion asignada.
Al expirar este tiempo el cliente debe renegociar su direccion IP.
- Reenlace: Por deIecto expira al 87,5 del tiempo de asignacion. Al llegar a este tiempo, el
cliente asume que el servidor se encuentra inactivo, y genera un mensaje Broadcast de
reenlace
- Expiracion: Expira si no recibe respuestas de ningun servidor y vence su tiempo de
asignacion.
Los protocolos DHCP y BOOTP son compatibles, de hecho un servidor DHCP puede ser
programado para responder solicitudes BOOTP, sin embargo DHCP cambia el signiIicado de
dos campos en el Header del mensaje como se vera a continuacion.

c. Formato del mensaje DHCP:
8 8 8 8
OP HTYPE HLEN HOPS
TRANSACTION ID
SECONDS FLAGS
CLIENT IP ADDRESS
YOUR IP ADDRESS
SERVER IP ADDRESS
ROUTER IP ADDRESS
CLIENT HARDWARE ADDRESS (16 octetos)
SERVER HOST NAME (64 octetos)
BOOT FILE NAME (128 octetos)
OPTIONS (Variable)

- OP: Toma valor (1) para solicitud y (2) para respuesta.
- HTYPE:
(1) DHCPDISCOVER.

(2) DHCPOFFER.
(3) DHCPREQUEST.
(4) DHCPDECLINE.
(5) DHCPACK.
(6) DHCPNACK.
(7) DHCPRELEASE.
- HLEN: EspeciIica el tipo y longitud de la direccion de Hardware (Ej: Ethernet tiene
tipo 1 y longitud 6 octetos).
- HOPS: El cliente coloca (0), si es necesario pasar a traves de distintos router , el
servidor BOOTP o DHCP lo incrementara.
- TRANSACTION ID: Contiene un numero entero que permite llevar el control entre
las solicitudes y respuestas.
- SECONDS: Determina el tiempo transcurrido desde que se inicio la operacion..
- FLAGS: IdentiIica por medio del primer bit si es un Broadcast, los restantes quince
deben estar puestos a cero.
- CLIENT IP ADDRESS:
- YOUR IP ADDRESS:
- SERVER IP ADDRESS:
- ROUTER IP ADDRESS:
- CLIENT HARDWARE ADDRESS:
- SERVER HOST NAME:
- BOOT FILE NAME: Puede contener el tipo de booteo (Ej: UNIX)
- OPTIONS: DeIine mascara de subred, hora,etc

Hasta aqui se aprecia el aspecto general de DHCP, pero si se desea analizar en detalle su
Iuncionamiento es necesaria remontarse a sus origenes y tener en cuenta como nacen los protocolos
de booteo (como se menciono en la introduccion).
Al inicializarse una maquina sin disco rigido, esta carga directamente de la ROM, una imagen a su
memoria que le permite comenzar una secuencia de actividades. Como las direcciones IP no
pueden ser impuestas por el Iabricante pues justamente se trata de un esquema logico, e inclusive en
redes privadas estas pueden estar repetidas en cualquier lugar del mundo; la direccion IP debe ser
solicitada a otra maquina en la red, e inclusive tambien necesitara una conIiguracion particular para
cada red, que tambien dependera de otra maquina que podra ser o no la misma que la anterior.
Una primera aproximacion es el Protocolo RARP (Mencionado con anterioridad) que permite
descubrir servidores y direcciones IP Iuente y destino para este problema. La primera limitacion
esta en la poca inIormacion que en sus campos se transmite (solo la IP cliente), la segunda es que es
de muy bajo nivel, lo que exige a cualquier programador mucho mas esIuerzo pues se debe llegar
hasta el Hardware.
Para mejorar a RARP se diseo BOOTP (Precursor de DHCP). La primera cualidad de este
protocolo es que emplea IP y UDP, causa por la cual tiene acceso al nivel de aplicacin, sin
ninguna tarea adicional. El segundo detalle signiIicativo es la cantidad de inIormacion que con solo
dos mensajes (Solicitud y respuesta) puede transIerir. Para graIicar este concepto es conveniente
analizar su Iormato (Similar a DHCP):
8 bit 8 bit 8 bit 8 bit
Operacion Tipo de Hard Long Hard Hops
IdentiIicador de transaccion
Segundos No deIinido
Direccion IP cliente
Su direccion IP
Direccion IP del Server

Direccion IP del Router
Direccion de Hardware cliente (16 octetos)
Nombre del Server (64 octetos)
Nombre del archivo de booteo (128 octetos)
Area especiIica del vendedor (64 octetos)

- Operacion: Solicitud (1), Respuesta (2).
- Tipo y Longitud de Hardware: EspeciIica que tipo de hardware es empleado y su
longitud (Ej: Ethernet : Tipo 1 , Long 6).
- Hops: El cliente coloca valor 0, si se permite el booteo a traves de multiples Router, el
BOOTP Server, lo incrementa en 1.
- IdentiIicador de transaccion: Contiene un numero entero generado pseudo-
aleatoriamente, que permitira reconocer respuestas con solicitudes.
- Segundos: IdentiIica el tiempo en el cual el cliente inicio su operacion de booteo.
- Direcciones y nombres: Estos campos le otorgan una gran Ilexibilidad a este
protocolo, pues permiten ser llenados con la inIormacion que se posea, y en los
campos que no se conozcan se colocaran ceros. Por lo tanto puede conocer o no su
direccion, la del Server, el nombre del mismo, etc.
- Area especiIica del vendedor: Dentro de este campo se permite por medio de un
Iormato establecido (un octeto de Tipo, un octeto de longitud y n octetos de valores):

Tipo Longitud Descripcin
0 n Relleno
1 4 Mascara de subred
2 4 Tiempo GMT
3 n Direcciones IP de routers
4 n Direcciones IP de Servidores de tiempo
6 n Direcciones IP de DNS Server
7 n Direcciones IP de de Log Server
10 n Direcciones IP de Server de impresion
12 n Nombres de cliente
13 2 Tamao del archivo de booteo
128-254 n Reservados para uso especiIico de esa Site
255 1 Fin de lista

Algunos de estos Tipos pueden obtenerse por medio de otros protocolos (Ej: ICMP, WINS,etc),
pero los estandares recomiendan el empleo de estos campos en BOOTP para evitar traIico de red.
Si se comparan con el Iormato DHCP se puede apreciar la similitud entre estos, pero en el detalle
diIieren.
Un detalle signiIicativo de este protocolo es que no provee la inIormacion de booteo, le brinda toda
la inIormacion de red necesaria, e inclusive en el campo Nombre del archivo de booteo puede
especiIicar la direccion y el nombre de un servidor TFTP (por ejemplo), y con este dato completar
el segundo paso que seria la obtencion de los archivos de booteo. Este detalle aunque pase
inadvertido es de suma importancia pues se puede desde optimizar el traIico hasta poseer distintos

sistemas operativos de booteo (Ej: UNIX, Windows 2000, etc) en distintos servidores, y acorde a la
solicitud BOOTP cliente, asignarle cada servidor.
Si bien el protocolo BOOTP Iue un avance signiIicativo, representa una conIiguracion bastante
estatica, el administrador de red, crea un serie de parametros para cada Host en el cliente y el
servidor, los cuales permaneceran en los mismos por periodos de tiempo relativamente largos.
A Iines de los 90'se hacen reales dos hechos que envejecen prematuramente este protocolo
- Integracion masiva de las distintas redes privadas a Internet.
- Empleo cotidiano de computadoras portatiles.
La explosion de Internet hace que las asignaciones de direcciones IP sean escasas e imponen a
muchas subredes rangos mas pequeos que la cantidad de host que se poseen, obligando a reducir el
tiempo de vida de las asignaciones IP dentro de una subred, para que de esta Iorma sean
compartidas por mas de un usuario. El empleo de Notebooks hace que las direcciones asignadas
sean diIerentes acorde a la subred en la cual se haga presente I'isicamente. BOOTP no se adapta a
estas situaciones pues realiza un mapeo estatico. Bajo esta situacion es que nace DHCP, tratado al
principio.

d. Seguridad (Asignacin dinmica o esttica?):
Si bien el Iuncionamiento de la asignacion dinamica, es un gran apoyo para los administradores
de redes, y en realidad Iacilita notablemente esta tarea, eliminando a su vez las posibilidades de
asignaciones repetidas de direcciones IP, lo cual era un problema bastante Irecuente en redes
grandes; nuevamente aparece esa peligrosa relacion de Iacilidad Vs seguridad. Si se analiza en
detalle la solicitud DHCP, se trata de un Broadcast, el cual sera recibido por todos los servidores
DHCP de la red (inclusive se puede programar como se desea operar con el mismo a traves de
los routers). Todos los servidores contestaran oIreciendo una direccion IP, y la que primero
llegue al host solicitante , sera la que este negocie en las dos tramas restantes.
Si se tiene en cuenta que en una red Ethernet, no existe forma de asignar prioridades de
acceso al canal, nunca se podra deIinir sectores de la red que sean clientes de ciertos servidores
DHCP, como si se puede hacer con servidores WINS o DNS (pues estos ya son parte de la
conIiguracion IP, estatica o dinamica), pues al host aun no posee ninguna conIiguracion IP.
Este detalle desde el punto de vista de la seguridad, presenta dos grandes problemas:
1) Si se posee mas de un servidor DHCP, los rangos de cada uno de ellos, seran
adjudicados aleatoriamente en los distintos host de la red. Este aspecto no permite
planiIicar grupos de direcciones IP que rapidamente identiIiquen la ubicacion Iisica de
un host en la red.
Se desea hacer especial hincapie en este parraIo, pues en redes seguras (con IP estaticas
bien asignadas), uno de las mayores ayudas que se tiene al realizar analisis de traIico es
que al capturar direcciones IP, inmediatamente se puede inIerir de que host se trata, si es
parte de la red, donde se encuentra el mismo, que Iunciones desempea y por lo tanto
que derechos y obligaciones posee. Detengase a pensar si esto es posible con
asignaciones estaticas.
Dentro de esta linea de pensamiento es que se debe tener muy en cuenta este punto al
comenzar a disear una red (pues luego se hace muy diIicultoso). Es de vital
importancia desde el vamos dedicarle todo el tiempo necesario para planiIicar la
estrategia de direccionamiento de la red completa (y si no se hizo desde el principio es
una tarea que SI o SI se debe hacer). Un muy buen punto de partida es armar planos de
cada subred, dimensionar las subredes, asignarle rangos de IP privadas acorde a la

magnitud de cada una de ellas, luego seguir avanzando de lo global a lo particular, es
decir, dentro de cada subred continuar por regiones, ediIicios, pisos, grupos de trabajo,
etc. hasta llegar a identiIicar al ultimo host.
Ej: 10.65.130.67
Podria ser interpretado como:
- 10.65 (1ro y 2do octeto): SubRed perteneciente a la zona A (Desde 10.65 hasta
10.127, podria ser zona B desde 10.128 hasta 10.191 )
- 130 (3er octeto): Edificio A2 - Piso 2 (EdiIicio A1 Subred 1 hasta 127,
EdiIicio A2 Subred 129 hasta 254, dentro del mismo: piso 1 129, Piso 2
130, Piso 3 131,.......).
- 67 (4to octeto): Grup 1:Podria asignarse desde 65 hasta 127 grupo 1 y desde
129 a 191 grupo 2.
Este ejemplo est basado en REDES REALES de alta seguridad, donde se
necesita tener inmediata visualizacion de toda direccion IP que se monitorice, y
por mas que parezca diIicil la logica de asignacion, cualquier operador que
trabaje con una consola en un muy corto periodo de aprendizaje, al ver pasar
cualquiera de estas direcciones inmediatamente ubica de dnde se encuentra
pues si se sigue una buena logica, es extremadamente Iacil Iamiliarizarse con la
red.
Esta planiIicacion no implica la obligacion de realizar todo con direcciones estaticas,
pero si la de hacerlo en los segmentos en los cuales las aplicaciones son criticas,
excluyendo estos rangos de direcciones de los servidores DHCP que se hayan instalado.
2) Cualquier host que se conecte Iisicamente a la red obtendra una direccion IP y a partir de
aqui navegara con total libertad por la red LAN.

3.17. HTTP (HiperText Transfer Protocol) (RFC 1945):
a. Conceptos:
Este es el protocolo empleado entre clientes y servidores Web. La diIerencia con los demas
protocolos de nivel de aplicacion es que este establece una sesion por cada inIormacion
requerida (texto, sonido, graIicos, etc), esta Iinaliza al completarse la solicitud. Es normal la
apertura de varias sesiones para bajar una sola pagina.
Desde la version 1.0 en adelante incorpora MIME (Multimedia Internet Mail Extensions) para
soportar la negociacion de distintos tipos de datos.
El acceso a este protocolo es por medio del puerto 80 por deIecto, pero es comun en redes
privadas el empleo de otro para incrementar las medidas de seguridad.

b. Solicitudes y respuestas:
Existen dos tipos de encabezado, el de solicitud y el de respuesta y son los siguientes:
Solicitud
Method Request URI HTTP version


- Method: DeIine el metodo a ser ejecutado sobre el recurso.
- Request URI (UniIorm Resource IdentiIier): Recurso sobre el que se aplica la solicitud.
- HTTP Version: La version a ser utilizada.
Respuesta
HTTP version Status Code Reason phrase

- HTTP Version: La version a ser utilizada.
- Status code: Se trata de un entero de 3 digitos que es el resultado de intentar entender y
satisIacer la respuesta.
- Reason phrase: Descripcion textual del status code.

c. CGI, ISAPI, NSAPI, Servlets y Cold Fusion:
Toda aplicacion Web que posea cierto tipo de interaccion con el cliente debe acceder a las
Iunciones del servidor. En la actualidad existen dos interIaces que son las mas diIundidas en el
mercado CGI (Common Gateway InterIace) e ISAPI (Internet Server Application Programming
InterIace).
CGI: Es un metodo estandar de escribir programas para que Iuncionan en los servidores Web,
a estos programas se los suele llamar "Scripts CGI", los cuales por lo general toman sus datos de
entrada de Iormas HTML que les permiten luego ejecutar tareas particulares. Estos programas
oIrecen una gran Iacilidad de desarrollo y como la interIaz con el usuario es HTML, se pueden
acceder desde cualquier navegador. Cada llamada a ejecucion de un scripts consume tiempo de
CPU y recursos del servidor, por esta razon se debe prestar especial atencion a la simultaneidad
de las mismas.
ISAPI: En los casos donde prive la eIiciencia, es una buena alternativa el empleo de esta
interIaz, pues a diIerencia de la anterior, las aplicaciones que emplean ISAPI, se compilan
dentro de archivos DLL del servidor, siendo sensiblemente mas eIicientes. Estos archivos son
el metodo nativo del ambiente Windows. LA desventaja aqui es que un colapso de DLL puede
provocar serios problemas en el servidor.
NSAPI: Es una version de ISAPI desarrollada por Nestcape, la cual tambien trabaja con
sistemas Unix que soportan objetos compartidos.
Servlets: Se trata de componentes del lado del servidor, que son independientes de las
plataIormas pues se ejecutan en una maquina virtual jJava (JVM). Por ejecutarse dentro del
servidor, no necesitan una interIaz graIica de usuario, permitiendo una interaccion completa
entre los mismos (usuario y servidor). En el caso de los servlets de Java, estos oIrecen una
solucion para generar contenido dinamico, son objetos de programa que pueden cargarse en
dinamicamente en los servidores Web, ampliannnndo su Iuncionalidad, desempeandose mejor
que las CGI. Estos Servlets a su vez son muy seguros y pueden emplearse sobre protocolos de
seguridad como SSL.
Cold Fusion: Se trata de un producto que integra navegador, servidor y base de datos en
importantes aplicaciones Web. Posee una perIecta integracion con HTML, lo que lo convierte
en una excelente opIerta.

d. Vulnerabilidades:

- Uno de los principales agujeros de IIS es debido a la explotacion de ISAPI, si los programas
de ISAPI se ejecutan bajo la cuenta IUSRMACHINENAME y se logra invertir la misma,
se heredan los permisos de la misma, a partir de aqui se puede ejecutar cualquier tipo de
programas, incluso las llamadas al sistema.
- Autenticacion arbitraria de solicitudes remotas.
- Autenticacion arbitraria de servidores Web.
- Falta de privacidad de solicitudes y respuestas.
- Abusos de caracteristicas y recursos del servidor.
- Abuso sobre servidores que explotan sus errores y problemas de seguridad.
- Abuso sobre la inIormacion de registro (Robo de direcciones, nombres de dominio,
archivos, etc).

3.18. NetBIOS over TCP/IP (RFC 1001 y 1002):

a. Puertos:
En el caso de las redes MicrosoIt Windows, es comun el empleo del protocolo NetBIOS sobre
TCP (NetBT), el cual emplea los siguientes puertos:
UDP port 137 (name services)
UDP port 138 (datagram services)
TCP port 139 (session servicNes)
b. mbito:
Este protocolo se encuentra estandarizado por las RFC: 1001 y 1002. El acceso a este
protocolo lo controla la InterIaz TDI (Transport Driver InterIace). Se deIine una interIaz de
soItware y una convencion de nombres, por lo tanto siendo rigurosos, en realidad no se trata de
un protocolo en si mismo. El concepto de NetBT nace de las primeras versiones de MicrosoIt,
que implementaban un protocolo llamado NetBEUI, el cual es muy agil, pero no ruteable, ante
lo cual se sustenta en base a Broadcast, este Iuncionamiento es inaceptable ante redes que por su
tamao comienzan a emplear switch, y por supuesto no lo soportan los routers. Para mantener
su estrategia de nombres es que en los entornos Windows de MicrosoIt se emplea hoy NetBT.
Al salir a Internet, este sistema de nombres pierde sentido, pues es reemplazado por DNS, pero
en los entornos locales resuelve los servicios de NT workstation, Server Service, Browser,
messenger y netlogon. Es por esta razon que su ambito esta acotado a las redes LAN y no tiene
signiIicado en Internet.

c. Esquema de nombres:
Este sistema de nombres es plano, es decir que todos los nombres de una red deben ser unicos.
Su longitud maxima es de 16 caracteres, quedando el ultimo de ellos reservado para identiIicar
el servicio, este ultimo caracter puede tomar los valores que se detallan a continuacion:

computername~|00h| Workstation Service
computername~|03h| Messenger Service

computername~|06h| RAS Server Service
computername~|1Fh| NetDDE Service
computername~|20h| Server Service
computername~|21h| RAS Client Service
computername~|BEh| Network Monitor Agent
computername~|BFh| Network Monitor Application
username~|03| Messenger Service
domainname~|1Dh| Master Browser
domainname~|1Bh| Domain Master Browser
Group Names
domainname~|00h| Domain Name
domainname~|1Ch| Domain Controllers
domainname~|1Eh| Browser Service Elections

d. Protocolo nodo:
El metodo de resolucion de estos nombres respecto de su direccion IP, depende de como sea
conIigurado. El sistema de resolucion se realiza a traves del llamado protocolo 'nodoy
oIrece las siguientes opciones:
- nodo-B: emplea Broadcast para resolver el nombre.
- nodo-P: emplea una comunicacion Punto a punto.
- nodo-M: emplea primero nodo-B, y si no recibe respuesta usa nodo-P.
- nodo-H: emplea primero nodo-P, y si no recibe respuesta usa nodo-B (caso tipico WINS).
Un servidor DNS puede ser conIigurado con un registro especial (Adicionado puntualmente
como una zona DNS), que le instruye para que pase al servidor WINS todo nombre que no
encuentre en su base de datos.

e. Vulnerabilidades:
Como se menciono, este protocolo no tiene sentido en Internet, pues la resolucion de nombres
en este ambito se realiza por medio del protocolo DNS, los tres puertos de este protocolo
(137,138 y 139) siempre van a estar abiertos en las redes MicrosoIt, por lo tanto si se logra
acceder a una red LAN de estos productos, se sabe como poder acceder a cualquier host. Las
cuentas de usuario y contrasea de cualquier cliente de la Iamilia Windows 9x, no estan
pensados para seguridad en red, por lo tanto son altamente violables. Si un intruso logra
conectarse desde el exterior con cualquier host de la LAN, rapidamente podria obtener las listas
de usuarios de la red, sus servicios, grupos y recursos compartidos, lo cual no es deseado por
ningun administrador. En el 16to caracter se pone de maniIiesto casi toda la organizacion de la
LAN.
Por esta razon, JAMAS SE DEBE DEJAR PASAR POR UN ROUTER NI FIREWALL, los
puertos de este protocolo, se deben bloquear siempre en la frontera de toda LAN con

Internet, pues no tiene sentido ninguna comunicacion desde adentro hacia Iuera o viceversa
bajo este protocolo.

3.19. SSL y TLS:
El Secure Socket Layer, (SSL) es un protocolo diseado originalmente por Netscape Development
Corporation para garantizar la seguridad de las transacciones entre sus servidores y clientes en su
version 2.0. A partir de la version 3.0 se convirtio un estandar utilizado no solo para el WWW, sino
para muchas otras aplicaciones utilizadas en Internet.
Siendo un protocolo que trabaja entre la capa de aplicacion y la capa de transporte, permite que las
aplicaciones existentes sean Iacilmente adaptadas para hacer uso de este protocolo, proporcionando
privacidad, integridad y autenticidad en la inIormacion transmitida.
Basado en el uso de la criprograIia de claves publicas, utiliza los certiIicados X-509 para el manejo
de estas claves y la inIraestructura desarrollada en torno de estos certiIicados.
Actualmente es el estandar de comunicacion segura en los navegadores web mas importantes
(protocolo HTTP), como Nestcape Navigator e Internet Explorer, y se espera que pronto se saquen
versiones para otras otros protocolos de la capa de Aplicacion (correo, FTP, etc.).
La identidad del servidor web seguro (y a veces tambien del usuario cliente) se consigue mediante
el CertiIicado Digital correspondiente, del que se comprueba su validez antes de iniciar el
intercambio de datos sensibles (Autenticacion), mientras que de la seguridad de Integridad de los
datos intercambiados se encarga la Firma Digital mediante Iunciones hash y la comprobacion de
resumenes de todos los datos enviados y recibidos.
Desde el punto de vista de su implementacion en los modelos de reIerencia OSI y TCP/IP, SSL se
introduce como una "especie de nivel o capa adicional", situada entre la capa de Aplicacion y la
capa de Transporte, sustituyendo los sockets del sistema operativo, lo que hace que sea
independiente de la aplicacion que lo utilice.
Este protocolo tambien puede aplicar algoritmos de compresion a los datos a enviar y Iragmentar
los bloques de tamao mayor a 2
14
bytes, volviendolos a reensamblar en el receptor.
La version vieja (2.0) puede ser encontrada en:
http://home.netscape.com/newsreI/std/SSLold.html

a. De SSL a TLS:
A partir de la version 3.0 de SSL toma participacion IETF-TLS (Ineternet Engineering Task
Force) Group y la convierte en un estandar de Internet bajo la denominacion de TLS (Transport
Layer Security) protocol en el ao 1996. La inIormacion de detalle puede obtenerse en:
http://www.ietI.org/internet-draIts/ draIt-ietI-tls-protocol-05.txt
Un tema de especial interes es que TLS Iue diseado especialmente para evitar el ataque de
hombre del medio, es por esta razon que presenta mucha diIicultad para pasar a traves de
proxies, pues considera a estos justamente como un ataque.

b. Versiones:
En la actualidad existen la version SSL 3.0 que es la que se estandariza como TLS 1.0.


c. Handshake:
Un tunel TLS se inicia a traves de una conexion normal, por ejemplo, en el caso de ser HTTP,
primero se establece esta conexion en texto plano y a traves del "Handshake" se crea la
conexion segura por medio del intercambio de claves (con el metodo de DiIIie - Hellman o
Fortezza , certiIicados RSA o no, y resumenes MD-5 o SHA) y la generacion del secreto
compartido, junto con el codigo de autenticacion de mensaje (MAC).

Hay dos Iormas de realizar el handshake para iniciar una conexion TLS:

Handshake Completo: Se lleva a cabo el handshake completo para iniciar una conexion, lo cual
puede incluir no autenticar las partes, autenticar el server, o autenticar
el server y el cliente. Se elige el ciphersuite a usar y se intercambian
las claves y secretos.
Handshake Abreviado: Se lleva a cabo el handshake abreviado para reanudar una conexion
previa mantenida en el cache del server. Solo se veriIican los
parametros del ciphersuite a usar.
Handshake Completo
Esta tabla muestra los diIerentes mensajes en la conexion completa:
Cliente Server
1) Client Hello
2) Server Hello
3) Certificate
4) Server Exchange
5) Certificate Request
6) Server Hello Done
7) Client Certificate
8) Client Key Exchange
9) Certificate Veify
10) Change Cipher Spec
11) Finished
13) Finished
14) HTTP Request
15) HTTP Response
16) Close Notify Alert
1) Client Hello
Una vez que el cliente (web browser) ingresa una URL https://......, el browser llama al
parser para que decodiIique la URL ingresada. Este se da cuenta que el protocolo elegido es
https, e inmediatamente crea un socket al host, al port 443 (el predeIinido para HTTP/TLS
cuando el protocolo de transporte es TCP).
Una vez creado el socket, el cliente manda un mensaje ClienteHello al server, en el cual van:
- La version de SSL,TLS (generalmente 3,1).

- Un numero Random que servira luego para veriIicar integridad. Y crear el secreto
compartido.
- Un session-id (inicialmente con valor 0).
- Los ciIrados que soporta el cliente.
- Si empleara o no compresion.
- Genera un hash con todo esto para evitar modiIicaciones.
2) Server Hello
El server al recibir el mensaje anterior, genera este segundo mensaje con los siguientes
datos:
- Version de TLS que soporta el server.
- Numero random generado por el server.
- La session-id que el server asigna a esta sesion.
- El algoritmo de ciIrado que elige de los propuestos por el cliente.
- Y el algoritmo de compresion que empleara o no
3) Certificate
El servidor genera este mensaje con la lista de certiIicados que este usando. Si depende de
una CA, le enviara tambien el de esta, para que el cliente pueda validarlo.
4) Server Key Exchange
Si no se emplean certiIicados, se genera este mensaje para transmitir su clave publica, caso
contrario no se emite.
5) Certificate Request
Si el server debe autenticar al cliente (si el servicio que presta asi lo requiere), genera este
mensaje, en el cual se especiIica la lista de CAs en los que conIia este server, y los tipos de
certiIicados requeridos, ordenados por preIerencia del server.
6) Server Hello Done
Una vez generado el mensaje anterior, se arma este mensaje, que indica el Iin del Hello del
server. El server envia todos los mensajes juntos, desde el SeverHello hasta el
ServerHelloDone en este momento y se queda esperando la respuesta del cliente.
Ahora, estos cuatro mensajes son mandados al cliente en un solo registro (o en varios si el
Record Protocol tiene que Iragmentarlo). No se genera el MAC, no se hace compresion, ni
se encripta el registro, ya que ningun registro change_cipher_spec ha sido mandado aun.
Los parametros de seguridad (ciphersuite) elegidos pasan a ser el Estado Pendiente de TLS.
Todos los mensajes se pasan por la Iuncion HASH (incluido el ClientHello recibido) para
poder veriIicar luego que no hayan sido IalsiIicados.
7) Client Certificate
El cliente ahora procede a autenticar al server. Si el server puede ser autenticado el cliente
prosigue con el handshake, de lo contrario se aborta el handshake.
Si se recibe el mensaje Certificate Request, el cual le dice al cliente que debe ser

autenticado, el cliente debe responder con una lista de certiIicados de cliente, para que el
server lo pueda autenticar. Por lo tanto se genera un mensaje Certificate, similar al enviado
por el server.
Los datos del mensaje son:
- Lista de certiIicados del cliente.
8) Client Key Exchange
Para comenzar a generar el secreto compartido, se genera este mensaje. Se trata aqui de 46
bytes de datos generados aleatoriamente (mas 2 bytes de la version de TLS que usa el
cliente), que se envian encriptados con la clave publica del server, la cual se obtuvo del
certiIicado del server.
Antes de mandar el mensaje clientkeyexchange, el cliente calcula el secreto previo basado
en la clave publica que recibio del server, y luego calcula el "key block", a partir del cual se
derivan los MAC Secrets, las session keys y los IVs.
9) Certificate Verify
Para probar que los datos que se han recibido y enviado no han sido ni IalsiIicados ni
modiIicados, se genera este mensaje. Tanto el cliente como el server ingresan todos los
mensajes del Handshake Protocol (los recibidos y los enviados desde el comienzo del
handshake) en las Iunciones de hashing.
Para evitar que los valores generados por MD5 y SHA sean IalsiIicados o modiIicados, se
Iirma digitalmente con la clave privada del cliente (la cual el solo conoce).
Cuando el server reciba este mensaje, debe calcular las hashes MD5 y SHA tal cual lo hizo
el cliente, y comparar el resultado calculado con lo que recibio en este mensaje. Si los
valores coinciden, entonces se prosigue con el handshake, sino se aborta el handshake.
Este mensaje se utiliza para indicar al server que debe hacer de su estado pendiente (los
parametros de seguridad negociados en este handshake) su estado corriente. Esto signiIica
que los siguientes registros que se envien desde el cliente al server seran protegidos con el
ciphersuite y claves negociados.
11) Finished
Este mensaje se genera para veriIicar con el server que los parametros de seguridad Iueron
correctamente calculados por ambos. Este mensaje consta de 12 bytes generados a partir del
secreto previo, y los hashes MD5 y SHA calculados hasta ahora.
En este punto, recien se envian al server todos los mensajes anteriores, desde Client
Certificate hasta Finished inclusive.
El cliente se queda esperando la respuesta del server.
El server recibe la respuesta del cliente.
Primero recibe el mensaje Certificate del cliente en el cual viaja la cadena de certiIicados
del cliente. El server autentica al cliente, si puede hacerlo continua con el proximo mensaje
recibido del cliente, de lo contrario aborta el handshake.

Suponiendo que pudo autenticar al cliente, procesa el mensaje ClientKeyExchange, en el
que viaja el secreto previo necesario para generar las claves de sesion, los secretos del MAC
y los IVs.
El server desencripta el contenido del mensaje usando su clave privada.
Procesa el mensaje CertificateVerify, que contiene los hashes generados por el cliente.
Compara los hashes MD5 y SHA calculados por el server con los enviados por el cliente y si
son iguales el server continua con el handshake, sino lo aborta.
Si los hashes coincidieron, el server procesa el mensaje ChangeCipherSpec enviado por el
cliente, que tiene el eIecto de cambiar el estado corriente (sin encriptacion ni MAC) por el
estado pendiente (encriptacion). A partir de este momento, el server enviara y recibira
mensajes protegidos con el ciphersuite negociado.
El server procesa ahora el mensaje Finished que envio el cliente. Este mensaje viene
protegido con el nuevo ciphersuite, y el cliente lo envia para veriIicar que los parametros
sean correctos. El server desencripta el mensaje con su clave de lectura, genera el MAC con
su secreto MAC de lectura y compara con el del cliente para veriIicar que el mensaje no ha
sido modiIicado, y genera los 12 bytes random de la misma Iorma que el cliente, si
coinciden, entonces este sentido de la conexion ha sido veriIicado.
Ahora el server genera un mensaje ChangeCipherSpec, para que el cliente cambie el
estado corriente de lectura con el estado pendiente de lectura, para poder usar el nuevo
ciphersuite en este sentido de la conexion.
13) Finished
El server genera 12 bytes random de Iorma muy similar a como lo hizo el cliente en su
mensaje Finished, usando el secreto compartido y las hashes calculadas hasta ahora.
Estos 12 bytes los encapsula en un mensaje Finished, genera el MAC con MD5, y encripta
todo con la clave de escritura.
Luego envia estos dos ultimos mensajes al cliente. En este momento la conexion ya esta lista
para transportar en Iorma segura datos de la capa de aplicacion, salvo que el cliente envie un
mensaje de Alerta para abortar la conexion.
14) HTTP request
El cliente recibe el mensaje anterior del server, y cambia el estado de lectura corriente con el
estado de lectura pendiente.
Ahora, el cliente recibe el mensaje Finished del server y chequea que la conexion en este
sentido tenga los parametros de seguridad correctos desencriptando el mensaje, comparando
el MAC y chequeando los 12 bytes random generados por el server.
Si no se encontro ningun error, el cliente se dispone a hacer el pedido al server. En caso
contrario se aborta la conexion enviando un mensaje Alert al server.
No habiendo errores en el handshake, el cliente (Web browser) se dispone ha hacer el
pedido al servidor Web.
15) HTTP response
Se envia la inIormacion solicitada por el cliente.
El resto de la comunicacion es de la misma Iorma para todos los datos del nivel de
aplicacion que se quieran transIerir.

Finalmente, el server manda un Alert Close Notify para indicarle al cliente que el server
termino. Por supuesto, este mensaje se envia protegido por el ciphersuite.
Dependiendo del protocolo de aplicacion que este usando la conexion, el servidor podria
decidir esperar a que llegue el Close Notify del cliente para cerrar el socket TLS, o bien
cerrarlo sin esperar el Close nofity.
El cliente recibe este mensaje del server y responde con otro Close Notify para cerrar la
sesion. Se envia protegido y se cierra el socket sobyacente.

Handshake Abreviado
En la tabla muestra los diIerentes mensajes en la conexion abreviada. Mensajes para la
conexin con handshake abreviado, el contenido de los mismos es de caracter similar al
completo detallado anteriormente:

Cliente Server
1)ClientHello
2) ServerHello
3) ChangeCipherSpec
4) Finished
5) ChangeCipherSpec
6) Finished
Datos de Aplicacin <-----> <-----> Datos de Aplicacin

En una Iorma resumida, el handshake es como sigue:
El cliente envia un ClientHello usando el session-ID de la sesion a ser reanudada y otros 48
bytes random. El server luego chequea en su cache de sesiones para ver si encuentra esa sesion.
Si se encuentra la sesion, y el server esta dispuesto a reestablecer la conexion bajo el estado
especiIicado de sesion, mandara un ServerHello con el mismo valor de session-ID y otros 48
bytes random. Se debe regenerar el secreto compartido y las claves de sesion, los secretos
MAC y los IVs. En este punto tanto el cliente como el server deben enviar directamente
mensajes ChangeCipherSpec y Finished. Una vez que el reestablecimiento esta completo, el
cliente y server empiezan a intercambiar datos de aplicacion.
Si el server no puede encontrar el session-ID en su cache, el server genera una nuevo session-
ID y tanto el cliente como el server TLS ejecutan un handshake completo.

d. Intercambio de claves, algoritmos de cifrado y resmenes:
Sin la intencion de exponer en este punto estas tecnicas, se trata solamente de incorporar los
nuevos aspectos que permite TLS, en virtud de nuevas legislaciones de EEUU, las cuales
permiten la exportacion de claves de 56 bits e intercambio e claves de hasta 1024 bits. Teniendo
en cuenta esta liberacion se incorporan las siguientes posibilidades:
Intercambio
de Claves
Clave
Intercambio
Cipher
Clave
Cipher
Exportable Hash
RSA 1024 bits DES (CBC) 56 bits SI SHA

RSA 1024 bits RC4 56 bits SI SHA
DiIIie-Hellman (eIimera, Iirma DSS) 1024 bits DES (CBC) 56 bits SI SHA
DiIIie-Hellman (eIimera, Iirma DSS) 1024 bits RC4 56 bits SI SHA
DiIIie-Hellman (eIimera, Iirma DSS) sin limite RC4 128 bits NO SHA

Tambien existe documentacion para el agregado a TLS del Elliptic Curve Cryptosystem (ECC).
Que en la actualidad se considera como un algoritmo muy robusto y mas veloz que RSA.
Para la implementacion de Curvas elipticas se deIine toda la cipher suite, empleando los
siguientes algoritmos de establecimiento de clave: ECES (Elliptic Curve Encryption Scheme),
ECDSA (Elliptic Curve Digital Signature Algorithm), ECNRA (Elliptic Curve Nyberg-
Rueppel Signature Scheme with Appendix), ECDH (Elliptic Curve DiIIie-Hellman Key
Agreement), ECMQV (Elliptic Curve Menezes-Qu-Vanstone Key Agreement).
Tambien se contempla la incorporacion de Kerberos. Las credenciales Kerberos se usan para
llevar a cabo una autenticacion mutua y para establecer un secreto compartido usado
subsecuentemente para asegurar la comunicacion cliente-servidor.

e. Puertos definidos:

Teoricamente TLS puede asegurar cualquier protocolo de la Iamilia TCP/IP ejecutandose sobre
todo puerto, si ambos lados conocen que en el otro extremo se esta ejecutando TLS, sin
embargo, en la practica un grupo de puertos han sido reservados para cada uno de los protocolos
comunmente empleados en Internet, Iacilitando con esto la tarea a los Iirewalls. En el ao
1998, IANA designo los siguientes puertos para SSL/TLS:

Keyword Decimal Description
Nsiiops 261/tcp IIOP Name Service over TLS/SSL
Https 443/tcp http protocol over TLS/SSL
Ddm-ssl 448/tcp DDM-SSL
Smtps 465/tcp smtp protocol over TLS/SSL
Nntps 563/tcp nntp protocol over TLS/SSL
Sshell 614/tcp SSLshell
Ldaps 636/tcp ldap protocol over TLS/SSL
Itps-data 989/tcp Itp protocol, data, over TLS/SSL
Itps 990/tcp Ftp, control, over TLS/SSL
Telnets 992/tcp telnet protocol over TLS/SSL
Imaps 993/tcp imap4 protocol over TLS/SSL
Ircs 994/tcp irc protocol over TLS/SSL
Pop3s 995/tcp pop3 protocol over TLS/SSL

La lista de puertos y sus detalles puede ser encontrada en:
http://www.isi.edu/in-notes/iana/assignments/port-numbers

3.20. IP Versin 6 (IP Next generation):

a. Conceptos:

Desde hace tiempo ya se hacen evidentes algunas Ialencias que hoy tiene la actual version del
Protocolo IP (Version 4). Algunas de ellas son la mala distribucion que utiliza de sus
cantidades de Host en cada una de sus redes (A, B y C); son muy pocas o ninguna las empresas
que poseen los millones de Host que permite una direccion tipo A, hoy tampoco existen

2.100.000 empresas, por lo tanto, tanto en A como en C se desperdicia la asignacion de
direcciones, si bien hoy se asignan porciones de las mismas, este no Iue el sentido con que
Iueron creadas. Otra debilidad es la no posibilidad asignaciones geograIicas , lo que representa
una enorme carga de tablas en los router exteriores, casi ya imposible de controlar. Tambien se
suman detalles de seguridad, criptogrIiado, Prioridades, longitud variable de cabecera, etc.

b. Caractersticas:

Las caracteristicas principales de IPv6 son:
Direccionamiento: 128 bit.
Encaminamiento: Direccionamiento jerarquico.
Prestaciones: Cabecera simple de 40 Byte, alineada de a 64 bit, y cualquier otra inIormacion
se agrega como cabecera en extension (opcional).
Versatilidad: Formato Ilexible de opciones.
Multimedia: Id de Ilujos.
Multicast: Obligatorio.
Seguridad: Soporte de autenticacion y ciIrado.
AutoconIiguracion: Tres metodos PnP.
Movilidad: Surce routing, seguridad, deteccion de moviles, hand-oII.
Fragmentacion: Unicamente de extremo a extremo, es decir que solo el origen puede
Iragmentar. Para implementar esto, hace uso de PMTU (Path MTU, RFC 1191), que es el
mecanismo empleado para determinar la maxima unidad de datos que contendra un
datagrama, una vez conocido este tamao, armara todos los paquetes sin superar el mismo,
por ende ningun router debera Iragmentarlo pues no sera necesario.
Tamao de datagrama: Mantiene el mismo concepto que la version 4 y propone un nuevo
modelo de datagrama, llamado Jumbograma, el cual se deIine a traves de una cabecera en
extension, y permite transmitir datagramas de hasta 4 Gbyte. La idea de esta nueva
aplicacion es permitir la transmision de grandes volumenes de datos entre servidores, los
cuales no necesitan incrementar con tanta redundancia de cabecera, siendo el mejor
representante de esto el empleo de cluster de servidores.

c. Header de IPv6:
Version Clase de traI. Rotulo de Ilujo
Longitud de carga util Sig. Cabecera Limite Saltos
Direccion Iuente

Direccion destino

Posibles cabeceras de extension

Version: (4), se mantiene el mismo tamao para permitir distinguirlo del version 4 y que
puedan convivir durante algun lapso de tiempo.
Clase de traIico (4): (Video, audio, datos, voz, etc).Cuanto mas alto sea su valor mas
importante es, los valores que puede adoptar son:

0 traIico sin caracterizar
1 traIico "Iiller"
2 transIerencia de datos no atendida, como E-mail
3 reservado
4 transIerencia de bloques de datos atendida, como FTP
5 reservado
6 traIico interactivo, como TELNET
7 traIico de control de Internet, como protocolos de encaminamiento
Rotulo de Ilujo: (24), Todos los datagramas del mismo Ilujo (Ej: todos los datagramas de una
misma FTP).
Longitud de carga util: (16): Cantidad de octetos de datos.
Siguiente cabecera: (8), se permiten varias, todas ellas van despues del campo Direccion
destino y aqui se identiIican cuales van.
Limite de saltos: (8), para evitar lazos inIinitos.
Direccion origen y destino (128 c/u), aparece aqui aparte de Net y Host un nuevo
identiIicador llamado Direccion de Agrupacion, que identiIica regiones topologicas.
Posibles cabeceras de extension (Extension Headers):
Iran colocadas antes del campo de datos, cada cabecera tendra un primer campo (8 bit) que
indica la proxima cabecera (Next Header) que indica si existe otra cabecera de extension o si
esta es la ultima
Cabecera salto por salto (valor 0): Lleva inIormacion para analizar en cada router.
Cabecera extremo a extremo: Lleva inIormacion que solo se examinara en el destino.
Cabecera de enrutamiento (valor 43): Ruta Iija.
Cabecera de Iragmento (valor 44): Si existe Iragmentacion.
Cabecera de veriIicacion de autenticidad(valor 51): Permite veriIicar autenticidad de
origen.
Cabecera de conIidencialidad: Los datos no deben ser leidos durante su paso por
Internet.

d. Direccionamiento de IPv6:

Direcciones de 128 bit (16 octetos) (mas de 10
38
direcciones posibles).
A pesar de las restricciones de redes y reservadas aun quedan mas de 1.500 direcciones
por m
2
de la superIicie de la tierra.
Tres tipos de direcciones (unicast, anycast y multicast).
No existen clases, similar al concepto de CIDR.

Notacion general 3FFE:2213:AE56:54AD:34EF:9888:33EA:AA21
Los ceros contiguos se pueden eliminar, es decir los siguientes pares de cotetos se podrian
representar como estan indicados a su derecha:
:002E: :2E:
:000A: :A:
:6700: :6700:
:0004:0000:0000:0000:000A: :4::A: (Solo una vez se pueden resumir las
secuencias seguidas de ceros, con dos puntos
seguidos ::).
0004:0000:0000:0000:000A:0000:0000:1243:00AD: 4::A:0000:0000:1243:AD:

Las direcciones compatibles con Ipv4 se abrevian con un solo punto (en vez de doble), o cual
indica que se trata de un solo octeto y no dos:

0:0:0:0:0:FFFF:201.200.32.129 ::FFFF:201.200.32.129

e. Tipos de direcciones:

Se deIinen tres tipos de direcciones IPv6:
Compatibles con IPv4
Una direccion indicando un nodo IPv6 con una direccion que se puede mapear
univocamente al espacio IPv4. Tienen el preIijo IP 0:0:0:0:0:IIII. Por ejemplo,
0:0:0:0:0:FFFF:119.234.21.44
Mapeadas a IPv4
Una direccion IPv6 que indica un nodo solo IPv4. Tienen el preIijo IP 0:0:0:0:0:0. Por
ejemplo, 0:0:0:0:0:0:36.56.24.241.. Es importante darse cuenta de que las direcciones
compatibles con IPv4 y las mapeadas a IPv4 utilizan el mismo espacio de direcciones.
El preIijo solo indica si el nodo soporta o no IPv6.
Solo IPv6
Una direccion IPv6 que indica un nodo que soporta IPv6 donde los 32 bits inIeriores
no contienen necesariamente una direccion IPv4. Los 96 bits de orden superior son
distintos de 0:0:0:0:0:FFFF o 0:0:0:0:0:0.

Direcciones especiales:
0:0:0:0:0:0:0:1 Loopback.
0:0:0:0:0:0:0:0 Direccion no especiIicada.

Concepto de preIijo: El preIijo es similar a la notacion de cisco de mascara de red, es decir
se anexa a continuacion de la direccion IP, separado por una barra (/) en notacion decimal el
valor que identiIica la cantidad de bit que estan puestos a uno en la mascara de red (de
izquierda a derecha):

0004:0000:0000:0000:000A:0000:0000:1243:00AD/48

RFC que hacen reIerencia a IPv6
1881 IPv6 Address Allocation Management.
1883 Internet Protocol, Version 6 (IPv6) SpeciIication.
1884 IP Version 6 Addressing Architecture.
1887 An Architecture Ior IPv6 Unicast Address Allocation.
1897 IPv6 Testing Address Allocation.
1924 A Compact Representation oI IPv6 Addresses.
1933 Transition Mechanisms Ior IPv6 Hosts and Routers.
1970 Neighbor Discovery Ior IP Version 6 (IPv6).
1971 IPv6 Stateless Address AutoconIiguration.
1972 A Method Ior the Transmission oI IPv6 Packets over Ethernet Networks.
2073 An IPv6 Provider-Based Unicast Address Format.
2147 TCP and UDP over IPv6 Jumbograms.
2374 An IPv6 Aggregatable Global Unicast Address Format.
2375 IPv6 Multicast Address Assignments.
2460 Internet Protocol, Version 6 (IPv6) SpeciIication.

2461 Neighbor Discovery Ior IP Version 6
2462 IPv6 Stateless Address AutoconIiguration.
2471 IPv6 Testing Address Allocation.
2473 Generic Packet Tunneling in IPv6 SpeciIication.
2474 DeIinition oI the DiIIerentiated Services Field in the IPv4 and IPv6 Headers.
2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks
2526 Reserved IPv6 Subnet Anycast Addresses.
2675 IPv6 Jumbograms.
2732 Format Ior Literal IPv6 Addresses in URL's.
2893 Transition Mechanisms Ior IPv6 Hosts and Routers.
2928 Initial IPv6 Sub-. TLA ID Assignments.

ANEXO: RFC RELACIONADAS CON TCP/IP.

768 User Datagram Protocol (UDP)
783 Trivial File Transfer Protocol (TFTP)
791 Internet Protocol (IP)
792 Internet Control Message Protocol (ICMP)
793 Transmission Control Protocol (TCP)
816 Fault Isolation and Recovery
826 Address Resolution Protocol (ARP)
854 Telnet Protocol (TELNET)
862 Echo Protocol (ECHO)
863 Discard Protocol (DISCARD)
864 Character Generator Protocol (CHARGEN)
865 Quote of the Day Protocol (QUOTE)
867 Daytime Protocol (DAYTIME)
894 IP over Ethernet
919, 922 IP Broadcast Datagrams (broadcasting with subnets)
950 Internet Standard Subnetting Procedure
959 File Transfer Protocol (FTP)
1001, 1002 NetBIOS Service Protocols
1009 Requirements for Internet Gateways
1034, 1035 Domain Name System (DNS)
1042 IP over Token Ring
1055 Transmission of IP over Serial Lines (IP-SLIP)
1112 Internet Gateway Multicast Protocol (IGMP)
1122, 1123 Host Requirements (communications and applications)
1134 Point-to-Point Protocol (PPP)

1144 Compressing TCP/IP Headers for Low-Speed Serial Links
1157 Simple Network Management Protocol (SNMP)
1179 Line Printer Daemon Protocol
1188 IP over FDDI
1191 Path MTU Discovery
1201 IP over ARCNET
1231 IEEE 802.5 Token Ring MIB (MIB-II)
1332 PPP Internet Protocol Control Protocol (IPCP)
1334 PPP Authentication Protocols
1518 An Architecture for IP Address Allocation with CIDR
1519 Classless Inter-Domain Routing (CIDR): An Address
Assignment and Aggregation Strategy
1533 DHCP Options and BOOTP Vendor Extensions
i

1534 Interoperation Between DHCP and BOOTP
1541 Dynamic Host Configuration Protocol (DHCP)
1542 Clarifications and Extensions for the Bootstrap Protocol
1547 Requirements for Point-to-Point Protocol (PPP)
1548 Point-to-Point Protocol (PPP)
1549 PPP in High-level Data Link Control (HDLC) Framing
1552 PPP Internetwork Packet Exchange Control Protocol (IPXCP)

i

Analisis de Trafico

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis de Trafico

Enviado por

Direitos autorais:

Formatos disponíveis

Curso: Analisis de traIico

Alejandro Corletti Pgina 1 de 85

Você também pode gostar