PROTOCOLO BOOTP.

QUE ES BOOTP ?

BOOTP se diseño originalmente para permitir la configuración de inicio de estaciones de trabajo sin disco en sistemas antiguos. Este protocolo era necesario, ya que los clientes de este tipo tienen una capacidad limitada para almacenar la información configurable, necesaria durante los respectivos procesos de inicio que se utilizan para iniciar y participar en una red.

Las LANs hacen posible usar host sin disco como estaciones de trabajo, "routers" concentradores de terminales, etc. Los host sin disco requieren de algún mecanismo para el arranque remoto sobre una red. El protocolo BOOTP se utiliza para efectuar arranques remotos en redes IP. Permite que una pila de IP mínima sin información de configuración, típicamente almacenada en la ROM, obtenga información suficiente para comenzar el proceso de descargar el código de arranque necesario. BOOTP no define como se realiza esta descarga, pero habitualmente se emplea TFTP ("Trivial File Transfer Protocol") como se describe en el RFC 906 - Carga en Bootstrap usando TFTP.

BOOTP es predecesor del protocolo de arranque DHCP.

PASOS PARA EL PROCESO DE BOOTP.

1. El cliente determina su propia dirección hardware; esta suele estar en una ROM del hardware.

2. El cliente BOOTP envía su dirección hardware en un datagrama UDP al servidor. Si el cliente conoce su dirección IP y/o la dirección del servidor, debería usarlas, pero en general los clientes BOOTP carecen de configuración IP en absoluto. Si el cliente desconoce su dirección IP, emplea la 0.0.0.0. Si desconoce la dirección IP del servidor, utiliza la dirección de broadcast limitado (255.255.255.255). El número del puerto UDP es el 67. 3. El servidor recibe el datagrama y busca la dirección hardware del cliente en su fichero de configuración, que contiene la dirección IP del cliente. El servidor rellena los campos restantes del datagrama UDP y se lo devuelve al cliente usando el puerto 68. Hay tres métodos posibles para hacer esto:

- Si el cliente conoce su propia dirección IP (incluida en la solicitud BOOTP), entonces el servidor devuelve directamente el datagrama a esa dirección. Es probable que la caché de ARP en la pila de protocolos del servidor desconozca la dirección hardware correspondiente a esa dirección IP. Se hará uso de ARP para determinarla del modo habitual. - Si el cliente desconoce su propia dirección IP (0.0.0.0 la solicitud BOOTP), entonces el servidor se ocupa de averiguarla con su propia caché de ARP. El servidor no puede usar ARP para resolver la dirección hardware del cliente porque el cliente no sabe su dirección IP y por lo

tanto no puede responder a una petición ARP. Hay dos soluciones posibles:

a) Si el servidor tiene un mecanismo para actualizar directamente su propia caché ARP sin usar ARP, lo utiliza y envía directamente el datagrama.

b) Si el servidor no puede actualizar su propia caché, debe enviar una respuesta en forma de broadcast.

4. Cuando reciba la respuesta, el cliente BOOTP grabará su dirección IP (permitiéndole responder a peticiones ARP) y comenzará el proceso de arranque.

SEGUNDA FASE DEL PROCESO BOOTP.

En BOOTP, los clientes obtienen su configuración en un proceso de dos fases que se muestra a continuación:

1. El cliente BOOTP solicita una dirección IP así como otra información relevante. Esta información podría incluir normalmente las direcciones IP de un gateway (puerta de enlace predeterminada) o un servidor DNS. Para obtener más información, consulte Opciones DHCP y BOOTP estándar

2. El cliente BOOTP también solicita información adicional. Esta información es necesaria para que el cliente localice un servidor de Protocolo de transferencia de archivos trivial (TFTP, Trivial File Transfer Protocol) que proporciona un archivo de imagen de inicio específico de su plataforma. El cliente sólo necesita este archivo para completar su configuración de inicio.

Una vez que el servidor BOOTP ha respondido con toda la información que ha solicitado el cliente BOOTP, el cliente puede realizar la solicitud independiente a su servidor TFTP para completar la segunda fase de su proceso de inicio.

FORMATO DEL MENSAJE BOOTP.

code Indica una solicitud o una respuesta

1 Request

2 Reply

HWtype El tipo de hardware, por ejemplo:

1 Ethernet

6 IEEE 802 Networks

Remitirse a STD 2 - Números asignados de Internet para un alista completa.

length Longitud en bytes de la dirección hardware. Ethernet y las redes en anillo usan 6, por ejemplo.

hops El cliente lo pone a 0. Cada "router" que retransmite la solicitud a otro servidor lo incrementa, con el fin de detectar bucles. El RFC 951 sugiere que un valor de 3 indica un bucle.

Transaction ID Número aleatorio usado para comparar la solicitud con la respuesta que genera.

Seconds Fijado por el cliente. Es el tiempo transcurrido en segundos desde que el cliente inició el proceso de arranque.

Flags Field El bit más significante de este campo se usa como flag de broadcast. Todos los demás bits deben estar a 0; están reservados para usos futuros. Normalmente, los servidores BOOTP tratan de entregar los mensajes BOOTREPLY directamente al cliente usando unicast. La dirección de destino en la cabecera IP se pone al valor de la dirección IP fijada por el servidor BOOTP, y la dirección MAC a la dirección hardware del cliente BOOTP. Si un host no puede recibir un datagrama IP en unicast hasta saber su propia dirección IP, el bit de broadcast se debe poner a 1 para indicar al servidor que el mensaje BOOTREPLY se debe enviar como un broadcast en IP y MAC. De otro modo, este bit debe ponerse a cero.

Client IP adress Fijada por el cliente. O bien es su dirección IP real , o 0.0.0.0.

Your IP Address Fijada por el servidor si el valor del campo anterior es 0.0.0.0

Server IP address Fijada por el servidor.

Router IP address Fijada por el "router" retransmisor si se usa retransmisión BOOTP.

Client hardware address Fijada por el cliente y usada por el servidor para identificar cuál de los clientes registrados está arrancando.

Server host name Nombre opcional del host servidor acabado en X'00'.

Boot file name El cliente deja este campo vacío o especifica un nombre genérico, tal como "router", indicando el tipo de archivo de arranque a usar. El servidor devuelve el nombre completo del fichero o bien el de un fichero de arranque adecuado para el cliente. Su valor tiene como terminador a la secuencia X'00.

Vendor-specific area Área específica del distribuidor (opcional). Se recomienda que el cliente llene siempre los cuatro primeros bytes con un "magic cookie" o galleta mágica. Si el cookie específica de un distribuidor no se usa, el cliente debería utilizar 99.130.83.99 seguido de una marca de fin (255) y fijar los bis restantes a cero. Remitirse al RFC 1533 para más detalles.

APLICACIÓN DE BOOTP EN UN SERVIDOR DHCP DE WINDOWS2000.

Para configurar los servidores DHCP de Windows 2000 para que proporcionen información del archivo de inicio a los clientes BOOTP, complete los pasos siguientes:

1. Agregue una reserva de cliente para cada cliente BOOTP de un ámbito DHCP activo.

2. Agregue entradas BOOTP para cada plataforma específica del cliente en la tabla BOOTP del servidor DHCP.

Los clientes BOOTP utilizan la información guardada en la tabla BOOTP para completar la segunda fase de su proceso de inicio. Esta información se devuelve a los clientes BOOTP de la red que difunden un mensaje de solicitud BOOTP.

Si se ha agregado al menos una entrada BOOTP a la tabla BOOTP, el servidor DHCP de Windows 2000 responderá a las solicitudes del cliente BOOTP. Si no se han configurado entradas BOOTP, el servidor pasará por alto los mensajes de solicitud BOOTP.

CONFIGURACIÓN DE LA TABLA BOOTP.

Cada registro de la tabla BOOTP contiene los tres campos en los que se incluye la información devuelta al cliente BOOTP:

• Nombre del archivo de imagen de inicio. Identifica el nombre de archivo genérico (por ejemplo, "unix") del archivo de inicio solicitado, basado en el tipo de hardware del cliente BOOTP.

• Ruta de acceso completa del servidor a la imagen de inicio. Identifica la ruta de acceso completa del archivo de inicio (por ejemplo, "/etc/vmunix") que devuelve al cliente el servidor BOOTP, mediante TFTP.

• Servidor de archivos TFTP. Identifica el nombre del servidor TFTP utilizado como origen del archivo de inicio.

Para agregar entradas a la tabla BOOTP, utilice la consola DHCP.

DETALLES ADICIONALES DE CONFIGURACIÓN DE BOOTP.

Para que los servidores DHCP de Windows 2000 suministren un archivo de imagen de inicio y la información del servidor TFTP a los clientes BOOTP, el servidor utiliza algunas opciones DHCP para cumplir con la información guardada en entradas de la tabla BOOTP.

La tabla siguiente muestra estas opciones, que se utilizan para completar los mensajes del protocolo BOOTP que se devuelven a los clientes durante su secuencia de arranque inicial.

Código Descripción66 Nombre de servidor TFTP67 Nombre de archivo de inicio

Una vez que haya agregado entradas BOOTP a la tabla BOOTP de un servidor DHCP de Windows 2000, también configurará las opciones previas que se utilizarán para admitir a los clientes BOOTP. No necesitará configurar más las opciones DHCP en el servidor para proporcionarlas y utilizarlas como parte de la compatibilidad con BOOTP.

CAPA DEL MODELO OSI EN QUE SE ENCUENTRA BOOTP.

BOOTP opera en la Capa de Red del modelo OSI (Open System Interconection).

SEGURIDAD DE BOOTP.

Una petición de BOOTP nada mas puede realizarse en la misma subred en la que se encuentra el cliente que hace la petición BOOTP. Ya que si lo hace un cliente que se encuentra fuera de esa subred, el cliente podrá acceder a la red, aunque éste no tenga privilegios para hacerlo.

ESTÁNDARES DE BOOTP.

El protocolo de inicio BOOTP es un estándar TCP/IP establecido para la configuración de host que precede DHCP.

Las especificaciones de BOOTP se encuentran en: RFC 951, RFC 1497, RFC 1542, RFC 1533 y RFC 1532.

PROTOCOLO SMTP.

El correo electrónico (E-mail) es probablemente la aplicación TCP/IP más usada. Los protocolos de correo básicos de correo proporcionan intercambio de correo y mensajes entre hosts TCP/IP hosts; se han añadido servicios para la transmisión de datos que no se pueden representar con texto ASCII de 7 bits.

Hay tres protocolos estándares que se aplican a este tipo de correo. Todos son recomendados. El término SMTP se emplea con frecuencia para referirse a la combinación de los tres protocolos, por su estrecha interrelación, pero estrictamente hablando, SMTP es sólo uno de los tres. Normalmente, el contexto hace evidente de cuál de los tres se está hablando. Cuando haya ambigüedad, se emplearán los números STD o RFC. Los tres estándares son:

Un estándar para el intercambio de correo entre dos ordenadores (STD 10/RFC 821), que especifica el protocolo usado para enviar correo entre hosts TCP/IP. Este estándar es SMTP.

Un estándar (STD 11) para el formato de los mensajes de correo, contenido en dos RFCs. El RFC 822 describe la sintaxis de las cabeceras y su interpretación. El RFC 1049 describe como un conjunto de documentos de tipos diferentes del texto ASCII plano se pueden usar en el cuerpo del correo(los mismos documentos están en ASCII de 7 bits con información de formato embebida: Postscript, Scribe, SGML, TEX, TROFF y DVI aparecen en el estándar).

El nombre oficial del protocolo para este estándar es MAIL.

Un estándar para el encaminamiento de correo usando el DNS, descrito en el RFC 974. El nombre oficial del protocolo para este estándar es DNS-MX.

El STD 10/RFC 821 establece que los datos enviados por SMTP son ASCII de 7-bis, con el bit de orden superior a cero. Esto es adecuado para mensajes en inglés, pero no para otros lenguajes o datos que no sean texto. Hay dos estrategias para superar estas limitaciones:

MIME ("Multipurpose Internet Mail Extensions"), definido en los RFCs 1521 y 1522, que especifica un mecanismo para codificar texto y datos binarios en ASCII de 7 bits en el mensaje RFC 822.

SMTPSE ("SMTP Service Extensions"), que define un mecanismo para extender las posibilidades de SMTP más allá de las limitaciones impuestas por RFC 821. Actualmente hay tres RFCs que lo describen:

o Un estándar para que un receptor SMTP informe al emisor que extensiones de servicio soporta (SMTPSE) soporta (RFC 1651).

El RFC 1651 modifica el 821 para permitir que un cliente agente SMTP solicite al servidor una lista de las

extensiones de servicio que soporta el inicio de una sesión SMTP. Si el servidor no soporta este RFC, responderá con un error y el cliente podrá terminar la sesión o intentar iniciar una sesión según las reglas RFC 821. Si sí lo soporta, puede responder con una lista de las extensiones que soporta.

o Un protocolo para transmisión de texto de 8 bits(RFC 1652) que permite a un servidor SMTP indicar que puede aceptar datos formados por bytes de 8 bits. Un servidor que informa que dispone de esta extensión no debe modificar el bit de orden superior de los bytes recibidos en un mensaje SMTP si el cliente así se lo pide.

Las extensiones de MIME y SMTP son estrategias que se complementan más que competir entre sí. En particular, el RFC 1652 se titula SMTPSE para transporte MIME en codificación "8bit", ya que MIME permite declarar mensajes con bytes de 8 bits, en vez de 7. Tales mensajes no se pueden transmitir con agentes SMTP que sigan estrictamente el RFC 821, pero se pueden transmitir cuando tanto el cliente como el servidor siguen los RFCs 1651 y 1652. Siempre que un cliente intenta enviar datos de 8 bits a un servidor que no soporta esta extensión, el cliente SMTP debe codificar el mensaje a 7 bits según el estándar MIME o devolver un mensaje de error permanente al usuario.

Esta extensión no permite el envío de datos binarios arbitrarios porque el RFC 821 fija la longitud máxima de las líneas aceptadas por un servidor SMTP a 1000 caracteres. Los datos que no son texto pueden tener con facilidad secuencias de más de 1000 caracteres sin una secuencia <CRLF>.

Nota: Las extensiones limitan específicamente el uso de caracteres no ASCII (aquellos con valor decimal superior a 127) al cuerpo de los mensajes - no están permitidos en las cabeceras RFC 822.

o Un protocolo para la declaración del tamaño del mensaje (RFC 1653) que permite a un servidor informar al cliente del tamaño máximo de mensaje que puede aceptar. Sin esta extensión, un cliente sólo puede ser informado de que un mensaje ha excedido el tamaño máximo (sea fijo o temporal, por falta de espacio en el servidor) tras transmitir todo el mensaje. Cuando esto sucede, el servidor desecha el mensaje. Con ella, el cliente puede declarar el tamaño estimado del mensaje y el servidor devolverá un error si es demasiado grande.

MODELO SMTP.

COMO FUNCIONA SMTP.

SMTP está basado en la entrega punto-a-punto; un cliente SMTP contactará con el servidor SMTP del host de destino directamente para entregar el correo. Guardará el correo hasta que se haya copiado con éxito en el receptor. Esto difiere del principio de retransmisión común a muchos sistemas de correo en las que el correo atraviesa un número de host intermedios de la misma red y donde una transmisión con éxito implica sólo que el correo ha alcanzado el host correspondiente al siguiente salto.

En varias implementaciones, existe la posibilidad de intercambiar correo entre los sistemas de correo locales y SMTP. Estas aplicaciones se denominan pasarelas o puentes de correo. Enviar correo a través de una pasarela puede alterar la entrega punto-a-punto, ya que SMTP sólo garantiza la entrega fiable a la pasarela, no al host de destino, más allá de la red local. La transmisión punto SMTP en estos casos es host-pasarela, pasarela-host o pasarela-pasarela; SMTP no define lo que ocurre más allá de la pasarela.

CONTENIDO DEL MENSAJE.

Cada mensaje tiene:

Una cabecera, o sobre, con estructura RFC 822. La cabecera termina con una línea nula (una línea con sólo la secuencia <CRLF>).

Contents.

Todo lo que hay tras la línea nula es el cuerpo del mensaje, una secuencia de líneas con caracteres ASCII (aquellos con valor menor del 128 decimal).

El RFC 821 define un protocolo cliente/servidor. Como siempre, el cliente SMTP es el que inicia la sesión (el emisor) y el servidor el que responde a la solicitud de sesión (el receptor). Sin embargo, como el cliente suele actuar como servidor para un programa de correo del usuario, es más sencillo referirse a él como emisor SMTP, y al servidor como receptor SMTP.

FORMATO DEL MENSAJE.

Normalmente, el usuario no tiene por qué preocuparse de la cabecera, que es responsabilidad de SMTP.

Algunos campos habituales son:

keyword valor

to Receptores primarios del mensaje.

cc Receptores Secundario("carbon-copy") del mensaje.

from Identidad del emisor.

reply-to El buzón al que se han de enviar las repuestas. Este campo lo añade el emisor.

return-path Dirección y ruta hasta el emisor. Lo añade el sistema de transporte final que entrega el correo.

Subject Resumen del mensaje. Suele proporcionarlo el usuario.

CLIENTE (EMISOR) Y SERVIDOR (RECEPTOR).

El RFC 821 define un protocolo cliente/servidor. Como siempre, el cliente SMTP es el que inicia la sesión (el emisor) y el servidor el que responde a la solicitud de sesión (el receptor). Sin embargo, como el cliente suele actuar como servidor para un programa de correo del usuario, es más sencillo referirse a él como emisor SMTP, y al servidor como receptor SMTP.

• EL RFC 821 define un protocolo cliente/servidor.

• El cliente SMTP es el emisor.

• El servidor que responde a la solicitud de sesión es el receptor.

INTERCAMBIO DE CORREO.

El diseño de SMTP se basa en el modelo de comunicación mostrado en la figura de abajo. Como resultado de la solicitud de correo de un usuario, el emisor SMTP establece una conexión en los dos sentidos con el receptor SMTP. El receptor puede ser el destinatario final o un intermediario (pasarela de correo). El emisor generará comandos a los que replicará el receptor.

FLUJO DE DATOS DE SMTP.

Aunque los comandos y réplicas de correo están definidas rígidamente, el intercambio se puede seguir en Flujo de Datos de SMTP. Todos los comandos, réplicas o datos intercambiados son líneas de texto, delimitadas por un <CRLF>. Todas las réplicas tienen un código numérico el comienzo de la línea.

1. El emisor SMTP establece una conexión TCP con el SMTP de destino y espera a que el servidor envíe un mensaje "220 Service ready" o "421 Service not available" cuando el destinatario es temporalmente incapaz de responder.

2. Se envía un HELO (abreviatura de "hello"), con el que el receptor se identificará devolviendo su nombre de dominio. El SMTP emisor puede usarlo para verificar si contactó con el SMTP de destino correcto.

Si el emisor SMTP soporta las extensiones de SMTP definidas en el RFC 1651, puede sustituir el comando HELO por EHLO. Un receptor SMTP que no soporte las extensiones responderá con un mensaje "500 Syntax error, command unrecognized". El emisor SMTP debería 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-línea 250 OK que incluye una lista de las extensiones de servicio que soporta.

3. El emisor inicia ahora una transacción enviando el comando MAIL al servidor. Este comando contiene la ruta de vuelta al emisor que se puede emplear para informar de errores. Nótese que una ruta puede ser más que el par buzób@nombre de dominio del host. Además, 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 más de un receptor). Esto se hace enviando uno o más comandos RCPT TO:<forward-path>. Cada uno de ellos recibirá una respuesta "250 OK" si el servidor conoce el destino, o un "550 No such user here" si no.

5. Cuando se envían todos los comandos rcpt, el emisor envía un comando DATA para notificar al receptor que a continuación se envían los contenidos del mensaje. El servidor replica con "354 Start mail input, end with <CRLF>.<CRLF>". Nótese que se trata de la secuencia de terminación que el emisor debería usar para terminar los datos del mensaje.

6. El cliente envía los datos línea a línea, acabando con la línea <CRLF>. <CRLF> que el servidor reconoce con "250 OK" o el mensaje de error apropiado si cualquier cosa fue mal.

7. Ahora hay varias acciones posibles:

o El emisor no tiene más mensajes que enviar; cerrará la conexión con un comando QUIT, que será respondido con "221 Service closing transmission channel".

o El emisor no tiene más mensajes que enviar, pero está preparado para recibir mensajes (si los hay) del otro extremo. Mandará 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.

o El emisor tiene otro mensaje que enviar, y simplemente vuelve al paso 3 para enviar un nuevo MAIL.

Figura: Flujo de datos normal de SMTP.

DIRECCIÓN DE DESTINO DE SMTP.

En su forma general, parte-localt@nombre de dominio, puede adoptar distintos esquemas:

usuario@host Para un destino directo en la misma red TCP/IP.

usuario%host.remoto@host-pasarela Para un usuario en un host remoto de destino no SMTP, vía una pasarela.

@host-a,@host-b:usuario@host-c Para un mensaje retransmitido. Contiene explícitamente información de encaminamiento. El mensaje será entregado primero al host a, que lo retransmitirá al host b. El host b enviará el mensaje al host de destino real, el c. Nótese que el mensaje se almacena en cada uno de los host intermedios, por lo que no se necesita un mecanismo de entrega punto-a-punto.

EJEMPLO DE ENVÍO DE MENSAJES.

En el siguiente escenario, el usuario abc en el host vm1.stockholm.ibm.comando envía una nota a los usuarios xyz, opq u rst en el host delta.aus.edu. Las líneas precedidas por R: son las enviadas por el receptor, las que empiezan por S: las enviadas por el emisor.

R: 220 delta.aus.edu Simple Mail Transfer Service Ready S: HELO stockholm.ibm.comando R: 250 delta.aus.edu

S: MAIL FROM:<abc@stockholm.ibm.comando> R: 250 OK

S: RCPT TO:<xyz@delta.aus.edu> R: 250 OK S: RCPT TO:<opq@delta.aus.edu> R: 550 No such user here S: RCPT TO:<rst@delta.aus.edu> R: 250 OK

S: DATA R: 354 Start mail input, end with <CRLF>.<CRLF> S: Date: 23 Jan 89 18:05:23 S: From: Alex B. Carver <abc@stockholm.ibm.comando> S: Subject: Important meeting S: To: <xyz@delta.aus.edu> S: To: <opq@delta.aus.edu> S: cc: <rst@delta.aus.edu> S: S: Blah blah blah S: etc..... S: . R: 250 OK

S: QUIT R: 221 delta.aus.edu Service closing transmission channel

Nótese que la cabecera del mensaje es parte de los datos a transmitir.

CAPA DEL MODELO OSI A LA QUE PERTENECE SMTP.

El protocolo SMTP pertenece a la Capa de Red del Modelo OSI (Open System Interface).

APLICACIONES DE SMTP.

La aplicación principal de SMTP es el correo, de hecho para eso fue creado el protocolo SMTP.

SEGURIDAD EN SMTP.

Las amenazas más comunes en el correo electrónico son:

Los ataques pasivos sobre los protocolos básicos del servicio de correo electrónico.

El uso incorrecto de las estafetas de correo que degradan la calidad de este servicio.

Las especificaciones originales del protocolo SMTP lo hacen vulnerable a los ataques pasivos que se producen cuando una aplicación escucha el tráfico de la red y accede al contenido de los mensajes, así como a la identificación del usuario: su nombre y password de acceso. Estos ataques pueden actuar sobre las aplicaciones de usuario más extendidas como: Netscape, Outlook, Eudora y las de tipo Web-Mail.

Por otro lado, el protocolo SMTP, en su versión original, no dispone de mecanismos de autenticación del usuario que envía un mensaje. Esto permite el uso fraudulento de servidores SMTP por parte de personas ajenas a la organización, así como el envío de mensajes con dirección de correo falsa.

Los problemas derivados de esta situación han contribuido a una degradación importante del servicio de correo electrónico, permitiendo la proliferación de "correo basura" y poniendo en entredicho la imagen de las organizaciones.

Para paliar estas "deficiencias", se han generalizado mecanismos de control de acceso a los servidores SMTP basados en la confianza respecto a clientes locales o en la desconfianza respecto a determinadas organizaciones "fichadas" como origen de correo basura. Si bien es cierto que estas medidas han conseguido limitar el uso fraudulento de los servidores SMTP de las organizaciones por parte de terceros, no han conseguido evitar el envío de mensajes falsificados desde el interior de la organización y han dificultado la utilización del servicio a personas de la organización con necesidad de desplazarse.

ESTÁNDARES QUE REGULAN SMTP.

• RFC 821 – SMTP.• RFC 1123 – Requerimientos para host de Internet-Aplicación y soporte. • RFC 1651 – SMTPSE.• RFC 1652 – SMTPSE para transporte MIME con codificación 8 bit.• RFC 1653 – SMTPSE para declaración de tamaño de mensaje.

PROTOCOLO ICMP.

Protocolo de mensajes de control Internet "ICMP"

Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol, protocolo de mensajes de control y error) se encarga de informar al origen si se ha producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de notificar los errores, sino que también transporta distintos mensajes de control. El protocolo ICMP está definido en la RFC 79.

El protocolo ICMP únicamente informa de incidencias en la red pero no toma ninguna decisión. Esto será responsabilidad de las capas superiores. Los mensajes ICMP viajan en el campo de datos de un datagrama IP.

El Protocolo IP utiliza el protocolo de mensajes de control Internet "ICMP Internet Control Message Protocol" para informar de los errores que pueden ocurrir durante el enrutamiento de paquetes IP. El protoclo ICMP utiliza el soporte básico de IP como si se tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte integral del protocol IP, y debe ser implementado por todo módulo IP.

Los mensajes ICMP son enviados en varias situaciones: por ejemplo, cuando un datagrama no puede alcanzar su destino, cuando un enrutador no dispone de capacidad de almacenamiento temporal para reenviar un paquete IP, y cuando el enrutador puede dirigir al computador para enviar el tráfico por una ruta más corta. El propósito de estos mensajes de control no es hacer a IP fiable, sino suministrar información sobre los problemas en el entorno de comunicación.Los mensajes ICMP se envían usando la cabecera IP básica. El primer octeto de la parte de datos del datagrama es el campo de tipo ICMP; el valor de este campo determina el formato del resto de los datos. Los campos etiquetados como "no usado" están reservados para posteriores extensiones y deben ser cero al ser enviados, y los receptores no deberán usar estos campos (excepto para incluirlos en la suma de control).

Datagramas ICMP

El protocolo ICMP no usa número de puerto de servicio y es por eso un poco más dificultoso coleccionar detalles. ICMP usa un número de tipos diferentes de datagramas. Muchos de éstos son inofensivos y normales, mientras otros sólo deben observarse bajo circunstancias especiales. A veces las personas con mucho tiempo en sus manos intentan maliciosamente deteriorar el acceso de un usuario a la red, generando grandes cantidades de mensajes ICMP. Esto es comúnmente denominado saturamiento ping. Aun cuando la contabilidad IP no puede hacer nada para prevenir este problema podemos al menos colocar reglas de contabilidad en un lugar que nos muestre si alguien lo ha estado intentando.

ICMP no usa los puertos como lo hacen TCP y UDP. En cambio ICMP tiene mensajes tipo ICMP. Podemos construir reglas de contabilidad para cada tipo de mensaje ICMP. Para hacer esto, colocamos el mensaje ICMP y el número del tipo en lugar del puerto en la orden de contabilidad ipfwadm.

Si usted especifica la dirección origen y/o destino en sus reglas, puede seguir la pista de dónde están viniendo los ping, tales como si ellos se originan dentro o fuera de su red. Una vez que ha determinado de dónde están viniendo los datagramas, usted puede decidir si quiere poner reglas en un sitio para evitarlos o tomar alguna otra acción, como avisar al dueño de la red agraviante para avisarles del problema, o quizás incluso, acción legal si el problema es un acto malévolo.

Por ejemplo, asumiremos que nos encontramos en erdos y queremos hacer telnet al puerto 12345 en quark, pero no hay procesos escuchando en ese puerto. Cuando el primer paquete TCP para este puerto llegue a quark, la capa de red reconocerá esta llegada e inmediatamente enviará un mensaje ICMP a erdos empezando con “Port Unreachable”.

El protocolo ICMP ofrece varios mensajes diferentes, muchos de ellos tratan con condiciones de error. De todas maneras, hay un mensaje muy interesante denominado mensaje Redirect. Lo genera el módulo de encaminamiento cuando detecta que otro puesto está usándolo como pasarela, aunque exista una ruta más corta. Por ejemplo, después del arranque, la tabla de encaminamiento de sophus puede estar incompleta. Puede que contenga las rutas a la red de Matemáticas, a la dorsal FDDI, y el encaminamiento por defecto apuntando a la pasarela del Groucho Computing Center. De este modo, los paquetes para quark serán enviados a gcc1 en vez de a niels, la pasarela del departamento de Fisicas. Cuando recibe un datagrama como éste, gcc1 notará que esa es una mala elección como ruta y reenviará el paquete a niels, mientras tanto envía un mensaje Redirect ICMP a sophus diciéndole la ruta superior.

Esta parece ser una forma muy inteligente de evitar la configuración manual de las rutas excepto las más básicas. De cualquier forma, hay que decir que depender de esquemas de encaminamiento dinámicos, sean RIP o mensajes Redirect ICMP, no es siempre una buena idea. Redirect ICMP y RIP ofrecen muy poca o ninguna capacidad de verificar si alguna información de encaminamiento es efectivamente auténtica. Esta situación permite a malévolos inútiles perturbar el desarrollo del tráfico de la red completa, o incluso algo peor. Consecuentemente, el código de red de GNU/Linux trata los mensaje Network Redirect como si fuesen Host Redirects. Esto minimiza los daños de un ataque restringiéndolos a sólo un puesto, en vez de la red completa. Por otro lado, esto significa que se generá un poco más de tráfico en las mismas condiciones, ya que cada puesto hace que se genere un mensaje Redirect ICMP.

Cada una de las órdenes de configuración del firewall le permite especificar tipos de datagrama de ICMP. Al contario que los puertos de TCP y de UDP, no existe un fichero de configuración conveniente que liste los tipos de datagramas y sus significados. Los tipos de datagrama de ICMP se definen en el RFC-1700, el RFC de los números asignados. Los tipos de datagrama de ICMP aparecen también listados en uno de los ficheros de cabecera de la biblioteca estándar de C. El fichero /usr/include/netinet/ip_icmp.h, que pertenece al paquete con la biblioteca estándar de GNU, y que los programadores de C utilizan cuando escriben 'software' de red que utilice el protocolo de ICMP, también define los tipos de datagrama de ICMP. La interfaz de la orden iptables le permite especificar los tipos de ICMP por su nombre, por lo que también se muestran los nombre nemotécnicos que utiliza.

Tabla 9-2. Tipos de datagramas de ICMP

Número de tipo Nnemónico de iptables Descripción del tipo

0 echo-reply Respuesta a eco

3 destination-unreachable Destino inaccesible

4 Source-quench Disminución del tráfico desde el origen

5 Redirect Redirección

8 echo-request Solicitud de eco

11 time-exceeded Tiempo superado

12 parameter-problem Problema de parámetros

13 timestamp-request Solicitud de marca de tiempo

14 timestamp-reply Respuesta de marca de tiempo

15 None Solicitud de información

16 None Respuesta de información

17 address-mask-request Petición de máscara de dirección

18 address-mask-reply Respuesta de máscara de dirección

 

    Tipo Datos ICMP  

     

 Encabezado del

datagramaÁrea de datos del datagrama IP  

     

Encabezado de la trama

Área de datos de la tramaFinal de la

trama

Debido a que el protocolo IP no es fiable puede darse el caso de que un mensaje ICMP se pierda o se dañe. Si esto llega a ocurrir no se creará un nuevo mensaje ICMP sino que el primero se descartará sin más.

Los mensajes ICMP comienzan con un campo de 8 bits que contiene el tipo de mensaje. El resto de campos son distintos para cada tipo de mensaje ICMP. 

nota: El formato y significado de cada mensaje ICMP está documentado en la RFC 792. 

Solicitud y respuesta de eco

Los mensajes de solicitud y respuesta de eco, tipos 8 y 0 respectivamente, se utilizan para comprobar si existe comunicación entre 2 hosts a nivel de la capa de red. Estos mensajes comprueban que las capas física (cableado), acceso al medio (tarjetas de red) y

red (configuración IP) están correctas. Sin embargo, no dicen nada de las capas de transporte y de aplicación las cuales podrían estar mal configuradas.

 

PING envía mensajes de solicitud de eco a un host remoto e informa de las respuestas.

1. A envía un mensaje ICMP de tipo 8 (Echo) a B 2. B recibe el mensaje y devuelve un mensaje ICMP de tipo 0 (Echo Reply) a

A

3. A recibe el mensaje ICMP de B y muestra el resultado.

 

Si el host de destino no existiese o no estuviera correctamente configurado recibiríamos un mensaje ICMP de tipo 11 (Time Exceeded).

Si tratamos de acceder a un host de una red distinta a la nuestra y no existe un camino para llegar hasta él, es decir, los routers no están correctamente configurados o estamos intentando acceder a una red aislada o inexistente, recibiríamos un mensaje ICMP de tipo 3 (Destination Unreachable).

 

Utilización de PING para diagnosticar errores en una red aislada

 .

Nota: El comando ping 127.0.0.1 informa de si están correctamente instalados los protocolos TCP/IP en nuestro host. No informa de si la tarjeta de red de nuestro host está correcta.

 

Utilización de PING para diagnosticar errores en una red de redes 

En el caso producirse errores de comunicación en una red de redes con más de un router (Internet es el mejor ejemplo), se suele utilizar el comando PING para ir diagnosticando

los distintos routers desde el destino hasta el origen y descubrir así si el fallo es responsabilidad de la red de destino, de una red intermedia o de nuestra red.

Algunos hosts en Internet tienen deshabilitadas las respuestas de eco (mensajes ICMP tipo 0) como medida de seguridad. En estos casos hay que utilizar otros mecanismos para detectar si responde.

Mensajes ICMP de tiempo excedido

Los datagramas IP tienen un campo TTL (tiempo de vida) que impide que un mensaje esté dando vueltas indefinidamente por la red de redes. El número contenido en este campo disminuye en una unidad cada vez que el datagrama atraviesa un router. Cuando el TTL de un datagrama llega a 0, éste se descarta y se envía un mensaje ICMP de tipo 11 (Time Exceeded) para informar al origen.

Tiempo de Vida (TTL, "Time To Live")

Si, de acuerdo con la información existente en las tablas de enrutamiento de la pasarela, la red especificada en el campo de destino internet de un datagrama es inaccesible, p. ej., si la distancia a la red es infinita, la pasarela pue de enviar un mensaje de destino inaccesible al "host" de origen del datagrama. Además, en algunas redes, la pasarela puede ser capaz de determinar si el "host" de destino en internet es inalcanzable. Las pasarelas de estas redes pueden enviar al "host" de origen mensajes de destino inaccesible cuando el "host" de destino sea inaccesible.

Si en el "host" de destino el módulo IP no puede enviar el datagrama debido a que el módulo de protocolo o el puerto del proceso indicado no estén activos, puede enviar un mensaje de destino inaccesible al "host" de origen.Otro caso se presenta cuando un datagrama debe ser fragmentado para poder ser enviado a través de una pasarela aún cuando el indicador "Don't Fragment" (No Fragmentar) esté activado. En este caso la pasarela debe desechar el datagrama y puede devolver un mensaje de destino inaccesible.

Mensaje de Tiempo Superado ("Time Exceeded Message")

Si la pasarela que está procesando el datagrama detecta que el campo tiempo de vida es cero debe desechar el datagrama. La pasarela puede también notificar el suceso al "host" de origen mediante el mensaje de tiempo de vida superado. Si un "host" que trata de reensamblar un datagrama fragmentado no puede hacerlo en el tiempo límite debido a fragmentos perdidos, descartará el datagrama y puede enviar un mensaje de tiempo de reensamblaje superado.Si el fragmento cero no está disponible no es necesario enviar ningún mensaje de tiempo superado.

Mensaje de Problema de Parámetros ("Parameter Problem Message")

Si la pasarela o "host" que procesa el datagrama encuentra un problema con los parámetros de cabecera, de modo que no puede completar el procesamiento del datagrama, debe desecharlo. Una potencial fuente de este tipo de problema son los

argumentos incorrectos en una opción. La pasarela o "host" puede también notificarlo al "host" de origen mediante el mensaje de Problema de Parámetros. Este mensaje sólo se envía si el error provocó que el datagrama fuera desechado.El puntero identifica el octeto de la cabecera del datagrama original donde fue detectado el error (puede estar en medio de una opción). Por ejemplo, 1 indica que algo va mal con el Tipo de Servicio y (si hay opciones presentes) 20 indica un error en el código de tipo de la primera opción.

Mensaje de Disminución del Tráfico desde el Origen ("Source Quench Message")

Una pasarela puede descartar datagramas de internet si no dispone del espacio de búfer suficiente para ponerlos en la cola de salida hacia la próxima red de la ruta a la red de destino. Si una pasarela descarta un datagrama por este motivo, puede enviar un mensaje de Disminución de Tráfico desde el Origen (DTO) al "host" de origen del datagrama. Un "host" de destino puede también enviar un DTO si los datagramas llegan demasiado rápido para ser procesados. El DTO es una petición al "host" para que reduzca el ritmo al que envía tráfico al "host" de destino. Una pasarela puede enviar un DTO por cada mensaje que descarta. Al recibir un DTO, el "host" de origen debe disminuir el ritmo de generación de tráfico al destino especificado hasta que deje de recibir DTOs de la pasarela. Después, el "host" de origen puede aumentar gradualmente la frecuencia de mensajes al destino hasta que vuelva a recibir DTOs.La pasarela o "host" puede enviar el DTO cuando se está acercando al límite de su capacidad, antes que esperar a que ésta se sobrepase. Esto significa que el datagrama de datos que provocó el DTO puede que sea enviado.

Mensaje de Redirección ("Redirect Message")La pasarela envía un mensaje de redirección a un "host" en la siguiente situación: Una pasarela, G1, recibe un datagrama internet de un "host" en una red a la cual la pasarela está conectada. G1 comprueba su tabla de encaminamiento y obtiene la dirección de la siguiente pasarela, G2, en la ruta hacia la red X, destino del datagrama en internet. Si G2 y el "host" identificado por la dirección internet de origen del datagrama están en la misma red, se envía un mensaje de redirección al "host". Un mensaje de redirección recomienda al "host" que dirija el tráfico destinado a la red X directamente a la pasarela G2, ya que se trata de un camino más corto hacia el destino. La pasarela reenvía el datagrama original a su destino en internet.No se envía ningún mensaje de redirección para aquellos datagramas con opciones IP de 'ruta de origen' y la dirección de la pasarela en el campo dirección de destino, incluso si existe una ruta mejor al destino final que la que pasa por la siguiente dirección en la ruta de origen.

Mensaje de Eco o de Respuesta de Eco ("Echo or Echo Reply Message")

Los datos recibidos en el mensaje de eco deben ser devueltos en el mensaje de respuesta de eco.El identificador y número de secuencia pueden ser usados por el emisor del eco como referencia para emparejar las respuestas con las peticiones de eco. Por ejemplo, el identificador podría usarse como un puerto en TCP o UDP para identificar una sesión, y el número de secuencia se iría incrementando con cada nueva petición de eco enviada. El "host" que hace eco devuelve estos mismos valores en la respuesta de eco.

Mensaje de Solicitud de Marca de Tiempo o de Respuesta de Marca deTiempo ("Timestamp or Timestamp Reply Message")

Los datos recibidos (una marca de tiempo) en el mensaje son devueltos en la respuesta junto con marcas de tiempo adicionales.La marca de tiempo es un entero de 32 bits que indica los milisegundos transcurridos desde la medianoche UT. Un posible uso de estas marcas de tiempo se describe en Mills [5].La Marca de Tiempo de Origen es el instante en el cual el mensaje fue manipulado por última vez por el emisor antes de enviarlo. La Marca de Tiempo de Recepción es el instante en el cual eldestinatario recibe el mensaje. Por último, la Marca de Tiempo de Transmisión es el momento en el cual el destinatario manipula el mensaje por última vez antes de enviarlo.Si la medida del tiempo no está disponible en milisegundos, o bien no puede ser indicada respecto a la medianoche UT, entonces se puede insertar cualquier valor de tiempo en la marca de tiempo, siempre y cuando el bit más significativo de la marca de tiempo sea puesto a uno para indicar que se trata de un valor no estándar.

El Identificador y Número de Secuencia pueden ser usados por el emisor del eco como ayuda para relacionar las respuestas con sus respectivas peticiones. Por ejemplo, el identificador puede usarse como un puerto en TCP o UDP para identificar una sesión, y el número de secuencia podría ser incrementado con cada petición enviada. El destinatario devuelve estos mismos valores en respuesta.

Mensaje de Solicitud de Información o de Respuesta de Información ("Information Request or Information Reply Message").

Este mensaje puede ser enviado indicando en el campo dirección de origen de la cabecera IP la dirección de red de origen y los campos de dirección de destino puestos a cero.Este mensaje puede ser enviado con la parte de red de la dirección de origen de la cabecera IP tomando un valor cero.El módulo IP que ha de responder debería enviar la respuesta con las direcciones completamente especificadas. Este es un mensaje mediante el cual un "host" puede saber el número de la red en laque se encuentra.El Identificador y Número de Secuencia puede ser usado por el emisor del eco como ayuda para relacionar las respuestas con sus respectivas peticiones. Por ejemplo, el identificador puede usarse como un puerto en TCP o UDP para identificar una sesión, y el número de secuencia podría ser incrementado con cada petición enviada. El destinatario devuelve estos mismos valores en la respuesta. El Código 0 puede ser recibido desde una pasarela o un "host".

Consideraciones De la Seguridad

Cuando no ha expirado una asociación anterior de la seguridad entre los partidos, estos mensajes SE DEBEN enviar con la autentificación. Sin embargo, el nodo NO DEBE establecer dinámicamente una nueva asociación de la seguridad para el propósito único de authenticar estos mensajes. La gerencia dominante automatizada es de cómputo intensiva. Esto se podía utilizar para una negación muy seria del ataque del servicio. Sería muy fácil hundir una blanco con SPIs falso de fuentes al azar del IP, y hace que comience para arriba sesiones dominantes inútiles numerosas de la gerencia para informar auténtico al remitente supuesto. En el acontecimiento de la pérdida de estado (tal como un fallo del sistema), el nodo necesitará enviar mensajes de la falta a todos los partidos que procuren la comunicación subsecuente. En este caso, el nodo pudo haber perdido la técnica de gerencia dominante que fue utilizada para establecer la asociación de la seguridad. Deje mucho mejor simplemente a pares saber que había una falta, y déjelos solicitar a la gerencia dominante según lo necesitado (en sus descansos escalonados). Recordarán la técnica de gerencia dominante anterior, y la recomienzan agraciado. Esto distribuye la carga del recomenzar entre sistemas, y las ayudas permiten que el nodo recientemente fallado maneje sus recursos de cómputo. Además, estos mensajes informan al recipiente cuando el remitente del ICMP está bajo ataque. Desemejante de otros mensajes de error del ICMP, los mensajes proporcionan suficientes datos para determinarse que estos mensajes están en respuesta a mensajes previamente enviados. Por lo tanto, es imprescindible que el recipiente acepta authenticado y unauthenticated mensajes de la falta. El registro del recipiente DEBE indicar cuando los mensajes del ICMP no se validan, y cuando los mensajes del ICMP no están en respuesta a un mensaje anterior válido Concepto del ICMP .- el paquete aislado perdió reconocido por el problema de los protocolos de un nivel más alto de todos los paquetes que eran perdidos = > colección específica y evitable de los detinations posibles predefinidos ICMP, IP, TCP de los mensajes de error...

Detalles del ICMP; especialmente silbido de bala etc del WRT. obligatorio para cada ICMP del anfitrión de TCP/IP como necesidad llana pseudo-superior de la carga útil de limitaciones de prevenir fugitivo las cascadas enumeran (p. 175) TFTP que no funciona (tapa del p. 179) otros ejemplos detallados (pp. 180-181)

ediciones de seguridad (comienzo) la comunicación administrativo prohibió (p.181) la edición los listserves posibles de las respuestas, USENET vuelva a dirigir las ediciones (pp. 184-185) concepto revisión de las comunicaciones de la rebajadora de las ediciones silbido de bala el ejemplo del laboratorio puso cómo en ejecucio'n (p. 171)

otras utilidades traceoute utilizado para qué: el diagnóstico del problema de la red no automatiza; mismo traceroute intensivo del recurso: subsistencia que incrementa descubrimiento del MTU de la trayectoria del parámetro de la TTL .

una discusión más general de capas el establecimiento de una red en relación con de la versión de los números OSI de la capa implica señales eléctricas = > significación de los repetidores de digital contra los puentes de las señales análogas: tome las decisiones solamente en la destinación en el nivel de Ethernet porqué: el funcionamiento publica el concepto original de Ethernet y del token ring como analogía de la línea de partido contra LANS cambiado (en la capa 2!) las rebajadoras, acodan 3 interruptores: comtemplaban la destinación del nivel del IP en tomar decisiones del passthru seguridad

vía la encaminamiento terminante de la fuente ¿el punto principal es que estas ediciones son todavía venir insisten que la trayectoria sea de una lista controlada es ésta la dirección derecha a ir? atado con alambre contra la versión sin hilos de la comunicación WW II: telegrafía contra la radio a ser características continuadas del servicio el viaje de cada paquete es no confiable independiente; los nodos proporcionan el mejor esfuerzo implican mucho que se hará en nivel del transporte

Interfaz

Este módulo ha sido diseñado especialmente para comunicarse con la capa IP. Aunque muchos de sus servicios también están disponibles a otros niveles, deben utilizarse con precaución. El hecho de que las capas superiores puedan utilizar el ICMP es una de las razones por las que IP envía hacia arriba la cabecera IP original de los datagramas que se reciben.

El ICMP ("Internet Control Message Protocol") se encarga de notificar diferentes errores y problemas que pueden producirse durante la transmisión de paquetes TCP/IP entre sistemas. En la práctica, los ataques basados en ICMP consisten en enviar mensajes falsos para hacer creer al sistema del usuario o al servidor IRC que se han detectado errores, y así provocar el corte de la comunicación que ambos mantenían.

Para que el ataque se realice con éxito es necesario enviar algún mensaje de error -como "Bad Port", "Network Unreachable", etc.-, al puerto utilizado para la comunicación IRC del cliente o del servidor. En el caso de los servidores suelen ser puertos fijos -como, por ejemplo, el estándar 6667-, mientras que en los clientes suele ser un puerto dinámico (a partir del 1024). Para evitar ataques como el anteriormente descrito, tanto los servidores como los clientes pueden utilizar cortafuegos hardware o software que filtren determinados paquetes ICMP.

Aplicaciones de ICMP

Hay dos aplicaciones simples y muy extendidas basadas en ICMP: el Ping y el Traceroute. El Ping usa los mensajes ICMP Echo y Echo Reply para determinar si un host es alcanzable. El Traceroute envía datagramas IP con bajos TTLs para que expiren durante la ruta que les dirige al destino. Utiliza los valores de los mensajes ICMP Time Exceeded para determinar en que parte de la red expiraron los datagramas y reconstruye así un esquema de la ruta hasta el host de destino. Estas aplicaciones se explican más detalladamente en Ping y Traceroute.

PROTOCOLO ARP.

ARP (Address Resolution Protocol) es el encargado de realizar las traducciones de direcciones lógicas a direcciones físicas. Esto es, traducir las direcciones IP utilizadas en las capas superiores a direcciones de dispositivos dependientes del hardware subyacente. Este hardware puede estar constituido por una red Ethernet, FDDI, un sistema AX.25, etc., cada uno de los cuales tiene sus propias características de direccionamiento. Este nivel, por tanto, aisla a las capas superiores (en especial a la capa IP) de los diferentes esquemas de nombramiento posibles a nivel físico.

Cuando un nodo de la red desea enviar un paquete a otra máquina debe averiguar su dirección física. La máquina fuente conoce sus propias direcciones IP y física (las direcciones de sus interfaces de red), pero toda la información que dispone sobre la máquina remota es su dirección IP. Para conocer la dirección física equivalente se envía un mensaje ARP Broadcast (en las redes sin la opción de Broadcast se suele confiar la tarea de resolver direcciones a un nodo conocido por los demás). Este mensaje lo reciben todas las máquinas de la red, pero sólo contesta la máquina solicitada. Este proceso, para el caso especial de una red Ethernet, se describe en [RFC826].

Existen situaciones, no obstante, en los que una máquina ni siquiera conoce su propia dirección IP. Es el caso, por ejemplo, de estaciones sin disco (en particular, terminales X-Window). En esta situación todas las estaciones son idénticas y ejecutan el mismo software (almacenado en una ROM o EPROM). La única diferencia entre ellas es la dirección física de su interfaz de red. Dado que para comunicarse con otros nodos necesitan conocer su propia dirección IP, realizan un proceso RARP (Reverse Address Resolution Protocol). Este consiste en el envío de un paquete RARP Broadcast. Este paquete es recibido, en particular, por una máquina (un servidor) que contiene una tabla de traducción entre direcciones físicas y direcciones IP. Dicha máquina envía a la primera una respuesta indicando qué dirección IP le corresponde. El procedimiento se describe en [RFC903].

Existen, todavía, dos extensiones al protocolo ARP a tener en cuenta. El primero [RFC1293] describe un procedimiento por medio del cual un sistema dado puede averiguar la o las direcciones del nodo situado al otro extremo de un enlace punto a punto. Ello resulta especialmente importante, por ejemplo, en redes de circuitos virtuales como ATM y Frame Relay. La segunda extensión [RFC1868] define un algoritmo a través del que un nodo concreto puede anunciar su retirada de la red. Ello es muy útil en accesos PROXY donde las direcciones asignadas a los nodos son dinámicas. Recientemente se ha definido una extensión al protocolo RARP [RFC1931] que permite la asignación de direcciones dinámicas a estaciones sin disco. Interfaz

PROCESOS DE ARP.-

PROC_ARP_BC.- Este proceso se encarga de inicializar y finalizar el módulo ARP. Los mensajes admitidos son MSG_INIT y MSG_QUIT. Los campos de información son ignorados.

PROC_ARP_SUP.- Este proceso es el encargado de realizar la traducción entre direcciones IP y direcciones físicas del dispositivo. Se sitúa entre la capa IP y el nivel físico. Admite mensajes MSG_MBUF con los campos siguientes:

Campo1: Ignorado.Campo2: Nombre del canal físico a través del cual se envía el datagrama.Campo3: Dirección IP destino.

En la implementación actual este proceso envía el mensaje directamente a la capa física, sin efectuar ninguna manipulación previa.

Estos son 4 tipos de mensajes ARP que podran ser mandados pore l protocolo ARP. Son identificados por 4 valores en el campo “operation” de un mensaje ARP. Los tipos de mensaje son:

ARP request, ARP reply, RARP request, RARP reply

Dos máquinas en una red física, se pueden comunicar solamente si conocen sus direcciones físicas de red. Los protocolos ARP y RARP se encarga de transformar una dirección IP en la dirección física correcta cuando un anfitrión o un encaminador envían un paquete a través de una red física.

Cuando dos máquinas dentro de una red física requieren compartir información nos encontramos con el problema de que ambas máquinas cuentan con una dirección IP así como una dirección física, pero para dicha transmisión de información solo la pueden realizar a través de la dirección física.

Para resolver el problema anterior la máquina A debe transformar la dirección IP en una dirección física que es la que utiliza el hardware para comunicarse con la máquina B. El problema de transformar direcciones de alto nivel en direcciones físicas se conoce como problema de asociación de direcciones.

TCP/IP utiliza dos técnicas para la definición de direcciones:

1. Asociación mediante transformación directa. 2. Definición mediante enlace dinámico.

Asociación mediante transformación directa

Esta técnica se utiliza en redes tipo proNet que utilizan números enteros pequeños para sus direcciones físicas y permite que el usuario elija una dirección de hardware cuando instala una tarjeta de interfaz en una computadora. Por lo tanto podemos asignar una dirección IP con el campo hostid igual a 1, 2, 3, etc. y configurar la dirección física con ese mismo nombre. Ejemplo:

Dirección IP                               Dirección física192.5.48.3                                  3

Por lo tanto la asociación mediante transformación directa se basa en  crear una función que resuelva la conversión entre direcciones IP y físicas de acuerdo al esquema de numeración que se utilizó en la instalación de la tarjeta de interfaz.

Pero este tipo de conversión se dificulta en redes donde no se puede elegir la dirección física como es el caso de redes orientadas a la conexión como ATM. En estos casos se podría utilizar una tabla que almacene en memoria los pares de direcciones y la función se encargaría de buscar la dirección física correspondiente para el envío de información.

Definición mediante enlace dinámico

Esta técnica es más utilizada en redes donde no podemos configurar la dirección física como es el caso de redes Ethernet.

Para evitar el uso de tablas en memoria, se utiliza un protocolo de bajo nivel para asignar direcciones en forma dinámica conocido como Protocolo de Asociación de Direcciones (ARP).

La función de este protocolo es transmitir por difusión un paquete especial que pide al anfitrión que posee la dirección IP deseada, que responda con su dirección física. Todos los anfitriones reciben la solicitud, pero solo el anfitrión deseado reconoce su propia dirección IP y envía una respuesta que contiene su dirección física.

Memoria intermedia para asociación de direcciones

La difusión es muy costosa para utilizarse cada vez que una máquina se quiere comunicar con otra. Para reducir los costos las computadoras que utilizan ARP cuentan con una memoria intermedia que almacena las direcciones IP y las direcciones físicas de las computadoras con las que se han comunicado. De esta manera, no se requiere utilizar ARP cada vez que se quiere comunicar con una computadora ya que primero busca si existe la relación de direcciones en la memoria intermedia.

La información así obtenida se guarda luego en una tabla ARP de orígenes y destinos, de tal forma que en los próximos envíos al mismo destinatario no será ya necesario realizar nuevas peticiones ARP, pués su dirección MAC es conocida.

Del mismo modo las computadoras que contestan el mensaje de difusión almacenan las direcciones de la máquina que solicito la comunicación. Estas direcciones son enviadas dentro del paquete que envió la máquina solicitante dentro del ARP.

Encapsulación y formato del protocolo ARP

Cuando los mensaje ARP viajan de una máquina a otra, se deben transportar en tramas físicas.

Para identificar que la trama transporta un mensaje ARP, el transmisor asigna un valor especial al campo de tipo en el encabezado de la trama y coloca el mensaje ARP en el campo de datos de la misma.

A diferencia de la mayor parte de los protocolos, los datos en los paquetes ARP no tienen un encabezado con formato fijo. Por el contrario, para hacer que ARP sea útil para varias tecnologías de red, la longitud de los campos que contienen direcciones depende del tipo de red. Sin embargo para hacer posible la interpretación de un mensaje ARP arbitrario, el encabezado incluye campos fijos cerca del comienzo, que especifican la longitud de las direcciones que se encuentran en los campos siguientes.

El formato de este encabezado es el siguiente:

Tipo de hardware especifica un tipo de interfaz de hardware para el que el transmisor busca una respuesta.

Tipo de prototipo especifica el tipo de dirección de protocolo de alto nivel que proporcionó el transmisor.

Operación especifica una solicitud ARP(1), una respuesta ARP(2), una solicitud RARP(3) o una respuesta RARP(4).

HLEN y PLEN permiten que ARP se utilice con redes arbitrarias ya que éstas especifican la longitud de la dirección de hardware y la longitud de la dirección del protocolo de alto nivel.

SENDER HA y SENDER IP proporcionan las direcciones IP y de hardware del transmisor.

TARGET IP y TARGET HA proporcionan la dirección IP del objetivo (ARP) o la dirección de hardware del objetivo (RARP).

Es importante resaltar que el formato de una dirección física utilizada por los protocolos 802 es el siguiente:

1Byte - 2Byte - 3Byte - 4Byte - 5Byte - 6Byte

ARP es pués un protocolo de bajo nivel que oculta el direccionamiento de la red en las capas inferiores, permitiendo asignar al administrador de la red direcciones IP a los host pertenecientes a una misma red física.

Los mensajes de petición ARP (ARP request) contienen las direcciones IP y Ethernet del host que solicita la información, junto con la dirección IP de la máquina destino. Los mensajes de respuesta ARP (ARP reply) son creados por el ordenador propietario de la IP buscada, que rellena el campo vacío con su dirección Ethernet y lo envía directamente al host que cursó la solicitud.

Cuando el host origen recibe la respuesta ARP y conoce la dirección física del host destino introduce esos datos en una tabla especial alojada en su caché, y lo mismo va haciendo con cada una de las parejas dirección IP-dirección física que utiliza en sus diferentes comunicaciones con otros host. Y no sólo eso; como las peticiones ARP se realizan por multidifusión, cada vez que pasa ante él un mensaje de respuesta ARP extráe del mismo la pareja IP-MAC y la incorpora a su tabla. De esta forma se va construyendo la tabla dinámicamente.

En sucesivas comunicaciones entre ambos host ya no será preciso realizar una nueva petición ARP, ya que ambos host saben las direcciones del otro.

Estas tablas se denominan tablas ARP o caché ARP, y son fundamentales para el funcionamiento y rendimiento óptimo de una red, pués reducen el tráfico en la misma al evitar preguntas ARP innecesarias.

tabla ARP

dirección IP dirección física

212.5.26.1 26-5A-C5-42-FD-11

212.5.26.2 2C-2A-48-A6-36-00

212.5.26.3 5D-F1-80-02-A7-93

Las tablas ARP son necesarias para poder dirigir tramas en una red, ya que las direcciones IP y las direcciones de las tarjetas de red son independientes, y no tienen ninguna equivalencia entre ellas, siendo necesario entonces algún método para poder obtener la equivalencia entre ambas.

De forma general, cuando una máquina desea comunicarse con otra a partir de su IP, lo primero que hace es mirar en su tabla ARP si tiene la dirección física asociada a esa dirección lógica. Si es así, envía directamente los paquetes al host destino. Si no encuentra la entrada adecuada en la tabla, lanza una petición ARP multidifusión a todos los host de su red, hasta encontrar respuesta, momento en el que incorpora la nueva entrada en su tabla ARP y envía los paquetes al destino.

Si la máquina destino no existe, no habrá respuesta ARP alguna. En estos casos, el protocolo IP de la máquina origen descartará las tramas dirigidas a esa dirección IP.

Cuando un host realiza una petición ARP y es contestado, o cuando recibe una petición o trama, actualiza su tabla ARP con las direcciones obtenidas. Estas entradas en la tabla

tienen un tiempo de vida limitado, con objeto de no sobrecargar la tabla con datos innecesarios, que suele ser de unos 20 minutos.

Si quieresver la tabla ARP de una máquina, tan sólo tenéis que abrir la consola del sistema y escribir el comando "arp -a". Si no encontráis entradas, abrid el navegador y hacer una petición HTTP a cualquier página web. Si volvéis a introducir en la consola el camando os aparecerá la entrada ARP del router o proxy que uséis para salir a Internet. En mi caso he obtenido la siguiente entrada:

.

Existen tecnologías de red que no usan la pila de protocolos TCP/IP, y que por lo tanto no manejan direcciones IP como base de enrutamiento general, por lo que debe haber algo que permita una técnica común de envío de tramas una vez llegadas a la red destino. Y este algo son las direcciones de las tarjetas de red de los host.

Comunicar entonces dos máquinas pertenecientes a redes o subredes diferentes, si la máquina destino no "oye" la petición ARP de la máquina origen.-

Esto es posible porque cuando un host realiza una petición ARP y no encuentra respuesta, envía la trama al router que tiene configurado como "gateway por defecto", siendo éste el encargado de transmitir la trama al exterior, hacia otros routers, enviando las tramas con la dirección IP del host destino y con su propia dirección física, proceso que continúa hasta que la trama llega al router perteneciente a la red en la que se encuentra el host destino. Entonces éste hace una petición ARP, obtiene la dirección física del host final y le envía la trama.

Cómo se entregan las tramas cuando me conecto mediante un modem y mi proveedor de Internet.- Pués es conexiones a dial-up, como las que hacemos a través de la línea telefónica, no es necesaria tarjeta de red alguna (en realidad pertenecemos a una red virtual, siendo los modem una especie de tarjetas de red virtuales), por lo que los paquetes se entregan directamente por medio de la dirección IP dinámica que nos asigna el proveedor en cada conexión y usando para ello el protocolo PPP.

ARP Proxi.-

En muchas redes, para evitar el proceso de peticiones ARP sin respuesta, se usa el protocolo denominado ARP Proxi, en el que el router de salida recoge todas las peticiones ARP que circulan por la red y observa si la IP destino pertenece a un host de la misma o a un host de otra red. En el primer caso deja pasar la petición, para que séa respondida por la máquina destino, pero en el segundo caso es él el que responde directamente a la máquina peticionaria con su propia dirección física, para posteriormente enrutar las tramas hacia la red destino.

Seguridad y ARP.-

Al igual que ocurre con casi todos los protocolos de comunicaciones, y en concreto TCP/IP, el protocolo ARP puede ser usado por un posible atacante para objetivos no deseados.

Una de las técnicas más usadas en este sentido es la conocida como ARP Spoofing que ,como su nombre indica, consiste el el uso del protocolo para hacerse pasar por quién no se es en realidad, es decir, para suplantar a otra persona o máquina.

Básicamente consiste en enviar a la máquina objetivo del ataque un paquete con la dirección IP que queremos suplantar pero con la dirección física de nuestra tarjeta de red. En este caso, la máquina objetivo guardará la entrada ARP en su tabla caché, y a partir de ese momento todos los paquetes que envíe a la dirección IP suplantada llegarán a la máquina del atacante, y no a su legítimo destinatario. Este ataque dura aproximadamente unos 20 minutos (varía según el sistema operativo de la máquina atacada), que es el tiempo que se guardan las entradas en las tablas ARP.

Cómo podemos enviar a una máquina un paquete falseado

Existen diferentes programas circulando por Internet que precisamente hacen esto, como arp-fun, que son fácilmente asequibles a cualquiera que los busque.

Estos ataques es posible realizarlos solo en el caso de redes LAN, ya que en cuanto nos encontremos con conexiones dial-up (modems, por ejemplo) no existen tarjetas de red a las que redireccionar. Además, las nuevas tarjetas de red hacen una actualización de las tablas ARP caché en intervalos muy cortos (unos cinco minutos), por lo que el ataque es de duración muy limitada.

Existen también programas específicos para controlar estos ataques, como ARPwatch, que observan los cambios que se producen en las entradas IP/Ethernet, enviando un correo al administrador de la red si aprecian cambios incorrectos.

ARP Gratuito

Cada vez que un computador inicia la configuración de una interface de red que hace uso del protocolo ARP, el protocolo ARP envía un paquete ARP con el fin de determinar si su dirección IP o dirección física está siendo utilizada por otro computador y así ofrecer la oportunidad a los demás computadores de actualizar su ARP Cache.

En un paquete ARP gratuito la dirección fisica destino es igual a la dirección física Fuente, y la dirección IP destino es igual a la dirección IP fuente. Si algún computador de la red local detecta un paquete ARP gratuito cuya dirección IP es la misma que la configurada de sus interface de red el mismo envía un paquete ARP indicando su dirección IP y dirección física al computador que transmitió el ARP gratuito. De esta manera el computador que envió el ARP gratuito genera un mensaje de advertencia indicando que dicha dirección IP está siendo utilizada por otro computador.

Nota: El protocolo ARP está definido en la RFC 826