Lenguajes de libre distribución para la gestión de redes basada en

Lenguajes de libre distribución para la gestión de redes basada en
políticas
Angélica Reyes, Antoni Barba
Ingeniería Telemática. Universidad Politécnica de Cataluña
angelica, [email protected]
Abstract. La gestión basada en políticas es uno de los últimos desarrollos en el área de gestión
de redes y sistemas distribuidos. Este artículo presenta una propuesta del uso de lenguajes de
libre distribución para la definición, edición y almacenamiento de políticas aplicables a la
gestión de redes.
1 Introducción
Las redes del mundo de las telecomunicaciones de hoy en día están basadas en diferentes
tecnologías para transmitir datos, telefonía, video-conferencia y otros servicios. Estas redes
utilizan sistemas de gestión que actualmente implican altos costos y una complejidad
extremadamente elevada en cuanto a la utilización y a la gestión, es por ello que se buscan
nuevos modelos de gestión para sistemas heterogéneos de redes. La gestión de redes basada en
políticas resuelve los problemas de gestión de los sistemas tradicionales y dado que resulta
evidente la necesidad de utilizar lenguajes que soporten la especificación de políticas de gestión,
de seguridad, etc. nos enfocamos principalmente en el software libre existente hoy en día para la
gestión de redes mediante políticas.
2 Sistemas de gestión basados en políticas
La gestión basada en políticas hace referencia a la agrupación de recursos (personas y
equipo) basada en las políticas (reglas) que determinan cómo interactuarán entre sí.
La gestión basada en políticas permite asegurar calidad de servicio de extremo a extremo
mediante una serie de reglas del tipo de los sistemas expertos o automatizados para proporcionar
calidad o clases de servicio basadas en prioridades ya sea de usuario, de servicio o de red.
El código de instrucción (acción) puede residir en cualquier combinación de sistemas de
gestión de redes, routers, conmutadores, servidores, bases de datos, aplicaciones y sistemas de
almacenamiento. Aunque actualmente las políticas suelen implementarse en routers y
conmutadores, es posible hacer que las políticas residan en módulos de software cargables en
los nodos de hardware, en programas dependientes de las plataformas de gestión de red o en
servidores dedicados específicamente a esta tarea. Estos elementos se encargan de recibir las
peticiones de tráfico solicitadas por los conmutadores u otros nodos, recabar información de
políticas de bases de datos y directorios, y, en consecuencia, configurar los dispositivos de red
de acuerdo con las peticiones recibidas y los derechos establecidos en la especificación de nivel
de servicio acordada entre el usuario y el proveedor de servicio Internet.
2. 1 Modelo de políticas
Una política es un conjunto de reglas definidas en un lenguaje de alto nivel por el
administrador de la red, es decir, una directiva a la red que puede contener simples mandatos
como asignar mayor prioridad a una aplicación que a otra o que un archivo sea encriptado antes
de ser transmitido.
Un ejemplo muy claro de políticas es el acuerdo de nivel de servicio (SLA) y los objetivos
de nivel de servicio (SLO), los cuales se utilizan para especificar los servicios que la red
proporcionará a sus clientes. Por lo tanto, las políticas expresan como debe ser utilizada la red
por parte de los usuarios, las aplicaciones, etc.
El grupo de trabajo del IETF se caracteriza por definir un modelo de referencia de una
arquitectura basada en políticas dirigida a la gestión de la red, especialmente la calidad de
servicio y el modelo de información básico para las políticas [1].
Un modelo de red típico basado en políticas incluye un repositorio de políticas basado en
LDAP1 (Lightweight Directory Access Protocol), un servidor de políticas, un Policy Decision
Point (PDP) y uno o varios Policy Enforcement Point (PEP) que gobiernan los dispositivos
físicos [2].
El PEP vigila que se cumplan las políticas y el PDP toma decisiones basadas en las
políticas que están en el repositorio y en otras localizaciones como los servidores de
autenticación. El PDP tiene tres tareas básicas: consultar las políticas existentes en el
repositorio, traducirlas al formato específico del dispositivo y distribuirlas a los PEPs. Cada PEP
recibe las políticas en forma de acciones de configuración específicas y es el responsable de
establecerlas en el dispositivo.
El servidor de políticas se comunica con el PEP, es decir, traducen en comandos las
políticas para enviarlas a los dispositivos de la red a través de un protocolo como el Common
Open Policy Service (COPS).
3 Lenguajes de Libre Distribución para políticas
Los lenguajes de libre distribución para políticas definen y aplican las políticas en la red,
para ello utilizan un gestor que controla los recursos de la red mediante un conjunto de políticas
predefinidas. Los lenguajes de políticas especifican reglas que son independientes de las
entidades que implementan las políticas. Estos lenguajes se definen en términos de métricas de
ejecución como ancho de banda, retraso, jitter y pérdida de paquetes y permiten la definición de
eventos y condiciones de red.
La mayoría de los lenguajes de políticas siguen el modelo de políticas que se explico
anteriormente en la sección 2.1, es decir, tienen como componentes elementales un PDP, uno o
varios PEPs, un servidor de políticas y un repositorio LDAP para las políticas.
Existen diversos lenguajes de libre distribución para la gestión basada en políticas, algunos
de ellos dan mayor énfasis a la seguridad, otros a la gestión de recursos, etc.
§
Ponder del Imperial College of Science en Inglaterra.
§
Policy Description Language (PDL) de la Universidad de Munich
§
Security Policy Language (SPL) del Institute Mageland en Portugal
A continuación se presenta una breve descripción de los lenguajes
3.1 Ponder
Ponder es uno de los lenguajes de políticas de libre distribución más antiguos y avanzados
[3]. Es un lenguaje declarativo orientado a objetos para especificar políticas de gestión y de
seguridad para sistemas de objetos distribuidos. El lenguaje permite cubrir el amplio rango de
los requerimientos actuales que presentan los paradigmas de los sistemas distribuidos.
Ponder utiliza dominios para facilitar la especificación de políticas relacionadas a sistemas
grandes, con millones de objetos; las políticas se especifican para colecciones de objetos
almacenados en dominios en lugar de objetos individuales, lo cual proporciona escalabilidad y
flexibilidad.
Las políticas que ponder soporta incluyen: Políticas básicas, compuestas y meta -políticas.
Las políticas básicas pueden ser:
1. Políticas de autorización. Definen control de acceso y uso de privilegios sobre los
objetos destino.
2. Políticas de obligación. Especifican políticas que deben ser ejecutadas sobre
determinados objetos cuando ocurren eventos específicos.
3. Políticas por delegación. Especifican acciones que un usuario puede delegar a otros.
1
El software de libre acceso del LDAP se encuentra en la página web de Open LDAP http://www.openldap.org/
Las políticas compuestas constan de:
1. Grupos. Son políticas y restricciones que tienen relaciones semántica similares y
deben utilizarse conjuntamente.
2. Roles. Especifican derechos y obligaciones para posiciones organizacionales.
3. Relaciones. Entre políticas que definen roles.
4. Tipo de especialización. Permiten la extensión a nuevas definiciones de políticas
utilizando la herencia.
La desventaja del ponder es que el nivel de complejidad es muy alto debido a que tie ne un
gran número de constructores. Además el compilador del ponder solamente genera las reglas de
implementación, es decir, dichas reglas aún necesitan mapearse manualmente al código de
aplicación específico.
3.2 Policy Description Language (PDL)
Este lenguaje se utiliza para políticas operacionales. PDL [4] no distingue entre políticas
de autorización y políticas de obligación. Las políticas hechas en PDL son por una parte
políticas de obligación, debido a que especifican explícitamente las acciones ejecutadas después
de la recepción de un evento. Por otra parte, las políticas se utilizan para configurar la
infraestructura de los nodos de la red para garantizar acceso a los distintos recursos de red. Por
lo tanto, este tipo de políticas puede verse como un refinamiento de las políticas de autorización.
Una de las desventajas del lenguaje PDL es que no permite la generación de eventos
mediante la aplicación de una política, sin embargo la descripción de una política no esta
separada de la especificación de los eventos, es decir, cada política tiene que introducir el
nombre del evento que utiliza. PDL no permite definir nuevos eventos debido a que los eventos
se reciben a partir de los agentes previamente definidos. PDL no contempla un lenguaje de
descripción de eventos.
La especificación de eventos como parte de la descripción de políticas consta de un nombre
de los eventos y sus atributos seguidos de la palabra clave DELIVERS. Los atributos se limitan
a variables de tipo “string, long y booleano”. Con la ayuda de las variables, es posible reutilizar
los valores de los atributos dentro de la especificación de las políticas en la parte de ACTION y
CONTRAINT de la política, ver tabla 1
PDL no hace distinciones entre los diferentes tipos de eventos, como la monitorización, los
eventos que responden a una fecha y hora determinada, etc.
POLICY name
FOR subject
ON ¡target¿
DELIVERS event –string –long –boolean attribute”
ACTION Idl:operation() –subject.idl:operation() – object.idl:operation()”
CONSTRAINT (…&&…--…-----….)
Tabla 1. Estructura de una política en PDL
Security Policy Language (SPL)
SPL [5] es un lenguaje de seguridad diseñado para expresar políticas que ayuden a decidir
acerca de la aceptabilidad de eventos. La aceptabilidad de cada uno de los eventos depende de
las propiedades de los eventos (por ejemplo: autor, destino, acción, etc), en el contexto
específico en el que suceden los eventos y depende también de las propiedades de los eventos
pasados. Las entidades de SPL ( usuarios, archivos , objetos, eventos, etc.) tienen una interfaz
mediante la cual se consultan sus propiedades. Una política SPL se compone de conjuntos y
reglas. Los conjuntos contienen las entidades que utilizan las políticas para decidir acerca de la
aceptabilidad de los eventos. Las reglas son funciones de los eventos que pueden tener tres tipos
de valores: negar, permitir y no aplicar. Las reglas son simples o compuestas. Las reglas simples
se conforman de dos expresiones binarias, una para decidir cual es el dominio de aplicación de
la regla y la otra para definir la aceptabilidad de los eventos aplicables a la regla. Las reglas
pueden estar compuestas de otras reglas y políticas a través del uso de álgebra ternaria. Cada
política tiene una regla especial llamada “regla de consulta” (identificada por el signo de
interrogación) la cual es una composición de otras reglas y define el comportamiento de la
política. La delegación se logra cuando se hace una instancia a una política y se utiliza como
una regla en la composició n de otras reglas.
Las desventajas de SPL son que a pesar de que SPL define un modelo de restricciones,
dicho modelo fue diseñado para que lo implementara un monitor de eventos y no es adecuado
para utilizarse en todas las plataformas de gestión.
5 Conclusión
Los lenguajes de libre distribución presentados en este artículo validan el uso actual de la
gestión basada en políticas en redes con garantías de calidad de servicio. Automatizan procesos
para facilitar la definición, verificación y aplicación de las políticas en diferentes redes, ya sea
redes ATM, redes con servicios diferenciados, etc.
Ninguno de los lenguajes presentados esta ligado a una base de datos en particular, sin
embargo se sugiere la utilización de un directorio LDAP de libre distribución para almacenar las
políticas.
Por último es importante mencionar que actualmente uno de los problemas abiertos que
intentan resolver los lenguajes de políticas es la detección y resolución de conflictos entre
políticas ya definidas. Cuando se habla de que un sistema necesita miles o millones de políticas
para definir los comportamientos de un sistema es posible encontrarse con diversos conflictos
que aún no tienen solución.
6 Referencias
[1] B. Moore, et al. Policy Core Information Model. RFC 3060. Febrero 2001
[2] R. Yavatkar, et al. A Framework for Policy-based Admission Control. RFC 2753 Enero
2000
[3] Jonathan D. Moffett and Morris S. Sloman. Policy Hierarchies for Distributed Systems
Management. IEEE JSAC Special Issue on Network Management, 11(9), Diciembre
1993.
[4] J. Lobo, R. Bathia, S. Naqvi. A policy Description Language. Sixteenth National
Conference on Artificial Intelligence (AAAI-99) 1999
[5] C.Ribeiro, P.Guedes. SPL: An access control language for security policies with
complex constraints. Technical Report RT/0001/99, INESC. Enero 1999.