Sergio Guaglianone

Magister en Redes de Datos,

Facultad de Ciencias Exactas,

Universidad Nacional de La Plata.

Escenario

El advenimiento de la Internet Pública como fuente de información y medio de comunicación ha modificado la forma de trabajo de todas las organizaciones sin importar su naturaleza. Hoy es una herramienta de trabajo casi indispensable si existe la necesidad de optimizar el flujo interno y externo de la información. Una ventaja que no debemos olvidar es el sustancial ahorro en servicios tradicionales de comunicaciones a través de la utilización de aplicaciones sobre TCP/IP. Todo esto crea la necesidad de poder contar con una forma barata, flexible y unificada de servicios que nos posibiliten trabajar y comunicarnos dentro de la organización y con las otras organizaciones o personas que interactúan con ella. La combinación Internet-Intranet-Extranet aparece como la solución ideal para cubrir estas necesidades y, al mismo tiempo, optimizar el gasto en servicios de comunicaciones en forma drástica.

Pero el tercer objetivo a cumplir es el de la seguridad. Al interconectar redes de comunicaciones debe ponerse un acento aún mayor en la definición de una política de seguridad lo suficientemente robusta como para poder enfrentar los potenciales riesgos de ataques internos y externos.

Existen diversos métodos para construir una intranet que además brinden la posibilidad de incorporar usuarios externos a la red corporativa (extranet) y con accesos a los servicios de Internet. Esos métodos podemos dividirlos en dos grandes grupos:

1. Basados en Redes Privadas.
2. Basados en Redes Privadas Virtuales.

Este es el método tradicional. Se trata de utilizar líneas de comunicaciones punto a punto rentadas a las compañías prestadoras de servicios. Con este método podemos construir la WAN de la intranet de una manera eficiente pero muy rígida, pues no se adapta a los cambios de topología y ancho de banda que necesitaremos a medida que nuestras necesidades de interconectividad cambien. Este método es el que la mayoría de las organizaciones consideran más seguro pero tampoco representan una garantía de privacidad total pues inevitablemente se comparten recursos de la red del prestador de servicios, lo cual es una fuente potencial de entrada para intrusos. Además la principal desventaja es el alto costo de este servicio.

Este método es el que más se tiende a utilizar hoy pues tienen precio más bajo y una mayor adaptabilidad a los cambios de topología y ancho de banda. Están basados en servicios de valor agregado de telecomunicaciones tales como redes públicas de Frame Relay, ATM o IP. Las tecnologías Frame Relay y/o ATM aseguran una gran calidad de servicio en vínculos del tipo de circuitos virtuales permanentes (PVC) o circuitos virtuales conmutados (SVC) con posibilidad de cursar tráficos de distinta naturaleza.

El caso de redes privadas virtuales IP será el mas analizado a lo largo de este documento pues aparece como el método más barato, más flexible y además el que mayor cantidad de servicios de valor agregado ofrece hoy. La alternativa ATM todavía se esta aplicando solo para cubrir necesidades de banda ancha o redes de transporte. Por redes IP hoy podemos cursar tráfico de voz con calidad aceptable, lo cual aparece como la tendencia más tentadora para disminuir costos de comunicaciones en redes de usuarios corporativos en el futuro inmediato. La otra razón fundamental para centrar el análisis en redes privadas virtuales IP es el especial cuidado que debe tenerse en los aspectos de la política de seguridad pues las soluciones de VPN basadas en ATM o Frame Relay no difieren de las soluciones de redes privadas tradicionales en el tratamiento de la seguridad.

Las diferentes alternativas que los proveedores de servicios de telecomunicaciones pueden ofrecer hoy para soluciones de Internet-Intranet-Extranet son tres:

1. Redes Privadas Virtuales IP Dial-up

Son aquellas que ofrecen acceso remoto discado a la red corporativa para usuarios móviles a través de la Internet Pública. El proveedor de servicios gestiona bancos de módems y asegura una conectividad confiable, mientras que la red corporativa asegura la autenticación de usuarios con la política y herramientas de seguridad que se desee.



 En la figura se observa la arquitectura de una Red Privada Virtual Dial-up en la que los diferentes usuarios móviles (roaming workers) acceden por medio de módems telefónicos a la Intranet de su organización a través de la Internet Pública usando túneles IP. Estos túneles se establecen solo durante el tiempo que dura la conexión (túneles IP dinámicos).

2. Redes Privadas Virtuales IP Dedicadas

Están caracterizadas por la multiplicidad de usuarios; sus velocidades de acceso a la Internet Pública son mayores que la de las Redes Privadas Virtuales IP Dial-up. Hay diversos tipos de Redes Privadas Virtuales IP Dedicadas pero su elemento en común es la conexión a servicios y redes IP de las LAN corporativas usando routers y firewalls.



Este esquema muestra el desarrollo de una solución de Intranet corporativa usando como WAN una plataforma de servicios IP. El prestador de servicios de valor agregado de telecomunicaciones hace uso del "static tunneling" como medio de interconexión para un servicio LAN-TO-LAN IP. Además es posible el acceso a la Internet Pública por un servicio de red IP sin túneles IP. Para el acceso de usuarios a la Internet Pública el proveedor de servicio debe asegurar una conexión segura lo cual se simboliza por medio del firewall instalado en el gateway de Internet.

En este punto es fácil deducir la tercera y ultima de las opciones a tratar, la cual es una combinación de las dos anteriores.

3. Redes Privadas Virtuales IP

• Acceso dedicado a un backbone IP virtual para conexión WAN de la Intranet corporativa.
• Acceso dial-up de usuarios móviles y homeworkers a la Intranet corporativa.
• Acceso dial-up de usuarios externos a la red corporativa (extranet).
• Opción de acceso a la Internet pública de los usuarios de las redes LAN interconectadas como así también de los usuarios dial-up.

En este escenario es fundamental replantear todo el concepto de política de seguridad.que se tiene para redes locales o intranet basadas en redes privadas convencionales. Tradicionalmente, los protocolos de acceso dial-up a la red corporativa confiaban todo el trabajo de chequeo de autorizaciones a los servidores de acceso y a los filtros de paquetes y/o firewalls. Cuando se hablaba de acceso dedicado a la Internet Pública desde la red corporativa se seguía la misma táctica. Los usuarios dial-up de la Internet pública, en general usuarios residenciales o corporativos, no ponían demasiado acento en la seguridad. Esto se debe a que los usuarios residenciales no estaban permanentemente conectados o no necesitaban de una rígida política de seguridad, pues los riesgos de pérdida eran mínimos frente a los costos de la seguridad. En el caso de usuarios corporativos se seguía la estrategia de habilitar a Internet solo algunos hosts de la LAN corporativa y se confiaba en la efectividad de ese aislamiento de hosts.para mantener la seguridad. Hoy el nuevo escenario de trabajo hace que sea indispensable que los trabajadores que viajan a menudo o los "home workers" puedan mantenerse on-line con su oficina en cualquier parte del mundo. Para ello, si utilizamos proveedores de servicios de valor agregado con una plataforma IP el usuario móvil podrá acceder a la red corporativa haciendo llamadas al "Point of Presence" (PoP) más cercano al usuario. Esto baja significativamente los costos de comunicaciones telefónicas. Esta idea también se aplica para usuarios extra-corporativos (que pueden ser clientes o terceros relacionados temporalmente) bajo el esquema extranet.

La idea del servicio extranet también puede incorporarse a las conexiones directas vía Internet de compañías u organizaciones asociadas con lo cual debemos poner atención especial en un punto. La política de seguridad de la organización es compatible con la de las demás organizaciones interconectadas con la primera? La respuesta a esta pregunta puede llevar a que debamos replantear toda o parte de la política de seguridad adoptada para nuestra organización pues los esquemas de interrelación que el mundo de hoy exige con compañías asociadas, clientes y/o proveedores pueden llegar a comprometer las políticas de seguridad aumentando las posibles fuentes de ataques y la vulnerabilidad del sistema.

Entonces si vamos a construir una intranet con capacidad de dar servicio extranet y acceder a la Internet Pública debemos asegurar que los protocolos y arquitecturas de acceso estén orientados a satisfacer nuestra política de seguridad. Analizando los diversos métodos de interconexión y acceso es obvio que la mayor debilidad aparente esta en el acceso de usuarios dial-up, y es allí donde centraremos el análisis en secciones posteriores.

El éxito del uso de los servicios IP de acceso dial-up reside en tres elementos fundamentales de seguridad:

• Identidad

• Integridad

• Auditoría activa

Para acceder a servicios IP el protocolo mas usado es PPP (point-to-point protocol) (RFC1662, RFC1663). PPP es un protocolo standard de enlace para transportar datagramas multiprotocolo sobre líneas punto a punto. PPP ofrece ademas los siguientes servicios:

• Un metodo de framing que delimita sin ambigüedad el comienzo y fin de cada frame. El formato del frame PPP también provee detección de errores.
• Un protocolo de control del enlace para establecer la conexión, testear el vínculo, negociar opciones y cerrar la conexión cuando ya no se la usa. Este protocolo es el LCP (Link Control Protocol).
• Define el LCP extensible en opciones y una de ellas permite la negociación de un protocolo de autenticación para permitir el acceso al servicio antes de permitir la transmision de datagrames por el enlace. Esos protocolos son PAP (Password Authentication Protocol) y CHAP (Challenge Handshake Authentication Protocol).
• Una manera de negociar opciones de capa de red independientemente del protocolo de red que se usará. El método elegido nos posibilita tener un protocolo de control de red (NCP- Network Control Protocol) para cada capa de red soportada.

Es en la transición desde el estado "establecido" al estado "autenticar" donde ambos extremos acuerdan si usarán o no un protocolo de autenticación y cuál de ellos (PAP o CHAP) usarán. Si queremos tener accesos a la red que sigan una determinada política de seguridad debemos procurar o, en caso de contratar el servicio a un proveedor, exigir que el acceso dial-up sea por medio de PPP con opción de autenticación.

Password Autentication Protocol – PAP

Este protocolo se define en la RFC1334. La opción de configuración de protocolo de autenticación se describe en la RFC1661. Los paquetes PAP se envían encapsulados en los frames PPP en la fase de autenticación.

PAP provee un método simple para que el usuario que solicita el servicio establesca su identidad usando un hand-shake doble una vez que se ha establecido el vínculo.

Luego de la fase de establecimiento del vínculo, un par usuario-password se envía repetidamente desde el solicitante al autenticador (access server) hasta que el acknowledgement de autenticación es recibido o el vínculo se cierra. El access server mantiene una base de datos con listas de pares usuario-password. Este método no es muy robusto, pues las passwords no se envían encriptadas por el canal sino en texto plano. No existe protección de duplicación del par user-password o protección contra ataques repetidos de prueba y error. El cliente tiene el control de la frecuencia y el timing de los intentos de acceso. Este método de autenticación es más apropiado cuando una password de texto plano debe estar disponible para simular un login en un host remoto. Entonces, en ese caso, PAP provee un nivel de seguridad similar al usuario habitual en el host remoto.

Debido a que la interacción entre PPP y PAP es dependiente de la implementación usada, habrá que tener especial cuidado en se cumplan todos los requerimientos de configuración del enlace. Por ejemplo cuando la autenticación PAP falla debe asegurarse que el vínculo se cierre. Algunas aplicaciones solo limitan el acceso a servicios de la capa de red y esto puede representar un serio back-hole de seguridad del sistema. Otra desventaja de PAP es que LCP puede renegociar la autenticación en cualquier momento permitiendo nuevos intentos. Se recomienda que se implementen contadores de intentos de acceso que no sean reseteados sino hasta después de la autenticación positiva. Si el usuario requiere distintos métodos de autenticación entonces es conveniente que use distintos pares usuario-password para cada método.

Idealmente las passwords solo deberían ser accesibles al proceso que las necesita pero como esto es poco probable deben seguirse todas las recomendaciones tradicionales de cuidado de passwords por parte del usuario.

Este protocolo se define en la RFC1994. La opción de configuración de protocolo de autenticación se describe en la RFC1661. Los paquetes CHAP se envían encapsulados en los frames PPP en la fase de autenticación.

CHAP es un método de autenticación de vínculos PPP. Usa una requisitoria aleatoria con una respuesta criptografiada que depende de la requisitoria y una clave secreta. Por defecto, la autenticación no es obligatoria en el protocolo PPP sino una opción de configuración. Si se requiere autenticación, el protocolo de autenticación debe ser especificado como opción durante la fase de establecimiento del enlace que se observa en el diagrama de estados PPP.

Este protocolo se destina para hosts y routers que se conectan a un servidor PPP vía circuitos switcheados o dial-up, pero también se pueden usar a líneas dedicadas. El servidos PPP puede usar la identificación del host o router que se ha conectado para la selección de opciones de las negociaciones de capa de red por NCP.

CHAP se usa para verificar periódicamente la identidad del usuario que accede al servicio mediante un triple hand-shaking. Esto se hace una vez que se ha establecido el enlace PPP y puede ser repetido en cualquier momento después de que esté establecida la conexión.

1. Luego de la fase de establecimiento del vínculo, el autenticador (access server) envía al usuario que desea acceder una requisitoria ("challenge").
2. El usuario responde con un valor calculado mediante una función de hash simple.
3. El autenticador (access server) chequea la respuesta comparándola con su propio cálculo del valor esperado como respuesta a su requisitoria. Si el valor concuerda entonces el access server envía el acknowledge; si no concuerda la conexión debe cerrarse.
4. A intervalos aleatorios de tiempo, el access server envía nuevos "challenge" al usuario, repitiendo los pasos 1 al 3.

• Ventajas de CHAP

CHAP provee protección contra ataques de reproducción por parte del supuesto usuario a través del uso de un identificador de variación incremental y un valor de challenge variable. El uso de challenges repetidas tiene por intención el tiempo de exposición a cualquier ataque simple, pues es el access server quien tiene el control de la frecuencia y el timing de los challenges.

CHAP depende de una password encriptada sólo conocida por el acces server y el programa cliente. La password no viaja por el link.

Aunque la autenticación es de una sola dirección, por medio de la negociación del CHAP en ambas direcciones las misma passwords encriptadas pueden usarse para autenticación mutua.

Dado que CHAP puede usarse para autenticar muchos sistemas y servicios distintos, el nombre de usuario puede usarse como índice para localizar la password asociada en una tabla mantenida por el access server. Esto posibilita el soporte de mas de un par usuario-password por sistema y cambiar la password en uso en cualquier momento durante la sesión.

• Desventajas de CHAP

CHAP requiere la disponibilidad local de las password en texto plano. Las bases de datos de passwords encriptadas irreversiblemente no pueden ser usadas.

No es recomendables para instalaciones muy grandes, pues toda password posible debe ser guardada a ambos lados del enlace. Esto hace que el protocolo no sea óptimo por sí solo para los access servers de empresas prestadoras de servicios.

Una recomendación para proveedores de servicios o sistemas grandes es que para evitar el envío de las passwords en el enlace y no requerir access servers de gran capacidad de almacenamiento de datos, los challenges y respuestas sean examinadas en un server central y no en cada access server de cada punto de presencia de la red de servicios de acceso. De lo contrario la password deberá enviarse por el enlace con una forma de encriptación reversible.

En los protocolos que examinaremos a continuación, donde veremos la solución de seguridad para acceso dial-up a intranets basadas en Redes Privadas Virtuales IP veremos como se evitan estas desventajas.

RADIUS es un protocolo de autenticación y contabilizacíon para access servers. Su empleo en Internet Service Providers (ISP) esta siendo cada vez mas difundido. Se especifica separadamente el protocolo de autenticación (RFC 2058) del de contabilización (RFC 2059).

Esta basado en el modelo cliente/servidor. El access server actúa como cliente, el cual es responsable de enviar la información del usuario al servidor RADIUS designado y actúa en función de las respuestas de este último. El server (o daemon) RADIUS puede dar autenticación y contabilización a uno o mas clientes. Denominaremos al cliente como NAS (Network Access Server). La función del server RADIUS es recibir los requerimientos de conexión, y luego devolver toda la información de configuración necesaria al NAS para que este habilite el servicio al usuario. El server RADIUS debe residir en un host dedicado y conectado permanentemente a la red; esta estación también se la puede denominar genéricamente AAA Server (Authentication Authorization & Accounting Server).

La comunicación entre el NAS y el RADIUS server se basa en el protocolo de transporte UDP. El formato del paquete es el siguiente:

El campo de código es un octeto e identifica el tipo de paquete RADIUS. Cuando se recibe un paquete con un código inválido se descarta sin aviso.

Las razones técnicas por las cuales se usa transporte sin conexión UDP recaen en cuestiones de disponibilidad del server, retransmisión y time-out manejados por RADIUS mas allá de UDP en sí. Un login de usuario consiste en el envío de un paquete Access-requets desde el NAS al RADIUS server y la correspondiente respuesta Access-accept o Access-reject desde el RADIUS server al NAS. El paquete Access-request contiene el username, la password encriptada, la dirección IP del NAS, y el port. El formato de la respuesta contiene el perfil del usuario, o sea los servicios o el tipo de sesión que el usuario quiere iniciar con su par username-password. Por ejemplo, el RADIUS server decide basándose en su base de datos si el usuario necesita una sesión de terminal remota, una conexión PPP transparente, etc. Cuando el server RADIUS recibe un Access-request del NAS, busca en su base de datos el username; si este no existe puede hacer dos cosas: habilita un perfil de usuario standard o por defecto, o inmediatamente envía al NAS un Access-reject. Esta última opción es la más recomendable para mantener la seguridad. Ese access-reject puede acompañarse con un mansaje de información del rechazo o denial of service. Si se encuentra el username, y la password es la correcta entonces el RADIUS server envía al NAS un Access-accept incluyendo una lista de pares atributo-valor que describe los parámetros de la sesión o perfil del usuario. Esto típicamente incluye tipo de servicio (shell o frames), dirección IP (estática o dinámica), la access list que se le aplica, o ruta estática a instalar en la tabla de ruteo del NAS.

La autenticación es el aspecto más problemático de la seguridad remota debido a la dificultad asociada con la identificación positiva de un usuario. Para asegurar la identidad del usuario remoto, el protocolo RADIUS soporta diversos métodos de autenticación, incluyendo PAP, CHAP, y token cards.

Si se escoge la opción de token cards, RADIUS deberá proveer la manera de enviar la información de autenticación al token card server para autenticar al usuario. De esta manera cuando el servidor RADIUS se encuentre con una password de esta naturaleza deberá solicitar la auenticación al token card server antes de responder el Access-request al NAS.

RADIUS solo encripta la password en el paquete Access-request desde el NAS al servidor. El resto del paquete no viaja encriptado. La otra información (como ser username, servicios autorizados y contabilización) podría ser capturada por intrusos de la red. Esto hace que el protocolo RADIUS pueda convertirse en un blanco de ataque potencial de un hacker que utilice la estrategia de captura de sesión y repetición de ataques. Por consiguiente las redes RADIUS deben ser cuidadosamente diseñadas para minimizar esta vulnerabilidad.

Nos referiremos a este protocolo delineando sus características mas importantes y sus diferencias con RADIUS subrayando aquellas características que tengan que ver con la seguridad.

En principio la funcionalidad es similar; ambos usan el modelo cliente/servidor siendo el NAS el cliente. Pero existen diferencias notables entre RADIUS y TACACS que hacen a este último mas robusto.La principal diferencia es que TACACS usa como transporte el protocolo TCP. Por lo tanto, el diálogo entra el NAS y el TACACS server será orientado a la conexión. Recordemos que RADIUS, al utilizar transporte UDP, tendrá una comunicación del tipo sin conexión, o sea, "best-effort". TACACS no necesita las variables extras que usaba RADIUS para controlar intentos de retransmisión y timers, pues el protocolo de transporte que le da servicio a TACACS se encarga de lograr un canal de comunicaciones seguro, transparente y libre de errores. TCP provee un ACK separado (a través de un ACK de TCP) de que un Access-request a sido recibido por el server TACACS en un tiempo aproximadamente igual al round-trip delay de la red, sin importar la congestión que tenga la red en ese momento. Además TCP provee una indicación inmediata de un server no disponible. Aún teniendo conexiones TCP con un timer de expiracion de espera de ACK largo, podremos tener la certeza de un server que sale de servicio y luego entra nuevamente en operación. UDP no puede darnos esta certeza, ni siquiera puede discriminar entre un server caído, un server lento o inexistente y por lo tanto RADIUS tampoco. Usando los keepalives de TCP podemos detectar las caídas del servidor TACACS fuera de banda. Además con TACACS podemos establecer y mantener conexiones simultaneas con varios servers, de esa manera no se necesita requerir servicio solo a servers que conocemos que están en servicio en cada momento.

TACACS encripta todo el paquete dejando solo un header standard TACACS. En ese header existe un campo que indica si el cuerpo del paquete ha sido encriptado o no. Normalmente es mas seguro optar por la total encriptación del cuerpo del paquete TACACS. Este protocolo usa una arquitectura modular llamada AAA (Authenticacion, Authorization & Accounting), la cual separa las tres funciones: autenticación, autorización y contabilización. Esta flexibilidad le da ventaja sobre RADIUS, pues puede separar la autenticación y seguir usando TACACS para la autorización y contabilización. Podemos usar TACACS para autorización y contabilización y hacer la autenticación por medio de Kerberos. Luego de que un NAS autentica mediante un servidor Kerberos, procederá a requerir información de autorización y/o perfil de usuario al server TACACS sin tener que re-autenticarse en el TACACS. El NAS informa al TACACS de la exitosa autenticación del usuario por Kerberos y entonces el server TACACS proveerá la información de autorización del usuario.

Si se necesita chequeo adicional de la autorización durante el transcurso de una sesión, el Network Access Server (NAS) chequea con el servidor TACACS para determinar si el usuario tiene permiso de uso de un comando o servicio en particular. Esta característica da gran poder de control sobre comandos prohibidos o servicios denegados durante la sesión de un usuario que fue positivamente autenticado y autorizado, gracias a la independencia de los procesos de autenticación y autorización. Mientras que la autenticación se hace antes del comienzo de la sesión del usuario, la autorización puede repetirse en cualquier momento durante la misma.

Otra ventaja de TACACS sobre RADIUS es que TACACS soporta en forma nativa su funcionamiento sobre familias de protocolos distintos de TCP/IP como ser Apple Talk Remote Access (ARA), NetBIOS frame protocol control, Novell Asynchronous Services Interface (NASI) y Packet Assembler/Disassembler connection. (PAD).

Como conclusión sobre TACACS se puede agregar que por sus características de robustez, flexibilidad y complejidad es recomendable para redes complejas que requieran múltiples tipos de autenticaciones.

Retomando nuestro escenario, veremos ahora la forma más segura para implementar el acceso dial-up a una Red Privada Virtual IP de servicios Intranet, Extranet e Internet.

El factor dominante en un esquema de Red Privada Virtual es el "tunneling". Mediante él se pueden crear vínculos dedicados de conectividad IP sobre una infraestructura de red pública IP o perteneciente a algún prestador de servicios. Existen dos tipos de túneles: estáticos y dinámicos.

• Un túnel estático se define por su cualidad de estar configurado para conexiones de acceso dedicado a una red y por ello están permanentemente establecidos entre un punto de acceso y otro de salida de una red.
• Un túnel dinámico se usa para conexiones temporarias, como las que se usan en accesos dial-up. Se crean y destruyen dinámicamente, a demanda del usuario que necesita conectarse desde un punto arbitrario de entrada a la red (Network Access Server) hasta un destino elegido por el usuario (Home Gateway). Solo existe durante el tiempo que dura la sesión del usuario o usuarios.

El concepto de tunneling se basa en la idea de proveer un vehículo para encapsular paquetes dentro de un protocolo que es entendido a la entrada y a la salida de una red dada. Estos puntos se definen como interfase del túnel y es similar a una interfase de hardware pero configurada en software. Examinemos qué protocolos necesitamos:

En la figura vemos que el túnel involucra tres tipos de protocolos:

• Passenger: este es el protocolo que será encapsulado. Si el túnel es para un acceso dial-up este será PPP; si es para una conexión dedicada de acceso permanente a la red entonces será IP.
• Encapsulator: es el protocolo que se usa para crear, mantener y desactivar el túnel. En el caso de un túnel dinámico para acceso dial-up se puede usa L2F (Layer Two Forwarding RFC 2341), L2TP (Layer Two Tunneling Protocol) o PPTP (Point-to-point Tunneling Protocol). Para un túnel permanente se puede usar GRE (Generic Routing Encapsulation RFC 1701 o Generic Routing Encapsulation over IPv4 networks (RFC 1702).
• Carrier: este protocolo "transporta" al protocolo encapsulado. Aquí es conveniente elegir IP por sus capacidades de ruteo pero se puede usar también Frame Relay, X.25 y ATM debido a que el encapsulador es totalmente independiente del protocolo de transporte.

Ahora cada usuario que desee acceder a la intranet de su organización desde un sitio remoto de un modo seguro, requerirá que se cree dinámicamente un túnel desde el Network Access Server que atiende su llamada telefónica hasta el gateway (llamado home gateway) de la red de su organización. Esto crea un vinculo directo, seguro y bajo demanda a través de una red IP del proveedor de servicios o la misma Internet Pública que se ve en el esquema.

Examinaremos los pasos de establecimiento del túnel dinámico y veremos que la conexión optimiza la seguridad del vínculo mediante un esquema de doble seguridad.

1. El usuario remoto inicia una conexión PPP al Network Access Server (NAS) y este acepta la llamada.
2. El NAS del proveedor autentica la llamada PPP por medio de PAP, CHAP mas RADIUS o TACACS. Autentica el usuario y el sistema destino. Solo el campo "username" se interpreta para determinar si el usuario requiere un servicio virtual de dial-up. Por ejemplo se puede estructurar el username como usuario@dominio.com o en su defecto, que el proveedor mantenga una base de datos mapeando usuarios con servicios. Si el usuario es de una red privada virtual, el mapeo identificará un destino específico que será la IP address del home gateway. Una manera de reducir la base de datos de autorización de acceso es que el proveedor de servicios solo autorice el nombre de dominio (dominio.com). Además de esa manera la política de seguridad de la Red Privada Virtual será independiente de la del proveedor de servicios, pues será la primera quien decida finalmente el acceso a su red. Si no se requiere la conexión directa por túnel a la Rde Privada Virtual entonces el NAS puede, opcionalmente, proveer acceso a la Internet pública sin tunelling.
3. El NAS inicia un túnel L2F (u otro protocolo) al home gateway deseado.
4. Una vez que el túnel está establecido el NAS asigna un MID (multiplex ID) y envía una indicación "connect" al home gateway de esta nueva sesión dial-up. El MID identifica una conexión particular en el túnel, pues este puede compartirse con varios usuarios con igual destino (si el túnel ya había sido establecido anteriormente para otro usuario del mismo dominio). A cada nuevo usuario se le asignará un MID libre en el túnel al momento de la conexión. Luego el home gateway decide si acepta o rechaza la conexión del usuario con algún mensaje de error. La notificación inicial que llega al home gateway puede incluir la información requerida para permitir que el home gateway autentique el usuario y decida si acepta o no esta llamada. Esta autenticación puede ser PAP, CHAP, RADIUS o TACACS. Aquí aparece el segundo nivel de seguridad de acceso. Esto permite que la Red Privada Virtual tenga su propia política de seguridad, pues es ella quien finalmente decide si el usuario accede o no a la red, y no el proveedor de servicios. O sea, no tiene que poner en manos de terceras partes su política de seguridad.
5. El home gateway confirma la aceptación de la llamda y del túnel. Asi crea una interface virtual para PPP de igual manera que si el home gateway estuviese recibiendo la llamada directamente. Ahora los frames PPP pueden pasar en ambas direcciones por el túnel.
6. El NAS puede, opcionalmente, loggear la aceptación de la llamada y cualquier información relevante respecto del tipo de servicios prestados al usuario remoto como la duración de la llamada, paquetes transferidos, y ports accedidos.
7. (y 8).Son los extremos del túnel (el NAS y el home gateway) los que se encargan de encapsular y desencapsular PPP de L2F creando una conectividad punto a punto entre el usuario remoto y su home gateway. Adicionalmente, existe la posibilidad de que estos extremos encripten los datos, dando un tercer nivel de seguridad.

El proveedor de servicios descubre la identidad corporativa del usuario o su dominio y asi resuelve el destino del túnel a construir (por PAP o CHAP más RADIUS o similar). En este punto no hay interacción de password. Cuando se determina el home gateway destino del túnel, se comienza la conexión con la información colectada por el NAS del proveedor de servicios. El home gateway corporativo completa la autenticación y puede aceptar o rechazar la conexión (por PAP, CHAP). Si se autoriza la conexión, entonces el gateway corporativo comienza el segundo nivel de autenticación en el ámbito de la capa PPP (por ejemplo con RADIUS).

Para cada túnel establecido, el protocolo encapsulador genera una llave aleatoria individual para prevenir ataques de spoofing. Además, dentro del mismo túnel, cada sesión multiplexada mantendrá un número de secuencia para prevenir la duplicación de paquetes. La tunelización posibilita el agregado de encriptado o compresión de paquetes a cada extremo del túnel.

Los recursos asignados de la base de datos del proveedor de servicios solo se usan para mapear usuario con perfil con destino-de-tunel . De esa manera, la autorización de accesos a servicios de la intranet corporativa queda a cargo de la Red Privada Virtual. Así cada corporación puede tener su propia política de seguridad independiente del proveedor de servicios y con la capacidad de poder reaccionar rápidamente a cambios en la comunidad de sus usuarios remotos.

El home gateway destino puede estar detrás del firewall de la red y asignar dinámicamente al usuario remoto direcciones internas de la red corporativa (pueden ser direcciones privadas según la RFC1918). Debido a que la tunelización opera exclusivamente en la capa de enlace, para todo propósito de manejo de PPP, el usuario remoto aparece como si estuviese entrando directamente al home gateway.

Pregunta 1

Pregunta 2

Pregunta 3

http://www.cisco.com/warp/public/778/security.html

http://www.cisco.com/warp/public/779/servpro/networks/9703/dialupvpn.htm

http://www.cisco.com/warp/public/779/servpro/ipvpn_bc.htm

http://www.cisco.com/warp/public/732/net_foundation/remote_security.html

http://www.sun.com/security/sec.policy.wp.html

http://www.sun.com/solutions/solstice/security/security_glossary.html

http://www.sun.com/software/whitepapers.htm#security

http://info.internet.isi.edu/7c/in-notes/rfc/.cache

W. Arbaugh, J.R. Davin, D.J. Farber, J.M. Smth, "Security for Virtual Private Intranets", Computer Magazine (Volume 31, Number9), IEEE Computer Society, Piscataway, NJ, USA, September 1998, pp. 48-55.

Douglas E. Comer, "Internetworking with TCP/IP, Volume I, Principles, Protocols and Architecture", Third Edition, Prentice-Hall, Upper Saddle River, New Jersey, U.S.A., 1995, ch. 28.

Andrew S. Tanenbaum, "Computer Networks", Third Edition, Prentice-Hall PTR, Upper Saddle River, New Jersey, U.S.A., 1996.