Resumo

  • A RFC 3336 usou a multiplexação AAL2 para transportar cargas PPP pequenas com menos desperdício, como voz depois da compressão dos cabeçalhos RTP.
  • A fronteira de confiança continuava menor que a conexão ATM compartilhada: a autenticação da sessão PPP não protegia CIDs vizinhos não PPP nem a rede de comutação ATM.

A fronteira não acompanhava o circuito

O problema começava com a escala. PPP sobre AAL5 era adequado para transportar IP, mas a RFC 3336 observava que preenchimento e encapsulamento podiam desperdiçar banda quando a carga era pequena — sobretudo em voz cujos cabeçalhos RTP já tinham sido comprimidos. AAL2 oferecia outra composição: sua subcamada comum (CPS) podia multiplexar várias cargas PPP em células ATM, em vez de cobrar de cada pacote curto o custo de um quadro inteiro.

Isso não transformava a conexão virtual ATM em um único enlace PPP. A RFC 3336 descreveu o serviço PPP/AAL2 como uma conexão virtual full-duplex e ponto a ponto, provisionada de antemão ou estabelecida sob demanda. Dentro dela, o identificador de canal AAL2 (CID) marcava um subfluxo. Uma sessão PPP podia usar um CID ou vários; as duas pontas precisavam concordar sobre a quantidade, o mapeamento das subcamadas específicas de serviço e os valores usados. Em uma conexão dedicada, o provisionamento fornecia esses parâmetros; em uma conexão comutada, a sinalização podia fazê-lo.

A mesma conexão virtual também podia carregar tráfego AAL2 convencional e funções diferentes de convergência específicas do serviço. Portanto, um CID separava subfluxos, mas não era uma identidade criptográfica. A RFC 3336 traçou um limite explícito: a autenticação de uma sessão PPP e seus mecanismos associados não autorizavam supor que os CIDs não PPP na mesma conexão também estivessem protegidos. A autenticação PPP tampouco protegia a rede de comutação ATM. Se essa infraestrutura de transporte fosse comprometida, advertia o documento, um ataque de intermediário ainda poderia ocorrer.

Havia outros sinais, mas nenhum apagava essas fronteiras. O estado Up/Down do enlace podia ser inferido de pacotes de gerenciamento de falhas tipo 3 no fluxo do CID correspondente. O encapsulamento também incluía um CRC de 16 bits para detectar erros. Nem o estado do enlace nem o CRC demonstravam quem controlava um CID vizinho ou ocultavam seu conteúdo de um adversário. Para proteger mais que a sessão PPP, a RFC 3336 apontava para autenticação ou criptografia em camadas superiores e/ou serviços de segurança da camada ATM.

A RFC 3337, publicada na mesma época, ajuda a entender por que a separação de canais interessava a aplicações de tempo real: uma sessão PPP podia atravessar vários CIDs, intercalando fragmentos de classes distintas. Mas o documento complementar deixava o método de escalonamento CPS depender das exigências de cada aplicação. Um identificador de classe, sozinho, não garantia determinada latência. O formato permitia tratamento diferenciado; não provava que um escalonador ou uma rede específica o entregasse.

A conclusão precisa ficar dentro do que os documentos mostram. O RFC Editor lista a RFC 3336 como Proposed Standard, e seu texto especifica um mecanismo. Nenhum desses fatos prova quais fornecedores o implementaram, o alcance de sua implantação ou a ocorrência de um incidente relacionado. A Nota 65 de Lu Heng oferece uma disciplina editorial útil: uma norma propõe algo para sistemas em operação; ela não prova que esses sistemas o adotaram.

A lição é arquitetural. Compartilhar uma conexão de transporte pode reduzir o custo por pacote e ainda manter vários domínios de controle e confiança dentro dela. Quando uma revisão encontra “PPP autenticado”, deve perguntar o que foi autenticado: os pares PPP e o tráfego daquela sessão ou todos os CIDs, funções de serviço e comutadores atravessados pela conexão virtual? A RFC 3336 responde que a primeira coisa não implica a segunda.

Fontes

Página de status do RFC Editor

Fontes: RFC 3336 · RFC 3337 · PPP sobre AAL5, RFC 2364 · Multiplexação PPP, RFC 3153 · PPP, RFC 1661 · Compressão de cabeçalhos RTP, RFC 2508 · Enlaces de baixa velocidade, RFC 2689 · UIT-T I.363.2 · UIT-T I.366.1 · Lu Heng, Nota 65