21.3 Utilización de IP para determinar una dirección - materia

Resumen del Libro
TCP / IP
De Douglas Comer
2do Parcial Redes II
Incluye temas adicionales
Índice
21 ARRANQUE Y AUTOCONFIGURACIÓN (BOOTP Y DHCP) ............................................................................. 6
21.1 INTRODUCCIÓN .............................................................................................................................................. 6
21.2 LA NECESIDAD DE UNA ALTERNATIVA A RARP ...................................................................................................... 6
21.3 UTILIZACIÓN DE IP PARA DETERMINAR UNA DIRECCIÓN IP ...................................................................................... 6
21.4 POLÍTICA DE RETRANSMISIÓN BOOTP ............................................................................................................... 6
21.5 FORMATO DE LOS MENSAJES BOOTP ................................................................................................................ 7
21.6 PROCEDIMIENTO DE ARRANQUE EN DOS PASOS .................................................................................................... 7
21.7 CAMPO DE ÁREA DE VENDEDOR ESPECIFICO ......................................................................................................... 7
21.8 LA NECESIDAD DE UNA CONFIGURACIÓN DINÁMICA ............................................................................................... 7
21.9 CONFIGURACIÓN DINÁMICA DE ANFITRIÓN .......................................................................................................... 8
21.10 ASIGNACIÓN DINÁMICA DE DIRECCIONES IP ....................................................................................................... 8
21.11 OBTENCIÓN DE DIRECCIONES MÚLTIPLES ........................................................................................................... 8
21.12 ESTADOS DE ADQUISICIÓN DE DIRECCIONES ....................................................................................................... 8
21.13 TERMINACIÓN TEMPRANA DE ARRENDAMIENTO ................................................................................................. 9
21.14 ESTADO DE RENOVACIÓN DE ARRENDAMIENTO................................................................................................... 9
21.15 FORMATO DE LOS MENSAJES DHCP............................................................................................................... 10
21.16 OPCIONES Y TIPOS DE MENSAJES DHCP.......................................................................................................... 10
21.17 OPCIÓN OVERLOAD .................................................................................................................................... 10
21.18 DHCP Y NOMBRES DE DOMINIOS .................................................................................................................. 10
22 SISTEMA DE NOMBRE DE DOMINIO (DNS) ............................................................................................... 11
22.1 INTRODUCCIÓN ............................................................................................................................................ 11
22.2 NOMBRES PARA LAS MÁQUINAS ...................................................................................................................... 11
22.3 ESPACIO DE NOMBRE PLANO .......................................................................................................................... 11
22.4 NOMBRES JERÁRQUICOS ................................................................................................................................ 11
22.5 DELEGAR AUTORIDAD PARA LOS NOMBRES ........................................................................................................ 11
22.6 AUTORIDAD PARA SUBCONJUNTOS DE NOMBRES ................................................................................................ 11
22.7 NOMBRES DE DOMINIO TCP/IP ...................................................................................................................... 12
22.8 NOMBRES DE DOMINIO OFICIALES Y NO OFICIALES .............................................................................................. 12
22.9 COSAS POR NOMBRAR Y SINTAXIS DE LOS NOMBRES ............................................................................................ 13
22.10 ASOCIACIÓN DE NOMBRES DE DOMINIO EN DIRECCIONES ................................................................................... 14
22.11 RESOLUCIÓN DE NOMBRES DE DOMINIO ......................................................................................................... 15
22.12 TRADUCCIÓN EFICIENTE ............................................................................................................................... 15
22.13 DESEMPEÑO DEL CACHE: LA CLAVE DE LA EFICIENCIA ......................................................................................... 15
22.14 FORMATO DE LOS MENSAJES DEL SERVIDOR DE DOMINIOS .................................................................................. 15
22.15 FORMATO DEL NOMBRE COMPRIMIDO ........................................................................................................... 15
22.16 ABREVIATURA DE NOMBRES DE DOMINIO ........................................................................................................ 15
22.17 ASOCIACIONES INVERSAS ............................................................................................................................. 16
22.18 BÚSQUEDAS DE APUNTADOR ........................................................................................................................ 16
22.19 TIPOS DE OBJETOS Y CONTENIDO DEL REGISTRO DE RECURSOS ............................................................................. 16
22.20 OBTENCIÓN DE AUTORIDAD PARA UN SUBDOMINIO........................................................................................... 16
23 APLICACIONES: ACCESO REMOTO ............................................................................................................ 17
23.2 COMPUTACIÓN REMOTA INTERACTIVA .............................................................................................................. 17
23.3 PROTOCOLO TELNET ................................................................................................................................... 17
23.4 ADAPTARSE A LA HETEROGENEIDAD ................................................................................................................. 18
23.5 TRANSFERENCIA DE COMANDOS QUE CONTROLAN EXTREMO REMOTO .................................................................... 18
23.6 FORZAR AL SERVIDOR A LEER UNA FUNCIÓN DE CONTROL...................................................................................... 19
23.7 OPCIONES DE TELNET.................................................................................................................................. 19
23.8 NEGOCIACIÓN DE OPCIONES DE TELNET .......................................................................................................... 19
23.9 RLOGIN (BSD DE UNIX) ............................................................................................................................... 19
24 APLICACIONES: TRANSFERENCIA Y ACCESO DE ARCHIVOS ....................................................................... 20
24.2 ACCESO Y TRANSFERENCIA DE ARCHIVOS ........................................................................................................... 20
24.3 ACCESO COMPARTIDO EN LÍNEA ...................................................................................................................... 20
24.4 COMPARTIR MEDIANTE TRANSFERENCIA DE ARCHIVOS ......................................................................................... 20
2
24.6 CARACTERÍSTICAS DE FTP .............................................................................................................................. 20
24.7 MODELO DE PROCESO FTP ............................................................................................................................ 21
24.8 ASIGNACIÓN DE NÚMEROS DE PUERTO ............................................................................................................. 21
24.10 EJEMPLO DE UNA SESIÓN CON FTP ANÓNIMO .................................................................................................. 21
24.11 TFTP ....................................................................................................................................................... 22
24.12 NFS ........................................................................................................................................................ 22
24.13 IMPLANTACIÓN NFS ................................................................................................................................... 22
24.14 LLAMADA DE PROCEDIMIENTO REMOTO (RPC) ................................................................................................ 23
24.15 RPC PORT MAPPER ................................................................................................................................... 23
24.16 SERVICIOS, PUERTOS Y PROCESOS ................................................................................................................. 24
24.17 EL PROCESO PORTMAP ................................................................................................................................ 25
25 APLICACIONES: CORREO ELECTRÓNICO .................................................................................................... 26
25.2 CORREO ELECTRÓNICO .................................................................................................................................. 26
25.3 NOMBRES Y ALIAS DE LOS BUZONES DE CORREO.................................................................................................. 26
25.4 EXPANSIÓN DE ALIAS Y DIRECCIONAMIENTO DE CORRESPONDENCIA ........................................................................ 26
25.5 RELACIÓN ENTRE EL ENLACE DE REDES Y EL CORREO ELECTRÓNICO .......................................................................... 27
25.6 ESTÁNDARES TCP/IP PARA EL SERVICIO DE CORREO ELECTRÓNICO ......................................................................... 27
25.7 DIRECCIONES DE CORREO ELECTRÓNICO ............................................................................................................ 28
25.8 PSEUDO DIRECCIONES DE DOMINIO .................................................................................................................. 28
25.9 PROTOCOLO DE TRANSFERENCIA DE CORREO SIMPLE (SMTP) ............................................................................... 28
25.10 LA EXTENSIÓN MIME PARA DATOS NO ASCII .................................................................................................. 29
25.11 MENSAJES MIME MULTIPART ...................................................................................................................... 30
25.12 EL COMANDO TURN .................................................................................................................................. 30
28 SEGURIDAD DE INTERNET Y DISEÑO DEL MURO DE SEGURIDAD .............................................................. 31
28.1 INTRODUCCIÓN ............................................................................................................................................ 31
28.2 RECURSOS DE PROTECCIÓN ............................................................................................................................ 31
28.3 NECESIDAD DE UNA POLÍTICA DE INFORMACIÓN ................................................................................................. 31
28.4 COMUNICACIÓN, COOPERACIÓN Y DESCONFIANZA MUTUA ................................................................................... 32
28.5 MECANISMOS PARA LA SEGURIDAD DE INTERNET ................................................................................................ 32
28.5.1 Mecanismos de autenticación ......................................................................................................... 32
28.5.2 Mecanismos de privacidad .............................................................................................................. 32
28.6 FIREWALLS Y ACCESO A INTERNET .................................................................................................................... 33
28.7 CONEXIONES MÚLTIPLES Y VÍNCULOS MÁS DÉBILES .............................................................................................. 33
28.8 IMPLANTACIÓN DE FIREWALL Y HARDWARE DE ALTA VELOCIDAD ............................................................................ 34
28.9 FILTROS DE NIVEL DE PAQUETES ...................................................................................................................... 34
28.10 ESPECIFICACIÓN DE SEGURIDAD Y DE FILTRO DE PAQUETES .................................................................................. 34
28.11 CONSECUENCIA DEL ACCESO RESTRINGIDO PARA CLIENTES .................................................................................. 34
28.12 ACCESO A SERVICIOS A TRAVÉS DE UN FIREWALL ............................................................................................... 35
28.13 DETALLES DE LA ARQUITECTURA DE UN FIREWALL ............................................................................................. 35
28.15 IMPLANTACIÓN ALTERNATIVA DE UN FIREWALL................................................................................................. 36
28.16 MONITOREO Y ESTABLECIMIENTO DE CONEXIÓN ............................................................................................... 36
29 EL FUTURO DE TCP/IP .............................................................................................................................. 37
29.2 ¿POR QUÉ CAMBIAR TCP/IP E INTERNET? ........................................................................................................ 37
29.2.1 Nuevas tecnologías de comunicación y computación ..................................................................... 37
29.2.2 Nuevas aplicaciones ........................................................................................................................ 37
29.2.3 Incrementos en el tamaño y en la carga .......................................................................................... 37
29.2.4 Nuevas políticas .............................................................................................................................. 37
29.3 MOTIVOS PARA EL CAMBIO DEL IPV4 ............................................................................................................... 37
29.4 EL CAMINO HACIA UNA NUEVA VERSIÓN DEL IP .................................................................................................. 37
29.5 NOMBRE DEL PRÓXIMO IP ............................................................................................................................. 37
29.6 CARACTERÍSTICAS DEL IPV6 ........................................................................................................................... 38
29.8 FORMA GENERAL DE UN DATAGRAMA IPV6 ...................................................................................................... 38
29.8 FORMATO DEL ENCABEZADO BASE DEL IPV6 ...................................................................................................... 38
29.9 ENCABEZADOS DE EXTENSIÓN IPV6 ................................................................................................................. 39
29.10 ANÁLISIS DE UN DATAGRAMA IPV6 ............................................................................................................... 39
29.11 FRAGMENTACIÓN Y RE ENSAMBLAJE DEL IPV6 ................................................................................................. 39
29.12 CONSECUENCIA DE LA FRAGMENTACIÓN DE EXTREMO A EXTREMO ....................................................................... 39
3
29.13 RUTEO DE ORIGEN DEL IPV6 ........................................................................................................................ 40
29.14 OPCIONES DEL IPV6 ................................................................................................................................... 40
29.15 TAMAÑO DEL ESPACIO DE DIRECCIÓN DEL IPV6 ................................................................................................ 40
29.16 NOTACIÓN HEXADECIMAL CON DOS PUNTOS DEL IPV6 ...................................................................................... 40
29.17 TRES TIPOS BÁSICOS DE DIRECCIONES IPV6 ..................................................................................................... 41
29.18 DUALIDAD DE DIFUSIÓN Y MULTIDIFUSIÓN....................................................................................................... 41
29.19 UNA ELECCIÓN DE INGENIERÍA Y DIFUSIÓN SIMULADA ........................................................................................ 41
29.20 ASIGNACIÓN PROPUESTA DE ESPACIO DE DIRECCIÓN IPV6 .................................................................................. 42
29.21 CODIFICACIÓN Y TRANSICIÓN DE LA DIRECCIÓN IPV4 ......................................................................................... 42
29.22 PROVEEDORES, SUSCRIPTORES Y JERARQUÍA DE DIRECCIONES .............................................................................. 42
29.23 JERARQUÍA ADICIONAL ................................................................................................................................ 42
APÉNDICE 1 IPSEC ......................................................................................................................................... 43
A.1.1 ¿QUÉ ES IPSEC? ......................................................................................................................................... 43
A.1.2 LOS PROTOCOLOS IPSEC ............................................................................................................................... 43
A.1.2.1 Cabecera de autenticación AH ...................................................................................................... 43
A.1.2.2 Carga de Seguridad Encapsulada ESP ......................................................................................... 44
APÉNDICE 2 PROTOCOLO IKE ........................................................................................................................ 46
A.2.1 ¿PARA QUE SIRVE IKE? ................................................................................................................................ 46
A.2.2 CARACTERÍSTICAS DE IKE.............................................................................................................................. 46
A.2.3 FASES DE IKE ............................................................................................................................................. 46
APÉNDICE 3 NAT ........................................................................................................................................... 47
A.3.1 ¿QUÉ ES NAT? .......................................................................................................................................... 47
A.3.2 FUNCIONAMIENTO ...................................................................................................................................... 47
A.3.2.1 Estático .......................................................................................................................................... 47
A.3.2.2 Dinámico ....................................................................................................................................... 47
A.3.2.3 Sobrecarga..................................................................................................................................... 48
A.3.2.4 Solapamiento ................................................................................................................................. 48
APÉNDICE 4 HTTP.......................................................................................................................................... 49
A.4.1 QUE ES HTTP? .......................................................................................................................................... 49
A.4.2 EL PROTOCOLO SEGÚN LAS VERSIONES ............................................................................................................ 49
A.4.3 CARACTERÍSTICAS DEL PROTOCOLO ................................................................................................................. 49
A.4.4 DEFINICIONES RELACIONADAS CON EL PROTOCOLO ............................................................................................ 49
A.4.5 SISTEMAS INTERMEDIOS ............................................................................................................................... 50
A.4.6 MÉTODOS DE PETICIÓN EXISTENTES ................................................................................................................ 50
A.4.7 IDENTIFICACIÓN DE RECURSOS ....................................................................................................................... 51
A.4.8 MENSAJES DE RESPUESTA ............................................................................................................................. 51
A.4.9 CABECERAS HTTP....................................................................................................................................... 51
APÉNDICE 5 PAT............................................................................................................................................ 52
A.5.1 ¿QUÉ ES PAT? .......................................................................................................................................... 52
A.5.2 PROCEDIMIENTO PAT.................................................................................................................................. 52
APÉNDICE 6 BGP ........................................................................................................................................... 53
A.6.1 INTRODUCCIÓN .......................................................................................................................................... 53
A.6.2 FUNCIONES DE BGP .................................................................................................................................... 53
A.6.3 MENSAJES DE BGP ..................................................................................................................................... 53
A.6.4 PROCEDIMIENTOS FUNCIONALES DE BGP ........................................................................................................ 53
A.6.4.1 Adquisición de vecino .................................................................................................................... 54
A.6.4.2 Detección de vecino alcanzable ..................................................................................................... 54
A.6.4.3 Detección de red alcanzable .......................................................................................................... 54
APÉNDICE 7 RSVP.......................................................................................................................................... 55
A.7.1 ¿QUÉ ES RSVP? ........................................................................................................................................ 55
A.7.2 CARACTERÍSTICAS DE RSVP .......................................................................................................................... 55
A.7.3 ¿QUÉ ES EL SOFT STATE? ............................................................................................................................. 55
A.7.4 LOS MENSAJES DE RSVP .............................................................................................................................. 55
4
REFERENCIAS ................................................................................................................................................ 56
ACRÓNIMOS ................................................................................................................................................. 57
5
21 Arranque y autoconfiguración (BOOTP y DHCP)
21.1 Introducción
Una máquina necesita de cierta información para poder transmitir, como por ejemplo la
dirección de un router, su propia dirección IP, la máscara de red en uso, etc.
Estos dos protocolos son una alternativa a RARP. Utilizan un esquema cliente/servidor y
trabajan sobre UDP como protocolo de transporte.
21.2 La necesidad de una alternativa a RARP
Una máquina sin disco, posee un pequeño programa de arranque en su memoria no volátil
(ROM). Pero como este código es utilizado en diferentes máquinas, la dirección IP no puede
ser harcodeada en el mismo, por lo tanto una máquina deberá obtener su IP (y otra
información adicional) desde otra fuente. RARP brinda esta funcionalidad, pero posee tres
problemas:
1. Como es un protocolo de bajo nivel, su uso requiere acceso directo al HW, por tanto
puede resultar muy difícil para un programador implementar un servidor.
2. La respuesta por parte del servidor a una solicitud contiene muy poca información
(dirección IP del cliente de 4 bytes) y esto resulta molesto para redes que imponen un
tamaño mínimo de paquete.
3. Como RARP utiliza las direcciones físicas para identificar las máquinas, no puede
usarse en redes de asignación dinámica de direcciones de HW.
Para sortear estas deficiencias de RARP fue que se presentó BOOTP (Boot Strip Protocol) y
más tarde DHCP (Dynamic Host Configuration Protocol) como su sucesor.
21.3 Utilización de IP para determinar una dirección IP
La máquina que desea obtener información de la red, envía un mensaje en modo difusión (IP
destino 255.255.255.255). Este mensaje es recibido por el servidor quien contestará con la
información correspondiente utilizando también la difusión, ya que si lo enviara directamente
al solicitante, cuando este reciba el paquete con la información, no sabrá que es para él ya
que no conoce su propia IP.
21.4 Política de retransmisión BOOTP
BOOTP confiere toda la responsabilidad de la confiabilidad de la comunicación al cliente.
BOOTP requiere que UDP realice sumas de verificación para protegerse de la alteración de
datos, ya que IP sólo verifica el encabezado IP, y además que se envíe con el bit de no
fragmentación activado.
Para manejar pérdidas se usa la técnica de temporizador y retransmisión. Los tiempos
elegidos para el timeout son aleatorios, y se duplican después de cada retransmisión. Esto
sirve para evitar que BOOTP añada un tráfico excesivo a la red (aumentar el temporizador) y
para evitar colisiones (tiempos aleatorios).
6
21.5 Formato de los mensajes BOOTP
Con motivos de tener una implantación sencilla, los mensajes de ida y vuelta de BOOTP
tienen el mismo formato y poseen campos de longitud fija.
Algunos campos son:





OP: Especifica si se trata de un mensaje de solicitud o respuesta.
HTYPE: Especifica el tipo de hardware de la red.
HLEN: Especifica la longitud de la dirección física.
HOPS: Indica la cantidad de veces que la solicitud es reenviada por un servidor
BOOTP a otro servidor BOOTP. Cuando el cliente envía la solicitud, pone este valor
en 0.
SECONDS: Especifica la cantidad de segundos desde que el cliente inició el
arranque.
21.6 Procedimiento de arranque en dos pasos
BOOTP no proporciona una imagen de memoria a los clientes, sino que brinda información
necesaria para que los clientes puedan obtenerla. Utilizar un procedimiento de dos pasos
ayuda a mantener separadas las etapas de configuración y almacenamiento y esto sirve para
permitir al administrador configurar conjuntos de máquinas para que estas actúen en forma
idéntica.
Ejemplo:
Supongamos un conjunto de estaciones de trabajo en el cual hay diferentes arquitecturas de
HW. Dada la diversidad de arquitecturas, se sabe que una sola imagen de memoria no puede
operar en todas las máquinas, por lo tanto BOOTP otorga un campo llamado BOOT FILE
NAME, para que cada cliente pueda manifestar su preferencia depositando un nombre
genérico (ej.: Unix). El servidor BOOTP luego relaciona ese nombre genérico con el nombre
de archivo buscando en una base de datos de configuración.
Si el cliente envía el campo en 0, el servidor seleccionará una imagen de manera automática.
Enviar “Unix” en el BOOT FILE NAME significa que el cliente dice “quiero arrancar el SO
UNIX para esta máquina”
21.7 Campo de área de vendedor especifico
21.8 La necesidad de una configuración dinámica
Como RARP, BOOTP fue diseñado para un ambiente relativamente estático en el que cada
anfitrión tiene una conexión de red permanente. Un administrador crea un archivo de
configuración BOOTP para cada máquina que especifica un conjunto de parámetros para
cada anfitrión, y éste permanece relativamente estable dada la baja cantidad de cambios.
Con la llegada de las redes inalámbricas se hizo posible el transporte de una máquina de un
lugar a otro, y BOOTP no se adapta porque es necesario que un administrador agregue
parámetros a cada anfitrión y almacene la información en un archivo de configuración de
servidor BOOTP. BOOTP no admite una forma de asignar dinámicamente valores a
máquinas individuales.
7
21.9 Configuración dinámica de anfitrión
Para la asignación dinámica de direcciones IP, se creó el protocolo DHCP (Dynamic Host
Configuration Protocol) que extiende a BOOTP de dos formas:
1. Permite que una máquina adquiera toda la información que necesita con un sólo
mensaje.
2. Permite que una computadora posea una dirección IP en forma rápida y dinámica.
Para ser completamente general, DHCP permite tres tipos de configuraciones diferentes:
1. Al igual que BOOTP, DHCP permite la configuración manual, donde el
administrador puede asignar una dirección específica para una máquina determinada.
2. Configuración automática, mediante la cual el administrador permite a un servidor
DHCP asignar una dirección automática a una computadora que es conectada por
primera vez a la red.
3. Configuración dinámica. El servidor “presta” una dirección para una computadora
por tiempo limitado.
Un servidor DHCP puede configurarse para asignar direcciones estáticas a ciertas máquinas y
direcciones dinámicas a otras.
21.10 Asignación dinámica de direcciones IP
La asignación dinámica no es una transformación uno a uno, y el servidor no necesita
conocer la identidad del cliente a priori.
Como el DHCP permite a un anfitrión obtener todos los parámetros necesarios
para la comunicación, sin la intervención manual, también permite la
autoconfiguración, la cual se encuentra sujeta a restricciones administrativas.
Para hacer posible la autoconfiguración un servidor DHCP comienza con un conjunto de
direcciones IP que el administrador de red asigna al servidor para su manejo, además de las
reglas bajo las que opera el servidor. Cuando se produce un intercambio el servidor
proporciona una dirección al cliente, el cliente chequea la IP y si es aceptable ya puede
comenzar a usarla. Esta asignación, a diferencia de la asignación estática, tiene un
determinado tiempo de validez. Ese tiempo lo establece el servidor en el momento de la
asignación. Cuando se vence ese tiempo, el cliente debe renovar la dirección o dejar de
usarla.
El tiempo de arrendamiento de las direcciones puede variar dependiendo del propósito de la
red. Para adaptarse a todos los ambientes, DHCP no especifica un periodo fijo sino que
permite que el cliente solicite un determinado tiempo y que el servidor le comunique que ese
tiempo ha sido garantizado. Así el administrador puede decidir durante cuánto tiempo podrá
asignar un servidor una dirección a un cliente.
21.11 Obtención de direcciones múltiples
21.12 Estados de adquisición de direcciones
Un cliente puede estar en alguno de los siguientes 6 estados:
1. INITIALIZE: Cuando el cliente arranca por primera vez.
8
2. SELECT: Este estado es seteado luego de que el cliente envió el mensaje
DHCPDISCOVER (este mensaje es enviado en un datagrama UDP con el
puerto de destino activado para el puerto BOOTP). Los servidores que están
configurados para responder, responden con un mensaje DHCPOFFER.
Mientras el cliente está en estado SELECT, recolecta dichas respuestas.
3. REQUEST: Una vez que el cliente selecciona una de las respuestas enviadas y
negocia el tiempo de arrendamiento, envía un mensaje DHCPREQUEST y entra
en este estado.
4. BOUND: Con fin de enviar un acuse de recibo, el servidor contesta la solicitud
con un mensaje DHCPACK. Cuando el cliente lo recibe cambia su estado a
BOUND, en el cual el cliente pasa a usar la dirección obtenida. Este estado sería
el estado normal de operación.
5. RENEW: Se alcanza cuando un cliente en estado BOUND envía un mensaje
DHCPREQUEST porque ha caducado el temporizador que controla la
renovación. En ese mensaje viaja la dirección IP del cliente.
6. REBIND: Cuando un cliente envió un mensaje DHCPREQUEST y no hay una
respuesta por parte del servidor, el cliente lo considera inactivo. Cuando el
temporizador que controla la reasignación (este se setea cuando el cliente entra
en el estado BOUND y tiene un valor por defecto del 87.5% del valor de
arrendamiento) caduca, el cliente pasa al estado REBIND y comienza a difundir
mensajes DHCPREQUEST.
21.13 Terminación temprana de arrendamiento
Sirve para cuando un cliente quiere terminar su arrendamiento sin tener que esperar a que ese
tiempo expire. Es especialmente útil cuando el número de máquinas es más elevado que el
número de direcciones IP disponibles, ya que los clientes que consideren que no necesitan la
IP que tienen asignada, pueden liberarla para que otras máquinas la utilicen.
Para terminar un arrendamiento de manera temprana, el cliente envía un mensaje
DHCPRELEASE. Liberar una dirección es una acción final que previene que el cliente
continúe utilizando la dirección, así, luego de transmitir el mensaje de liberación, el cliente
no debe enviar ningún otro datagrama que utilice la dirección IP.
Cuando el mensaje DHCPRELEASE es enviando, el cliente pasa del estado BOUND al
estado INITIALIZE.
21.14 Estado de renovación de arrendamiento
Cuando un cliente adquiere el estado BOUND, inicia 3 temporizadores que controlan:
1. La renovación de arrendamiento
2. La reasignación de arrendamiento
3. La expiración de arrendamiento
El servidor puede determinar valores para estos temporizadores, pero en caso de que no lo
haga, el cliente asignará valores por omisión. El valor para el temporizador de renovación
será la mitad del tiempo de arrendamiento.
Cuando se vence el tiempo de renovación, el cliente pasa al estado RENEW y envía un
mensaje DHCPREQUEST con su IP y espera una respuesta por parte del servidor. El
servidor puede responder de dos formas:
1. Puede instruir al cliente para que deje de usar la IP enviando DHCPNACK, lo cual
obliga al cliente a volver a su estado INITIALIZE.
9
2. Puede aprobar que siga usando su IP actual enviando un DHCPACK. En este mensaje
pueden viajar nuevos valores de temporización.
Si el servidor no responde (por estar inactivo o inaccesible para el cliente) el cliente pasará al
estado REBIND en el momento en que se venza el temporizador de reasignación (este posee
un valor por defecto de un 87.5% del tiempo de arrendamiento) y comienza a difundir
mensajes DHCPREQUEST. Cualquier servidor habilitado para responder, puede hacerlo de
manera positiva o negativa. Si la respuesta es positiva, el cliente pasa nuevamente al estado
BOUND (en esa respuesta pueden enviarse nuevos valores de temporizacion). Si la respuesta
es negativa el usuario deberá dejar de utilizar la dirección IP inmediatamente.
Si estando en REBIND ningún servidor contesta los DHCPREQUEST del cliente, este
último pasará al estado INITIALIZE (para comenzar nuevamente la obtención de una IP) una
vez que haya vencido el tercer temporizador (el que controla la expiración).
21.15 Formato de los mensajes DHCP
El formato de los mensajes DHCP es muy similar al de los mensajes BOOTP, de hecho, los
protocolos son compatibles. Hay algunas diferencias en la interpretación de algunos campos,
como por ejemplo el campo UNUSED de BOOTP que en DHCP se llama FLAGS y se usa
para que el cliente pueda informarle al servidor si quiere que este último responda realizando
una unidifusión o una multidifusión por HW.
21.16 Opciones y tipos de mensajes DHCP
21.17 Opción Overload
Los campos SERVER HOST NAME y BOOT FILE NAME en el encabezado BOOTP
ocupan mucho espacio, entonces si un mensaje no contiene información en estos campos,
DHCP posee una Option Overload para que los campos puedan ser sobrecargados e indica al
receptor si debe ignorar el significado usual de estos campos y considerar las opciones con
las que se sobrecargó.
21.18 DHCP y nombres de dominios
10
22 Sistema de nombre de dominio (DNS)
22.1 Introducción
22.2 Nombres para las máquinas
22.3 Espacio de nombre plano
Se denomina espacio de nombre plano al conjunto original de nombres usados a través de
Internet formado por una secuencia de caracteres que no contiene ninguna estructura
adicional. Estos nombres eran administrados por la NIC (Network Information Center) que
luego fue reemplazado por la INTERNIC. (Internet Network Information Center).
Ventajas:
 Nombres convenientes y cortos
Desventajas:
 El espacio de nombres no puede generalizarse para conjuntos grandes de máquinas.
 Mucho tráfico en la única entidad administradora.
 Poca adaptabilidad para el crecimiento rápido.
22.4 Nombres jerárquicos
Se creó para la descentralización del mecanismo de asignación de nombres, delegando la
autoridad del espacio de nombres y repartiendo la responsabilidad de traducción de nombres.
La estructura elegida es una estructura de árbol invertido.
22.5 Delegar autoridad para los nombres
El espacio de nombres es particionado y la autoridad para los nombres de las subdivisiones
pasa a agentes designados.
Ejemplo:
local.localidad
La autoridad central autoriza a la localidad localidad a administrar una determinada partición
de nombres. En el ejemplo, local es la parte del nombre controlado por localidad.
Cuando la máxima autoridad añade una nueva localidad X, la añade a la lista de localidades
válidas y delega a X la autoridad sobre todos los nombres que terminen con “.X”
22.6 Autoridad para subconjuntos de nombres
En el espacio jerárquico de nombres, la autoridad puede subdividirse en cada nivel. La idea
es subdividir tanto como sea necesario para que las subdivisiones sean manejables.
Sintácticamente, cada vez que se subdivide el espacio de nombres, se introduce una nueva
partición del nombre.
Ejemplo:
local.grupo.localidad
11
La localidad localidad delega autoridad a grupo, por lo tanto podrá haber nombres distintos o
no de grupos para las diferentes localidades.
Ejemplo:
producción.grupo1.localidad1
producción.grupo1.localidad2
producción.grupo2.localidad1
En una red de redes TCP/IP, la jerarquía de nombres de máquina se asigna de
acuerdo con la estructura de la organización que obtiene la autoridad para dividir
el espacio de nombres y no necesariamente de acuerdo con la estructura de las
interconexiones de red física.
En una universidad puede pasar que dos departamentos diferentes compartan físicamente las
mismas instalaciones de red, pero pueden tener líneas de autoridad diferentes dentro de la
misma.
22.7 Nombres de dominio TCP/IP
El mecanismo que implanta una jerarquía de nombres para la red de redes TCP/IP se llama
DNS (Domain Name System) y tiene dos aspectos independientes:
1. Es abstracto. Especifica la sintaxis del nombre y las reglas para delegar autoridad de
los nombres.
2. Es concreto. Dice como se implementa el sistema distribuido que transforma los
nombres en direcciones IP.
El sistema de nombres de dominio llama a cada componente del nombre (separados por
punto) etiqueta, por lo tanto el siguiente ejemplo posee tres etiquetas:
cs.purdue.edu



cs: Este dominio corresponde al departamento de ciencias Computacionales de la
Universidad de Purdue.
purdue: Es el nombre de dominio para la Universidad de Purdue.
edu: Es el nombre de dominio para las instituciones educativas.
22.8 Nombres de dominio oficiales y no oficiales
El sistema de dominio dicta sólo la forma de los nombres y no sus valores, por lo tanto es
posible, para cualquier grupo que constituya una instancia del dominio seleccionar etiquetas
para todas las partes de su jerarquía.
Sin embargo la mayoría de los usuarios de tecnología de dominio sigue la jerarquía de
etiquetas usada por el sistema de dominio oficial de Internet por dos razones:
1. El esquema de Internet es completo y flexible y se adapta a una amplia variedad de
organizaciones.
2. Porque de esta manera pueden conectar sus instalaciones TCP/IP a la red global de
Internet.
La autoridad central, particionó sus dominios en los siguientes subdominios:
 COM
Organizaciones comerciales
12







EDU
GOV
MIL
NET
ORG
ARPA
INT
Instituciones educativas
Instituciones gubernamentales
Grupos militares
Centros mayores de soporte de red
Organizaciones
Para ARPANET (obsoleto)
Organizaciones internacionales
El nombre de nivel superior admite dos jerarquías de nombres diferentes:
1. El esquema geográfico
2. El esquema organizacional
El geográfico divide el universo de máquinas por país.
Ejemplo:
El dominio para el estado de Virginia en EEUU seria: va.us
La desventaja de este esquema es que los nombres son largos y difíciles de adivinar.
Como alternativa al esquema jerárquico geográfico existe el organizacional. Si una
organización quiere registrarse bajo cierto dominio, se lo solicita a la autoridad central y ésta
deberá autorizarlo.
Ejemplo:
Una máquina en el departamento de ciencias de la Universidad de Purdue tiene el siguiente
dominio:
xinu.cs.purdue.edu
El nombre de la máquina (xinu) fue aprobado y registrado por el administrador de la red local
en el departamento de ciencias. El administrador de tal departamento había obtenido previa
autorización para el dominio cs.purdue.edu de una autoridad de la red universitaria, quien a
su vez había obtenido permiso para administrar el subdominio purdue.edu de la autoridad de
Internet. La autoridad de Internet conserva el control del dominio edu, de manera que nuevas
universidades puedan añadirse sólo con su permiso.
22.9 Cosas por nombrar y sintaxis de los nombres
El esquema de nombres de dominio permite que los clientes distingan entre varios tipos de
entrada. Para esto, cada aspecto almacenado en el sistema es asignado a un tipo que
especifica si se trata de una máquina, buzón, usuario, etc.
Cuando una aplicación solicita resolver el problema de un nombre, especifica qué tipo de
aspecto que está buscando.
Es importante entender lo siguiente:
Un nombre dado puede transformarse en más de un aspecto en el sistema de
dominio. El cliente especifica el tipo de aspecto deseado cuando resuelve el
problema de un nombre, y el servidor devuelve objetos de ese tipo.
Además de especificar el tipo de respuesta, el sistema de dominio permite al cliente
especificar la familia de protocolos que utilizará.
13
raíz sin nombre
com
edu
gov
us
va
nsf
purdue
reston
cc
cs
ecn
Organizacional
cnri
Geográfico
Figura 22
22.10 Asociación de nombres de dominio en direcciones
El esquema de nombres de dominio incluye un sistema distribuido, confiable y de propósito
general para asociar nombres en direcciones.



Distribuido: Un conjunto de servidores opera en varias localidades de manera
conjunta.
Eficiente: La mayor parte de los nombres pueden ser asociados localmente, sólo unos
pocos requieren tráfico de red de redes.
Confiable: Una sola falla de una máquina previene al sistema para que opere
correctamente.
El mecanismo de dominio está conformado por sistemas independientes y cooperativos
llamados servidores de nombres. Un servidor de nombres es un programa servidor que ofrece
asociación entre nombres y direcciones IP.
La forma más fácil de entender cómo trabaja un servidor es verlo como un árbol que
corresponde a la jerarquía nombrada (Figura 22.3).
14
Servidor
raíz
Servidor
.com
Servidor
.edu
Servidor
.gov
Servidor
dec.com
Servidor
purdue.edu
Servidor
nsf.gov
…
Servidor
.us
Nivel
Superior
Servidor
va.us
Figura 22.3
La jerarquía del árbol se divide de la siguiente forma:




La raíz del árbol es un servidor que reconoce el dominio de nivel superior y
sabe que servidor resuelve cada dominio.
En el siguiente nivel, un conjunto de servidores de nombre proporciona
respuestas para un dominio de nivel superior (Ej.: edu).Un servidor en este
nivel sabe que servidor puede resolver cada uno de los subdominios bajo su
dominio
En el tercer nivel del árbol, el servidor de nombres proporciona respuestas
para el subdominio (Ej.: purdue bajo edu).
El árbol conceptual continúa con un servidor en cada nivel para el que se ha
definido un subdominio.
Las conexiones entre servidores no indican conexiones físicas. Cada servidor puede estar en
una red distinta dentro de la red de redes.
22.11 Resolución de nombres de dominio
CONTINUAR DESDE LA PÁGINA 395
22.12 Traducción eficiente
22.13 Desempeño del cache: la clave de la eficiencia
22.14 Formato de los mensajes del servidor de dominios
22.15 Formato del nombre comprimido
22.16 Abreviatura de nombres de dominio
15
22.17 Asociaciones inversas
22.18 Búsquedas de apuntador
22.19 Tipos de objetos y contenido del registro de recursos
22.20 Obtención de autoridad para un subdominio
16
23 Aplicaciones: acceso remoto
(TELNET y Rlogin)
23.2 Computación remota interactiva
23.3 Protocolo TELNET
Permite establecer una conexión TCP con un servidor de acceso a otro. TELNET transfiere
las pulsaciones de teclado directamente desde el teclado del usuario a la computadora remota.
También transporta la salida de la máquina remota de regreso al usuario. Este servicio se
llama transparent ya que el usuario ve como si su teclado y monitor estuvieran conectados
directamente a la máquina remota.
TELNET permite que el usuario especifique la máquina remota a través del nombre de
dominio o de la dirección IP. Ofrece tres servicios básicos:
1. Define una Terminal virtual de red que proporciona una interfaz estándar para los
sistemas remotos.
2. Incluye un mecanismo que permite negocias opciones entre cliente y servidor.
3. Maneja los extremos de la conexión de manera simétrica.
El cliente lee de
la terminal
Cliente
Telnet
El cliente manda
al servidor
Servidor
Telnet
El servidor
manda a una
pseudo terminal
Disp.
de E/S
usuario
sistema
operativo
El servidor recibe
del cliente
sistema
operativo
red de
redes
TCP/IP
Figura 23.1
Cuando un usuario invoca a TELNET, un programa de aplicación se convierte en el cliente,
que establece la conexión TCP con el servidor. Una vez hecha la conexión, el cliente acepta
los pulsos de teclado y los envía al servidor. Concurrentemente, acepta los caracteres
enviados por el servidor y los muestra en la pantalla de usuario.
El servidor puede atender varias conexiones con distintos clientes. Lo que se muestra en la
figura 23.1 es un esclavo dentro del servidor que atiende una conexión con un cliente.
El termino pseudo terminal de la figura se refiere a que el servidor no envía los caracteres
directamente al terminal, sino que los manda al SO que actúa simulando una terminal.
17
Que el servidor TELNET corra como una aplicación cliente tiene como:


Ventaja: Es más fácil controlarlo y modificarlo que si el servidor estuviera enclavado
en el SO.
Desventaja: Es menos eficiente porque los caracteres deben atravesar una capa mas
(el SO).
23.4 Adaptarse a la heterogeneidad
Para adaptarse a la heterogeneidad de los sistemas, TELNET define como deben mandarse
las secuencias de datos y comandos a través de Internet. Dicha definición se conoce como
network virtual terminal (NVT).
La idea es realizar una traducción de las pulsaciones de teclado antes de enviarlas.
Disp.
de E/S
usuario
conexión TCP
Cliente
Formato sistema
cliente
Sistema del
servidor
Servidor
Formato NVT
Formato sistema
servidor
Figura 23.2
La codificación usada por NVT es USASCII, que incluye 95 caracteres imprimibles y 33
códigos de control. Cada código de control de USASCII tiene una interpretación determinada
dentro de NVT (ver figura 23.3 en el libro) y los caracteres imprimibles tienen el mismo
significado que el conjunto de caracteres estándar de USACII.
Ejemplo:
Si el usuario presiona ENTER, el cliente deberá traducir el código que el sistema cliente usa
para el ENTER a CR-LF del sistema NVT y eso es lo que viaja a través de la conexión TCP
hasta el servidor que luego traducirá CR-LF al código que use el sistema del servidor.
23.5 Transferencia de comandos que controlan extremo remoto
NVT adapta las funciones de control creando funciones de control conceptuales. Algunas de
esas funciones son:
 IP
(Interrupt Process)
Interrupción del proceso
 AO
(Abort Output)
Salida abortada
 AYT
(Are You There)
Estas ahí. Prueba si el servidor responde
 EC
(Erase Character)
Borra carácter.
 EL
(Erase Line)
Borra línea
 SYNCH
(Syncronize)
Sincroniza. Despeja la trayectoria de datos
hasta que el punto de datos TCP es urgente, pero interpreta comandos
 BRK
(Break)
Teclas de pausa o señal de atención
El hecho de que NVT separe la definición de comandos de control *1 de los caracteres ASCII
normales tiene dos ventajas:
1. Permite mayor flexibilidad, porque de esta forma se pueden transmitir todas
las secuencias de caracteres ASCII posibles entre el cliente y el servidor *2
2. Permite que el cliente especifique las señales de manera no ambigua.
18
TELNET codifica los comandos de control a través de TCP usando la secuencia de escape. O
sea que envía un byte IAC (Internet as Command) que indica que a continuación sigue un
comando de control (Para ver los comandos de control, ver la figura 23.5 en el libro, pagina
415). Cuando se va a enviar un IAC y en los datos existe un carácter IAC, este se envía dos
veces.
23.6 Forzar al servidor a leer una función de control
En ciertos casos, puede pasar que los buffers del servidor estén llenos, entonces el servidor
anuncie un tamaño de ventana cero lo que evita la transferencia de datos a través de la
conexión TCP. Si en ese momento el usuario envía un IAC IP para finalizar la aplicación, el
servidor no leerá la secuencia porque TCP ha dejado de enviar datos a la máquina del
servidor. Para evitar esto, TELNET utiliza una señal fuera de banda. Esto se implementa
con el mecanismo de dato urgente. Cuando se va a transmitir un comando de control,
TELNET también envía un comando SYNCH, luego anexa un byte especial llamado marca
de datos y hace que TCP envíe los datos con el bit de URGEN DATA.
Los segmentos que llevan los datos urgentes evitan el control de flujo y así logran llegar al
servidor.
23.7 Opciones de TELNET
En TELNET las opciones son negociables, con lo que se logra reconfigurar una conexión
entre el cliente y el servidor. El rango de opciones es bastante amplio. Por ejemplo, una de
las opciones permite que TELNET opere en half-duplex (modo de operación normal) o fullduplex (Para ver más opciones ver la figura 23.6 en el libro, pagina 417).
23.8 Negociación de opciones de TELNET
Telnet utiliza un mecanismo de negociación de opción simétrica para permitir a los
clientes y a los servidores reconfigurar los parámetros que controlan su
interacción. Como el software TELNET comprende un protocolo NVT básico, los
clientes y los servidores pueden interoperar aun cuando uno comprenda las
opciones y el otro no.
23.9 Rlogin (BSD de UNIX)
*1: Nótese la diferencia entre caracteres de control y comando de control. El primero es un código ASCII que
sirve por ejemplo para mover el cursor, indicar una nueva línea, etc. Los caracteres de control llegan a la
aplicación cliente. En cambio los comandos, no llegan al cliente, ya que indican una terminación abrupta, o una
consulta al servidor, etc.
*2: Recordar que los comandos no llegan a la aplicación cliente. Por ejemplo, cuando se presiona CTRL+C para
la terminación de un programa, este nunca se entera de que el usuario presionó esa combinación de teclas, ya
que el SO lo mata antes.
19
24 Aplicaciones: transferencia y acceso de archivos
(FTP, TFTP, NFS)
24.2 Acceso y transferencia de archivos
Algunos sistemas son pensados como unidades centrales de almacenamiento que
proporcionan almacenamiento secundario a un conjunto de máquinas de bajo costo que no
poseen disco. Otros diseños se valen del almacenamiento remoto para archivar datos y en
otros casos la motivación principal es la compartición de datos entre varios usuarios.
24.3 Acceso compartido en línea
Compartir archivos se presenta en dos formas:
1. Acceso en línea
2. Copiado de archivo completo
El primero significa que permite a varios programas acceder de manera concurrente a un solo
archivo y los cambios estarán disponibles para todos los que acceden, mientras que el
copiado significa que cada vez que un programa quiera acceder a un archivo, este obtendrá
una copia local. El copiado se usa generalmente para datos de solo lectura, pero en caso de
que se hagan modificaciones, el programa hace los cambios locales y luego transfiere de
regreso el archivo modificado a la localidad original.
Los archivos remotos están integrados con los archivos locales, es decir, el usuario no
necesita acceder a los remotos a través de aplicaciones cliente particulares, sino que el acceso
a ellos es idéntico al acceso a los locales, por lo tanto se dice que se proporciona acceso
transparente, lo que brinda como ventaja que el acceso a archivos remotos ocurre sin
cambios visibles en los programas de aplicación.
Esta integración entre máquinas puede verse complicada por la diversidad de arquitecturas y
SO que estas puedan utilizar.
24.4 Compartir mediante transferencia de archivos
Acceder a datos remotos a través de una transferencia requiere dos pasos:
1. Obtener la copia local
2. Trabajar en la copia
La mayor parte de los mecanismos de transferencia no están integrados, por eso para que el
usuario pueda transferir debe acceder a aplicaciones cliente de propósito especial a las que le
deberá especificar la máquina de la que se obtendrán los archivos además de cuenta y clave
(de ser necesario).
24.6 Características de FTP
FTP (File Ttransfer Protocol) es un protocolo complejo porque lidia con las diferentes
arquitecturas de máquinas y además brinda más facilidades que la simple transferencia.

Acceso interactivo: Si bien está orientado para usarse mediante programas, posee
una interfaz que permite a los usuarios interactuar con los servidores remotos.
20


Especificación de formato: El FTP permite especificar al usuario el tipo y formato
de los datos almacenados.
Control de autenticación: Requiere que los usuarios se autoricen a si mismos con el
envío de nombre de conexión y una clave de acceso al servidor.
24.7 Modelo de proceso FTP
Un proceso servidor maestro espera las conexiones y crea un proceso esclavo para manejar
cada conexión, pero a diferencia de casi todos los servidores, el proceso esclavo no ejecuta
todos los cómputos necesarios, sino que crea un proceso (o varios) adicional que se encarga
de manejar la transferencia de manera separada.
Por la conexión de control se transmiten comandos que le dicen al servidor que archivo
transferir, mientras que los datos viajan por la conexión de transferencia de datos. Ambas
conexiones utilizan TCP como transporte.
Las conexiones y procesos de transferencia de datos pueden crearse de manera
dinámica cuando se necesitan, pero la conexión de control continúa a través de una
sesión. Una vez que la conexión de control desaparece, la sesión se termina y el
software en ambos extremos termina todos los procesos de transferencia de datos.
sistema cliente
transf.
de
datos
proceso
de
control
sistema
operativo
sistema servidor
conexión de
control de cliente
proceso
de
control
conexión de control
de servidor
transf.
de
datos
sistema
operativo
red de
redes
TCP/IP
Figura 24.1
24.8 Asignación de números de puerto
CONTINUAR DESDE LA PÁGINA 428
24.10 Ejemplo de una sesión con FTP anónimo
El acceso al FTP anónimo significa que un cliente no necesita una cuenta o clave para
acceder al servidor de recursos sino que accede con un nombre de conexión anónimo y una
21
clave de invitado. El servidor restringe el acceso a los archivos públicos que figuran en el
servidor.
Los mensajes de control y error entre el cliente y servidor FTP comienzan con un
número de tres dígitos seguido de texto. El software interpreta el numero; el texto
está dirigido a los usuarios.
24.11 TFTP
TFTP (Trivial File Transfer Protocol) es un segundo protocolo del grupo de protocolos
TCP/IP que se utiliza para la transferencia de archivos. Es una versión simplificada de FTP
para aquellas máquinas que no necesitan o no pueden soportar la complejidad del FTP, ya
que este requiere que se manejen varias conexiones TCP/IP simultáneas. TFTP restringe las
operaciones a transferencia de archivos sencilla y no proporciona autenticación.
SE PUEDE AGREGAR INFORMACION (PAGINA 432)
24.12 NFS
NFS (Network File System) proporciona un acceso de archivos compartidos en línea que es
transparente e integrado.
24.13 Implantación NFS
NFS se encuentra embebido en el SO. El mecanismo de acceso a archivos recibe las
peticiones y las transmite de manera automática al SW de sistema de archivos local o del
cliente NFS dependiendo de si el archivo solicitado esta en el disco local o en una máquina
remota.
aplicación
Mecanismo de acceso a
archivos
Local File
System
Disco
local
Cliente
NFS
Conexión de red
de redes hacia el
servidor NFS
Figura 24.3
22
24.14 Llamada de procedimiento remoto (RPC)
En lugar de definir el protocolo NFS de cero, los diseñadores prefirieron construir tres piezas
independientes.
El protocolo NFS, es un mecanismo general de llamada de procedimiento remoto o RPC
(Remote Procedure Call) y una representación de datos externa o XDR (External Data
Representation).
Desde el punto vista del programador, NFS no proporciona por si mismo nuevos
procedimientos que un programa pueda llamar, pero una vez que un administrador configura
el NFS los programas pueden acceder a los archivos remotos de la misma forma que acceden
a los archivos locales. RPC y XDR proporcionan mecanismos que los programadores pueden
usar para crear programas distribuidos.
Ejemplo RPC:
Un programador puede dividir un programa de un lado como cliente y de otro como servidor
y usar RPC como principal mecanismo de comunicación. En el lado cliente, el programador
designa como remotos algunos procedimientos, forzando así al compilador a incorporar el
código RPC en dichos procedimientos. En el lado del servidor, el programador implanta los
procedimientos deseados y utiliza otras características de RPC para declararlos como parte de
un servidor. Cuando el cliente llama a los procedimientos remotos, el RPC recolecta
automáticamente los valores para los argumentos, forma el mensaje y lo envía al servidor,
espera una respuesta, y cuando llega alacena los datos devueltos en los argumentos
designados. Entonces, gracias a RPC, la comunicación ocurre de manera automática,
haciendo posible que el programador se abstraiga de los detalles de la misma.
Ejemplo XDR:
Brinda a los programadores una manera de transmitir datos entre máquinas heterogéneas de
manera transparente. El caso puntual de aplicación puede verse en la escritura de enteros de
32 bits. Algunos sistemas utilizan Big Endian y otros Little Endian, por lo tanto si no se
hicieran las traducciones necesarias, el valor del entero pondría cambiar de un sistema a otro.
XDR resuelve este problema definiendo una presentación independiente en cada máquina. En
un extremo de la comunicación, un programa invoca procedimientos XDR para hacer la
conversión de la representación del hardware local a la representación independiente de
máquina. Una vez que los datos son transmitidos, se realizará el mismo proceso pero
invertido en el otro extremo.
24.15 RPC Port Mapper
El Port Mapper mapea programas RPC con números de puertos. Este programa realiza un
binding dinámico de posibles programas remotos. Esto es deseable ya que el rango de los
números de puerto reservados es muy pequeño en relación al número de programas remotos,
que potencialmente es muy grande.
También ayuda en la comunicación RPC. Cuando un RPC en el servidor inicia, el sistema le
puede asignar un puerto arbitrario y ese puerto puede no ser conocido por el cliente, por lo
tanto el cliente no sabrá a qué puerto enviar los paquetes para utilizar el RPC. El port mapper
tiene dos funciones para solucionar esto.
1. La primera es que el port mapper siempre escucha en el mismo puerto, por eso los
clientes saben a priori a que dirección enviar los paquetes.
2. La segunda es que cuando un RPC inicie, le informará al port mapper que puerto le
fue asignado y que números de programa está preparado para atender, así cuando un
23
cliente invoque al RPC el port mapper le indicará al cliente a donde enviar los datos.
Por tal motivo el port mapper debe ser iniciado antes que cualquier RPC.
El Port Mapper soporta dos protocolos UDP y TCP, y es accedido desde el puerto 111.
Los procedimientos del Port Mapper son los siguientes:









PMAPPROC_NULL: Este procedimiento no realiza ningún trabajo. Por convenio,
el procedimiento nulo de cualquier protocolo no requiere parámetros y no retorna
ningún resultado.
PMAPPROC_SET: Cuando un programa esta disponible en una máquina, se
registra el mismo con el programa Port Mapper en la misma máquina. El programa
pasa su número de programa, su número de versión, su número de protocolo de
transporte y el puerto donde espera servicio. El procedimiento retorna una variable
booleana puesta a TRUE si el procedimiento ha establecido correctamente el mapeo,
y FALSE en cualquier otro caso. El procedimiento rechaza el establecimiento del
mapeo si ya existe una tupla (programa, versión, protocolo).
PMAPPROC_UNSET: Cuando un programa ya no esta disponible, debe eliminarse
él mismo con el Port Mapper en la misma máquina. Los parámetros y resultado tienen
el mismo significado que en el procedimiento anterior. El número de protocolo y de
puerto son ignorados en este procedimiento.
PMAPPROC_GETPORT: Dado un número de programa, un número de versión y
un número de protocolo de transporte, este procedimiento retorna el número de puerto
en donde el programa está esperando solicitudes. Un número de puerto igual a cero,
quiere decir que el programa no ha sido registrado. El argumento puerto es ignorado.
PMAPPROC_DUMP: Este procedimiento enumera todas las entradas en la base de
datos del port mapper. El procedimiento no toma parámetros y retorna una lista de
programa, versión, protocolo y valores de puerto.
PMAPPROC_CALLIT: Este procedimiento permite a un cliente llamar a otro
procedimiento remoto en la misma máquina, sin conocer el número de puerto del
procedimiento remoto. Está destinado para soportar broadcast a programas remotos
arbitrariamente vía los puertos conocidos del port mapper.
Este procedimiento solo envía respuesta si el procedimiento ha sido correctamente
ejecutado y no responde en otros casos.
El Port Mapper comunica con el programa remoto utilizando solamente el protocolo
UDP.
Este procedimiento retorna el número de puerto del programa remoto, y la respuesta
es la respuesta del procedimiento remoto.
24.16 Servicios, Puertos y Procesos
Un proceso de servicio RPC se asocia a un programa constituido por un conjunto de
procedimientos, mediante un número de identificación. Cuando hay una llamada a un
procedimiento existirá un proceso encargado de la ejecución del servicio solicitado. Esto
implica que se tiene acceso al código de los diferentes procesos de servicio. El proceso de
servicio comunica con el modulo solicitado a través de un socket del dominio INTERNET,
es decir mediante un protocolo de transporte: UDP o TCP. El socket en cuestión se asocia a
un número de puerto. Puede ocurrir que se genere el proceso de servicio para que esté
permanentemente a la escucha en el puerto asociado, o que el puerto asociado forme parte de
un conjunto de puertos sobre los que escucha un proceso particular. Este último proceso es el
que creará el proceso de servicio en el momento adecuado.
24
24.17 El proceso Portmap
Este es un proceso que responde a un servicio RPC reservado (numero de programa 100000
y puerto 111). Su misión es la de asociar un número de puerto a cada número de servicio
RPC dado. Para establecer una transmisión RPC este proceso debe estar activo. Por esto,
cada nuevo servicio disponible debe ser notificado al proceso Portmap del sistema (proceso
llamado: mecanismo de grabación de servicio).
25
25 Aplicaciones: Correo electrónico
25.2 Correo electrónico
A diferencia de otros protocolos, el correo electrónico puede manejar las entregas con
retraso. Esto es, enviar el correo a pesar de que las conexiones hayan fallado o que la
máquina remota no esté disponible. Para lograrlo, se utiliza una técnica conocida como
spooling. En el envío, se coloca una copia del mensaje en un área de almacenamiento
privado, y el sistema inicia una actividad subordinada que realiza el envío hacia la máquina
remota mientras el emisor puede dedicarse a otras tareas.
envío de correo
del usuario
área spool
de salida
de correo
cliente
(transferencia
subordinada)
conexión TCP
buzones
para correo
entrante
servidor
(para aceptar
correo)
conexión TCP
para salida de correo
Interfaz
de
usuario
lectura de correo
del usuario
para correo entrante
Figura 25.1
25.3 Nombres y alias de los buzones de correo
Tres ideas importantes:
1. Los usuarios especifican recipientes, proporcionando pares de cadenas que
identifican el nombre de la máquina y la dirección de buzón.
2. Los nombres utilizados en estas especificaciones son independientes de otros
nombres asignados a las máquinas. Usualmente la dirección de un buzón es la misma
que la del usuario frente al sistema, y el nombre de la máquina el mismo que el del
dominio de la máquina aunque esto no tiene que ser así necesariamente.
3. La tercera realmente no se entiende, verla del libro (página 441).
25.4 Expansión de alias y direccionamiento de correspondencia
Los alias incrementan la funcionalidad del correo electrónico. Permiten a una persona tener
varios identificadores de correo como también generar un identificador asociado a varias
direcciones (listas de correo electrónico).
26
Normalmente, luego de que el usuario compone el mensaje y nombra un recipiente, el
programa de interfaz de correo consulta los alias locales para reemplazar el recipiente con la
versión transformada antes de pasar el mensaje al sistema de entrega.
25.5 relación entre el enlace de redes y el correo electrónico
Existen sistemas que pueden enviar e-mails sin estar conectados a Internet.
¿Cuál es la diferencia entre estos y los que se describen acá?
1. La primera es que una red de redes TCP/IP hace posible el servicio de entrega
universal.
2. El sistema de correo TCP/IP es inherentemente más confiable.
La primer razón es fácil de validar, ya que TCP/IP proporciona conexión a todas las
máquinas en la red de redes, y en esencia todas las máquinas están conectadas a una sola red.
La segunda se debe a que dado que el sistema emisor puede determinar siempre el estado
exacto de un mensaje, éste puede guardar una copia hasta tener la certeza de que el mensaje
fue correctamente enviado al servidor.
Los sistemas de correo que utilizan la entrega EAE pueden garantizar que cada
mensaje de correo se mantenga en la máquina del emisor hasta ser copiado con
éxito en la máquina del receptor.
Una alternativa a la entrega EAE es el uso de mail gateways. Es este caso los envíos se
realizan a una máquina intermedia que se encarga de completar el envío.
Las desventajas de las compuertas de mensajes son:


Una disminución de la confiabilidad ya que una vez que se envió una copia al
intermediario, se borra la copia local y mientras tanto ni el emisor ni el receptor
tienen una copia del mensaje.
Introducción de retardos.
Las ventajas:

Interoperabilidad. Permite enviar mensajes entre redes que soportan diferentes
tecnologías.
25.6 Estándares TCP/IP para el servicio de correo electrónico
TCP/IP persigue la interoperabilidad entre un amplio rango de sistemas. Para extenderla en el
sistema de correo, divide sus entandares en dos grupos:
1. Uno especifica el formato de los mensajes.
2. El otro especifica los detalles de intercambio de correo entre dos computadoras.
Un mensaje de correo está compuesto por un encabezado y por un cuerpo. El estándar TCP /
IP para los mensajes de correo, especifica el formato del encabezado así como su
interpretación. Por ejemplo, debe contener una línea que especifique el destino y otra que
especifique el remitente (To: y From:). Algunos campos del encabezado son opcionales,
como por ejemplo el campo de dirección de réplica (Cc:).
27
25.7 Direcciones de correo electrónico
Normalmente las direcciones de correo poseen una forma sencilla de recordar:
parte-local@nombre-dominio
Donde el nombre de dominio es el nombre de dominio de un destino de correo (técnicamente
especifica un distribuidor de correo, no un nombre de máquina) al que el correo debe ser
entregado y parte local es la dirección de un buzón en la máquina.
Ejemplo:
[email protected]
Sin embargo, las compuertas de correo pueden volver complejas a las direcciones.
Cualquiera que esté fuera de Internet, deberá direccionar a la compuerta de correo más
cercana, o tener un SW que lo haga automáticamente.
parte-local % nombre-dominio @ compuerta
Ejemplo:
comer % purdue.edu @ relay.cs.net
25.8 Pseudo direcciones de dominio
Es una forma que ayuda a resolver el problema de los diversos sistemas de correo, cada uno
con su propio formato de dirección, logrando que para el usuario todas las direcciones de
correo tengan la misma forma. Esto se logra utilizando direcciones especiales que serán
luego traducidas por el SW para el envío de correo.
25.9 Protocolo de transferencia de correo simple (SMTP)
SMTP (Simple Mail Transfer Protocol) es el protocolo de transferencia estándar.
SMTP se enfoca en:

Como el sistema de entrega de correo subyacente transfiere los mensajes a través del
enlace de una máquina a otra.
SMTP no especifica:




De que manera el sistema de correo acepta los mensajes de un usuario.
Como representa al usuario la interfaz de usuario de correo entrante.
Como se almacena el correo
Con que frecuencia el sistema de correo intenta enviar mensajes.
El establecimiento de la conexión entre cliente y servidor sigue el siguiente esquema:
1. El cliente establece una conexión de flujo confiable (TCP) y espera que el servidor
envíe el mensaje 220 READY FOR MAIL.
2. Al recibir el mensaje, el cliente envía el mensaje HELO (abreviatura de HELLO).
3. El servidor responde identificándose.
28
4. Una vez que se estableció la comunicación el emisor puede transmitir uno o más
mensajes de correo.
5. El emisor puede terminar la conexión o solicitar al receptor que se intercambien los
roles de emisor y receptor para que los mensajes puedan fluir en dirección opuesta
(mensaje TURN).
6. El receptor debe enviar un acuse de recibo por cada correo recibido.
7. El receptor también puede abortar la transferencia.
Una transacción de correo sigue los siguientes pasos:
1. Se comienza con el envío del comando MAIL, que proporciona la identificación del
emisor así como un campo FROM que contiene la dirección a donde se deberán
reportar los errores.
2. Un recipiente prepara su estructura de datos para recibir un nuevo correo y responde
al comando MAIL enviando un 250 OK.
3. Cuando al emisor le llega el 250 OK, emite una serie de comandos RCPT que
identifican a los recipientes del mensaje de correo. Los receptores deben enviar un
acuse de recibo por cada comando RCPT enviando un 250 OK o 550 No Such User
Here.
4. Después de que todos los comandos RCPT han sido reconocidos, el emisor emite un
comando DATA que indica al receptor que el emisor esta listo para enviar un correo
completo.
5. El receptor responde 354 Start mail input y especifica la secuencia de caracteres para
terminar el mensaje de correo.
La conexión se cierra en dos pasos. Primero el emisor envía una orden QUIT y espera una
respuesta. Luego sigue cerrando la conexión TCP. El receptor hará lo propio luego de enviar
su respuesta a la orden QUIT.
El siguiente ejemplo tomado de la RFC 821 muestra el proceso:
25.10 La extensión MIME para datos no ASCII
MIME (Multipurpose Internet Mail Extension) fue creado para la transmisión de datos no
ASCII a través de e-mail. La MIME no cambia ni reemplaza a SMTP, sino que lo extiende.
29
De hecho permite que datos arbitrarios sigan codificándose en ASCII y luego se envíen a
través de mensajes de mail estándar.
La información MIME reside dentro del encabezado 822 y posee cinco campos:
1.
2.
3.
4.
5.
versión MIME
Tipo de contenido
Codificación de transferencia de contenido
Identificador del contenido
Descripción del contenido
Los posibles tipos de contenido son:
1.
2.
3.
4.
5.
6.
7.
Texto
Multiparte
Mensaje
Audio
Imagen
Video
Aplicación
25.11 Mensajes MIME multipart
El tipo de contenido multipart permite cuatro subtipos:
1. Mixed: permite que un sólo mensaje contenga submensajes independientes en donde
cada uno tiene un tipo independiente y una codificación diferente. Un mensaje podrá
contener audio, imágenes y otros formatos en simultáneo.
2. Alternative: permite que un sólo mensaje sea representado de diferentes formas. Esto
es útil cuando se envían mensajes a varios recipientes que no utilizan el mismo HW /
SW de sistema.
3. Parallel: Permite que un mensaje tenga subpartes que tengan que ser vistas todas
juntas. Por ejemplo, subpartes de imagen y video que deben presentarse de manera
simultánea)
4. Digest: Permite que un solo mensaje contenga un conjunto de otros mensajes. Por
ejemplo, la colección mensajes de una discusión.
25.12 El comando TURN
Este comando (descrito en la RFC 821), conlleva importantes problemas de seguridad,
debido a que en ausencia de una fuerte autenticación del host que pide que el cliente y el
servidor intercambien roles, puede ser fácilmente utilizado para desviar correos de su destino
correcto, por tal motivo su uso fue deprecado. Los sistemas SMTP no deberían usarlo a
menos que puedan autentificar al cliente.
30
28 Seguridad de Internet y diseño del muro de seguridad
28.1 Introducción
La seguridad se apoya en tres acciones principales:
1. Prevención
2. Detección
3. Reacción
Prevenir los ataques, detectarlos en caso de que ocurran y reaccionar ante tales detecciones.
28.2 Recursos de protección
Seguridad significa integridad de los datos, confianza en que no existan accesos no
autorizados, que los recursos están libres de intromisiones y que no hay interrupciones de
servicios.




Integridad
Autenticidad
Privacidad
Disponibilidad
La seguridad está ligada no solo a los recursos físicos sino también a los recursos abstractos,
siendo esta ultima más difícil de implementar. La integridad de datos así como la
disponibilidad de datos son cruciales, y como la información puede ser accedida a través de
una red, la protección debe prevenir lecturas no autorizadas.
28.3 Necesidad de una política de información
Antes de que se implante un proyecto de seguridad, la organización debe asumir riesgos y
desarrollar una política clara de accesos de información y protección y darla a conocer a
todos sus empleados. Esto es crucial dado que:
Las personas son por lo general el punto más susceptible de cualquier esquema
de seguridad. Un trabajador malicioso, descuidado o ignorante de las políticas
de información puede comprometer la seguridad.
Un empleado debe ser capaz de responder preguntas básicas como:





¿Qué tan importante es la información para la organización?
¿Qué significan los derechos de autor?
¿Qué tanto de la información a la que tiene acceso puede discutir con otros
empleados?
¿Qué información puede importar a la compañía?
¿Qué son los derechos de propiedad intelectual?
Las políticas de información deben abarcar tanto la información “entrante” como la
“saliente”.
31
Las políticas de información pueden entrar en conflicto. Por ejemplo, si se consideran tres
organizaciones A, B y C, donde A permite que la información fluya hacia B pero no hacia C,
si la política de B permite fluir información hacia C eso entraría en conflicto con las políticas
de A.
28.4 Comunicación, cooperación y desconfianza mutua
Se dice que cuando tres organizaciones intercambian información, la seguridad de la política
de seguridad es el cierre transitivo de las políticas de seguridad individuales. Como
resultado:
Una organización no puede conocer el efecto de comunicarse e interactuar con
otras a menos que las dos organizaciones acuerden un nivel de confianza
recíproca.
28.5 Mecanismos para la seguridad de Internet
Los problemas de seguridad y los mecanismos de software que ayudan a prevenirlos pueden
clasificarse en tres conjuntos:
1. El primero se enfoca en la autorización, autenticación e integridad.
2. El segundo en el problema de la privacidad.
3. El tercero en la disponibilidad mediante el control de acceso.
28.5.1 Mecanismos de autenticación
Resuelven el problema de verificar la identificación. Cuando un cliente hace un primer
contacto con un servidor, este debe verificar que el cliente este autorizado antes de prestar el
servicio. El servidor puede utilizar diferentes técnicas para autenticar. Una de esas técnicas es
identificar al cliente según su dirección IP, aunque puede ser violada con facilidad si es que
un router que rutea paquetes al servidor es controlado por un impostor. El impostor puede
actuar como servidor para un cliente como de cliente para un servidor. La solución a este
problema radica en proporcionar un servicio confiable. Una forma de lograr esto es a través
del cifrado de clave pública. Para usar un sistema de clave pública cada participante debe ser
asignado a dos claves que son utilizadas para codificar y decodificar mensajes. Cada clave es
un entero largo.


Un participante publica una clave, llamada clave pública, en una base de datos
pública y conserva la otra en secreto.
Un mensaje se codifica mediante una clave que se puede decodificar usando la otra.
Por ejemplo, un emisor codifica un mensaje con la clave pública del receptor. Ese mensaje
puede solamente ser decodificada con la clave privada del receptor que sólo el receptor
conoce. Un cliente y un servidor que utilicen cifrado de clave pública pueden estar
razonablemente seguros de que su interlocutor es auténtico, aún si sus datagramas pasan a
través de una red poco segura.
28.5.2 Mecanismos de privacidad
Para dar privacidad con el mecanismo de cifrado de clave pública se procede de la siguiente
forma:
32
Supongamos dos participantes Ay B. Ambos tienen una clave pública y otra privada. Si A
tiene que enviar un mensaje a B y quiere que no sea leído por nadie más que B, lo que hace
es encriptar ese mensaje con la clave pública de B. Ese mensaje podrá ser desencriptado
únicamente con la clave privada de B, clave que es únicamente conocida por B. Así nos
aseguramos que sólo B lea el mensaje (privacidad).
En caso de que se quiera otorgar autenticidad e integridad se procede de la siguiente forma:
Si A quiere enviar a B un mensaje y quiere que B sepa que sólo él (A) le pudo haber enviado
ese mensaje, lo que hace A es encriptar el mensaje con su propia clave privada. Ese mensaje
podrá ser desencriptado con la clave pública de A. Con esto no se puede asegurar que sólo B
lea el mensaje (no aseguro privacidad), pero sí se asegura la autenticidad ya que B sabe que
solamente A puede haberle enviado el mensaje, porque nadie más puede encriptar con la
clave privada de A.
En caso de querer otorgar autenticidad y privacidad en simultáneo se procede a un doble
encriptado:
Primero A encripta con su clave privada y luego encripta con la clave pública de B.
28.6 Firewalls y acceso a Internet
Los mecanismos de control de acceso a la red de redes manejan el problema del filtrado
hacia las redes de las comunicaciones no previstas. A diferencia de los mecanismos de
autenticación y privacidad que pueden ser implementados a nivel de capa de aplicación, el
control de acceso a la red por lo general requiere cambios en los componentes básicos de la
infraestructura de la red. Una técnica para implementar esto es la de la creación de un
firewall. Un firewall aparece como entrada a la red de redes que será protegida, y divide a la
red de redes en dos regiones que se conocen informalmente como el interior y el exterior.
Firewall de la
organización
Resto de
Internet
Red de la
organización
exterior
interior
Figura 28.1
28.7 Conexiones múltiples y vínculos más débiles
En ciertos casos la imagen conceptual presentada por la figura 28.1 puede complicarse dado
que una organización puede poseer una red interna que tenga varias conexiones externas. En
tal caso, se deberá formar un perímetro de seguridad instalando un muro de seguridad en
cada conexión externa, los cuales deberán estar coordinados para que posean restricciones de
acceso idénticas.
33
Una organización que tiene múltiples conexiones externas debe instalar un muro de
seguridad en cada conexión externa y coordinar todos los muros de seguridad. Las
fallas para restringir en forma idéntica el acceso en todos los muros de seguridad
pueden hacer que la organización sea vulnerable.
28.8 Implantación de firewall y hardware de alta velocidad
En teoría, un firewall bloquea todas las comunicaciones no autorizadas entre máquinas
internas y externas a la organización. En la práctica esto depende de las políticas de la
organización, la carga de tráfico y la capacidad de conexión.
La implantación de un firewall requiere de una alta capacidad de procesamiento ya que se
deben analizar todos los datagramas que viajan a través de él (dentro-fuera o fuera-dentro).
Muchos routers poseen un mecanismo de filtrado de alta velocidad que puede usarse para
realizar muchas de las funciones necesarias, y pueden configurarse para que bloqueen
datagramas específicos.
28.9 Filtros de nivel de paquetes
El término filtrado de paquetes se debe a que el mecanismo de filtrado no conserva un
registro de las interacciones o una historia de los datagramas previos, por el contrario, el
filtro considera a cada datagrama de forma separada.
Como TCP / IP no dicta un estándar de filtrado, cada fabricante de routers puede seleccionar
las características que desee darle a su filtro. Algunos routers permiten configurar opciones
de filtrado diferentes para cada interfaz. Los parámetros de filtrado pueden ser direcciones IP
de origen o destino, numero de puerto, protocolo fuente, etc.
28.10 Especificación de seguridad y de filtro de paquetes
El uso de listas de filtrado (se pueden filtrar puertos bien conocidos, direcciones IP,
protocolos, etc.) en un firewall puede tener ciertos inconvenientes:



El número de puertos bien conocidos es extenso y un administrador podría necesitar
actualizar la lista continuamente debido a que un simple error puede volver
vulnerable al muro.
Gran parte del tráfico no viaja desde o hacia puertos bien conocidos. Además el uso
de Port Mapper asigna puertos dinámicamente para las aplicaciones que así lo
requieran.
Los filtros pueden ser vulnerados por el uso de túneles. Un datagrama prohibido
puede viajar encapsulado hacia un puerto habilitado.
Para sortear estos problemas con las listas de filtrado, lo que se hace es justamente lo inverso,
en vez de listar los datagramas que deben filtrarse, un firewall se configura para bloquear
todos los datagramas, excepto aquellos destinados a redes específicas, anfitriones y puertos
de protocolo para los que se ha aprobado la comunicación.
28.11 Consecuencia del acceso restringido para clientes
Si el firewall de una organización restringe los datagramas entrantes excepto para puertos
que corresponden a servicios puestos a disposición del exterior, una aplicación del interior no
podrá volverse cliente de un servicio del exterior. Esto es porque:
34





Cuando un cliente trata de comunicarse con un servidor de afuera, genera uno o más
datagramas y los envía.
Cada datagrama que sale, tiene el puerto de protocolo del cliente como puerto de
origen, y el puerto bien conocido del servidor como puerto de destino.
El firewall no bloquea los datagramas salientes.
Cuando se genera una respuesta, el puerto del cliente se vuelve el puerto de destino y
el del servidor el puerto fuente.
Cuando el datagrama llegue al firewall, será bloqueado ya que el puerto de destino
no está aprobado.
28.12 Acceso a servicios a través de un firewall
Dado la problemática del punto anterior, los usuarios necesitan un mecanismo seguro que
proporcione acceso a servicios del exterior.
En lugar de tratar de hacer que todas la maquinas de una organización sean seguras, lo que se
hace es asociar una computadora segura con cada firewall, y se la conoce como anfitrión
baluarte.
Anfitrión
baluarte
Red de
redes
interior
Red de
redes
exterior
Barrera exterior
Barrera de
entrada
Derivación habilitada
manualmente
Figura 28.3
La barrera exterior bloquea todo el tráfico entrante excepto:
1. Datagramas destinados a servicios en el anfitrión baluarte que la organización elige
mantener disponibles al exterior.
2. Datagramas destinados a clientes en el anfitrión baluarte.
La barrera de entrada bloquea el tráfico entrante excepto datagramas que vienen del anfitrión
baluarte.
28.13 Detalles de la arquitectura de un firewall
Las barreras mencionadas en el ítem anterior, son implementadas con routers que poseen
filtros de paquetes. Las redes interconectan los routers y el anfitrión baluarte.
Aún cuando un anfitrión baluarte es esencial para la comunicación a través de un
firewall, la seguridad de dicho firewall depende de la seguridad en el anfitrión
35
baluarte. Un intruso que abra una grieta en la seguridad en el SO del baluarte
puede lograr el acceso del anfitrión dentro del firewall.
28.15 Implantación alternativa de un firewall
28.16 Monitoreo y establecimiento de conexión
36
29 El futuro de TCP/IP
(IPng, IPV6)
29.2 ¿Por qué cambiar TCP/IP e Internet?
29.2.1 Nuevas tecnologías de comunicación y computación
Continuamente están saliendo nuevas tecnologías que los profesionales prueban en diferentes
ámbitos y aplicaciones y que pueden producir mejoras significativas y fomentar cambios en
las implementaciones ya existentes.
29.2.2 Nuevas aplicaciones
Las nuevas aplicaciones crean una demanda continua de infraestructura y servicios que los
protocolos actuales no pueden proporcionar.
29.2.3 Incrementos en el tamaño y en la carga
Los últimos años Internet ha experimentado un crecimiento exponencial tanto en tamaño
como en tráfico y todo apunta a que esta tendencia se siga manteniendo.
29.2.4 Nuevas políticas
A medida de que Internet se expande hacia nuevos países, cambia de forma adquiriendo
nuevas autoridades administrativas. Los cambios en las autoridades provocan cambios en las
políticas administrativas. La evolución continúa conforme se conectan más columnas
vertebrales de redes nacionales, produciendo un incremento complejo de las políticas que
regulan la interacción.
29.3 Motivos para el cambio del IPV4
Algunas de las principales razones que motivan el cambio del protocolo IP son:



El agotamiento del espacio de direcciones.
Soporte a nuevas aplicaciones.
Mejoramiento de la seguridad
29.4 El camino hacia una nueva versión del IP
El diseño de base elegido para la nueva versión del IP es SIPP (Simple IP Plus). Toma la
base del IP y añade algunas ideas de otras propuestas.
29.5 Nombre del próximo IP
En primera instancia la IAB propuso el nombre de IP versión 7 lo cual trajo confusiones por
el supuesto salto de dos versiones (5 y 6). Para evitar confusión el IETF cambió el nombre a
IP la nueva generación (IPng).
Luego, tras varias discusiones se decidió llamarlo IPV6.
37
29.6 Características del IPV6
IPV6 conserva varias de las características que hicieron exitoso al IPV4. Algunas son:



Soporta entrega sin conexión.
Permite al emisor seleccionar el tamaño de un datagrama.
Solicita al emisor que especifique la cantidad máxima de saltos para la entrega de un
datagrama.
Los cambios que introduce IPV6 pueden ser agrupados en cinco categorías:
1. Direcciones más largas. Se paso de 32 a 128 bits.
2. Formato de encabezado flexible. El encabezado es incompatible con la versión
anterior ya que IPV4 usa un encabezado donde sólo las opciones son de tamaño
variable.
3. Opciones mejoradas. Se incluyen nuevas opciones que proporcionan capacidades
adicionales no disponibles en IPV4.
4. Soporte de asignación de recursos. Permite la pre asignación de recursos de red.
5. Previsión para extensión del protocolo. Se pasa de un protocolo que especifica
TODOS los detalles a otro que puede permitir características adicionales.
29.8 Forma general de un datagrama IPV6
El formato del datagrama cambia completamente. El encabezado base es de tamaño fijo
seguido por posibles encabezados de extensión y luego los datos.
opcional
Encabezado base
Extensión 1 de
encabezado
…
Extensión n de
encabezado
DATOS
Figura 29.1
29.8 Formato del encabezado base del IPV6
Cambios en los encabezados de los datagramas:







La alineación se cambió de múltiplos de 32 bits a múltiplos de 64 bits.
Los campos de longitud de encabezado se eliminaron, y el campo de longitud de
datagrama se cambió por el campo PAYLOAD LENGTH.
Los campos que llevan las direcciones (fuente y destino) se incrementaron a 16 bytes
(128 bits).
La información de fragmentación se ha movido de los campos fijos en el encabezado
base hacia un encabezado de extensión.
El campo TTL se reemplazó por el de HOP LIMIT (limite de saltos)
El campo TOS se cambió por el FLOW LABEL.
El campo protocolo se cambió por un campo que especifica el tipo del próximo
encabezado.
38
4
16
ETIQUETA DE FLUJO
VERS
LONGITUD DE PAYLOAD
PROX. ENCAB.
31
LIMITE DE SALTOS
DIRECCION DE FUENTE
DIRECCION DE DESTINO
Figura 29.2
29.9 Encabezados de extensión IPV6
La idea de utilizar encabezados de extensión nació para lograr tanto eficiencia como
generalidad. No todas las características del protocolo son necesarias en todos los
datagramas, por eso es útil la capacidad de agregar sólo los encabezados necesarios como
encabezados de extensión, que son similares a las opciones de IPV4.
29.10 Análisis de un datagrama IPV6
Cada encabezado de extensión posee un campo que determina cual será el siguiente
encabezado (NEXT HEADER).
29.11 Fragmentación y re ensamblaje del IPV6
En IPV4, si un datagrama es más grande que el MTU, los routers intermedios podían
fragmentar el datagrama. En cambio en IPV6 la fragmentación está restringida a la fuente
para liberar a los intermediarios de esta acción. Para esto la fuente utiliza la técnica MTU
Discovery. La fragmentación en si es bastante parecida a la de IPV4, ya que hay un campo
que indica el desplazamiento y otro que indica si hay mas fragmentos.
ENCAB. PROX
RESERVADO
DESPLAZAMIENTO DE FRAG.
IDENTIFICACION DE DATAGRAMA
MF
Figura 29.5
29.12 Consecuencia de la fragmentación de extremo a extremo
La fragmentación EAE (extremo a extremo) está fomentada por la reducción de carga para
los routers intermedios, para que justamente estos se dediquen a rutear y no a fragmentar. Sin
embargo esto trae una consecuencia, que es que los routers no puedan cambiar las rutas como
en IPV4 ya que dicha acción puede modificar el tamaño del MTU.
39
Un protocolo de red de redes que use la fragmentación de EAE requiere que el
emisor descubra el Path MTU para cada destino y que fragmente cualquier
datagrama que salga si es mayor que el Path MTU. La fragmentación de EAE no se
adapta al cambio de rutas.
Para solucionar el cambio de rutas, si un router intermedio necesita fragmentar un datagrama,
en vez de hacerlo, crea un túnel de IPV6 a través de IPV6. En vez de modificar el datagrama
original, crea uno completamente nuevo que encapsula el datagrama original como dato.
Como resultado, lo que fragmenta es el nuevo datagrama replicando el encabezado base e
insertando un encabezado de extensión en cada fragmento. Luego envía todos los fragmentos
al destino.
29.13 Ruteo de origen del IPV6
Para especificar opciones de ruteo desde el origen, a diferencia de IPV4 que usaba el campo
OPTIONS, IPV6 usa encabezados de extensión. El encabezado de ruteo debe ser el primero
de los encabezados de extensión, y posee un campo NUM ADDRS que especifica la cantidad
de direcciones que componen la ruta y otro NEXT ADDRESS que especifica la dirección
siguiente a la que se enviará el datagrama.
29.14 Opciones del IPV6
Existen además encabezados de opción, para que IPV6 se adapte a cualquier tipo de
información. Estos encabezados se llaman:


Hop By Hop extension Header
End To End extension Header
Ambos encabezados poseen la misma forma, y se los identifica por un código. El primero de
ellos se examina en cada salto y el otro sólo en el destino. Poseen un campo NEXT
HEADER, HEADER LEN (ambos de 1 byte) y OPTIONS (de size variable). Las opciones se
colocan secuencialmente en el campo OPTIONS.
29.15 Tamaño del espacio de dirección del IPV6
El espacio de direccionamiento es ENORME. Si las direcciones se asignaran a razón de un
millón de direcciones por milisegundo, harían falta alrededor de 20 años para asignarlas
todas.
29.16 Notación hexadecimal con dos puntos del IPV6
Obviamente la notación en binario no sirve y la decimal usada en IPV4 tampoco.
Ejemplo:
Dirección IPV6 en notación IPV4
104.230.140.100.255.255.255.255.0.0.17.128.150.10.255.255
Para evitar cadenas tan largas se usa notación hexadecimal usando los dos puntos como
separador
40
Ejemplo:
La dirección anterior sería:
68E6:8C64:FFFF:FFFF:0:1180:96A:FFFF
Se pueden expresar cadenas contiguas de 0s con dobles dos puntos.
Ejemplo:
Las siguientes direcciones son equivalentes
FF05:0:0:0:0:0:0:B3 = FF05::B3
También se permite mezclar notaciones para hacer más amena la transferencia de IPV4 a
IPV6.
Ejemplo:
0:0:0:0:0:0:128.10.2.1
El ejemplo anterior también se puede comprimir.
Ejemplo:
::128.10.2.1
La compresión de 0s se permite sólo una vez en toda la dirección.
29.17 Tres tipos básicos de direcciones IPV6
La asociación de direcciones es similar a IPV4. Las direcciones IP determinan una conexión
de red y no una máquina.
La diferencia de IPV6 es que permite que más de un prefijo sea asignado a una misma red, y
que además, más de una dirección sea asignada a una interfaz determinada.
En general, una dirección IP de destino cae entre los siguientes tres grupos:
1. Unidifusión: La dirección de destino especifica una sola computadora
2. Grupo: El destino es un conjunto de computadoras que comparten un prefijo de
dirección.
3. Multidifusión: El destino es un conjunto de computadoras, posiblemente en
múltiples localidades.
29.18 Dualidad de difusión y multidifusión
El IPV6 no emplea difusión o difusión dirigida para referirse a la entrega a todas las
computadoras en una red o una subred IP lógica. En cambio, utiliza el término multidifusión,
y trata a la difusión como una forma especial de multidifusión.
29.19 Una elección de ingeniería y difusión simulada
COMPLETAR ESTOS ULTIMOS PUNTOS
41
29.20 Asignación propuesta de espacio de dirección IPV6
Como dividir el espacio de direcciones es un tema de bastante debate. IPV4 tiene dividido su
espacio según
29.21 Codificación y transición de la dirección IPV4
29.22 Proveedores, suscriptores y jerarquía de direcciones
29.23 Jerarquía adicional
42
Apéndice 1 IPsec
A.1.1 ¿Qué es IPsec?
IPsec es una extensión al protocolo IP que proporciona seguridad a IP y a los protocolos de
capas superiores. Fue desarrollado para el nuevo estándar IPV6 y después fue portado a
IPV4.
Sirve para asegurar la autenticación, integridad y confidencialidad de la comunicación.
Posee dos modos:
1. Modo Túnel
2. Modo Transporte
En modo túnel el datagrama IP se encapsula completamente dentro de un nuevo datagrama
IP que emplea el protocolo IPsec.
En modo transporte IPsec sólo maneja la carga del datagrama IP, insertándose la cabecera
IPsec entre la cabecera IP y la cabecera del protocolo de capas superiores (ver Figura a.1.1).
Modo transporte
IP
Paquete original
Modo túnel
IP
Nuevo header IP
AH
AH TCP
DATA
IP
TCP
DATA
IP
TCP
DATA
Figura a.1.1
A.1.2 Los protocolos IPsec
La familia de protocolos IPsec está formada por dos protocolos:
1. AH (Authentication Header).
2. ESP (Encapsulated Security Payload).
Ambos son protocolos IP independientes. AH es el protocolo IP 51 y ESP el protocolo IP 50.
A.1.2.1 Cabecera de autenticación AH
El protocolo AH protege la integridad del datagrama IP. Para conseguirlo, calcula una
HMAC (Hash-based Message Authentication Code) basada en la clave secreta, el contenido
del paquete y las partes inmutables de la cabecera IP (como son las direcciones IP). Tras esto,
añade la cabecera AH al paquete (Ver Figura a.1.2).
43
8
Next Header
16
Payload Length
Reserved
Security Parameter Index (SPI)
Sequence Number
Hash Message Authentication Code
Figura a.1.2





La cabecera AH mide 24 bytes. El primer byte es el campo Siguiente cabecera. Este
campo especifica el protocolo de la siguiente cabecera.
o En modo túnel se encapsula un datagrama IP completo, por lo que el valor de
este campo es 4.
o Al encapsular un datagrama TCP en modo transporte, el valor correspondiente
es 6.
El siguiente byte especifica la longitud del contenido del paquete. Este campo está
seguido de dos bytes reservados.
Los siguientes 4 bytes especifican en Índice de Parámetro de Seguridad (SPI). El SPI
especifica la asociación de seguridad (SA) a emplear para el desencapsulado del
paquete.
El Número de Secuencia de 32 bit protege frente a ataques por repetición.
Finalmente, los últimos 96 bit almacenan el código de resumen para la autenticación
de mensaje (HMAC). Este HMAC protege la integridad de los paquetes ya que sólo
los miembros de la comunicación que conozcan la clave secreta pueden crear y
comprobar HMACs.
Como el protocolo AH protege la cabecera IP incluyendo los aportes inmutables de la
cabecera IP como las direcciones IP, el protocolo AH no permite NAT. Tras el intercambio,
la HMAC ya no es válida. La extensión a IPsec NAT-transversal implementa métodos que
evitan esta restricción.
A.1.2.2 Carga de Seguridad Encapsulada ESP
El protocolo ESP puede asegurar la integridad del paquete empleando una HMAC y la
confidencialidad empleando cifrado. La cabecera ESP se genera y añade al paquete tras
cifrarlo y calcular su HMAC. La cabecera ESP consta de dos partes (Ver Figura a.1.3).
44
Security Parameter Index (SPI)
Sequence Number
Initialization Vector
DATA
Padding
Padding Length
Next Header
Hash Message Authentication Code
Figura a.1.3







Los primeros 32 bits de la cabecera ESP especifican el Índice de Parámetros de
Seguridad (SPI). Este SPI especifica qué SA emplear para desencapsular el paquete
ESP.
Los siguientes 32 bits almacenan el Número de Secuencia. Este número de secuencia
se emplea para protegerse de ataques por repetición de mensajes.
Los siguientes 32 bits especifican el Vector de Inicialización (IV - Initialization
Vector) que se emplea para el proceso de cifrado. Los algoritmos de cifrado simétrico
pueden ser vulnerables a ataques por análisis de frecuencias si no se emplean IVs. El
IV asegura que dos cargas idénticas generan dos cargas cifradas diferentes.
IPsec emplea cifradores de bloque para el proceso de cifrado. Por ello, puede ser
necesario rellenar la carga del paquete si la longitud de la carga no es un múltiplo de
la longitud del paquete (Padding). En ese caso se añade a continuación la longitud del
relleno (Padding length).
Tras la longitud del relleno se coloca el campo de 2 bytes Siguiente cabecera que
especifica la siguiente cabecera.
Por último, se añaden los 96 bit de HMAC para asegurar la integridad del paquete.
Esta HMAC sólo tiene en cuenta la carga del paquete: la cabecera IP no se incluye
dentro de su proceso de cálculo.
El uso de NAT, por lo tanto, no rompe el protocolo ESP. Sin embargo, en la mayoría
de los casos, NAT aún no es compatible en combinación con IPsec. NAT-Transversal
ofrece una solución para este problema encapsulando los paquetes ESP dentro de
paquetes UDP.
45
Apéndice 2 Protocolo IKE
A.2.1 ¿Para que sirve IKE?
El protocolo IKE (Internet Key Exchange) resuelve el problema más importante del
establecimiento de comunicaciones seguras: la autenticación de los participantes y el
intercambio de claves simétricas, tras ello, crea las asociaciones de seguridad.
A.2.2 Características de IKE

Suele implementarse a través de servidores de espacio de usuario, y no suele
implementarse en el sistema operativo.
 Emplea el puerto 500 UDP para su comunicación.
 Funciona en dos fases.
1. La primera fase establece un ISAKMP SA (Internet Security Association Key
Management Security Association).
2. En la segunda fase, el ISAKMP SA se emplea para negociar y establecer las SAs
(Security Asociations) de IPsec.
A.2.3 Fases de IKE
La primer fase suele soportar dos modos distintos:
1. Modo principal
2. Modo agresivo.
Ambos modos autentican al participante en la comunicación y establecen un ISAKMP SA,
pero el modo agresivo sólo usa la mitad de mensajes para alcanzar su objetivo. Esto, sin
embargo, tiene sus desventajas, ya que el modo agresivo no soporta la protección de
identidades y, por lo tanto, es susceptible a un ataque man-in-the-middle (por escucha y
repetición de mensajes en un nodo intermedio) si se emplea junto a claves compartidas con
anterioridad (PSK Pre Shared Keys). Pero sin embargo este es el único objetivo del modo
agresivo, ya que los mecanismos internos del modo principal no permiten el uso de distintas
claves compartidas con anterioridad con participantes desconocidos. El modo agresivo no
permite la protección de identidades y transmite la identidad del cliente en claro. Por lo tanto,
los participantes de la comunicación se conocen antes de que la autenticación se lleve a cabo,
y se pueden emplear distintas claves pre-compartidas con distintos comunicantes.
En la segunda fase, el protocolo IKE intercambia propuestas de asociaciones de seguridad y
negocia asociaciones de seguridad basándose en la ISAKMP SA.
La ISAKMP SA proporciona autenticación para protegerse de ataques man-in-the-middle.
Esta segunda fase emplea el modo rápido.
Normalmente, dos participantes de la comunicación sólo negocian una ISAKMP SA, que se
emplea para negociar varias (al menos dos) IPsec SAs unidireccionales.
46
Apéndice 3 NAT
(Network Address Translation)
A.3.1 ¿Qué es NAT?
Es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se
asignan mutuamente direcciones incompatibles. Consiste en convertir en tiempo real las
direcciones utilizadas en los paquetes transportados. También es necesario editar los paquetes
para permitir la operación de protocolos que incluyen información de direcciones dentro de
la conversación del protocolo.
Su uso más común es permitir utilizar direcciones privadas para acceder a Internet. Existen
rangos de direcciones privadas que pueden usarse libremente y en la cantidad que se quiera
dentro de una red privada. Si el número de direcciones privadas es muy grande puede usarse
solo una parte de direcciones públicas para salir a Internet desde la red privada. De esta
manera simultáneamente sólo pueden salir a Internet con una dirección IP tantos equipos
como direcciones públicas se hayan contratado. Esto es necesario debido al progresivo
agotamiento de las direcciones IPV4. Se espera que con el advenimiento de IPV6 no sea
necesario continuar con esta práctica.
A.3.2 Funcionamiento
Una pasarela NAT cambia la dirección origen en cada paquete de salida y, dependiendo del
método, también el puerto origen para que sea único. Estas traducciones de dirección se
almacenan en una tabla, para recordar qué dirección y puerto le corresponde a cada
dispositivo cliente y así saber donde deben regresar los paquetes de respuesta. Si un paquete
que intenta ingresar a la red interna no existe en la tabla de traducciones, entonces es
descartado.
Debido a este comportamiento, se puede definir en la tabla que en un determinado puerto y
dirección se pueda acceder a un determinado dispositivo, como por ejemplo un servidor web,
lo que se denomina NAT inverso o DNAT (Destination NAT).
NAT tiene muchas formas de funcionamiento, entre las que destacan:




Estático
Dinámico
Sobrecarga
Solapamiento
A.3.2.1 Estático
Es un tipo de NAT en el que una dirección IP pública se traduce a una dirección IP privada, y
donde esa dirección pública es siempre la misma. Esto le permite a un host, como un servidor
Web, tener una dirección IP de red privada pero aún así ser visible en Internet.
A.3.2.2 Dinámico
Es un tipo de NAT en la que una dirección IP privada se mapea a una IP pública basándose
en una tabla de direcciones de IP públicas registradas. Normalmente, el router NAT en una
47
red mantendrá una tabla de direcciones IP registradas, y cuando una IP privada requiera
acceso a Internet, el router elegirá una dirección IP de la tabla que no esté siendo usada por
otra IP privada. Esto permite aumentar la seguridad de una red dado que enmascara la
configuración interna de una red privada, lo que dificulta a los hosts externos de la red el
poder ingresar a ésta. Para este método se requiere que todos los hosts de la red privada que
deseen conectarse a la red pública posean al menos una IP pública asociada.
A.3.2.3 Sobrecarga
La forma más utilizada de NAT, proviene del NAT dinámico, ya que toma múltiples
direcciones IP privadas (normalmente entregadas mediante DHCP) y las traduce a una única
dirección IP pública utilizando diferentes puertos. Esto se conoce también como PAT (Port
Address Translation), NAT de única dirección o NAT multiplexado a nivel de puerto.
A.3.2.4 Solapamiento
Cuando las direcciones IP utilizadas en la red privada son direcciones IP públicas en uso en
otra red, el router posee una tabla de traducciones en donde se especifica el reemplazo de
éstas con una única dirección IP pública. Así se evitan los conflictos de direcciones entre las
distintas redes.
48
Apéndice 4 HTTP
(RFC 2616, 2068)
A.4.1 Que es HTTP?
HTTP (Hyper Text Transport Protocol) es un protocolo de capa de aplicación que fue creado
por el World Wide Web Consortium y es utilizado en cada transacción a través de Internet.
En un principio era limitado y no soportaba encabezados, por lo tanto no poseía el comando
POST con lo cual solo era posible enviar poca información al servidor a través del comando
GET.
A.4.2 El protocolo según las versiones
Versión 0.9:
 Solo soporta el comando GET
 Permitía transmitir texto plano
Versión 1.0
 Permite mas opciones de transferencia
 Datos con formato MIME.
 Metodos Get, Post y Head.
 Modifica la sintaxis de la petición y de la respuesta.
Versión 1.1
 Necesidades de los sistemas intermedios
 Necesidades de persistencia de la conexión.
 Metodos: Get, Post, Head, Options, Put, Delete, Trace, Patch, etc.
A.4.3 Características del protocolo
Algunas características importantes del protocolo son:






Es un protocolo stateless, es decir que no presenta estados por lo cual no guarda
información de conexiones anteriores.
Es orientado a transacciones. Esquema de consulta / respuesta. El cliente, quien inicia
la transacción, se denomina user agent. El servidor, quien posee el recurso, es quien
realiza la respuesta.
Es flexible en cuanto a los formatos.
Es robusto.
Se implementa sobre TCP / IP para brindar seguridad.
Utiliza un cache.
A.4.4 Definiciones relacionadas con el protocolo


Cliente: Un programa de aplicación que establece conexiones con el propósito de
enviar peticiones.
Conexión: Circuito virtual de la capa de transporte establecido entre dos programas
de aplicación con propósitos de comunicación.
49


Entidad: Una representación de un recurso de datos que puede estar incluido dentro
de un mensaje de petición o respuesta. Una entidad consiste de cabeceras y un cuerpo.
Mensaje: Es la unidad básica de comunicación HTTP.
A.4.5 Sistemas intermedios
El protocolo acepta sistemas intermedios. Se definen a continuación:




Cache: Es un almacenamiento local que sirve para reducir el tiempo de respuesta y el
consumo de ancho de banda en peticiones futuras. Puede ser implementado tanto en
el cliente como en el servidor, aunque un servidor no puede utilizar un cache cuando
actúa como túnel. No todas las operaciones pueden cachearse (Ej. Validación de
usuario y password).
Gateway (Pasarela): Se trata de un servidor que trabaja como intermediario para
otros servidores, que recibe peticiones como si fuera el servidor original del recurso
solicitado. Se usa cuando hay un firewall del lado del servidor y cuando hay que
hacer traducciones de protocolos cómo FTP – HTTP.
Proxy (Representante): Es un programa intermedio que trabaja tanto como un
servidor como un cliente. Debe interpretar y/o reescribir un mensaje de petición antes
de reenviarlo. Se usa cuando hay un firewall del lado del cliente, o hay diferentes
versiones de HTTP.
Túnel: Es un programa intermedio que trabaja como transmisor ciego entre dos
conexiones. No se considera como parte de la comunicación HTTP. Un túnel se cierra
cuando los dos extremos de la conexión transmitida se cierran. Se usa cuando hay un
firewall del lado del cliente o del servidor. Se establece una conexión autenticada, que
luego se usa solo para HTTP.
A.4.6 Métodos de petición existentes
GET: para pedir información identificada por una URL.
PUT: petición para aceptar la entidad incorporada y almacenarla bajo la URL proporcionada.
DELETE: solicita que el servidor origen suprima el recurso identificado por la URL.
POST: una petición para aceptar la entidad incorporada como una nueva subordinada al
URL identificado.
LINK: establece una o más relaciones de enlace entre recursos identificados.
PATCH: es similar a put salvo que la entidad contiene una lista de diferencias respecto al
contenido del recurso original.
UNLINK: elimina una o más relaciones de enlace entre recursos.
COPY: solicita una copia del recurso identificado por la URL.
TRACE:
HEAD: es idéntica a GET salvo que la respuesta del servidor no debe incluir un cuerpo de
entidad.
MOVE: solicita que el recurso identificado por la URL se mueva a la localización dada en el
campo cabecera-URL en la cabecera entidad.
OPTIONS: para pedir las opciones disponibles para la cadena petición/respuesta identificada
por la URL.
WRAPPED: permite a un cliente enviar una o más solicitudes encapsuladas.
50
A.4.7 Identificación de recursos



Para identificar el recurso con el que se desea trabajar se usa la URI (Uniform
Resource Identifier) o la URL (Uniform Resource Locator).
Es una cadena de caracteres que identifica el recurso que está disponible.
Sintaxis de la URL:
o Protocolo: // Host : Puerto/ ruta ? Parámetro = valor # Enlace
A diferencia de la URL, la URI no especifica el protocolo.
A.4.8 Mensajes de respuesta
A.4.9 Cabeceras HTTP
51
Apéndice 5 PAT
(Port Address Translation)
A.5.1 ¿Qué es PAT?
Es una característica del estándar NAT, que traduce conexiones TCP y UDP hechas por un
host y un puerto en una red externa a otra dirección y puerto de la red interna. Permite que
una sola dirección IP sea utilizada por varias máquinas de la intranet. Con PAT, una IP
externa puede responder hasta a ~64000 direcciones internas.
Cualquier paquete IP contiene la dirección y el puerto tanto del origen como del destino. En
el destino, el puerto le dice al receptor cómo procesar el paquete. Un paquete con puerto 80
indica que contiene una página web, mientras que el puerto 25 es usado para transmitir
correo electrónico entre servidores de correo. La traducción de los puertos, llamada PAT para
distinguirla de la traducción de direcciones (NAT), se apoya en el hecho de que el puerto de
origen carece de importancia para la mayoría de los protocolos. Igual que NAT, se sitúa en la
frontera entre la red interna y externa, y realiza cambios en la dirección del origen y del
receptor en los paquetes de datos que pasan a través de ella. Los puertos (no las IP), se usan
para designar diferentes hosts en el intranet.
El servicio PAT es como una oficina de correo que entrega las cartas. Los sobres
que salen son modificados para que el remitente sea la oficina de correos,
mientras que las cartas que llegan de afuera pierden su dirección y reciben la
nueva con la calle y el número real.
A.5.2 Procedimiento PAT








Cuando un ordenador de la intranet manda un paquete hacia fuera, queremos ocultar
su dirección real. El servicio NAT remplaza la IP interna con la nueva IP del propio
servicio.
Luego asigna a la conexión un puerto de la lista de puertos disponibles, inserta el
puerto en el campo apropiado del paquete de datos y envía el paquete.
El servicio NAT crea una entrada en su tabla de direcciones IP internas, puertos
internos y puertos externos. A partir de ese entonces, todos los paquetes que
provengan del mismo host serán traducidos con los mismos puertos.
El receptor del paquete utilizará los IP y puerto recibidos para responder, por lo que
dicha respuesta llegará a la “oficina de correos”.
Si el puerto destino no existe en la tabla del NAT, los datos serán descartados.
En otro caso, la nueva dirección y el nuevo puerto reemplazarán los datos de destino
en el paquete y éste será enviado por la red interna.
La traducción de puertos permite a varias máquinas compartir una única dirección IP.
El servicio PAT borra las traducciones periódicamente de su tabla cuando aparenten
no estar en uso. Como el número de posibles puertos a otorgar es de 16 bit (65535), la
probabilidad de que un ordenador no encuentre una traducción es realmente pequeña.
52
Apéndice 6 BGP
(Border Gateway Protocol) RFC 1771
A.6.1 Introducción
BGP es un protocolo de routing externo. Los protocolos de routing externo son los que se
utilizan para interconectar sistemas autónomos. En los protocolos de routing externo la
prioridad es buscar rutas óptimas atendiendo únicamente al criterio de minimizar la distancia
medida en términos de la métrica elegida para la red.
Hasta 1990 se utilizaba como protocolo de routing externo en Internet el denominado EGP
(Exterior Gateway Protocol). Este protocolo no fue capaz de soportar el crecimiento de la
red y entonces se desarrollo un nuevo protocolo de routing externo denominado BGP. Desde
entonces se ha producido 4 versiones de BGP, las especificaciones ahora vigentes de BGP-4
se encuentran en el RFC 1771.
BGP es un protocolo de transporte fiable. Esto elimina la necesidad de llevar a cabo la
fragmentación de actualización explícita, la retransmisión, el reconocimiento, y
secuenciación.
A.6.2 Funciones de BGP
BGP se diseño para permitir la cooperación en el intercambio de información de
encaminamiento entre dispositivos de encaminamiento, llamados pasarelas, en sistemas
autónomos diferentes. El protocolo opera en términos de mensajes, que se envían utilizando
TCP.
A.6.3 Mensajes de BGP

OPEN: sirve para adquirir un vecino. Un dispositivo de encaminamiento abre
primero una conexión TCP con el vecino y después envía un OPEN.

UPDATE: facilita dos tipos de información:
o Información sobre una ruta particular a través del conjunto de redes. Esa
información se puede incorporar a la base de datos de cada dispositivo de
encaminamiento que la recibe.
o Una lista de rutas previamente anunciadas por este dispositivo de
encaminamiento que van a ser eliminadas

KEEPALIVE: consta solo de la cabecera. Cada dispositivo de mantenimiento envía
regularmente estos mensajes para evitar que expire el temporizador mantenimiento.

NOTIFICATION: se envían cuando se detecta algún tipo de error.
A.6.4 Procedimientos funcionales de BGP
BGP posee tres procedimientos funcionales principales:
1. Adquisición de vecino.
2. Detección de vecino alcanzable.
3. Detección de red alcanzable.
53
A.6.4.1 Adquisición de vecino
Dos dispositivos de encaminamiento se consideran vecinos si están en la misma subred. Si
los dos dispositivos de encaminamiento están en sistemas autónomos, podrían desear
intercambiar información de encaminamiento. Para este cometido es necesario realizar
primero el proceso de adquisición de vecino.
Para llevar a cabo la adquisición de vecino, un dispositivo envía al otro un mensaje OPEN. Si
el otro dispositivo acepta la relación, envía un mensaje KEEPALIVE.
A.6.4.2 Detección de vecino alcanzable
Una vez establecida la relación de vecino, se utiliza el procedimiento de detección de vecino
alcanzable para mantener la relación. Este procedimiento consiste en enviarse entre los dos
vecinos periódicamente mensajes de KEEPALIVE para asegurarse de que la relación sigue
establecida.
A.6.4.3 Detección de red alcanzable
El último procedimiento especificado por BGP es la detección de red alcanzable. Cada
dispositivo de encaminamiento mantiene una base de datos con las redes que puede alcanzar
y la ruta preferida para llegar hasta esa red. Siempre que se realiza un cambio en esa base de
datos, el dispositivo de almacenamiento envía un mensaje de UPDATE por difusión a todos
los dispositivos de encaminamiento que implementan BGP.
54
Apéndice 7 RSVP
(RFC 2205)
A.7.1 ¿Qué es RSVP?
Protocolo de reserva de recursos (RSVP) es una técnica de señalización que se utiliza para
garantizar la calidad de servicio (QoS) reservar ancho de banda para flujos de datos
compatibles con RSVP. Todos los nodos de la ruta de acceso a datos deben ser compatibles
con RSVP para una garantía de QoS. Las reservas son iniciado receptor para tráfico
multidifusión y unidifusión.
A.7.2 Características de RSVP









La reserva es realizada por flujo.
Es un protocolo de señalización.
Es un protocolo de la capa de transporte.
RSVP no es un protocolo de encaminamiento, pero trabaja con protocolos de
enrutamiento actuales.
RSVP está orientada hacia el receptor: es el receptor de un flujo de datos el que inicia
y mantiene la reserva de recursos para ese flujo.
RSVP es Soft State, es decir que mantiene solo temporalmente el estado de las
reservas de recursos del host y de los routers, de aquí que soporte cambios dinámicos
de la red.
RSVP debe mantener en cada nodo los requerimientos de reserva (se define el Soft
State).
La reserva en cada nodo necesita refresco periódico.
RSVP proporciona varios estilos de reserva (un conjunto de opciones) y permite que
se añadan futuros estilos al protocolo para permitirle adaptarse a diversas
aplicaciones.
A.7.3 ¿Qué es el Soft State?
Son los estados en los router y hosts extremos, refrescados por los mensajes Path y Resv.
A.7.4 Los mensajes de RSVP
55
Referencias
Redes Globales de Informacion con Internet y TCP /IP – Tercera Edicion.
Douglas E. Commer
Comunicaciones y Redes de William Stallings
Wikipedia
56
Acrónimos
EAE: Extremo a extremo.
SW: Software.
HW: Hardware.
57
Dudas
Diferencia entre difusión por dirección de HW y difusión IP
Temas
BGP
bootp
dhcp
nat
pat
proxy
gateway
firewall
tunel
dmz
ftp
tftp
rsvp
ipv6
ipsec
seguridad
IKE
telnet
dns
http
smtp
mime
ISA
DSA
58