PROTOCOLO BOOTP.

QUE ES BOOTP ? BOOTP se diseo originalmente para permitir la configuracin 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 informacin 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 algn 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 mnima sin informacin de configuracin, tpicamente almacenada en la ROM, obtenga informacin suficiente para comenzar el proceso de descargar el cdigo 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 direccin hardware; esta suele estar en una ROM del hardware. 2. El cliente BOOTP enva su direccin hardware en un datagrama UDP al servidor. Si el cliente conoce su direccin IP y/o la direccin del servidor, debera usarlas, pero en general los clientes BOOTP carecen de configuracin IP en absoluto. Si el cliente desconoce su direccin IP, emplea la 0.0.0.0. Si desconoce la direccin IP del servidor, utiliza la direccin de broadcast limitado (255.255.255.255). El nmero del puerto UDP es el 67. 3. El servidor recibe el datagrama y busca la direccin hardware del cliente en su fichero de configuracin, que contiene la direccin IP del cliente. El servidor rellena los campos restantes del datagrama UDP y se lo devuelve al cliente usando el puerto 68. Hay tres mtodos posibles para hacer esto: - Si el cliente conoce su propia direccin IP (incluida en la solicitud BOOTP), entonces el servidor devuelve directamente el datagrama a esa direccin. Es probable que la cach de ARP en la pila de protocolos del servidor desconozca la direccin hardware correspondiente a esa direccin IP. Se har uso de ARP para determinarla del modo habitual. - Si el cliente desconoce su propia direccin 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 direccin hardware del cliente porque el cliente no sabe su direccin IP y por lo

tanto no puede responder a una peticin 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 enva 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 direccin IP (permitindole responder a peticiones ARP) y comenzar el proceso de arranque.

SEGUNDA FASE DEL PROCESO BOOTP. En BOOTP, los clientes obtienen su configuracin en un proceso de dos fases que se muestra a continuacin: 1. El cliente BOOTP solicita una direccin IP as como otra informacin relevante. Esta informacin podra incluir normalmente las direcciones IP de un gateway (puerta de enlace predeterminada) o un servidor DNS. Para obtener ms informacin, consulte Opciones DHCP y BOOTP estndar 2. El cliente BOOTP tambin solicita informacin adicional. Esta informacin 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 especfico de su plataforma. El cliente slo necesita este archivo para completar su configuracin de inicio. Una vez que el servidor BOOTP ha respondido con toda la informacin 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 - Nmeros asignados de Internet para un alista completa. length Longitud en bytes de la direccin 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

Nmero 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 ms significante de este campo se usa como flag de broadcast. Todos los dems bits deben estar a 0; estn reservados para usos futuros. Normalmente, los servidores BOOTP tratan de entregar los mensajes BOOTREPLY directamente al cliente usando unicast. La direccin de destino en la cabecera IP se pone al valor de la direccin IP fijada por el servidor BOOTP, y la direccin MAC a la direccin hardware del cliente BOOTP. Si un host no puede recibir un datagrama IP en unicast hasta saber su propia direccin 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 direccin 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 retransmisin BOOTP. Client hardware address Fijada por el cliente y usada por el servidor para identificar cul 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 vaco o especifica un nombre genrico, 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 especfica del distribuidor (opcional). Se recomienda que el cliente llene siempre los cuatro primeros bytes con un "magic cookie" o galleta mgica. Si el cookie especfica de un distribuidor no se usa, el cliente debera utilizar 99.130.83.99 seguido de una marca de fin (255) y fijar los bis restantes a cero. Remitirse al RFC 1533 para ms detalles. APLICACIN DE BOOTP EN UN SERVIDOR DHCP DE WINDOWS2000.

Para configurar los servidores DHCP de Windows 2000 para que proporcionen informacin 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 especfica del cliente en la tabla BOOTP del servidor DHCP. Los clientes BOOTP utilizan la informacin guardada en la tabla BOOTP para completar la segunda fase de su proceso de inicio. Esta informacin 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.

CONFIGURACIN DE LA TABLA BOOTP. Cada registro de la tabla BOOTP contiene los tres campos en los que se incluye la informacin devuelta al cliente BOOTP: Nombre del archivo de imagen de inicio. Identifica el nombre de archivo genrico (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 CONFIGURACIN DE BOOTP. Para que los servidores DHCP de Windows 2000 suministren un archivo de imagen de inicio y la informacin del servidor TFTP a los clientes BOOTP, el servidor utiliza algunas opciones DHCP para cumplir con la informacin 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. Cdigo Descripcin

66 67

Nombre de servidor TFTP Nombre de archivo de inicio

Una vez que haya agregado entradas BOOTP a la tabla BOOTP de un servidor DHCP de Windows 2000, tambin configurar las opciones previas que se utilizarn para admitir a los clientes BOOTP. No necesitar configurar ms 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 peticin de BOOTP nada mas puede realizarse en la misma subred en la que se encuentra el cliente que hace la peticin 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.

ESTNDARES DE BOOTP.

El protocolo de inicio BOOTP es un estndar TCP/IP establecido para la configuracin 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 electrnico (E-mail) es probablemente la aplicacin TCP/IP ms usada. Los protocolos de correo bsicos de correo proporcionan intercambio de correo y

mensajes entre hosts TCP/IP hosts; se han aadido servicios para la transmisin de datos que no se pueden representar con texto ASCII de 7 bits. Hay tres protocolos estndares que se aplican a este tipo de correo. Todos son recomendados. El trmino SMTP se emplea con frecuencia para referirse a la combinacin de los tres protocolos, por su estrecha interrelacin, pero estrictamente hablando, SMTP es slo uno de los tres. Normalmente, el contexto hace evidente de cul de los tres se est hablando. Cuando haya ambigedad, se emplearn los nmeros STD o RFC. Los tres estndares son:

Un estndar 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 estndar es SMTP. Un estndar (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 interpretacin. 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 estn en ASCII de 7 bits con informacin de formato embebida: Postscript, Scribe, SGML, TEX, TROFF y DVI aparecen en el estndar). El nombre oficial del protocolo para este estndar es MAIL.

Un estndar para el encaminamiento de correo usando el DNS, descrito en el RFC 974. El nombre oficial del protocolo para este estndar 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 ingls, 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 ms all de las limitaciones impuestas por RFC 821. Actualmente hay tres RFCs que lo describen: o Un estndar 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 sesin SMTP. Si el servidor no soporta este RFC, responder con un error y el cliente podr terminar la sesin o intentar iniciar una sesin segn las reglas RFC 821. Si s lo soporta, puede responder con una lista de las extensiones que soporta.

Un protocolo para transmisin 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 extensin 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 ms que competir entre s. En particular, el RFC 1652 se titula SMTPSE para transporte MIME en codificacin "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 extensin, el cliente SMTP debe codificar el mensaje a 7 bits segn el estndar MIME o devolver un mensaje de error permanente al usuario. Esta extensin no permite el envo de datos binarios arbitrarios porque el RFC 821 fija la longitud mxima de las lneas aceptadas por un servidor SMTP a 1000 caracteres. Los datos que no son texto pueden tener con facilidad secuencias de ms de 1000 caracteres sin una secuencia <CRLF>. Nota: Las extensiones limitan especficamente el uso de caracteres no ASCII (aquellos con valor decimal superior a 127) al cuerpo de los mensajes - no estn permitidos en las cabeceras RFC 822.

Un protocolo para la declaracin del tamao del mensaje (RFC 1653) que permite a un servidor informar al cliente del tamao mximo de mensaje que puede aceptar. Sin esta extensin, un cliente slo puede ser informado de que un mensaje ha excedido el tamao mximo (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 tamao 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 retransmisin comn a muchos sistemas de correo en las que el correo atraviesa un nmero de host intermedios de la misma red y donde una transmisin con xito implica slo 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 travs de una pasarela puede alterar la entrega punto-a-punto, ya que SMTP slo garantiza la entrega fiable a la pasarela, no al host de destino, ms all de la red local. La transmisin punto SMTP en estos casos es host-pasarela, pasarela-host o pasarela-pasarela; SMTP no define lo que ocurre ms all de la pasarela.

CONTENIDO DEL MENSAJE. Cada mensaje tiene:

Una cabecera, o sobre, con estructura RFC 822. La cabecera termina con una lnea nula (una lnea con slo la secuencia <CRLF>). Contents. Todo lo que hay tras la lnea nula es el cuerpo del mensaje, una secuencia de lneas 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 sesin (el emisor) y el servidor el que responde a la solicitud de sesin (el receptor). Sin embargo, como el cliente suele actuar como servidor para un programa de correo del usuario, es ms 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 buzn al que se han de enviar las repuestas. Este campo lo aade el emisor. return-path Direccin y ruta hasta el emisor. Lo aade 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 sesin (el emisor) y el servidor el que responde a la solicitud de sesin (el

receptor). Sin embargo, como el cliente suele actuar como servidor para un programa de correo del usuario, es ms 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 sesin es el receptor.

INTERCAMBIO DE CORREO. El diseo de SMTP se basa en el modelo de comunicacin mostrado en la figura de abajo. Como resultado de la solicitud de correo de un usuario, el emisor SMTP establece una conexin 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 rplicas de correo estn definidas rgidamente, el intercambio se puede seguir en Flujo de Datos de SMTP. Todos los comandos, rplicas o datos

intercambiados son lneas de texto, delimitadas por un <CRLF>. Todas las rplicas tienen un cdigo numrico el comienzo de la lnea. 1. El emisor SMTP establece una conexin TCP con el SMTP de destino y espera a que el servidor enve un mensaje "220 Service ready" o "421 Service not available" cuando el destinatario es temporalmente incapaz de responder. 2. Se enva 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 debera 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-lnea 250 OK que incluye una lista de las extensiones de servicio que soporta. 3. El emisor inicia ahora una transaccin enviando el comando MAIL al servidor. Este comando contiene la ruta de vuelta al emisor que se puede emplear para informar de errores. Ntese que una ruta puede ser ms que el par buzb@nombre de dominio del host. Adems, 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 ms de un receptor). Esto se hace enviando uno o ms 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 envan todos los comandos rcpt, el emisor enva un comando DATA para notificar al receptor que a continuacin se envan los contenidos del mensaje. El servidor replica con "354 Start mail input, end with <CRLF>.<CRLF>". Ntese que se trata de la secuencia de terminacin que el emisor debera usar para terminar los datos del mensaje. 6. El cliente enva los datos lnea a lnea, acabando con la lnea <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 ms mensajes que enviar; cerrar la conexin con un comando QUIT, que ser respondido con "221 Service closing transmission channel". El emisor no tiene ms 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. 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.

DIRECCIN 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, va una pasarela. @host-a,@host-b:usuario@host-c Para un mensaje retransmitido. Contiene explcitamente informacin 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. Ntese 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 ENVO DE MENSAJES. En el siguiente escenario, el usuario abc en el host vm1.stockholm.ibm.comando enva una nota a los usuarios xyz, opq u rst en el host delta.aus.edu. Las lneas 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 Ntese 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 aplicacin principal de SMTP es el correo, de hecho para eso fue creado el protocolo SMTP.

SEGURIDAD EN SMTP. Las amenazas ms comunes en el correo electrnico son:

Los ataques pasivos sobre los protocolos bsicos del servicio de correo electrnico. 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 aplicacin escucha el trfico de la red y accede al contenido de los mensajes, as como a la identificacin del usuario: su nombre y password de acceso. Estos ataques pueden actuar sobre las aplicaciones de usuario ms extendidas como: Netscape, Outlook, Eudora y las de tipo Web-Mail. Por otro lado, el protocolo SMTP, en su versin original, no dispone de mecanismos de autenticacin del usuario que enva un mensaje. Esto permite el uso fraudulento de servidores SMTP por parte de personas ajenas a la organizacin, as como el envo de mensajes con direccin de correo falsa. Los problemas derivados de esta situacin han contribuido a una degradacin importante del servicio de correo electrnico, permitiendo la proliferacin 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 envo de mensajes falsificados desde el interior de la organizacin y han dificultado la utilizacin del servicio a personas de la organizacin con necesidad de desplazarse.

ESTNDARES QUE REGULAN SMTP. RFC 821 SMTP. RFC 1123 Requerimientos para host de Internet-Aplicacin y soporte. RFC 1651 SMTPSE. RFC 1652 SMTPSE para transporte MIME con codificacin 8 bit. RFC 1653 SMTPSE para declaracin de tamao 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 algn error durante la entrega de su mensaje. Pero no slo se encarga de notificar los errores, sino que tambin 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 decisin. 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 bsico 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 mdulo 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 trfico por una ruta ms corta. El propsito de estos mensajes de control no es hacer a IP fiable, sino suministrar informacin sobre los problemas en el entorno de comunicacin. Los mensajes ICMP se envan usando la cabecera IP bsica. 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" estn reservados para posteriores extensiones y deben ser cero al ser enviados, y los receptores no debern usar estos campos (excepto para incluirlos en la suma de control). Datagramas ICMP El protocolo ICMP no usa nmero de puerto de servicio y es por eso un poco ms dificultoso coleccionar detalles. ICMP usa un nmero de tipos diferentes de datagramas. Muchos de stos son inofensivos y normales, mientras otros slo 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 comnmente 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 nmero del tipo en lugar del puerto en la orden de contabilidad ipfwadm. Si usted especifica la direccin origen y/o destino en sus reglas, puede seguir la pista de dnde estn viniendo los ping, tales como si ellos se originan dentro o fuera de su red.

Una vez que ha determinado de dnde estn viniendo los datagramas, usted puede decidir si quiere poner reglas en un sitio para evitarlos o tomar alguna otra accin, como avisar al dueo de la red agraviante para avisarles del problema, o quizs incluso, accin legal si el problema es un acto malvolo. 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 mdulo de encaminamiento cuando detecta que otro puesto est usndolo como pasarela, aunque exista una ruta ms corta. Por ejemplo, despus del arranque, la tabla de encaminamiento de sophus puede estar incompleta. Puede que contenga las rutas a la red de Matemticas, a la dorsal FDDI, y el encaminamiento por defecto apuntando a la pasarela del Groucho Computing Center. De este modo, los paquetes para quark sern 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 eleccin como ruta y reenviar el paquete a niels, mientras tanto enva un mensaje Redirect ICMP a sophus dicindole la ruta superior. Esta parece ser una forma muy inteligente de evitar la configuracin manual de las rutas excepto las ms bsicas. De cualquier forma, hay que decir que depender de esquemas de encaminamiento dinmicos, 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 informacin de encaminamiento es efectivamente autntica. Esta situacin permite a malvolos intiles perturbar el desarrollo del trfico de la red completa, o incluso algo peor. Consecuentemente, el cdigo de red de GNU/Linux trata los mensaje Network Redirect como si fuesen Host Redirects. Esto minimiza los daos de un ataque restringindolos a slo un puesto, en vez de la red completa. Por otro lado, esto significa que se gener un poco ms de trfico en las mismas condiciones, ya que cada puesto hace que se genere un mensaje Redirect ICMP. Cada una de las rdenes de configuracin 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 configuracin 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 nmeros asignados. Los tipos de datagrama de ICMP aparecen tambin listados en uno de los ficheros de cabecera de la biblioteca estndar de C. El fichero /usr/include/netinet/ip_icmp.h, que pertenece al paquete con la biblioteca estndar de GNU, y que los programadores de C utilizan cuando escriben 'software' de red que utilice el protocolo de ICMP, tambin 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 tambin se muestran los nombre nemotcnicos que utiliza. Tabla 9-2. Tipos de datagramas de ICMP

Nmero de tipo 0 3 4 5 8 11 12 13 14 15 16 17 18

Nnemnico de iptables echo-reply destination-unreachable Source-quench Redirect echo-request time-exceeded parameter-problem timestamp-request timestamp-reply None None address-mask-request address-mask-reply

Descripcin del tipo Respuesta a eco Destino inaccesible Disminucin del trfico desde el origen Redireccin Solicitud de eco Tiempo superado Problema de parmetros Solicitud de marca de tiempo Respuesta de marca de tiempo Solicitud de informacin Respuesta de informacin Peticin de mscara de direccin Respuesta de mscara de direccin

Tipo Encabezado del datagrama Encabezado de la trama

Datos ICMP

rea de datos del datagrama IP

rea de datos de la trama

Final 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 dae. Si esto llega a ocurrir no se crear un nuevo mensaje ICMP sino que el primero se descartar sin ms. 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 comunicacin entre 2 hosts a nivel de la capa de red. Estos mensajes comprueban que las capas fsica (cableado), acceso al medio (tarjetas de red) y red (configuracin IP) estn correctas. Sin embargo, no dicen nada de las capas de transporte y de aplicacin las cuales podran estar mal configuradas.

PING enva mensajes de solicitud de eco a un host remoto e informa de las respuestas. 1. A enva 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 recibiramos 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 estn correctamente configurados o estamos intentando acceder a una red aislada o inexistente, recibiramos un mensaje ICMP de tipo 3 (Destination Unreachable).

Utilizacin de PING para diagnosticar errores en una red aislada . Nota: El comando ping 127.0.0.1 informa de si estn correctamente instalados los protocolos TCP/IP en nuestro host. No informa de si la tarjeta de red de nuestro host est correcta.

Utilizacin de PING para diagnosticar errores en una red de redes En el caso producirse errores de comunicacin en una red de redes con ms 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 nmero 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 enva un mensaje ICMP de tipo 11 (Time Exceeded) para informar al origen. Tiempo de Vida (TTL, "Time To Live") Si, de acuerdo con la informacin 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. Adems, 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 mdulo IP no puede enviar el datagrama debido a que el mdulo de protocolo o el puerto del proceso indicado no estn 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 travs de una pasarela an 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 tambin 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 lmite 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 ningn mensaje de tiempo superado. Mensaje de Problema de Parmetros ("Parameter Problem Message") Si la pasarela o "host" que procesa el datagrama encuentra un problema con los parmetros 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 opcin. La pasarela o "host" puede tambin notificarlo al "host" de origen mediante el mensaje de Problema de Parmetros. Este mensaje slo se enva 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 opcin). Por ejemplo, 1 indica que algo va mal con el Tipo de Servicio y (si hay opciones presentes) 20 indica un error en el cdigo de tipo de la primera opcin. Mensaje de Disminucin del Trfico desde el Origen ("Source Quench Message") Una pasarela puede descartar datagramas de internet si no dispone del espacio de bfer suficiente para ponerlos en la cola de salida hacia la prxima red de la ruta a la red de destino. Si una pasarela descarta un datagrama por este motivo, puede enviar un mensaje de Disminucin de Trfico desde el Origen (DTO) al "host" de origen del datagrama. Un "host" de destino puede tambin enviar un DTO si los datagramas llegan demasiado rpido para ser procesados. El DTO es una peticin al "host" para que reduzca el ritmo al que enva trfico 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 generacin de trfico al destino especificado hasta que deje de recibir DTOs de la pasarela. Despus, 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 lmite 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 Redireccin ("Redirect Message") La pasarela enva un mensaje de redireccin a un "host" en la siguiente situacin: 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 direccin 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 direccin internet de origen del datagrama estn en la misma red, se enva un mensaje de redireccin al "host". Un mensaje de redireccin recomienda al "host" que dirija el trfico destinado a la red X directamente a la pasarela G2, ya que se trata de un camino ms corto hacia el destino. La pasarela reenva el datagrama original a su destino en internet. No se enva ningn mensaje de redireccin para aquellos datagramas con opciones IP de 'ruta de origen' y la direccin de la pasarela en el campo direccin de destino, incluso si existe una ruta mejor al destino final que la que pasa por la siguiente direccin 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 nmero 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 podra usarse como un puerto en TCP o UDP para identificar una sesin, y el nmero de secuencia se ira incrementando con cada nueva peticin 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 de

Tiempo ("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 Recepcin es el instante en el cual el destinatario recibe el mensaje. Por ltimo, la Marca de Tiempo de Transmisin 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 ms significativo de la marca de tiempo sea puesto a uno para indicar que se trata de un valor no estndar. El Identificador y Nmero 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 sesin, y el nmero de secuencia podra ser incrementado con cada peticin enviada. El destinatario devuelve estos mismos valores en respuesta.

Mensaje de Solicitud de Informacin o de Respuesta de Informacin ("Information Request or Information Reply Message"). Este mensaje puede ser enviado indicando en el campo direccin de origen de la cabecera IP la direccin de red de origen y los campos de direccin de destino puestos a cero. Este mensaje puede ser enviado con la parte de red de la direccin de origen de la cabecera IP tomando un valor cero. El mdulo IP que ha de responder debera enviar la respuesta con las direcciones completamente especificadas. Este es un mensaje mediante el cual un "host" puede saber el nmero de la red en la que se encuentra. El Identificador y Nmero 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 sesin, y el nmero de secuencia podra ser incrementado con cada peticin enviada. El destinatario devuelve estos mismos valores en la respuesta. El Cdigo 0 puede ser recibido desde una pasarela o un "host". Consideraciones De la Seguridad Cuando no ha expirado una asociacin anterior de la seguridad entre los partidos, estos mensajes SE DEBEN enviar con la autentificacin. Sin embargo, el nodo NO DEBE establecer dinmicamente una nueva asociacin de la seguridad para el propsito nico de authenticar estos mensajes. La gerencia dominante automatizada es de cmputo intensiva.

Esto se poda utilizar para una negacin muy seria del ataque del servicio. Sera muy fcil hundir una blanco con SPIs falso de fuentes al azar del IP, y hace que comience para arriba sesiones dominantes intiles numerosas de la gerencia para informar autntico al remitente supuesto. En el acontecimiento de la prdida de estado (tal como un fallo del sistema), el nodo necesitar enviar mensajes de la falta a todos los partidos que procuren la comunicacin subsecuente. En este caso, el nodo pudo haber perdido la tcnica de gerencia dominante que fue utilizada para establecer la asociacin de la seguridad. Deje mucho mejor simplemente a pares saber que haba una falta, y djelos solicitar a la gerencia dominante segn lo necesitado (en sus descansos escalonados). Recordarn la tcnica 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 cmputo. Adems, 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 estn 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 estn en respuesta a un mensaje anterior vlido Concepto del ICMP .- el paquete aislado perdi reconocido por el problema de los protocolos de un nivel ms alto de todos los paquetes que eran perdidos = > coleccin especfica 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 anfitrin 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 comunicacin administrativo prohibi (p.181) la edicin los listserves posibles de las respuestas, USENET vuelva a dirigir las ediciones (pp. 184-185) concepto revisin de las comunicaciones de la rebajadora de las ediciones silbido de bala el ejemplo del laboratorio puso cmo en ejecucio'n (p. 171) otras utilidades traceoute utilizado para qu: el diagnstico del problema de la red no automatiza; mismo traceroute intensivo del recurso: subsistencia que incrementa descubrimiento del MTU de la trayectoria del parmetro de la TTL . una discusin ms general de capas el establecimiento de una red en relacin con de la versin de los nmeros OSI de la capa implica seales elctricas = > significacin de los repetidores de digital contra los puentes de las seales anlogas: tome las decisiones solamente en la destinacin en el nivel de Ethernet porqu: el funcionamiento publica el concepto original de Ethernet y del token ring como analoga de la lnea de partido contra LANS cambiado (en la capa 2!) las rebajadoras, acodan 3 interruptores: comtemplaban la destinacin del nivel del IP en tomar decisiones del passthru seguridad va la encaminamiento terminante de la fuente el punto principal es que estas ediciones son todava venir insisten que la trayectoria sea de una lista controlada es sta la direccin derecha a ir? atado con alambre contra la versin sin hilos de la comunicacin WW II: telegrafa contra la radio a ser caractersticas 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 mdulo ha sido diseado especialmente para comunicarse con la capa IP. Aunque muchos de sus servicios tambin estn disponibles a otros niveles, deben utilizarse con precaucin. El hecho de que las capas superiores puedan utilizar el ICMP es una de las razones por las que IP enva 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 transmisin de paquetes TCP/IP entre sistemas. En la prctica, 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 comunicacin que ambos mantenan. Para que el ataque se realice con xito es necesario enviar algn mensaje de error -como "Bad Port", "Network Unreachable", etc.-, al puerto utilizado para la comunicacin IRC del cliente o del servidor. En el caso de los servidores suelen ser puertos fijos -como, por ejemplo, el estndar 6667-, mientras que en los clientes suele ser un puerto dinmico (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 enva 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 ms detalladamente en Ping y Traceroute.

PROTOCOLO ARP. ARP (Address Resolution Protocol) es el encargado de realizar las traducciones de direcciones lgicas a direcciones fsicas. 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 caractersticas 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 fsico. Cuando un nodo de la red desea enviar un paquete a otra mquina debe averiguar su direccin fsica. La mquina fuente conoce sus propias direcciones IP y fsica (las direcciones de sus interfaces de red), pero toda la informacin que dispone sobre la mquina remota es su direccin IP. Para conocer la direccin fsica equivalente se enva un mensaje ARP Broadcast (en las redes sin la opcin de Broadcast se suele confiar la tarea de resolver direcciones a un nodo conocido por los dems). Este mensaje lo reciben todas las mquinas de la red, pero slo contesta la mquina solicitada. Este proceso, para el caso especial de una red Ethernet, se describe en [RFC826]. Existen situaciones, no obstante, en los que una mquina ni siquiera conoce su propia direccin IP. Es el caso, por ejemplo, de estaciones sin disco (en particular, terminales X-Window). En esta situacin todas las estaciones son idnticas y ejecutan el mismo software (almacenado en una ROM o EPROM). La nica diferencia entre ellas es la direccin fsica de su interfaz de red. Dado que para comunicarse con otros nodos necesitan conocer su propia direccin IP, realizan un proceso RARP (Reverse Address Resolution Protocol). Este consiste en el envo de un paquete RARP Broadcast. Este paquete es recibido, en particular, por una mquina (un servidor) que contiene una tabla de traduccin entre direcciones fsicas y direcciones IP. Dicha mquina enva a la primera una respuesta indicando qu direccin IP le corresponde. El procedimiento se describe en [RFC903]. Existen, todava, 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 extensin [RFC1868] define un algoritmo a travs 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 dinmicas. Recientemente se ha definido una extensin al protocolo RARP [RFC1931] que permite la asignacin de direcciones dinmicas a estaciones sin disco. Interfaz PROCESOS DE ARP.PROC_ARP_BC.- Este proceso se encarga de inicializar y finalizar el mdulo ARP. Los mensajes admitidos son MSG_INIT y MSG_QUIT. Los campos de informacin son ignorados. PROC_ARP_SUP.- Este proceso es el encargado de realizar la traduccin entre direcciones IP y direcciones fsicas del dispositivo. Se sita entre la capa IP y el nivel fsico. Admite mensajes MSG_MBUF con los campos siguientes: Campo1: Ignorado. Campo2: Nombre del canal fsico a travs del cual se enva el datagrama. Campo3: Direccin IP destino.

En la implementacin actual este proceso enva el mensaje directamente a la capa fsica, sin efectuar ninguna manipulacin 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 mquinas en una red fsica, se pueden comunicar solamente si conocen sus direcciones fsicas de red. Los protocolos ARP y RARP se encarga de transformar una direccin IP en la direccin fsica correcta cuando un anfitrin o un encaminador envan un paquete a travs de una red fsica. Cuando dos mquinas dentro de una red fsica requieren compartir informacin nos encontramos con el problema de que ambas mquinas cuentan con una direccin IP as como una direccin fsica, pero para dicha transmisin de informacin solo la pueden realizar a travs de la direccin fsica. Para resolver el problema anterior la mquina A debe transformar la direccin IP en una direccin fsica que es la que utiliza el hardware para comunicarse con la mquina B. El problema de transformar direcciones de alto nivel en direcciones fsicas se conoce como problema de asociacin de direcciones. TCP/IP utiliza dos tcnicas para la definicin de direcciones: 1. Asociacin mediante transformacin directa. 2. Definicin mediante enlace dinmico. Asociacin mediante transformacin directa Esta tcnica se utiliza en redes tipo proNet que utilizan nmeros enteros pequeos para sus direcciones fsicas y permite que el usuario elija una direccin de hardware cuando instala una tarjeta de interfaz en una computadora. Por lo tanto podemos asignar una direccin IP con el campo hostid igual a 1, 2, 3, etc. y configurar la direccin fsica con ese mismo nombre. Ejemplo: Direccin 192.5.48.3 IP 3 Direccin fsica

Por lo tanto la asociacin mediante transformacin directa se basa en crear una funcin que resuelva la conversin entre direcciones IP y fsicas de acuerdo al esquema de numeracin que se utiliz en la instalacin de la tarjeta de interfaz. Pero este tipo de conversin se dificulta en redes donde no se puede elegir la direccin fsica como es el caso de redes orientadas a la conexin como ATM. En estos casos se podra utilizar una tabla que almacene en memoria los pares de direcciones y la funcin se encargara de buscar la direccin fsica correspondiente para el envo de informacin. Definicin mediante enlace dinmico

Esta tcnica es ms utilizada en redes donde no podemos configurar la direccin fsica 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 dinmica conocido como Protocolo de Asociacin de Direcciones (ARP). La funcin de este protocolo es transmitir por difusin un paquete especial que pide al anfitrin que posee la direccin IP deseada, que responda con su direccin fsica. Todos los anfitriones reciben la solicitud, pero solo el anfitrin deseado reconoce su propia direccin IP y enva una respuesta que contiene su direccin fsica. Memoria intermedia para asociacin de direcciones La difusin es muy costosa para utilizarse cada vez que una mquina 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 fsicas 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 relacin de direcciones en la memoria intermedia. La informacin as obtenida se guarda luego en una tabla ARP de orgenes y destinos, de tal forma que en los prximos envos al mismo destinatario no ser ya necesario realizar nuevas peticiones ARP, pus su direccin MAC es conocida. Del mismo modo las computadoras que contestan el mensaje de difusin almacenan las direcciones de la mquina que solicito la comunicacin. Estas direcciones son enviadas dentro del paquete que envi la mquina solicitante dentro del ARP. Encapsulacin y formato del protocolo ARP Cuando los mensaje ARP viajan de una mquina a otra, se deben transportar en tramas fsicas. 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 tecnologas de red, la longitud de los campos que contienen direcciones depende del tipo de red. Sin embargo para hacer posible la interpretacin 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 direccin de protocolo de alto nivel que proporcion el transmisor. Operacin 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 direccin de hardware y la longitud de la direccin 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 direccin IP del objetivo (ARP) o la direccin de hardware del objetivo (RARP). Es importante resaltar que el formato de una direccin fsica utilizada por los protocolos 802 es el siguiente: 1Byte - 2Byte - 3Byte - 4Byte - 5Byte - 6Byte

ARP es pus 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 fsica. Los mensajes de peticin ARP (ARP request) contienen las direcciones IP y Ethernet del host que solicita la informacin, junto con la direccin IP de la mquina destino. Los mensajes de respuesta ARP (ARP reply) son creados por el ordenador propietario de la IP buscada, que rellena el campo vaco con su direccin Ethernet y lo enva directamente al host que curs la solicitud. Cuando el host origen recibe la respuesta ARP y conoce la direccin fsica 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 direccin IP-direccin fsica que utiliza en sus diferentes comunicaciones con otros host. Y no slo eso; como las peticiones ARP se realizan por multidifusin, cada vez que pasa ante l un mensaje de respuesta ARP extre

del mismo la pareja IP-MAC y la incorpora a su tabla. De esta forma se va construyendo la tabla dinmicamente. En sucesivas comunicaciones entre ambos host ya no ser preciso realizar una nueva peticin 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, pus reducen el trfico en la misma al evitar preguntas ARP innecesarias. tabla ARP direccin IP 212.5.26.1 212.5.26.2 212.5.26.3 direccin fsica 26-5A-C5-42-FD-11 2C-2A-48-A6-36-00 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 algn mtodo para poder obtener la equivalencia entre ambas. De forma general, cuando una mquina desea comunicarse con otra a partir de su IP, lo primero que hace es mirar en su tabla ARP si tiene la direccin fsica asociada a esa direccin lgica. Si es as, enva directamente los paquetes al host destino. Si no encuentra la entrada adecuada en la tabla, lanza una peticin ARP multidifusin a todos los host de su red, hasta encontrar respuesta, momento en el que incorpora la nueva entrada en su tabla ARP y enva los paquetes al destino. Si la mquina destino no existe, no habr respuesta ARP alguna. En estos casos, el protocolo IP de la mquina origen descartar las tramas dirigidas a esa direccin IP. Cuando un host realiza una peticin ARP y es contestado, o cuando recibe una peticin 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 mquina, tan slo tenis que abrir la consola del sistema y escribir el comando "arp -a". Si no encontris entradas, abrid el navegador y hacer una peticin HTTP a cualquier pgina web. Si volvis a introducir en la consola el camando os aparecer la entrada ARP del router o proxy que usis para salir a Internet. En mi caso he obtenido la siguiente entrada:

Existen tecnologas 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 tcnica comn de envo 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 mquinas pertenecientes a redes o subredes diferentes, si la mquina destino no "oye" la peticin ARP de la mquina origen.Esto es posible porque cuando un host realiza una peticin ARP y no encuentra respuesta, enva 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 direccin IP del host destino y con su propia direccin fsica, proceso que contina hasta que la trama llega al router perteneciente a la red en la que se encuentra el host destino. Entonces ste hace una peticin ARP, obtiene la direccin fsica del host final y le enva la trama. Cmo se entregan las tramas cuando me conecto mediante un modem y mi proveedor de Internet.- Pus es conexiones a dial-up, como las que hacemos a travs de la lnea telefnica, 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 direccin IP dinmica que nos asigna el proveedor en cada conexin 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 peticin, para que sa respondida por la mquina destino, pero en el segundo caso es l el que responde directamente a la mquina peticionaria con su propia direccin fsica, 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 tcnicas ms 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 quin no se es en realidad, es decir, para suplantar a otra persona o mquina. Bsicamente consiste en enviar a la mquina objetivo del ataque un paquete con la direccin IP que queremos suplantar pero con la direccin fsica de nuestra tarjeta de red. En este caso, la mquina objetivo guardar la entrada ARP en su tabla cach, y a partir de ese momento todos los paquetes que enve a la direccin IP suplantada llegarn a la mquina del atacante, y no a su legtimo destinatario. Este ataque dura aproximadamente

unos 20 minutos (vara segn el sistema operativo de la mquina atacada), que es el tiempo que se guardan las entradas en las tablas ARP. Cmo podemos enviar a una mquina un paquete falseado Existen diferentes programas circulando por Internet que precisamente hacen esto, como arp-fun, que son fcilmente 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. Adems, las nuevas tarjetas de red hacen una actualizacin de las tablas ARP cach en intervalos muy cortos (unos cinco minutos), por lo que el ataque es de duracin muy limitada. Existen tambin programas especficos 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 configuracin de una interface de red que hace uso del protocolo ARP, el protocolo ARP enva un paquete ARP con el fin de determinar si su direccin IP o direccin fsica est siendo utilizada por otro computador y as ofrecer la oportunidad a los dems computadores de actualizar su ARP Cache. En un paquete ARP gratuito la direccin fisica destino es igual a la direccin fsica Fuente, y la direccin IP destino es igual a la direccin IP fuente. Si algn computador de la red local detecta un paquete ARP gratuito cuya direccin IP es la misma que la configurada de sus interface de red el mismo enva un paquete ARP indicando su direccin IP y direccin fsica 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 direccin IP est siendo utilizada por otro computador. Nota: El protocolo ARP est definido en la RFC 826