Resumen

  • RFC 3323 separó la identidad visible en From de la información funcional en Contact, Via y SDP que a menudo requería un intermediario para quedar oculta sin romper la sesión.
  • Solicitar privacidad no probaba su ejecución; critical exigía rechazar la petición cuando la red no podía cumplirla.

Una dirección falsa podía romper la conversación

El usuario podía poner Anonymous y el dominio SIP anónimo reservado en From porque ese campo no tenía que servir como ruta dentro del diálogo. Contact era diferente. Los mensajes posteriores necesitaban encontrar al participante. Via también guiaba respuestas. Alterar sus hostnames por simple ocultación podía destruir la función que mantenía viva la conversación.

La privacidad no consistía, por tanto, en borrar toda dirección. El agente retiraba encabezados opcionales, evitaba nombres y organizaciones, aleatorizaba la parte reveladora del Call-ID y usaba una identidad anónima donde era seguro hacerlo. Para los campos funcionales necesitaba una entidad que asumiera el enrutamiento después de ocultar el valor original.

Ese era el servicio de privacidad. Podía reescribir Contact y Via, evitar añadir información innecesaria y situarse en el camino de la sesión para ocultar una dirección de medios. Sabía o alcanzaba lo que ocultaba. El llamante podía ser anónimo para el destino y seguir plenamente identificable para el servicio o para el sistema de autenticación.

Privacidad siempre significaba “frente a alguien”

RFC 3323 describió al menos tres relaciones. La identidad podía ocultarse al destino y mostrarse a intermediarios; ocultarse a algunos intermediarios y revelarse de extremo a extremo; o esconderse de ambos. Una etiqueta global de anonimato borra al observador y no permite auditar ninguna de esas promesas.

El encabezado Privacy expresaba funciones header, session y user. Eran instrucciones, no recibos. Una limitación jurídica, una función ausente, una configuración incorrecta u otra condición podía impedir el servicio. La presencia del token no demostraba que la transformación se hubiera realizado.

Con critical, el usuario declaraba que no aceptaba la entrega sin esas funciones. La red debía rechazar la solicitud si no podía cumplirlas. El fallo cerrado era parte de la privacidad: reenviar exponía información de modo irreversible. none expresaba la decisión contraria y impedía que un perfil automático aplicara anonimización no deseada.

Confiar en el lugar que borra

La recomendación de usar TLS hasta el servicio protegía el trayecto previo. Sin él, otro intermediario podía leer la identidad antes de que se borrara o eliminar la petición. Una conexión directa permitía inspeccionar el certificado y reducir los puntos de exposición.

TLS no ocultaba la identidad al propio servicio. Tampoco la privacidad de sesión garantizaba confidencialidad del medio frente al relay. Un anonimizador insertado en la ruta podía ocultar la IP de un extremo al otro y, al mismo tiempo, ver tráfico no cifrado. Las dos propiedades debían declararse por separado.

Proxies y usuarios mantenían el derecho a rechazar peticiones de un originador que no podían identificar. La privacidad no confería autoridad para obligar a aceptar. RFC 3325 trató la identidad afirmada dentro de redes de confianza, mientras especificaciones posteriores de identidad e historial cambiaron otras superficies. Es posible autenticar a una persona ante un dominio y ocultarla ante el destino sin contradicción.

La contribución histórica de RFC 3323 fue convertir “anónimo” en una arquitectura de responsabilidades. El agente, los proxies, el servicio, el receptor y el sistema de autenticación veían cosas distintas. La afirmación solo era cierta si nombraba a cuál de ellos.

Sources