Resumo

  • O túnel L2F usa MID=0; conexões clientes usam MIDs não nulos e precisam de aceitação própria pela Home Gateway.
  • CLID, MID, challenge e Key identificam um contexto entre equipamentos, mas não comprovam identidade autorizada nem sessão de aplicação.
  • O próprio RFC não oferece entrega confiável para o tráfego de dados, portanto OPEN e contadores de controle não certificam cada quadro.

Três livros-caixa para uma única ligação

Na arquitetura de discagem virtual, a pessoa chama o Network Access Server de um provedor por PSTN ou ISDN. O acesso físico termina no NAS, mas a ligação PPP ou SLIP deve terminar em uma Home Gateway remota. L2F cria o transporte de camada de enlace entre esses pontos.

Isso significa que o provedor de acesso, o operador da Home Gateway e a aplicação final têm observações diferentes. O NAS pode confirmar a chamada e identificar apenas o bastante para escolher a gateway. A Home Gateway pode rejeitar o cliente. O protocolo transportado pode perder e repetir dados. Uma aplicação pode negar login ou falhar ao processar a solicitação mesmo após todas as camadas inferiores avançarem.

O primeiro estágio de L2F ocorre com MID=0. NAS e Home Gateway trocam L2F_CONF e L2F_OPEN, incluindo Name, Challenge e CLID atribuído. O resultado deixa o túnel disponível para estabelecer clientes. Essa disponibilidade é capacidade criada, não cliente aceito.

O segundo estágio usa um MID não nulo para cada conexão. O NAS envia outro L2F_OPEN, possivelmente com tipo de autenticação e informações de CHAP, PAP ou LCP. A resposta L2F_OPEN da Home Gateway registra a aceitação daquela conexão cliente. Só então começa o encaminhamento de quadros PPP ou SLIP. Um túnel aberto pode não ter clientes; e vários clientes no mesmo túnel podem ter resultados diferentes.

Chaves de multiplexação não são credenciais

O CLID demultiplexa túneis quando o transporte inferior não oferece distinção suficiente. O MID seleciona uma conexão cliente dentro do túnel. Zero pertence ao controle do túnel; valores não nulos pertencem aos clientes. Depois do fechamento, um MID reaproveitado deve nascer como estado novo.

Esses identificadores informam qual entrada da máquina de estados processar. Eles não identificam juridicamente uma pessoa, não carregam sua autorização corrente e não dizem qual sujeito uma aplicação reconheceu. Transformar MID em identidade seria atribuir poder de credencial a um mecanismo de encaminhamento.

RFC 2341 chama de “apparent identity” o que o ISP busca inicialmente. Essa informação serve para localizar a Home Gateway, que então aceita ou rejeita a conexão. Após a aceitação, ainda pode haver uma terceira autenticação PPP ou SLIP fora do escopo de L2F. CHAP, no RFC 1994, mantém seu próprio limite de challenge-response. Coletar um nome, encaminhar dados de autenticação, validar um segredo, autorizar rede e concluir login são registros distintos.

Controle confirmado, dados sem garantia própria

Mensagens de controle L2F precisam ser retransmitidas. O tráfego de dados não recebe de L2F controle de fluxo nem entrega confiável; o protocolo carregado deve cuidar de suas retomadas. Em geral, quadros de dados comuns nem usam o campo Seq.

Logo, OPEN, ECHO, Key válida ou um contador de túnel crescente não são recibos de cada payload. Eles podem comprovar que houve resposta do par, que um contexto estava ativo ou que um equipamento observou tráfego. Não comprovam o destino de todas as unidades entre as duas pontas.

Para PPP, L2F transporta o quadro após remover framing físico, transparência e FCS. PPP Echo, negociação NCP e TERMREQ seguem como quadros HDLC-like. L2F não interpreta sozinho o TERMREQ; o endpoint PPP deve provocar a transição de fechamento. A camada que transporta o quadro não conhece automaticamente o resultado que o conteúdo causou.

PPP ainda passa por LCP, autenticação opcional e configuração de protocolos de rede por NCP. Só depois uma aplicação estabelece sessão e atende uma solicitação. A cadeia completa contém muitos comprovantes; nenhum deles herda o significado dos seguintes.

A proteção da Key é específica

Na criação do túnel, as pontas usam segredo compartilhado e challenge-response. Pacotes posteriores podem carregar uma Key de 32 bits derivada da resposta de autenticação, enquanto CLID desconhecido, Key errada e pacote inválido devem ser descartados. É uma defesa contra certos tipos de spoofing no relacionamento configurado entre NAS e Home Gateway.

Não é confidencialidade do payload, autorização da pessoa, autenticação da aplicação nem prova de resultado. RFC 3193, ao tratar depois da proteção de L2TP com IPsec, separou autenticação de túnel, integridade por pacote, antirreplay, confidencialidade e segurança ponta a ponta. Essas capacidades não podem ser atribuídas retroativamente a L2F. A taxonomia, porém, ajuda a impedir que uma confirmação de par seja vendida como segurança integral.

Um registro Historic não comprova implantação

RFC 2341 está classificado como Historic. Seu Status of Memo afirma que não especifica um padrão da Internet. O Datatracker o descreve no fluxo Legacy, sem endosso da IETF nem posição formal no processo de padronização. A publicação preserva uma especificação; não mede adoção, interoperabilidade, uso atual ou conformidade de qualquer produto.

O valor permanente está na contabilidade de fronteiras. Registre separadamente chamada física, LCP, seleção de gateway, túnel por CLID, cliente por MID, autenticação posterior, quadros em cada ponta, NCP, sessão da aplicação e resultado percebido. Não some os contadores do NAS e da Home Gateway antes de guardar os originais. Um recibo só pode responder pela etapa que realmente observou.

Fontes