Resumo

  • A RFC 2516 separou a descoberta, sem estado de sessão, da sessão PPP ponto a ponto; host e concentrador só alocavam recursos de interface virtual depois de estabelecê-la.
  • Um AC-Cookie opcional permitia ao concentrador verificar se um valor enviado a determinado endereço podia voltar. Host-Uniq e Relay-Session-Id resolviam necessidades de correlação distintas, do host e do relé.
  • Esses tokens transportavam contexto limitado de pacotes. Nenhum autenticava uma pessoa nem comprovava configuração PPP, tráfego ou serviço comercial posterior.

Broadcast sem tabela de sessões

Em fevereiro de 1999, a RFC 2516 descreveu como transportar PPP por uma Ethernet compartilhada por vários hosts e concentradores de acesso. O host transmitia um PADI em broadcast; concentradores aptos podiam responder com PADO. O host escolhia uma oferta e enviava um PADR unicast ao concentrador selecionado. O PADS confirmava o serviço aceito e entregava um identificador de sessão. A especificação separou Descoberta e Sessão PPP: a primeira permanecia sem estado de sessão até a segunda existir. Nesse momento, tanto o host como o concentrador deveriam alocar recursos para uma interface PPP virtual.

Essa fronteira impedia que cada solicitação visível numa rede compartilhada virasse automaticamente um compromisso duradouro de recursos de sessão. “Sem estado” não quer dizer que o processamento do pacote custasse nada; define quando o estado persistente associado ao par PPP passa a existir.

O valor precisava fazer a volta

O concentrador podia incluir um AC-Cookie opcional no PADO. O host precisava devolvê-lo sem alteração no PADR e não interpretava seus bytes. A RFC recomendava que o concentrador pudesse regenerar o valor com base no endereço de origem do PADR. Assim, ele poderia verificar se o endereço que recebeu a oferta era alcançável no sentido de retorno e limitar as sessões simultâneas para aquele endereço.

A especificação cita como exemplo um HMAC sobre o MAC do host, com uma chave conhecida apenas pelo concentrador. Não exige esse algoritmo nem promete proteção universal; afirma que o cookie não impede todos os ataques de negação de serviço. A ideia é adiar o compromisso de recursos até o retorno do valor, não identificar quem está por trás do endereço.

As outras etiquetas têm donos diferentes. Host-Uniq, escolhido pelo host, associa uma resposta à solicitação que ele fez; o concentrador o devolve sem interpretar. Relay-Session-Id, que um relé intermediário pode inserir, é opaco para as duas pontas e também volta inalterado. Correlação não é identidade.

O PADS muda o estado dos recursos

O PADS aceito contém um SESSION_ID não nulo e o nome do serviço aceito; uma recusa usa zero e uma etiqueta de erro. A sessão é definida em conjunto pelos MACs de origem e destino e pelo SESSION_ID. O número de 16 bits, isolado, não identifica a sessão.

O PADS inicia a etapa de Sessão PPP, mas não executa a negociação LCP, a autenticação opcional ou a configuração dos protocolos de controle de rede descritas na RFC 1661. Este artigo não repete o limite de payload nem os 1492 bytes tratados pela RFC 4638. Seu assunto é quando se alocam recursos e qual é o alcance de cada etiqueta — não se o serviço foi entregue depois.

A RFC registra uma escolha de projeto e os limites declarados por ela; não mede memória economizada, uso atual nem autenticação ou tráfego em uma sessão específica.

Fontes: RFC 2516; RFC 1661; RFC 2104; RFC 4638 (assunto vizinho de tamanho de payload, excluído deste texto).