viernes, 11 de noviembre de 2011

Postfix - Configuración y Puesta en Marcha III

DEL ARCHIVO DE CONFIGURACION

El formato general del archivo de configuración (main.cf) sigue el siguiente formato. (El siguiente texto es tomado textualmente de la documentación ofiicial de Postfix. http://www.postfix.org/postconf.5.html).
  • Cada línea de configuración obedece al formato "parametro = value". Los espacios en blanco alrededor del signo "=" son ignorados, igualmente sucede con los espacios en blanco al final de cada línea.
  • Líneas vacías y líneas que solo contengan espacios en blanco son ignoradas. Igualmente se ignoran todas las líneas que cuyo primer caracter no sea el espacio en blanco sino el caracter "#".
  • Cada línea válida de configuración comienza con texto diferente de espacio en blanco. Sin embargo, una línea que comience con espacio en blanco, seguirá siendo una línea de configuración válida.
  • El valor asignado a un parámetro puede hacer referencia a los valores de otros parámetros:
    • Las expresiones"$name", "${name}" o "$(name)" son recursivamente reemplazadas por el valor del parámetro al que están haciendo referencia.
    • La expresión "${name?value}" se extiende a "value" cuando "$name" no está vacía. Solo se soporta en versiones de Postfix 2.2 ó superiores.
    • La expresión "${name:value}" se extiende a "value" cuiando "$name" está vacía. Solo se soporta en versiones de Postfix 2.2 ó superiores.
  • Cuando un mismo parámetro es definido varias veces, solo aplica a la configuración, la última instacia encontrada del mismo.
  • En cualquier otro caso, el orden de los parámetros definidos en main.cf no es importante.

DEL RELAY

La verdad es que Postfix es tan bueno, que por defecto sin decirle nada es capaz de hacer Relay a todo el conjunto de clientes que se encuentren en la misma subred de cada interface de red que tengamos conectada al sistema. Por ejemplo, suponiendo que tenemos una máquina con tres interfaces de red así:
10.1.0.254  MASK 255.255.0.0
192.168.1.254          MASK 255.255.255.0
200.1.2.3  MASK 255.255.255.248

Suponiendo que la interface con la IP 200.1.2.3 es nuestra interface externa, Postfix es capaz de hacerle Relay por defecto a todos los clientes que se encuentren en la subred 10.1.0.0/255.255.0.0 y la subred 192.168.1.0/255.255.255.0. Postfix también sabe que la interface 200.1.2.3 es la externa y que a esa subred no se le debe hacer Relay. Sin embargo hay dos parámetros en el archivo de configuración de Postfix, que pueden sintonizar al gusto de ustedes el tema del Relay. Ambos parámetros son los siguientes:
 
mynetworks_style 
mynetworks
  
No voy a entrar a explicarlos, son sumamente simples y como Postfix le hace Relay por defecto a los clientes que se encuentran en la misma subred creo que no hace falta entrar ahora en esos detalles. Si se pasan por esta página http://www.postfix.org/BASIC_CONFIGURATION_README.html, se van a dar cuenta lo simples que son.
Entre otras cosas, ¿qué es el Relay?. Tomen esta explicación del concepto de Open Relay.
- http://es.wikipedia.org/wiki/Open_Relay

Postfix - Configuración y Puesta en Marcha II

Las directivas mínimas, para tener nuestro Postfix corriendo a las mil maravillas son las siguientes:

mydomain =
El nombre del dominio de Internet para este sistema de correo; por defecto se utiliza el valor de la variable $myhostname sin el primer componente del valor de la misma. El valor de la variable $mydomain se utiliza por defecto en muchos otros parámetros de la configuración de Postfix.
Ej:
mydomain = antel.com.uy

myhostname =
Especifique el nombre de Internet para este host. El valor de esta variable debe ser un nombre FQDN resoluble a través de consultas DNS.
Ej:
myhostname = mail.antel.com.uy
Ustedes saben que el servicio de correo va muy de la mano con el DNS, quizá en otro artículo haga más detalle sobre el DNS, pero por ahora solo puedo decirles lo que explico aquí. Por ejemplo, el valor de esta directiva aparece en el banner SMTP cuando se establece una sesión SMTP con nuestro servidor de correo Postfix, por ejemplo:
telnet 192.168.1.1 25
220 mail.antel.com.uy ESMTP Postfix
Aquí solo estoy ejemplificando el uso de esta variable, pero la verdad es que se utiliza para más parámetros de la configuración de Postfix.

myorigin =
Especifique el dominio de Internet con el que se originan los mensajes de correo salientes de este servidor de correo. Este es el dominio que aparece en el campo “From” de los mensajes de correo.
Ej:
myorigin = $mydomain
ó bien,
myorigin = antel.com.uy
En otras palabra, cuando ustedes envíen un mensaje de correo a través del servidor Postfix, el destinatario final verá en el campo "From:" ó en el campo "De:" (para los hispano hablantes) del mensaje de correo, algo como:
From: Juan Sosa 
En caso de que se coloque
myorigin = $myhostname
Entonces el destinatario final de nuestros correos vería algo como:
From: Juan Sosa 


mydestination =
Especifique los dominios de Internet que este sistema de correo atiende.
Ej:
mydestination = $mydomain localhost.localdomain localhost $myhostname
ó bien,
mydestination = antel.com.uy localhost.localdomain localhost mail.antel.com.uy

Es con este parámetro que le estamos diciendo a Postfix cuales dominios de Internet atiende para el correo. Si, como ya habrán sacado sus conclusiones, es con este parámetro que le decimos a Postfix que reciba el correo que va dirigido para antel.com.uy, localhost.localdomain, localhost y mail.antel.com.uy. ¿Oiste Juan, y porque tantos valores para este parámetro?. Pues porque la novia que tenemos en la empresa X y la novia que tenemos en la empresa Y no son las únicas que nos mandan correo a juan@antel.com.uy. Dentro del mismo servidor de correo hay aplicaciones que envían notificaciones vía correo electrónico a los administradores de las mismas (notificando algún evento particular), generalmente estas aplicaciones envían mensajes de correo de la siguiente manera: root@localhost ó root@localhost.localdomain ó juan@mail.antel.com.uy ó postmaster@localhost.localdomain. Por esta razón es que hay que decirle a Postfix que reciba el correo para todas estas denominaciones.

inet_interfaces =
Especifique las direcciones IP de las Interfaces por las cuales se desea que Postfix quede a la escucha del servicio SMTP. Si desea configurar el servicio en todas las interfaces, asigne a esta variable el valor all.
Ej:
inet_interfaces = all
inet_interfaces = loopback-only (Postfix 2.2 and later)
inet_interfaces = 127.0.0.1
inet_interfaces = 127.0.0.1, [::1] (Postfix 2.2 and later)
inet_interfaces = 192.168.1.2, 127.0.0.1
    
Como sabemos, el servicio de correo pone un Socket TCP en el puerto 25, con este parámetro le decimos a Postfix en que interface de red vamos a colocar el Socket TCP/25 a la escucha de las peticiones. Si lo que estamos configurando es un servicio que está disponible desde Internet, entonces deberíamos asignar el valor all a esta variable. Con el valor all ponemos un Socket TCP/25 en todas las interfaces de red que tengamos, es decir, si tenemos tres interfaces de red así:
127.0.0.1
192.168.1.1
200.1.2.3
 
Una petición dirigida a 127.0.0.1 puerto 25, será válida, lo mismo sucede con las peticiones hechas a 192.168.1.1 y 200.1.2.3.
  • Ahora si, con la explicación anterior, agregamos al final del archivo main.cf, los parámetros explicados:
    mydomain = antel.com.uy
    myhostname = mail.antel.com.uy
    myorigin = $mydomain
    mydestination = $mydomain localhost.localdomain localhost $myhostname
    inet_interfaces = all
    
  • Hemos finalizado la configuración. Guardamos los cambios en el archivo main.cf e iniciamos nuestro servidor Postfix de la siguiente manera:
    /etc/init.d/postfix start
  • Para hacer que nuestro servidor Postfix arranque cuando la máquina se encienda nuevamente, ejecutamos el siguiente comando:
  • chkconfig --level 345 postfix on
    
    
DE LAS VERIFICACIONES

Lo primero que deberíamos verificar es lo siguiente:
  • Socket TCP con Puerto 25 disponible en todas las interfaces. Para esto, ejecutamos:
  • netstat -an | grep 25
deberíamos ver una salida similar a la siguiente:
.
.
.
tcp        0      0 10.100.0.253:53             0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN
.
.
 
De especial interés la línea:
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN

Con esto verificamos que el servicio está a la escucha en todas las interfaces. Recuerden que 0.0.0.0 significa todas las interfaces y el 25 significa el número de puerto que está a la escucha. El puerto No. 25 corresponde al protocolo SMTP. Otras salidas interesantes del comando netstat, son las siguientes (compruébelo usted mismo):
netstat -anp
netstat -pls (jejeje...está me la pille en pello.info)
netstat -ano  (juas!!!..microsoft.com no deja de impresionarme)
  
  • Hablando SMTP.
     También es interesante aprender hablar LDAP, BGP-4, HTTP, entre otras cosas. Una prueba que usualmente se hace es hablar SMTP directamente con nuestro servidor de correo para verificar que todo está funcionando como esperamos (es decir, por lo menos es capaz de recibir correo). Para hablar SMTP con nuestro servidor de correo solo basta con hacer una sesión telnet dirigida al puerto 25 de cualquier dirección IP de nuestro servidor de correo.
    En el ejemplo que voy a ilustrar a continuación, supongo lo siguiente:
    La IP interna de mi servidor de correo es: 192.168.1.1
    Dentro del servidor de correo existe un buzón de correo para juan@antel.com.uy
    Voy a enviarle un mensaje de prueba a juan@antel.com.uy, diciendo que yo soy mrwolf@pulpfiction.com.

Pongo a continuación mi diálogo SMTP con mi servidor de correo a través de una sesión Telnet al puerto 25 de mi servidor de correo. Usted puede probar de acuerdo con sus configuraciones lo mismo (lo que yo escribí está en negrita y de color verde, lo demás son respuestas del servidor a los diferentes comandos SMTP):
telnet 192.168.1.1 25

220 mail.antel.com.uy ESMTP Postfix
HELO juanmuno.antel.com.uy
250 mail.antel.com.uy
MAIL FROM: mrwolf@pulpfiction.com
250 Ok
RCPT TO: juan@antel.com.uy
250 Ok
DATA
354 Please start mail input.
HI, MY NAME IS MR WOLF. I SOLVE PROBLEMS...
.
250 Mail queued for delivery.

QUIT
221 Closing connection. Good bye.


Connection to host lost.
  
Con lo anterior, a juan@antel.com.uy, le debió llegar un mensaje de correo de mrwolf@pulpfiction.com diciendo:
HI, MY NAME IS MR WOLF. I SOLVE PROBLEMS
Para aquellos novicios y curiosos, el protocolo SMTP está especificadoen el RFC 821 (http://www.faqs.org/rfcs/rfc821.html).

Postfix - Configuración y Puesta en Marcha I

Introducción

Esto es una breve introducción de como configurar nuestro propio servidor de correo basado en Postfix (http://www.postfix.org). Postfix es un MTA (Mail Transfer Agent) que nace como una alternativa para sustituir al viejo y archi reconocido Sendmail (http://www.sendmail.org). ¿Qué cual es la diferencia entonces? Sendmail ha sido un MTA (al igual que Postfix) que ha evolucionado con el tiempo, inicialmente Sendmail fue un MTA que nació con muchas deficiencias, incluso aquellos geeks que han leído un poco sobre el tema, se acordarán del famoso gusano Morris (http://en.wikipedia.org/wiki/Morris_worm) el cual, entre otros atributos, explotaba una vulnerabilidad de Sendmail. Incluso, durante aquella época, populaba un chiste entre los geeks el cual decía: "¿y cual es la nueva vulnerabilidad de Sendmail para hoy?". Bien, no es que Sendmail sea malo, por el contrario, como cualquier software, éste ha evolucionado con el tiempo y mejorado mucho más. Si algo hay que saber sobre Sendmail, es que es uno de los servidores de correo más utilizados en el mundo. 
Pero bueno, no vinimos aquí a saber de Sendmail, como lo dije al principio, esta vez vamos a conocer a un viejo también archi conocido Postfix. Postfix nace como una alternativa más segura, más rápida, más simple de administrar y lo suficientemente compatible con Sendmail. Postfix es una creación de Wietse Zweitze Venema (http://www.porcupine.org/wietse/).
Para este documento asumo como distribución de Linux, las siguientes: Redhat 9, Fedora Core 3 ó Fedora Core 4 basadas en el sistema de paquetes rpm.

HOWTO
  • Descargamos el RPM de la distribución que tengamos, para ello nos podemos apoyar en Rpmfind.net y buscar allí el término "postfix" para encontrar un grande listado de recursos en donde podemos descargar esta maravilla de servidor de correo.
  • Instalamos el RPM que descargamos con los famosos comandos RPM, por ejemplo:
    rpm -i postfix-1.1.12-1.i386.rpm
  • Es bueno hacer las siguientes anotaciones:
- Si ya tenemos Sendmail funcionando en nuestra máquina, es bueno que detengamos el servicio para no entrar en conflicto con nuestra nueva adquisición. Para ello basta con que ejecuten los siguientes comandos:

/etc/init.d/sendmail stop
chkconfig --level 345 sendmail off

- Si lo que tenemos es un Sendmail levantado por Gateways antivirus como MailScanner, entonces hacemos lo siguiente:
    /etc/init.d/MailScanner stop 
  • Si todo se instaló sin problemas, entonces nos vamos para /etc/postfix.
    cd /etc/postfix
  • Una vez en el directorio de configuración de Postfix, por seguridad nos hacemos una copia del archivo main.cf.
    cp main.cf main.cf.ori
     
    El ".ori" no es de "orines", "orinoco" ni nada por el estilo, el ".ori" es de "original". Esto es bueno hacerlo por si no somos muy diestros al editar archivos y por si algo va mal, pues ponemos el archivo de configuración original y listo, "no ha pasado nada".

DEL ARCHIVO DE CONFIGURACION

El formato general del archivo de configuración (main.cf) sigue el siguiente formato. (El siguiente texto es tomado textualmente de la documentación ofiicial de Postfix. http://www.postfix.org/postconf.5.html).
  • Cada línea de configuración obedece al formato "parametro = value". Los espacios en blanco alrededor del signo "=" son ignorados, igualmente sucede con los espacios en blanco al final de cada línea.
  • Líneas vacías y líneas que solo contengan espacios en blanco son ignoradas. Igualmente se ignoran todas las líneas que cuyo primer caracter no sea el espacio en blanco sino el caracter "#".
  • Cada línea válida de configuración comienza con texto diferente de espacio en blanco. Sin embargo, una línea que comience con espacio en blanco, seguirá siendo una línea de configuración válida.
  • El valor asignado a un parámetro puede hacer referencia a los valores de otros parámetros:
    • Las expresiones"$name", "${name}" o "$(name)" son recursivamente reemplazadas por el valor del parámetro al que están haciendo referencia.
    • La expresión "${name?value}" se extiende a "value" cuando "$name" no está vacía. Solo se soporta en versiones de Postfix 2.2 ó superiores.
    • La expresión "${name:value}" se extiende a "value" cuiando "$name" está vacía. Solo se soporta en versiones de Postfix 2.2 ó superiores.
  • Cuando un mismo parámetro es definido varias veces, solo aplica a la configuración, la última instacia encontrada del mismo.
  • En cualquier otro caso, el orden de los parámetros definidos en main.cf no es importante.

DEL RELAY

La verdad es que Postfix es tan bueno, que por defecto sin decirle nada es capaz de hacer Relay a todo el conjunto de clientes que se encuentren en la misma subred de cada interface de red que tengamos conectada al sistema. Por ejemplo, suponiendo que tenemos una máquina con tres interfaces de red así:
10.1.0.254  MASK 255.255.0.0
192.168.1.254          MASK 255.255.255.0
200.1.2.3  MASK 255.255.255.248

Suponiendo que la interface con la IP 200.1.2.3 es nuestra interface externa, Postfix es capaz de hacerle Relay por defecto a todos los clientes que se encuentren en la subred 10.1.0.0/255.255.0.0 y la subred 192.168.1.0/255.255.255.0. Postfix también sabe que la interface 200.1.2.3 es la externa y que a esa subred no se le debe hacer Relay. Sin embargo hay dos parámetros en el archivo de configuración de Postfix, que pueden sintonizar al gusto de ustedes el tema del Relay. Ambos parámetros son los siguientes:
 
mynetworks_style 
mynetworks
  
No voy a entrar a explicarlos, son sumamente simples y como Postfix le hace Relay por defecto a los clientes que se encuentran en la misma subred creo que no hace falta entrar ahora en esos detalles. Si se pasan por esta página http://www.postfix.org/BASIC_CONFIGURATION_README.html, se van a dar cuenta lo simples que son.
Entre otras cosas, ¿qué es el Relay?. Tomen esta explicación del concepto de Open Relay.
- http://es.wikipedia.org/wiki/Open_Relay

sábado, 27 de agosto de 2011

OpenVPN I

Es un software que brinda una solución de conectividad punto a punto en capa
2 o en capa 3, basada en SSL (Secure Sockets Layer) y VPN (Virtual Private Network). Posee validación jerárquica de usuarios y hosts remotos.
Es una aplicación multiplataforma, que surge para facilitar la configuración de
vpn's dejando atrás soluciones complejas como sería IPsec.

Seguridad en OPENVPN, este implementa dos modos:

claves estáticas pre-compartidas: se posee una clave que se comparte entre todos los clientes y servidor, de forma que cualquiera que posea dicha clave podrá encriptar/desencriptar los mensajes.

SSL/TLS usando certificados y claves RSA: se utilizan dos claves, una pública y otra privada. La pública será entregada a todos y usada para encriptar los datos, mientras que la privada será usada para desencriptar los menajes recibidos.

VPN (Virtual Private Network)

Una Red Privada Virtual o VPN (por sus siglas en Inglés, Virtual Private Network), es una tecnología de red que permite extender la red local (o LAN) sobre una red no controlada (por ejemplo “Internet”) garantizando a los usuarios un acceso seguro consiguiendo las cuatro características básicas de seguridad, estas son:

  • Autenticación y autorización

  • Integridad

  • Confidencialidad

  • No repudio



Existen varios tipos de técnicas, tanto a nivel de capa 3 o a nivel de capa 2. Cuando las redes están conectadas a través de internet, precisaremos de la capa IP para alcanzar las otras redes, por lo tanto se implementa lo que se denomina una VPN de acceso remoto.


jueves, 25 de agosto de 2011

IPsec II

Propósito de diseño

IPsec fue proyectado para proporcionar seguridad en modo transporte (extremo a extremo) del tráfico de paquetes, en el que los ordenadores de los extremos finales realizan el procesado de seguridad, o en modo túnel (puerta a puerta) en el que la seguridad del tráfico de paquetes es proporcionada a varias máquinas (incluso a toda la red de área local) por un único nodo. IPsec puede utilizarse para crear VPNs en los dos modos, y este es su uso principal. Hay que tener en cuenta, sin embargo, que las implicaciones de seguridad son bastante diferentes entre los dos
modos de operación. La seguridad de comunicaciones extremo a extremo a escala Internet se ha desarrollado más lentamente de lo esperado. Parte de la razón a esto es que no ha surgido infraestructura de clave pública universal o universalmente de confianza (DNSSEC fue originalmente previsto para esto); otra parte es que muchos usuarios no comprenden lo suficientemente bien ni sus necesidades ni las opciones disponibles como para promover su inclusión en los productos de los vendedores. Como el Protocolo de Internet no provee intrínsecamente de ninguna capacidad de seguridad, IPsec se introdujo para proporcionar servicios de seguridad tales como:

1. Cifrar el tráfico (de forma que no pueda ser leído por nadie más que las partes a las que está dirigido)
2. Validación de integridad (asegurar que el tráfico no ha sido modificado a lo largo de su trayecto)
3. Autenticar a los extremos (asegurar que el tráfico proviene de un extremo de confianza)
4. Anti-repetición (proteger contra la repetición de la sesión segura).

Podemos establecer dos modos básicos de operación de IPsec: modo transporte y modo túnel.

Modo transporte

En modo transporte, sólo la carga útil (los datos que se transfieren) del paquete IP es cifrada o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticación (AH), las direcciones IP no pueden ser traducidas, ya que eso invalidaría el hash. Las capas de transporte y aplicación están siempre
aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplo traduciendo los números de puerto TCP y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador.
Una forma de encapsular mensajes IPsec para atravesar NAT ha sido definido por RFCs que describen el mecanismo de NAT transversal.

Modo túnel

En el modo túnel, todo el paquete IP (datos más cabeceras del mensaje) es cifrado o autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo túnel se utiliza para comunicaciones red a red (túneles seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a ordenador sobre Internet.

jueves, 18 de agosto de 2011

IPsec I


IPsec
(Internet Protocol security) es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos. IPsec también incluye protocolos para el establecimiento de claves de cifrado. Los protocolos de IPsec actúan en la capa de red. Otros protocolos de seguridad para Internet de uso extendido, como SSL, TLS y SSH operan de la capa de transporte (capas OSI 4 a 7) hacia arriba. Esto hace que IPsec sea más flexible, ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendo TCP y UDP, los protocolos de capa de transporte más usados. Una ventaja importante de IPsec frente a SSL y otros métodos que operan en capas superiores, es que para que una aplicación pueda usar IPsec no hay que hacer ningún cambio, mientras que para usar SSL y otros protocolos de niveles superiores, las aplicaciones tienen que modificar su código.

Arquitectura de seguridad

IPsec está implementado por un conjunto de protocolos criptográficos para (1) asegurar el flujo de paquetes, (2) garantizar la autenticación mutua y (3) establecer parámetros criptográficos. La arquitectura de seguridad IP utiliza el concepto de asociación de seguridad como base para construir funciones de seguridad en IP. Una asociación de seguridad es simplemente el paquete de algoritmos y parámetros (tales como las claves) que se está usando para cifrar y autenticar un flujo
particular en una dirección. Por lo tanto, en el tráfico normal bidireccional, los flujos son asegurados por un par de asociaciones de seguridad. La decisión final de los algoritmos de cifrado y autenticación le corresponde al administrador de IPsec.
Para decidir qué protección se va a proporcionar a un paquete saliente, IPsec utiliza el índice de parámetro de seguridad (SPI), un índice a la base de datos de asociaciones de seguridad (SADB), junto con la dirección de destino de la cabecera del paquete, que juntos identifican de forma única una asociación de seguridad para dicho paquete. Para un paquete entrante se realiza un procedimiento similar; en este caso IPsec toma las claves de verificación y descifrado de la base de
datos de asociaciones de seguridad. En el caso de multicast, se proporciona una asociación de seguridad al grupo, y se duplica para todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un
grupo, utilizando diferentes SPIs, y por ello permitiendo múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, permitiendo autenticación, ya que un receptor sólo puede saber que alguien que conoce las claves ha enviado los datos. Hay que observar que el estándar pertinente no describe cómo se elige y duplica la asociación a través del grupo; se asume que un interesado responsable habrá hecho la elección.

domingo, 29 de mayo de 2011

NGN - PSTN Simulation Services

  • Proporciona en tecnología de paquetes una funcionalidad que puede ser equivalente a la telefonía sobre circuitos.
  • Posibilita el uso de nuevos tipos de terminales telefónicos, con interfaces de datos y con conversión de la voz a paquetes en el mismo terminal.
  • Para conectar terminales telefónicos de PSTN/ISDN es necesario instrumentar dispositivos adaptadores en el hogar del suscriptor (IADs) que adapten la interfaz analógica a un User Agent de VoIP.

Principales razones para la evolución hacia esta implementación:
  • Posibilidad de extender el servicio telefónico a cualquier sitio que disponga de conectividad basada en protocolo IP.
  • Utilizar terminales con mayores capacidades posibilita que parte de la capacidad de procesamiento del terminal se utilice para prestaciones adicionales a las que brinda PSTN.


  • Es importante destacar que PSS no puede emular el 100% de las funcionalidades de PSTN, dado que no hay interacción analógica entre el terminal y la red.
  • La arquitectura de NGN para PSS se basa en el IP Multimedia Subsystem o IMS.

miércoles, 25 de mayo de 2011

NGN - PSTN Emulation Services

El objetivo de la PES (PSTN Emulation Services) es replicar el 100% de las funcionalidades de la PSTN reemplazando la conmutación de circuitos por conmutación de paquetes.
Procura que todos los servicios PSTN permanezcan disponibles e idénticos en la red de paquetes. El terminal es el mismo de PSTN. La adaptación de los terminales o interfaces se realiza mediante gateways.

Razones para la evolución hacia PES:
  • Obsolencia de la red PSTN existente.
  • Disminución de costos operativos.
  • La centralización de servicios de red inteligente a través del softswitch.
  • Posibilidad de converger sobre protocolos de paquetes (IP) en la red de transporte y cuando emplea gateways residenciales también converger en el acceso.

Elementos de la red son, softswitches, gateways de señalización, gateways de acceso, gateways residenciales, gateways de troncales y servidores de aplicaciones.

El Softswitch también conocido como Call Agent o Media Gateway Controller (MGC), controla la provisión del servicio y de las llamadas. Controla los media gateway (de acceso y/o enlace) mediante H.248 o MGCP. También debe manejar otros protocolos, como SIP-T y BICC, para comunicarse con otros softswitches. Genera información para la tarificación.

Softswitch = Media Gateway Controller + Signaling Gateway

Posibilita el control de llamadas para clientes de VoIP incorporando funcionalidades de SIP proxy y/o H.323 Gatekeeper. Generalmente pueden replicar funciones de las centrales de PSTN:
  • Equivalentes clase 4: Los switches Class 4 sustituyen a las centrales de larga distancia (centrales interurbanas o internacionales).
  • Equivalentes clase 5: Los switches Class 5 se sitúan en lugar de las tradicionales centrales locales para servicios residenciales y clientes empresariales.
  • Equivalentes a un SSP de redes inteligentes: Esta función generalmente está incluida en un softswitch clase 4, y su propósito es disparar la interacción de llamadas con lógicas de servicios de redes inteligentes tales como 0800 y llamadas de prepago, redes privadas virtuales de telefonía, etc.
  • Equivalente a conmutadores para celular: También es cada vez más corriente que los MSC celulares se reemplacen por softswitches para introducir nuevas funcionalidades en redes de 2G.

Signaling gateway:
  • Puede proveer conversión de señalización de un medio a otro, por ejemplo, SS7 sobre TDM y SS7 sobre IP; o SS7 y IP.
  • Su función es actuar como gateway entre la señalización de la PSTN y la señalización del softswitch.
  • Muchas veces está incluido en el softswitch
Application Server:
  • Brinda aplicaciones que no son realizadas por el Softswitch.
  • Por ejemplo correo de voz, entre otras.
Gateways de Acceso: puntos de concentración similar al tradicional concentrador de abonados de conmutación de circuitos.
Gateways Residenciales: elementos instalados en las premisas del suscriptor convierten el servicio PSTN a paquetes.
Gateways de troncales: vinculan a la red de paquetes con los troncales de la red PSTN existente.

Son controlados por el Media Gateway Controller mediante H.248 o MGCP.


SOFTSWITCHING

  • Requiere construir por lo menos un contexto por llamada en cada MGW extremo de la comunicación.
  • Cada contexto tendrá al menos 2 terminaciones porque vincula ambos lados del GW.
  • Por lo tanto una llamada tendrá al menos 2 contextos y 4 terminaciones.
  • Los procesadores digitales (DSP) cargan las muestras de voz "comprimidas" por el codec en paquetes RTP sobre UDP para ser transportados mediante flujos RTP/RTCP.

PROTOCOLOS
  • H.248: Estándar definido por la ITU-T (MEGACO), Gestiona sesiones y señalización, Esta gestión es necesaria durante la comunicación entre una pasarela de medios y el controlador que la gestiona, para establecer, mantener, y finalizar las llamadas entre múltiples extremos.
  • SIP (Session Initation Protocol): Gestiona la señalización de las comunicaciones y las negociaciones para el establecimiento, mantenimiento y terminación de llamada desde los terminales modo paquete.
  • ENUM (Electronic NUMbering): Permite establecer correspondencia entre la numeración telefónica tradicional (E.164) y las direcciones de acceso relacionadas con las redes modo paquete.

CALIDAD DE SERVICIO

En una red de paquetes hay tres factores que afectan la calidad del servicio telefónico:
  • latencia o retardo total en la red.
  • jitter o variación del retardo.
  • pérdida de paquetes.
  • Considerando que una red IP es de mejor esfuerzo, es necesario agregar mecanismos adicionales para proveer calidad de servicio.
  • En general consisten en diferenciar el tráfico de voz y darle mayor prioridad que al tráfico que no es en tiempo real.
  • Mecanismos:a nivel de capa 2: separación en VLAN y priorización. a nivel de capa 3: Diffserv, RSVP y MPLS.



martes, 24 de mayo de 2011

NGN - Parte 2

Definición de NGN según ITU-T: "una red basada en paquetes, que puede proveer servicios de telecomunicaciones y que puede hacer uso de múltiples tecnologías de banda ancha con transporte de calidad de servicio y en la cual las funciones relativas al servicio son independientes de las tecnologías relativas al transporte..."

  • Red multiservicio capaz de manejar voz, datos y video.
  • Plano de control (señalización, control) separado del plano de transporte y conmutación /ruteo.
  • Interfaces abiertos en el transporte, el control y las aplicaciones.
  • Usa tecnología de paquetes (IP) para transportar todo tipo de información.
  • Calidad de servicio garantizada extremo a extremo para distintos tipos de tráfico y acuerdos de nivel de servicio.
  • Interoperabilidad con las redes legadas mediante interfaces abiertas.
  • Soporte de movilidad generalizada.
  • Soporte de múltiples tecnologías de última milla.

ARQUITECTURA

La red se divide en:
  • acceso/borde: Permite el acceso de los usuarios a la red. Provee adaptación a diferentes métodos de transporte.
  • transporte/core conmutado: Realiza el transporte de los paquetes. Provee la interconexión entre las otras partes.
  • servicios/control/aplicación: Provee control inteligente de la señalización y los medios para proveer los servicios a los usuarios.

La división funcional básica es en dos estratos:
  • Estrato de Servicio
  • Estrato de Transporte
Estrato de Transporte: "La parte de la NGN que provee las funciones de usuario que transfieren datos y las funciones que controlan y administran los recursos de transporte para llevar dichos datos entre entidades terminales..."
  • Transmisión de información digital entre dos puntos geográficamente separados.
  • Involucra en particular un conjunto de capas 1 a 3 del modelo de referencia OSI, con sus funcionalidades.
  • Provee conectividad: usuario a usuario, usuario a plataforma de servicio, plataforma de servicio a usuario.
Estrato de Servicio: "La parte de la NGN que provee las funciones de usuario que transfieren datos relativos a servicios y funciones que controlan y mantienen recursos de servicios y los servicios de red para posibilitar los servicios del usuario y aplicaciones... El estrato de servicio NGN consta de la aplicación y sus servicios que funcionan entre entidades pares..."

  • Funciones de aplicación relativas al servicio a ser invocado.
  • Los servicios pueden ser por ejemplo: voz, datos, video o multimedia.

Cada estrato comprende una o más capas. Cada capa se compone de: plano de datos, plano de control y plano de mantenimiento.

Plano de gestión de la NGN: unión del plano de gestión del estrato de servicio y el plano de gestión del estrato de transporte.

Plano de control de la NGN: unión del plano de control del estrato de servicio y el plano de control del estrato de transporte.

Calidad de Servicio (QoS)

La NGN debe ser capaz de soportar una gran variedad de servicios con especificación de QoS.
Para ofrecer estos servicios de QoS es necesario definir:
  1. clases de QoS del servicio portador
  2. mecanismos de control de la QoS
  3. arquitectura funcional del control de la QoS
  4. control/señalización de la QoS

Seguridad

La PSTN ha sido muy poco vulnerable a problemas de seguridad.
Hay tres elementos fundamentales a prevenir: Negación de servicio, Robo de servicio, Invasión de privacidad.


Posibilidades de evolución

Se plantean dos posibilidades técnicas de evolución NGN.
  • PSTN Emulation Services o PES.
  • PSTN Simulation Services o PSS.

NGN - Next Generation Networks (Redes de Próxima Generación)

NGN ha sido considerado muchas veces sinónimo de convergencia, pero convergencia no implica una arquitectura de red.
La convergencia puede darse en el transporte, acceso, o en los servicios. Los usuarios desean convergencia a nivel de dispositivo. Las empresas y operadores desean convergencia a nivel de transporte.
Convergencia: Es la combinación de dos o más tecnologías en un mismo dispositivo.

La convergencia de los servicios de voz y datos en el uso del transporte, y en algunos casos del acceso, fue la primera que se planteó. Las primeras arquitecturas de NGN basadas en un conmutador de conexiones en una red de paquetes son las que están más difundidas.

Los denominados "softswitches" son los nodos controladores de comunicaciones que caracterizan esta etapa. La idea de tener Softswitches es mover el control de las llamadas y de otros servicios localizados en los conmutadores de las PSTN, hacia servidores vinculados a una red de paquetes.

La voz que transcurre por circuitos en PSTN es convertida a paquetes por medio de gateways que actúan como frontera de la red de conmutación de paquetes. Esto requiere de ciertos cambios o consideraciones en la red de paquetes, si se pretende brindar un servicio que conserve las características de PSTN de calidad y grado de servicio. De no existir acuerdo los servicios brindados sobre Internet hacen uso de una calidad de servicio (QoS) muy limitada. Muchos consumidores utilizan servicios sin QoS porque el ancho de banda disponible es suficiente para un uso satisfactorio, y las tarifas son muy convenientes.

Evolución a Redes Convergentes

Si los servicios de PSTN se van a seguir brindando como tales esta transformación tiene que tomar en cuenta la expectativa de los usuarios, logrando al menos:
  • El teléfono funcione bajo condiciones adversas, incluyendo falta de suministro eléctrico.
  • Incidencia de la ingeniería de tráfico sobre los recursos de la red resulte en una casi imperceptible imposibilidad de realizar comunicaciones.
  • Calidad de voz igual o mejor a la de la telefonía PSTN.
  • Confidencialidad en las comunicaciones comparable con la PSTN. (Toda solución de NGN debe soportar la intercepción de llamadas por razones judiciales).
  • Disponibilidad del servicio igual o mejor a la de PSTN. (99.999% y en algunos clientes corporativos 99,9999%).


Cuando se evalúa la posibilidad de evolucionar a una red convergente existen varios factores a ser considerados:
  • Ubicación de la inteligencia del servicio (dentro de un nuevo elemento de la red convergente).
  • Utilización de estándares abiertos.
  • Convergencia en la red de acceso (la tecnología de acceso debe poder evolucionar para entregar voz y datos, logrando a largo plazo una convergencia total de la red).
  • Convergencia en el backbone.
  • Integración con sistemas conmutados legados.
  • La solución es robusta y confiable.

Para una PSTN ya instalada se puede sugerir que la evolución de la red en los próximos años sea de la siguiente forma:
  • No instalar más equipos basados en conmutación de circuitos.
  • Implementar los nuevos servicios en torno a una arquitectura convergente.
  • La red de transporte evoluciona a paquetes con capacidad para proporcionar calidad de servicio por medio de una adecuada ingeniería de tráfico.
  • Prever una mejora en la inteligencia del terminal del usuario y en los servidores de aplicaciones.
  • Prever la evolución del terminal del usuario a un teléfono "inteligente".
  • Renovar los terminales para incorporar nuevas y atractivas funcionalidades.