Resumo

  • A RFC 3495 transformou a opção DHCP 122 em uma superfície de roteamento anterior à autenticação: ela indicava servidores permitidos, servidor de provisionamento, reino Kerberos, tentativas e prazo total.
  • A exigência posterior de certificado válido podia impedir a ativação diante de um destino hostil, mas não autenticava retroativamente o seletor DHCP nem comprovava que o provedor alcançado era o escolhido pelo cliente.

No PacketCable 1.0, o cable modem fornecia o acesso de dados e o Media Terminal Adapter cuidava de mídia e sinalização de voz. Eles podiam formar um único EMTA ou existir separadamente. Mesmo no mesmo gabinete, continuavam sendo dispositivos IP distintos, com endereços MAC, configurações e responsáveis próprios.

O Data Access Provider configurava o modem; o Telephony Service Provider configurava o MTA. A RFC 3495 registrou que a entidade que controlava a primeira configuração também determinava quais empresas poderiam exercer a segunda. A comparação com operadora local e longa distância mostrava que a inicialização carregava uma delegação comercial.

A opção CableLabs Client Configuration reunia subopções marcadas por tipo e tamanho. Elas continham endereços de servidores DHCP primário e secundário do TSP, endereço ou FQDN de provisionamento, reino Kerberos, uso do servidor de concessão de tickets, parâmetros AS e AP e um temporizador geral. A IANA reservou 122; o código local 177 foi descontinuado.

O formato resolvia ambiguidades de transporte. IPv4 ocupava quatro octetos em ordem de rede. O FQDN seguia a RFC 1035, terminava em zero e não usava compressão. Opções maiores dependiam da concatenação da RFC 3396. Ainda assim, sintaxe correta só provava que uma instrução podia ser lida. Não provava que o destino existia, que o DNS era honesto ou que o KDC reconheceria o terminal.

O sentido do preenchimento identifica quem afirmou o quê. O cliente solicitava CCC pela lista de parâmetros e declarava sua classe; o servidor escolhia as subopções conforme o projeto CableLabs. O cliente nunca colocava CCC em sua própria solicitação. Um reino capturado era, portanto, a declaração do servidor de configuração, não uma seleção independente do assinante.

A RFC descreveu o potencial de desvio. Endereços inválidos podiam negar serviço; um endereço de espionagem podia criar oportunidade de intermediário; um reino falso encaminhava o MTA ao KDC errado. Um TSP malicioso podia alterar essa indicação para tomar o cliente do TSP que ele havia escolhido.

Uma barreira estava no CMTS. Quando corretamente configurado, ele encaminharia pedidos somente a servidores DHCP aprovados e aceitaria tráfego descendente apenas das faixas autorizadas. Mas “corretamente configurado” era uma condição operacional, não um bit da opção. Exigia recibos próprios de configuração, filtro e tráfego.

Outra barreira vinha depois. Mesmo levado a um KDC por endereços falsos, o MTA precisava apresentar certificados válidos antes de receber serviço. Isso podia deter uma ponta sem credencial. A validação, porém, consumia processamento e também podia sustentar uma negação de serviço. Rejeitar o certificado dizia algo sobre o portão posterior, não sobre a autenticidade da escolha DHCP.

Aceitar o certificado também não comprovava a vontade do cliente. A RFC admitia a possibilidade de um TSP certificado e malicioso, presumia convivência pacífica entre entidades admitidas à rede e tratava o desvio de clientes como questão administrativa. Identidade criptográfica, permissão de entrada e autorização comercial eram fatos diferentes.

Os temporizadores multiplicavam o custo. As trocas AS e AP tinham espera inicial, máximo e número de novas tentativas separados. Um prazo externo reiniciava todo o provisionamento ao expirar. Uma instrução errada podia, assim, repetir consultas, rotas e validações. O valor zero apenas desligava o prazo; não atestava sucesso.

As RFCs vizinhas tratavam de outras fronteiras: a 3361 descobria candidatos SIP, a 3396 recompunha fragmentos, a 3397 instalava sufixos de busca e a 3442 entregava rotas. A singularidade da RFC 3495 era colocar o destino e a cadência da autenticação em um canal que chegava antes dela.

Uma auditoria precisa preservar a sequência: bytes recebidos, subopções analisadas, reino e ponta escolhidos, resolução e rota, KDC contatado, certificado e Kerberos aceitos, ticket obtido, provisionamento concluído, TSP autorizado preservado e serviço entregue. Nenhum recibo anterior substitui o seguinte.

Fontes