SIP ALG

Operación SIP ALG

Hay dos tipos de tráfico SIP, la señalización y el flujo de medios. El tráfico de señalización SIP consta de mensajes de solicitud y respuesta entre el cliente y el servidor y utiliza protocolos de transporte como UDP o TCP. El flujo de medios transporta los datos (datos de audio, por ejemplo) mediante protocolos de transporte.

A partir de Junos OS versión 12.3X48-D25 y Junos OS versión 17.3R1, SIP ALG admite TCP. El soporte TCP a través de SIP ALG reduce el tráfico al servidor al eliminar la necesidad de volver a registrar o actualizar el servidor con frecuencia.

De forma predeterminada, Junos OS admite mensajes de señalización SIP en el puerto 5060. Puede configurar el puerto mediante la creación de una política que permita el servicio SIP y el software filtra el tráfico de señalización SIP como cualquier otro tipo de tráfico, permitiéndolo o denegándolo. Sin embargo, la transmisión de medios utiliza números de puerto asignados dinámicamente que pueden cambiar varias veces durante el transcurso de una llamada. Sin puertos fijos, no es seguro crear una política estática para controlar el tráfico de medios. En este caso, el dispositivo invoca el ALG SIP. Los puertos de transporte de dispositivos utilizados para las sesiones de medios no se conocen de antemano; sin embargo, los puertos utilizados para la negociación SIP son bien conocidos (o predefinidos). El ALG registra el interés en los paquetes de la sesión de control, que puede distinguir fácilmente de los demás paquetes, e inspecciona la negociación para la información de transporte utilizada para la sesión de medios (tanto direcciones IP como puertos).

El SIP ALG monitorea las transacciones SIP y crea y administra dinámicamente agujeros en función de la información que extrae de estas transacciones. El ALG SIP de Juniper Networks admite todos los métodos y respuestas SIP. Puede permitir que las transacciones SIP atraviesen el firewall de Juniper Networks creando una política estática que permita el servicio SIP. Si la política está configurada para inspeccionar el tráfico SIP (o, más apropiadamente, si la política envía algo de tráfico al ALG SIP para su inspección), las acciones permitidas son permitir el tráfico (en cuyo caso se abren los agujeros adecuados) o denegar el tráfico.

El ALG SIP intercepta los mensajes SIP que contienen SDP y, mediante un analizador, extrae la información que necesita para crear agujeros de alfiler. El ALG SIP examina la parte SDP del paquete y un analizador extrae información como direcciones IP y números de puerto, que el ALG SIP registra en una tabla estenopeica. El ALG SIP utiliza las direcciones IP y los números de puerto registrados en la tabla de agujeros para abrir agujeros y permitir que las transmisiones de medios atraviesen el dispositivo.

Los productos SIP de NEC son compatibles condicionalmente.

Descripciones de sesiones de SDP

La descripción de una sesión SDP es un formato bien definido para transmitir información suficiente para descubrir y participar en una sesión multimedia. Una sesión se describe mediante una serie de pares de atributo y valor, uno por línea. Los nombres de atributo son caracteres individuales, seguidos de = y un valor. Los valores opcionales se especifican con =*. Los valores son una cadena ASCII o una secuencia de tipos específicos separados por espacios. Los nombres de atributo solo son únicos dentro de la construcción sintáctica asociada, como dentro de la sesión, la hora o el medio solamente.

De los muchos campos de la descripción de SDP, dos son particularmente útiles para SIP ALG porque contienen información de la capa de transporte.

• c= Para obtener información sobre la conexión

  Este campo puede aparecer a nivel de sesión o multimedia. Aparece en este formato:

  c=<tipo-de-red><><tipo-de-dirección-de-dirección-de-conexión>

  Junos OS solo admite "IN" (para Internet) como tipo de red, "IPv4" como tipo de dirección y una dirección IP de unidifusión o un nombre de dominio como dirección IP de destino (conexión). A partir de Junos OS versión 15.1X49-D40 y Junos OS versión 17.3R1, también se admite el tipo de dirección "IPv6".

  Si la dirección IP de destino es una dirección IP de unidifusión, SIP ALG crea agujeros de alfiler utilizando la dirección IP y los números de puerto especificados en el campo de descripción de medios m=.

• m= para anuncios a los medios

  Este campo aparece en el nivel de medios y contiene la descripción de los medios. Aparece en este formato:

  m=<lista media><port><transport><fmt>

  Actualmente, Junos OS admite "RTP" como protocolo de transporte de la capa de aplicación. El número de puerto indica el puerto de destino del flujo de medios (el origen lo asigna la UA remota). La lista de formatos (lista fmt) proporciona información sobre el protocolo de capa de aplicación que utiliza el medio.

  El software abre puertos solo para RTP y el Protocolo de control en tiempo real (RTCP). Cada sesión RTP tiene una sesión RTCP correspondiente. Por lo tanto, cada vez que un flujo de medios utiliza RTP, el ALG SIP debe reservar puertos (crear agujeros de alfiler) para el tráfico RTP y RTCP. De forma predeterminada, el número de puerto RTCP es uno más alto que el número de puerto RTP.

Creación estenopeica

Cada orificio (uno para el tráfico RTP y el otro para el tráfico RTCP) comparten la misma dirección IP de destino. La dirección IP proviene del campo c= en la descripción de la sesión SDP. Dado que el campo c= puede aparecer en la parte de nivel de sesión o de nivel de medios de la descripción de la sesión SDP, el analizador determina la dirección IP en función de las siguientes reglas (de acuerdo con las convenciones de SDP):

• Primero, el analizador SIP ALG busca un campo c= que contenga una dirección IP en el nivel de medios. Si existe un campo de este tipo, el analizador extrae esa dirección IP y el ALG SIP utiliza esa dirección para crear un orificio para el medio.

• Si no hay ningún campo c= en el nivel de medios, el analizador SIP ALG extrae la dirección IP del campo c= en el nivel de sesión y SIP ALG utiliza esa dirección IP para crear un orificio para los medios. Si la descripción de la sesión no contiene un campo c= en ninguno de los niveles, esto indica un error en la pila de protocolos, el dispositivo descarta el paquete y registra el evento.

El SIP ALG también abre orificios para el tráfico de señales. Estos agujeros de señal son útiles después del tiempo de espera de la sesión de señal anterior y también son útiles para el tráfico de señal enviado a una dirección de terceros que no coincide con la sesión de señal anterior. Los agujeros de señal SIP ALG nunca envejecen, a diferencia de los agujeros RTP o RTCP, donde solo se especifican la IP de destino y el puerto de destino.

El SIP ALG abre agujeros de señal para los siguientes encabezados, si es necesario:

• VIA

• CONTACTO

• RUTA

• RUTA RÉCORD

El ALG SIP necesita la siguiente información para crear un agujero de alfiler. Esta información proviene de la descripción de la sesión SDP o de los encabezados SIP (como se indicó anteriormente).

• Protocolo: UDP o TCP.

• IP de origen: desconocida.

• Puerto de origen: desconocido.

• IP de destino: el analizador extrae la dirección IP de destino del campo c= en el nivel de medios o sesión.

• Puerto de destino: el analizador extrae el número de puerto de destino para RTP del campo m= en el nivel de medio y calcula el número de puerto de destino para RTCP mediante la siguiente fórmula:

  Número de puerto RTP + uno

• Duración de la vida: este valor indica el tiempo (en segundos) durante el cual un orificio está abierto para permitir el paso de un paquete. Un paquete debe pasar por el orificio antes de que expire su vida útil. Cuando caduca la vida útil, el SIP ALG elimina el orificio de alfiler.

  Cuando un paquete pasa por el orificio dentro del período de vida útil, inmediatamente después, el SIP ALG elimina el orificio de la dirección de la que proviene el paquete.

  La Figura 1 describe una configuración de llamada entre dos clientes SIP y cómo el ALG SIP crea agujeros para permitir el tráfico RTP y RTCP. En la ilustración se supone que el dispositivo tiene una política que permite SIP, por lo que se abre el puerto 5060 para mensajes de señalización SIP.

  Figura 1: Configuración de llamada SIP ALG

• Descripción de la compatibilidad de IPv6 para SIP ALG
• Descripción del escalado de la compatibilidad con el campo de luz ocupada para el ALG SIP basado en UDP
• Descripción de los métodos de solicitud SIP ALG
• Descripción general de la configuración de SIP ALG
• Descripción de la protección contra ataques DS SIP ALG
• Descripción de los tipos de mensajes desconocidos de SIP ALG
• Descripción de la duración y los tiempos de espera de las llamadas SIP ALG

Retención de recursos de retención SIP ALG (procedimiento de la CLI)

Para adaptarse a los flujos de llamadas SIP patentados:

Llamadas salientes

Cuando se inicia una llamada SIP con un mensaje de solicitud SIP de la red interna a la externa, TDR reemplaza las direcciones IP y los números de puerto en el SDP y vincula las direcciones IP y los números de puerto al firewall de Juniper Networks. Los campos de encabezado SIP Vía, Contacto, Ruta y Ruta de registro, si están presentes, también están vinculados a la dirección IP del firewall. El ALG almacena estas asignaciones para usarlas en retransmisiones y para mensajes de respuesta SIP.

Luego, el ALG SIP abre agujeros en el firewall para permitir que los medios pasen por el dispositivo en los puertos asignados dinámicamente negociados en función de la información del SDP y los campos de encabezado Vía, Contacto y Ruta de registro. Los agujeros también permiten que los paquetes entrantes lleguen a las direcciones y puertos IP de contacto, vía y ruta de registro. Al procesar el tráfico de retorno, el ALG inserta los campos SIP originales Contact, Via, Route y Record-Route nuevamente en los paquetes.

Llamadas entrantes

Las llamadas entrantes se inician desde la red pública a direcciones TDR públicas estáticas o a direcciones IP de interfaz en el dispositivo. Las NAT estáticas son direcciones IP configuradas estáticamente que apuntan a hosts internos; Las direcciones IP de interfaz son registradas dinámicamente por el ALG mientras monitorea los mensajes de REGISTRO enviados por hosts internos al registrador SIP. Cuando el dispositivo recibe un paquete SIP entrante, configura una sesión y reenvía la carga útil del paquete al ALG SIP.

El ALG examina el mensaje de solicitud SIP (inicialmente una INVITACIÓN) y, según la información del SDP, abre puertas para los medios salientes. Cuando llega un mensaje de respuesta 200 OK, el ALG SIP realiza TDR en las direcciones IP y los puertos y abre agujeros en la dirección de salida. (Las puertas abiertas tienen un corto tiempo de vida y se agotan si no se recibe rápidamente un mensaje de respuesta de 200 OK).

Cuando llega una respuesta 200 OK, el proxy SIP examina la información del SDP y lee las direcciones IP y los números de puerto de cada sesión multimedia. El ALG SIP del dispositivo realiza TDR en las direcciones y los números de puerto, abre agujeros para el tráfico saliente y actualiza el tiempo de espera para las puertas en la dirección entrante.

Cuando el ACK llega para el 200 OK, también pasa por el SIP ALG. Si el mensaje contiene información de SDP, el ALG SIP garantiza que las direcciones IP y los números de puerto no se cambien con respecto a la invitación anterior; si lo hacen, el ALG elimina los agujeros antiguos y crea nuevos agujeros para permitir el paso de los medios. El ALG también supervisa los campos SIP Vía, Contacto y Ruta de registro y abre nuevos agujeros si determina que estos campos han cambiado.

Llamadas desviadas

Una llamada desviada es cuando, por ejemplo, el usuario A fuera de la red llama al usuario B dentro de la red y el usuario B desvía la llamada al usuario C fuera de la red. El ALG SIP procesa la INVITACIÓN del usuario A como una llamada entrante normal. Pero cuando el ALG examina la llamada desviada de B a C fuera de la red y observa que se llega a B y C mediante la misma interfaz, no abre agujeros en el firewall, ya que los medios fluirán directamente entre el usuario A y el usuario C.

Terminación de la llamada

El mensaje BYE finaliza una llamada. Cuando el dispositivo recibe un mensaje BYE, traduce los campos del encabezado como lo hace con cualquier otro mensaje. Pero debido a que un mensaje BYE debe ser reconocido por el receptor con un 200 OK, el ALG retrasa el desmontaje de llamadas durante 5 segundos para dar tiempo a la transmisión del 200 OK.

Mensajes de reinvitación de llamadas

Los mensajes de re-INVITAR agregan nuevas sesiones multimedia a una llamada y eliminan las sesiones multimedia existentes. Cuando se agregan nuevas sesiones de medios a una llamada, se abren nuevos agujeros en el firewall y se crean nuevos enlaces de dirección. El proceso es idéntico a la configuración de llamada original. Cuando se eliminan todas las sesiones de medios o los agujeros de medios de una llamada, la llamada se elimina cuando se recibe un mensaje BYE.

Temporizadores de sesión de llamada

Como medida de precaución, el ALG SIP utiliza valores de tiempo de espera estrictos para establecer la cantidad máxima de tiempo que puede existir una llamada. Esto garantiza que el dispositivo esté protegido en caso de que ocurra uno de los siguientes eventos:

• Los sistemas finales se bloquean durante una llamada y no se recibe un mensaje BYE.

• Los usuarios malintencionados nunca envían un BYE en un intento de atacar un ALG SIP.

• Las implementaciones deficientes del proxy SIP no procesan Record-Route y nunca envían un mensaje BYE.

• Los errores de red impiden que se reciba un mensaje BYE.

Cancelación de llamada

Cualquiera de las partes puede cancelar una llamada enviando un mensaje CANCELAR. Al recibir un mensaje CANCEL, el ALG SIP cierra los agujeros a través del firewall, si se ha abierto alguno, y libera los enlaces de dirección. Antes de liberar los recursos, el ALG retrasa la antigüedad del canal de control durante aproximadamente 5 segundos para dar tiempo a que pasen los últimos 200 OK. La llamada finaliza cuando expira el tiempo de espera de 5 segundos, independientemente de si llega una respuesta 487 o no 200.

Bifurcación

La bifurcación permite que un proxy SIP envíe un único mensaje de INVITACIÓN a varios destinos simultáneamente. Cuando llegan varios mensajes de respuesta 200 OK para la sola llamada, el ALG SIP analiza pero actualiza la información de la llamada con los primeros 200 mensajes OK que recibe.

Mensajes SIP

El formato de mensaje SIP consta de una sección de encabezado SIP y el cuerpo SIP. En los mensajes de solicitud, la primera línea de la sección de encabezado es la línea de solicitud, que incluye el tipo de método, el URI de solicitud y la versión del protocolo. En los mensajes de respuesta, la primera línea es la línea de estado, que contiene un código de estado. Los encabezados SIP contienen direcciones IP y números de puerto que se utilizan para la señalización. El cuerpo del SIP, separado de la sección de encabezado por una línea en blanco, está reservado para la información de descripción de la sesión, lo cual es opcional. Actualmente, Junos OS solo admite SDP. El cuerpo del SIP contiene las direcciones IP y los números de puerto que se utilizan para transportar los medios.

Encabezados SIP

En el siguiente mensaje de solicitud SIP de ejemplo, TDR reemplaza las direcciones IP en los campos de encabezado para ocultarlas de la red externa.

La forma en que se realiza la traducción de direcciones IP depende del tipo y la dirección del mensaje. Un mensaje puede ser cualquiera de los siguientes:

• Solicitud entrante

• Respuesta saliente

• Solicitud saliente

• Respuesta entrante

La Tabla 1 muestra cómo se realiza la TDR en cada uno de estos casos. Tenga en cuenta que para varios de los campos de encabezado, el ALG determina más que solo si los mensajes provienen de dentro o fuera de la red. También debe determinar qué cliente inició la llamada y si el mensaje es una solicitud o respuesta.

Cuerpo SIP

La información del SDP en el cuerpo del SIP incluye las direcciones IP que el ALG utiliza para crear canales para la transmisión de medios. La traducción de la sección SDP también asigna recursos, es decir, números de puerto para enviar y recibir los medios.

El siguiente extracto de una sección de SDP de ejemplo muestra los campos que se traducen para la asignación de recursos.

Los mensajes SIP pueden contener más de una secuencia de medios. El concepto es similar a adjuntar varios archivos a un mensaje de correo electrónico. Por ejemplo, un mensaje INVITE enviado desde un cliente SIP a un servidor SIP puede tener los siguientes campos:

Junos OS admite hasta 6 canales SDP negociados para cada dirección, para un total de 12 canales por llamada. Para obtener más información, consulte Descripción del ALG SIP.

Escenario SIP TDR

La Figura 2 y la Figura 3 muestran una llamada SIP INVITE y 200 OK. En la Figura 2, ph1 envía un mensaje SIP INVITE a ph2. Observe cómo el dispositivo traduce las direcciones IP en los campos de encabezado, que se muestran en negrita.

La sección SDP del mensaje INVITE indica dónde la persona que llama está dispuesta a recibir medios. Tenga en cuenta que el orificio de medio contiene dos números de puerto, 52002 y 52003, para RTCP y RTP. El orificio de vía / contacto proporciona el número de puerto 5060 para la señalización SIP.

Observe cómo, en el mensaje de respuesta 200 OK de la Figura 3, se invierten las traducciones realizadas en el mensaje INVITE. Las direcciones IP en este mensaje, al ser públicas, no se traducen, pero se abren puertas para permitir que la transmisión de medios acceda a la red privada.

Figura 2: Escenario 1 de SIP TDR

Figura 3: Escenario 2 de SIP TDR

Clases de respuestas SIP

Las respuestas SIP proporcionan información de estado sobre las transacciones SIP e incluyen un código de respuesta y una frase de motivo. Las respuestas SIP se agrupan en las siguientes clases:

• Informativo (100 a 199): solicitud recibida, continuando con el procesamiento de la solicitud.

• Éxito (200 a 299): acción recibida, comprendida y aceptada con éxito.

• Redirección (300 a 399): se requiere otra acción para completar la solicitud.

• Error de cliente (400 a 499): la solicitud contiene una sintaxis incorrecta o no se puede cumplir en este servidor.

• Error del servidor (500 a 599): el servidor no pudo cumplir con una solicitud aparentemente válida.

• Error global (600 a 699): la solicitud no se puede cumplir en ningún servidor.

La Tabla 2 proporciona una lista completa de las respuestas SIP actuales.

Modo TDR en modo IPv6 puro (NAT66) para SIP IPv6 ALG

El ALG SIP IPv6 admite NAT66 al igual que NAT44. NAT66 (IPv6 TDR) proporciona funciones de TDR de origen y TDR estáticas similares a NAT44 (IPv4 TDR).

TDR-PT

La traducción de protocolos de traducción de red (TDR-PT) (RFC 2766) es un mecanismo de traducción de protocolos que permite la comunicación entre nodos de solo IPv6 y solo IPv4 a través de la traducción independiente de protocolos de datagramas IPv4 e IPv6, sin requerir información de estado para la sesión.

El TDR-PT se implementa mediante el TDR normal de la dirección IPv6 a la dirección IPv4 y viceversa. El ALG SIP procesa esas traducciones de direcciones en la carga del mismo modo que las direcciones se procesan en el TDR normal.

TDR-PT vincula las direcciones de la red IPv6 con direcciones de la red IPv4 y viceversa para proporcionar un enrutamiento transparente para los datagramas que atraviesan entre los reinos de direcciones.

La principal ventaja de TDR-PT es que los dispositivos finales y las redes pueden ejecutar direcciones IPv4 o direcciones IPv6 y el tráfico se puede iniciar desde cualquier lado.

NAT64

NAT64 es un mecanismo para permitir que los hosts IPv6 se comuniquen con servidores IPv4. Se requiere NAT64 para mantener la asignación de direcciones IPv6 a IPv4. Dicha asignación de direcciones es configurada estáticamente por el administrador del sistema (traducción sin estado) o, con mayor frecuencia, se crea automáticamente cuando el primer paquete de la red IPv6 llega a NAT64 para ser traducido (con estado).

NAT64 se implementa en dispositivos mediante el uso de TDR persistente. Cuando el primer mensaje de solicitud SIP (el primer paquete debe ser solo de IPv6) atraviesa el DUT, se crea el enlace de dirección y, luego, los paquetes pueden fluir en ambas direcciones.

El mecanismo NAT64 traduce paquetes IPv6 a paquetes IPv4 y viceversa, lo que permite que los clientes IPv6 se comuniquen con los servidores IPv4 mediante UDP de unidifusión, TCP o ICMP. El comportamiento de TDR-PT y NAT64 parece similar, pero estos mecanismos se implementan de manera diferente.

Cuando se implementa NAT64 con TDR persistente, el ALG SIP con compatibilidad con IPv6 agrega la traducción de TDR a la tabla de enlace de TDR persistente si TDR está configurado en la dirección de registro. Dado que el TDR persistente no puede duplicar la dirección configurada, no se admite la coexistencia de NAT66 y NAT64 configurados en la misma dirección.

Solo se crea un enlace para la misma dirección IP de origen.

STUN y SIP ALG

Los Servicios públicos de recorrido de sesión para TDR (STUN) son una solución para hacer que VoIP funcione a través de TDR y firewall.

Anteriormente, STUN funcionaba sin el SIP ALG. Esto significa que el ALG SIP no estaba involucrado cuando se configuró la TDR persistente.

STUN puede coexistir con SIP ALG y SIP ALG está involucrado cuando se configura TDR persistente.

Figura 4: Uso del registrador SIP