Consigna y contexto
Varios proveedores de servicios telefónicos no pueden garantizar que la señalización SIP transporte un PASSporT de extremo a extremo. Basándote en RFC 9888, diseña un Call Placement Service (CPS) fuera de banda y explica el descubrimiento, el envío y la recuperación, la autorización mTLS, la expiración, la interoperabilidad de gateways y los riesgos de privacidad.
RFC 9888 está dirigido a grandes proveedores de servicios que no pueden transportar PASSporTs de manera confiable a través de SIP. Un OOB Authentication Service (OOB-AS) envía un PASSporT a un CPS sobre HTTP, y un OOB Verification Service (OOB-VS) lo recupera mediante pull o lo recibe mediante push. La entrevista evalúa los límites de confianza y el ciclo de vida de los objetos, no un bucket REST genérico.
Qué evalúa el entrevistador
El entrevistador busca responsabilidades claras entre las credenciales de STIR, los PASSporTs, el CPS, OOB-AS y OOB-VS; un modelo confiable de anuncio de CPS y de autorización de rangos de números telefónicos; mTLS, cuotas y ventanas de frescura cortas contra falsificación, repetición (replay) e inundación (flooding); y una explicación concreta de la recuperación multiproveedor, la conversión de gateways, la privacidad de metadatos y la política ante fallos.
Preguntas para clarificar
Participantes y límites de red
Identifica quién firma el PASSporT, quién opera el CPS del proveedor de destino, si OOB-VS realiza pull o se suscribe a envíos push, y qué rutas cruzan un gateway PSTN o una red heredada (legacy).
Objetivos de autenticidad y privacidad
Aclara si el sistema debe demostrar la identidad de quien llama, reducir la suplantación de números (spoofing) o también ocultar los metadatos de la llamada. En el modelo de proveedores de RFC 9888, el CPS es operado por un participante de la llamada, por lo que sus supuestos de privacidad difieren de un servicio OOB abierto en Internet.
Latencia y retención
Define el retraso máximo permitido antes de mostrar un indicador de llamada, la tolerancia al desfase de reloj (clock skew) y si un PASSporT solo se necesita hasta la verificación. Un CPS no es un archivo a largo plazo.
Respuesta de 30 segundos
“Publicaría un anuncio de CPS firmado que vincule un SPC o rango de números telefónicos a un URI HTTPS. OOB-AS enviaría PASSporTs sobre mTLS utilizando una credencial STIR confiable; el CPS autorizaría el destino, aplicaría cuotas y retendría cada objeto solo durante su ventana de frescura. OOB-VS podría realizar pull tras la llegada de una llamada o suscribirse a envíos push por rango. Un CPS multiproveedor debe autorizar las lecturas utilizando el destino del PASSporT y la TNAuthList. Los gateways solo traducen dentro de un alcance delegado. Mediría la expiración, los duplicados, las solicitudes no autorizadas y la latencia, y documentaría el límite de recopilación de metadatos.”
Solución paso a paso
Paso 1: Mapear la confianza y el flujo de datos
OOB-AS crea o transporta el PASSporT y lo envía al CPS de destino. El CPS lo acepta conforme al anuncio y la política local. OOB-VS recibe únicamente los rangos de destino que está autorizado a verificar. La verificación sigue comprobando la firma de PASSporT, orig, dest y la frescura; llegar desde un CPS no reemplaza la verificación criptográfica.
Paso 2: Publicar un anuncio de CPS seguro
El anuncio mapea un SPC o rango de números telefónicos a un URI HTTPS de CPS. Debe estar firmado por una credencial STIR confiable, y el receptor compara la TNAuthList del firmante con el rango anunciado. Esto evita que cualquier titular de credenciales secuestre un rango. El descubrimiento puede utilizar configuración, una base de datos o DNS seguro, pero las cachés necesitan control de versiones y expiración.
Paso 3: Autorizar los envíos
OOB-AS establece TLS con el CPS, preferiblemente mTLS, y el CPS verifica que el certificado pertenezca a un proveedor emisor permitido. Aplica cuotas por proveedor, rango y tasa; rechaza credenciales desconocidas, destinos erróneos e inundaciones. Devuelve estados observables de aceptación, rechazo y duplicados sin exponer detalles de políticas internas que ayuden a atacantes a sondear el servicio.
Paso 4: Aplicar retención y frescura
Conserva un PASSporT únicamente durante el tiempo que requiera la recuperación y nunca más allá de su intervalo de frescura; RFC 9888 describe un máximo de 60 segundos para este flujo de proveedores. Deduplica utilizando orig, dest, un identificador de llamada y datos específicos de PASSporT para que el mismo objeto no pueda reproducirse indefinidamente. La expiración debe ser un invariante estricto, no una tarea de limpieza ocasional.
Paso 5: Soportar la recuperación por pull y push
En modo pull, OOB-VS consulta al CPS después de recibir una llamada sin un PASSporT incrustado. En modo push, se suscribe por rango o SPC y recibe objetos de forma proactiva. Un CPS multiproveedor verifica dest del PASSporT antes de entregarlo a un proveedor. Un fallo en el push no extiende la frescura de la firma; la verificación debe distinguir entre “aún no disponible” e “inválido”.
Paso 6: Restringir gateways y contingencias
Un gateway puede extraer un PASSporT de un SIP INVITE y enviarlo a un CPS que dé servicio a proveedores de PSTN heredados, o traducir un objeto OOB para un protocolo descendente. Su credencial debe tener un alcance delegado explícito y no puede otorgar autoridad a nivel de toda la red. Si se continúa con una llamada no verificada, se retrasa o se bloquea cuando el CPS no está disponible es una decisión de política regulatoria y de producto.
Paso 7: Cubrir privacidad, operaciones y simulacros
El CPS ve metadatos de las llamadas, por lo que se deben limitar los campos, la retención y el acceso a auditorías. Rastrea el éxito de envíos, solicitudes no autorizadas, duplicados, expiraciones, latencia de pull, acumulaciones de push y rechazos por cuota por proveedor. Prueba la revocación de certificados, rangos superpuestos, repetición, lecturas cruzadas entre proveedores, anuncios alterados, pérdidas en gateways PSTN y caídas parciales del CPS.
Respuesta modelo
Primero registraría los participantes y los rangos de autorización. Cada proveedor de destino publica un anuncio de CPS firmado por STIR que vincula su SPC o rango de números telefónicos a un URI HTTPS. OOB-AS envía PASSporTs sobre mTLS; el CPS valida la credencial, el destino, el rango y la cuota, y luego retiene el objeto solo durante su frescura. RFC 9888 describe una retención máxima de 60 segundos. OOB-VS puede realizar pull después de que llegue una llamada no firmada o suscribirse a pushes. Un CPS multiproveedor autoriza lecturas utilizando dest y TNAuthList. Un gateway PSTN solo puede extraer o traducir dentro del alcance delegado. El servicio distingue credenciales faltantes, expiradas e inválidas, aplica una política de contingencia explícita, audita el acceso a metadatos y mide inundaciones, repetición, latencia y rechazos por cuota.
Errores comunes
- Error: Tratar al CPS como almacenamiento de objetos público. → Por qué falla: Las escrituras y lecturas no autorizadas permiten falsificación, filtración e inundación. → Solución: Utilizar credenciales confiables, mTLS, autorización de rangos y cuotas por proveedor.
- Error: Retener PASSporTs para investigación a largo plazo. → Por qué falla: Una ventana más larga aumenta el riesgo de repetición y la exposición de metadatos. → Solución: Utilizar un TTL corto vinculado a la verificación y forzar la eliminación.
- Error: Autorizar lecturas únicamente mediante orig. → Por qué falla: El acceso multiproveedor también debe restringir dest y la TNAuthList del proveedor. → Solución: Autorizar el rango de destino tanto en el envío como en la recuperación.
- Error: Confiar en un PASSporT tras la extracción por un gateway. → Por qué falla: Mover el objeto entre protocolos no sustituye a la verificación. → Solución: Conservar la verificación y otorgar una delegación mínima al gateway.
Preguntas de seguimiento y respuestas
¿Qué ocurre si se filtra el certificado mTLS de un OOB-AS?
Se revoca, se detiene su autoridad de envío y se aísla el alcance de su proveedor. Los objetos ya enviados siguen requiriendo validación de frescura y de la firma de PASSporT; la identidad de la conexión por sí sola es insuficiente.
¿Por qué firmar el anuncio de CPS?
El anuncio determina a dónde debe enviarse un PASSporT. La firma vincula el URI del CPS a un SPC o rango de números telefónicos y previene la redirección hacia un recolector controlado por un atacante.
¿Recuperación mediante pull o push?
Pull es simple y se activa con llamadas reales. Push puede reducir el retraso en la verificación, pero necesita autorización de suscripción, gestión de acumulaciones y revocación. Las implementaciones a gran escala pueden combinarlos según el proveedor y el rango de números.
¿Debería bloquearse una llamada cuando el CPS no está disponible?
Se debe separar un indicador de prevención de suplantación de identidad (anti-spoofing) de un bloqueo regulatorio. Las llamadas ordinarias pueden continuar con una etiqueta de no verificada; los flujos de alto riesgo pueden retrasarse o bloquearse, pero la política, el tiempo de espera y las métricas de falsos positivos deben ser explícitos.