Resumo

  • O Token do receptor no primeiro SYN MP_JOIN apenas localiza o estado MPTCP a que o novo TCP quer se juntar; HMACs, nonces e política local tratam da admissão.
  • Um subfluxo estabelecido preserva um fato de transporte. Não prova que um endereço é propriedade de alguém nem que uma ação da aplicação foi autorizada ou concluída.

O nome Multipath TCP sugere uma estrada larga que simplesmente se abre em várias faixas. A especificação é mais cuidadosa. RFC 6182 separa a visão da aplicação—um fluxo de bytes confiável, ordenado, como o TCP—da visão da rede, que contém vários subfluxos TCP. Endereços múltiplos permitem procurar diversidade de caminho; não demonstram que os caminhos não compartilhem roteadores, que o desempenho aumentará ou que o uso de várias rotas seja livre de custos para outros usuários.

O primeiro subfluxo cria a relação de que os demais dependerão. Em RFC 8684, MP_CAPABLE participa do SYN, SYN/ACK e ACK iniciais. Ele negocia a capacidade MPTCP e intercambia o material de chave usado mais tarde para autenticar a incorporação de outro subfluxo. Se esse intercâmbio não se completa, a sessão volta a operar como TCP comum de caminho único. Uma opção que desaparece no trajeto não transforma uma conexão parcialmente negociada em MPTCP por vontade de uma ponta.

Também a história do documento exige modéstia. RFC 6824 descreveu a versão inicial como Experimental em 2013. RFC 8041 reuniu, em 2017, experiências de implementação e operação. RFC 8684 substituiu aquela v0 como Standards Track em 2020 e atribui principalmente às experiências de implantação suas mudanças e esclarecimentos. Isso registra aprendizado sobre o protocolo; não mede adoção atual, uma configuração de fornecedor ou benefício universal.

O SYN novo ainda precisa achar uma memória antiga

No começo de um MP_JOIN, o emissor envia o Token do receptor, um nonce novo e um Address ID. Com a escolha SHA-256 da versão 1, o Token vem dos 32 bits mais significativos do hash SHA-256 da chave inicial do receptor. O receptor usa esse valor para encontrar qual conexão MPTCP local o SYN está propondo ampliar.

O Token é, portanto, um índice de demultiplexação. Não é uma credencial de usuário nem uma licença que acompanha o endereço. Durante o SYN, o subfluxo ainda não possui um cinco-tupla já associado à conexão anterior. Depois que ele é admitido, seus pacotes passam a ser demultiplexados pelo cinco-tupla TCP comum. O seletor temporário do pedido e o identificador operacional do fluxo estabelecido não são a mesma coisa.

O Address ID resolve outro problema limitado: ele identifica a direção de origem para correlação e retirada mesmo quando um NAT altera o cabeçalho IP que o par observa. Não é evidência de titularidade do IP, controle de rota ou autorização fora do estado desta conexão.

A prova não substitui a decisão do anfitrião

O Token não basta para incorporar o fluxo. O receptor responde com nonce e HMAC truncado; o iniciador devolve seu HMAC. Os dois HMACs são calculados com as chaves trocadas em MP_CAPABLE e com os novos nonces. Assim, a confirmação vincula esta tentativa à relação anterior e não aceita simplesmente a repetição de uma troca gravada.

Quando os HMACs são corretos, RFC 8684 limita o resultado: os dois hosts verificaram que são os mesmos pares MPTCP presentes no início e concordaram sobre a conexão a que o subfluxo pertence. Isso não autentica a pessoa, não dá permissão para a operação que seguirá no byte stream e não prova que as duas rotas são independentes.

Há ainda uma decisão que permanece inteiramente local. Token desconhecido recebe RST. Token conhecido também recebe RST se a política do receptor proibir um novo subfluxo. HMAC ausente ou incorreto fecha a tentativa. O host que mantém o estado não perde seu direito de controlar limites e recursos apenas porque alguém encontrou a chave de busca correta.

Depois da admissão, um observador pode demonstrar negociação inicial, busca de Token, HMACs válidos e um cinco-tupla vivo. Não pode usar a mesma captura para afirmar que a aplicação aceitou uma solicitação, que um banco gravou um registro, que alguém estava autorizado ou que o efeito comercial ocorreu. Continuidade de bytes não é continuidade de significado.

Fontes e limites de evidência

As RFCs abaixo definem a arquitetura, o histórico documental e o comportamento especificado. Elas não demonstram prevalência atual, independência de rotas reais, comportamento de um NAT concreto, conformidade de produto, identidade humana ou conclusão de aplicação.