Resumo

  • O RFC 3193 exigiu ESP no controle e nos dados de L2TP, mas a SA só protegia o túnel correto quando endereços e portas descobertos pela aplicação eram injetados nos filtros do IPsec.
  • A verificação por pacote confirmava a identidade autenticada por IKE; se PPP autenticava uma pessoa e IKE apenas a máquina, era preciso separar o tráfego local para provar que somente aquela pessoa usou o túnel.

L2TP podia mudar a porta no meio da criação do túnel. O IPsec, por sua vez, precisava saber antecipadamente quais pacotes proteger. O RFC 3193 nasceu nesse intervalo entre uma decisão ainda em formação e uma política que precisava existir antes do primeiro pacote.

O primeiro SCCRQ abria a conexão de controle. O filtro inicial tinha de estar pronto antes de sua saída. Se não houvesse uma SA de Phase 2 adequada, o envio deveria acionar IKE; se a associação não pudesse ser criada, o pacote seria descartado. Proteger somente o tráfego posterior deixaria a própria abertura fora do perímetro.

L2TP já possuía autenticação de túnel e carregava PPP, com suas opções de autenticação, criptografia e compressão. Esses mecanismos, porém, não davam integridade e proteção contra replay a cada pacote de controle e de dados. A criptografia PPP não protegia o canal de controle L2TP nem oferecia a gestão de chaves exigida.

Por isso, implementações conformes tinham de oferecer ESP para controle e dados, suportar modo transporte e replay protection. Modo túnel era opcional. As suítes então obrigatórias, inclusive criptografia nula, precisavam existir na implementação; a escolha operacional permanecia com o operador. Capacidade disponível não era evidência de que confidencialidade fora ativada.

Na Phase 2, Quick Mode descrevia o tráfego por endereços, protocolo e portas. L2TP podia usar uma porta de origem dinâmica, e o respondente podia escolher outra ao mandar SCCRP. O texto-base permitia até uma mudança de endereço IP. Um filtro preso ao encontro inicial poderia rejeitar o túnel legítimo ou ficar amplo demais.

A solução foi fazer L2TP entregar seus fatos ao IPsec. Quando a porta do iniciador se tornava conhecida, L2TP a injetava na base de filtros. Depois de Quick Mode, IKE associava um filtro específico à SA. Regras provisórias aceitavam a transição; após a conclusão, SAs e filtros residuais podiam ser retirados.

Uma mudança de endereço não era continuidade silenciosa. O respondente enviava StopCCN pela rota protegida original, marcava “Try Another” e informava o novo endereço. O iniciador validava o formato, instalava nova política, refazia Phase 1 e Phase 2 e só então mandava outro SCCRQ. A intenção de continuar não substituía a criação de novo estado criptográfico.

Na mudança de porta, a decisão ocorria antes de SCCRP. L2TP injetava filtros e o respondente iniciava uma nova Phase 2. A regra final representava o socket efetivamente escolhido. A porta 1701 podia ser apenas ponto de encontro; vê-la num pacote não autenticava o túnel.

Na recepção, duas verificações continuavam obrigatórias. Primeiro, L2TP confirmava que IPsec autenticara ou decifrara o pacote, evitando entrada em claro. Depois, comparava endereços e portas UDP com o socket usado para criar aquele túnel. Um peer confiável ainda podia enviar tráfego protegido ao contexto L2TP errado. Pertencer à SA e pertencer ao túnel eram afirmações distintas.

O encerramento também atravessava vários estados. PPP tinha sua sequência LCP; L2TP mantinha conexão de controle e hellos; IKE mantinha Phase 1 e SAs de Phase 2; filtros persistiam na política. Ao apagar o túnel, as SAs criadas por ele deveriam ser apagadas. Ao receber um delete, IKE deveria avisar L2TP. Só após a confirmação apropriada era seguro remover estado e filtros.

Um único campo “desconectado” não mostra se esse fechamento terminou. Pode haver túnel removido e SA sobrevivente, SA removida e túnel ainda aparente, ou filtro de descoberta esquecido. O documento coordenava os objetos sem fingir que formavam uma transação indivisível.

A sobrecarga física precisava voltar ao PPP. Cabeçalhos L2TP e IPsec reduziam o espaço de uma MRU de 1.500 bytes. O RFC sugeria calcular o MTU da interface menos os cabeçalhos antes de LCP. Se o IPsec descobrisse depois um PMTU menor, armazenaria o valor na SA e avisaria L2TP. A observação de uma camada só mudava outra por uma interface explícita.

Compressão com estado trazia risco semelhante. L2TP era orientado a conexão, mas não exigia ordenação quando rodava sobre IP. Uma perda podia quebrar o histórico necessário para muitos pacotes seguintes. Métodos sem estado eram preferíveis. O desenho lógico do túnel não convertia a Internet num fluxo confiável.

Então surgia a pergunta principal: qual identidade a proteção por pacote sustentava?

PPP podia autenticar um usuário no início. IKE podia autenticar uma máquina e derivar chaves usadas em cada pacote. O IPsec repetia a prova de posse ligada à identidade IKE, não a autenticação PPP. A força criptográfica não transferia um nome de uma camada para outra.

Num computador multiusuário, outro usuário podia aproveitar um túnel já aberto se o sistema não segregasse o tráfego. O pacote continuaria íntegro e válido sob a chave da máquina. Ainda assim, não provaria que partiu da pessoa autenticada por PPP.

Autenticação de usuário em IKE ajudava, mas criava outra obrigação: o cliente tinha de garantir que somente o tráfego daquele usuário entrasse no túnel. Certificado, sucesso de IKE e aplicação da política local eram recibos separados.

Certificados deslocavam autoridade para o processo de emissão. O LNS podia confiar em várias CAs e tratar revogação de modo diferente. Um certificado de máquina valia tanto quanto o rigor do enrollment. Smartcards reduziam riscos de cópia de chave, mas podiam contrariar uma política que prendia acesso a hardware aprovado. O meio de armazenamento não definia sozinho a autoridade concedida.

Chaves pré-compartilhadas de grupo comprimiam identidades. Em acesso remoto com endereço dinâmico, Main Mode podia precisar da chave antes da identidade. Uma chave comum resolvia a seleção, mas qualquer membro do grupo podia provar apenas conhecimento coletivo. Um portador poderia se passar pelo LNS no cenário descrito e atacar credenciais PPP antigas. O RFC recomendou não usar chave de grupo para autenticar o LNS.

Aggressive Mode entregava a identidade cedo o bastante para escolher a chave, mas a expunha. Certificados escalavam melhor, mas exigiam emissão, confiança e revogação. A palavra “autenticado” escondia essa escolha se não viesse acompanhada do mecanismo.

O túnel compulsório distribuía conhecimento de forma desigual. O cliente mandava PPP ao LAC e talvez nem soubesse da proteção LAC–LNS. O LNS podia consultar a SA; o cliente não podia concluir que seu trecho até o LAC estava protegido. No túnel voluntário, o cliente originava L2TP e conhecia melhor a SA até o LNS, mas o caminho posterior continuava fora do escopo.

O RFC foi explícito: segurança do túnel não era segurança fim a fim. Sua contribuição não foi colar um cadeado a L2TP, mas obrigar cada camada a compartilhar o fato que possuía e preservar o limite daquilo que não podia afirmar.