Resumen

  • La RFC 3495 convirtió la opción DHCP 122 en un plano de selección previo a la autenticación: indicaba servidores permitidos, servidor de aprovisionamiento, reino Kerberos, reintentos y plazo global.
  • Un certificado válido podía impedir la activación frente a un destino hostil, pero no autenticar hacia atrás la respuesta DHCP ni demostrar que el TSP contactado era el elegido por el cliente.

PacketCable separaba dos funciones dentro de la conexión doméstica. El módem de cable pertenecía al acceso de datos; el Media Terminal Adapter atendía señalización y medios de voz. Aunque ambos pudieran convivir en un EMTA, conservaban direcciones MAC, configuraciones IP y autoridades administrativas distintas.

El proveedor de acceso a datos configuraba el módem. El proveedor de telefonía configuraba el MTA. La RFC 3495 observó que quien controlaba la primera configuración también podía decidir qué entidades comerciales participarían en la segunda. Comparó esa posición con la del operador local frente al transportista de larga distancia. El arranque técnico contenía una decisión de mercado.

IANA asignó el código 122 a CableLabs Client Configuration. Sus subopciones transportaban direcciones primarias y secundarias de servidores DHCP del TSP, dirección o nombre del servidor de aprovisionamiento, reino Kerberos, uso del servidor de concesión de tickets, parámetros de reintento AS y AP y temporizador de aprovisionamiento. El antiguo código local 177 quedó obsoleto.

El formato imponía límites concretos. Las direcciones IPv4 ocupaban cuatro octetos en orden de red. Los nombres completos seguían la RFC 1035, terminaban en cero y no admitían compresión. Si el conjunto superaba 255 octetos, la RFC 3396 definía la concatenación. Esas reglas demostraban que una instrucción era interpretable, no que su destino fuera correcto.

La dirección del intercambio ayuda a ubicar la autoridad. Los clientes usaban las opciones 55 y 60 para solicitar CCC e identificarse por clase; el servidor elegía los campos conforme a las especificaciones del proyecto. El cliente nunca poblaba la opción 122 en su solicitud. El reino visto en un paquete era lo que una autoridad de configuración había afirmado, no una elección autenticada del dispositivo.

La RFC enumeró el daño posible. Una dirección inválida provocaba denegación de servicio. Una dirección de un observador abría una oportunidad de intermediario. Un reino alterado desviaba el MTA hacia otro KDC. Un TSP malicioso podía usar esa capacidad para quitar un cliente al proveedor que éste había seleccionado.

La primera contención dependía del CMTS. Se suponía que reenviaría solicitudes sólo a servidores DHCP configurados explícitamente y aceptaría tráfico descendente únicamente desde rangos autorizados. Esa garantía era condicional: había que probar la configuración activa y el comportamiento del equipo. La opción no llevaba dentro el recibo de que el CMTS estaba bien administrado.

La autenticación posterior tampoco borraba la selección previa. Antes de habilitar servicio, el MTA debía presentar certificados válidos. Un KDC impostor podía quedar bloqueado, pero alcanzar ese control ya consumía red y cómputo; la propia validación podía convertirse en denegación de servicio. Un rechazo demostraba que falló el certificado, no que el reino DHCP hubiese sido legítimo.

El caso más difícil era el TSP malicioso pero certificado. Su identidad podía ser válida dentro de la PKI y aun así no corresponder al proveedor elegido. La RFC confiaba en que los TSP admitidos convivieran pacíficamente y remitía el desvío comercial a un arreglo administrativo. Identidad, admisión y consentimiento seguían siendo estados separados.

Los reintentos hacían persistente el error. Los intercambios AS y AP tenían valores propios de espera inicial, máximo y número de intentos. El temporizador exterior limitaba el aprovisionamiento y, al vencer, reiniciaba todo el proceso. Desactivarlo con cero tampoco probaba que el servicio hubiese terminado; sólo quitaba un límite.

Las RFC vecinas iluminan otros límites. La RFC 3361 descubre candidatos SIP; la RFC 3396 recompone fragmentos; la RFC 3397 instala una lista de búsqueda; la RFC 3442 entrega rutas. La RFC 3495 es la historia de una selección de confianza anterior a Kerberos: DHCP decidía dónde empezaría el juicio.

La prueba debe conservar cada escalón: bytes recibidos, subopciones analizadas, destino y reino elegidos, resolución, ruta, KDC contactado, certificado y diálogo Kerberos aceptados, ticket obtenido, aprovisionamiento completado, TSP autorizado por el cliente y servicio entregado. Saltar del primer escalón al último convierte automatización en ficción probatoria.

Fuentes