Analisando cabeçalhos de extensão IPv6 contendo extensões desconhecidas


113

Estou escrevendo um filtro de rede muito simples e chegando ao ponto em que desejo analisar os cabeçalhos IPv6 para corresponder a coisas como tipos ICMPv6, números de porta TCP / UDP etc.

Então, estou lendo sobre o formato de pacote IPv6 em profundidade, e eu meio que ... bem ... Eu meio que tive que ler várias vezes para ter certeza de que estava realmente lendo direito. Parece-me que você precisa começar com o cabeçalho fixo de 40 bytes e examinar o próximo campo de cabeçalho. Em seguida, você deve olhar para o próximo campo de cabeçalho do próximo cabeçalho e assim por diante, como uma lista vinculada, até chegar ao fim. Se houver carga útil, ela seguirá.

O problema é que não há campo de comprimento no cabeçalho fixo ou nos cabeçalhos de extensão. Você tem que ter uma tabela de tipos de cabeçalho de extensão e seus tamanhos para que você possa perseguir esta lista vinculada até o fim.

Isso me parece um desenho estranho, possivelmente até mesmo desmiolado. E se eu encontrar um tipo de cabeçalho de extensão não reconhecido? O que eu faço? Não sei seu comprimento. Acho que tenho que jogar o pacote fora e bloqueá-lo, já que em um filtro de rede, permitir a passagem do pacote permitiria a um invasor escapar do filtro de rede incluindo um tipo de cabeçalho falso. Mas isso significa que, se o protocolo for estendido, cada pedaço do software de análise de cabeçalho IPv6 já escrito deve ser atualizado simultaneamente se a nova extensão for usada.

Então, como posso analisar os cabeçalhos IPv6 se não sei as extensões que eles estão usando? Como posso pular um cabeçalho para uma extensão desconhecida, já que não sei seu comprimento?


10
Com base nesta pergunta, parece que não sou estúpido e sim, estou lendo certo: é (no mundo real) impossível adicionar um novo cabeçalho de extensão ao IPv6. stackoverflow.com/questions/9847923/…
AdamIerymenko

10
E sim, também parece que calcular o comprimento do cabeçalho requer uma travessia de lista vinculada: stackoverflow.com/questions/14762193/… Não me entenda mal. IPv6 é incrível e muito necessário. Mas isso ainda parece estúpido.
AdamIerymenko

3
A especificação (vinculada no comentário superior) diz que os roteadores não devem olhar os cabeçalhos, então não devem se importar com quais cabeçalhos você adiciona. Apenas o nó de destino deve olhar os cabeçalhos.
Anders E. Andersen

2
Apenas uma observação: "hair-brained" é uma grafia bastante confusa, e "hare-brained" deve ser preferível (fonte: tfd )
pzkpfw

2
Na medida em que há apenas uma grafia correta, que é 'cérebro de lebre'.
Alan B

Respostas:


33

Se você se deparar com algo que não pode analisar, terá que tomar sua decisão ou executar sua ação com base no que já analisou.

O design é assim porque no IPv6, cada cabeçalho de extensão "envolve" o resto do pacote. Se você vir o cabeçalho de roteamento, então algum cabeçalho que você nunca ouviu falar, então a carga útil, então você não pode analisar a carga útil. O significado da carga útil depende, em princípio, do cabeçalho que você não sabe como interpretar.

Os roteadores podem rotear esses pacotes, porque tudo de que precisam é o cabeçalho de roteamento. Dispositivos de inspeção profunda de pacotes e afins precisam saber muito, mas esse é o destino deles de qualquer maneira.

Editado para adicionar: Este design significa que middleboxes só podem mudar o que sabem. Se um middlebox vir um cabeçalho que não conhece, então terá apenas duas opções: Rejeitar ou passar adiante. No IPv4, ele também pode remover a extensão desconhecida e passar o resto adiante. IMO esta propriedade torna o design mais ao invés de menos extensível.


97

E se eu encontrar um tipo de cabeçalho de extensão não reconhecido?

Da RFC 2460 :

Se, como resultado do processamento de um cabeçalho, um nó é necessário para prosseguir para o próximo cabeçalho, mas o valor do próximo cabeçalho no cabeçalho atual não é reconhecido pelo nó, ele deve descartar o pacote e enviar uma mensagem de problema de parâmetro ICMP para a fonte do pacote , com um valor de Código ICMP de 1 ("tipo de próximo cabeçalho não reconhecido encontrado") e o campo Ponteiro ICMP contendo o deslocamento do valor não reconhecido no pacote original. A mesma ação deve ser realizada se um nó encontrar um valor de próximo cabeçalho de zero em qualquer cabeçalho diferente de um cabeçalho IPv6.


15
Boa. Achei que estava perdendo a cabeça. Então, sim, é realmente um design completamente não extensível ... pelo menos sem sinalização em banda e outros hacks. Isso é desculpável em um protocolo de aplicativo em que você controla as duas extremidades e só precisa contabilizar novas versões de seu aplicativo, mas não em algo projetado para durar ... centenas de anos?
AdamIerymenko

8
Ter a capacidade de ignorar cabeçalhos desconhecidos levaria a problemas muito mais complicados. (E se um proxy intermediário modificasse os cabeçalhos TCP sem o conhecimento de um cabeçalho ESP de encapsulamento?) A simplicidade é melhor do que "extensível" neste caso!
jman

4
@Max IPv6 tem, literalmente, endereços suficientes para atribuir um a cada átomo da Terra. Não há torradeiras conectadas à Internet que esgotem esse espaço.
Tyler McHenry

8
@Max Não vou dizer que nunca precisaremos de IPv7, mas com IPv6 temos espaço de endereço suficiente para dar a cada milímetro cúbico na atmosfera da Terra (130.000km acima) um endereço único ... 100.000 vezes. Então, quero dizer, uma vez que começarmos a colonizar outras galáxias, podemos ter algo com que nos preocupar, mas até então estaremos muito bem.
cincodenada de

4
Algum contexto está faltando:With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
Tobu

28

É (no mundo real) impossível adicionar um novo cabeçalho de extensão ao IPv6.

Incorreto, porque:

  1. Apenas o host de destino pode rejeitar com base em cabeçalhos de extensões não reconhecidos (com aquela única exceção mencionada na pergunta que você vinculou )

  2. Se o seu novo cabeçalho de extensão for de alguma forma opcional (é melhor que seja), você receberá um erro ICMP sobre isso e poderá tentar novamente sem ele.


1
E você tem certeza de que esse pacote ICMP passará pelo NAT até o remetente real?
Dexter

5
@Dexter ipv6 vai matar o NAT ... com sorte
Janus Troelsen

2
@Dexter: Esses pacotes ICMP precisam chegar por vários motivos. Por exemplo, se o MTU do pipe encolheu (talvez o encapsulamento do pacote tenha ocorrido por causa do PPPoE ou VPN) e o pacote enviado for muito grande, um pacote ICMP será retornado dizendo que o pacote é muito grande.
Bill Lynch

4
@JanusTroelsen nem todos compartilham de suas esperanças.
Dexter

4

A atualização RFC 6564 cobre esse caso. Ele apresenta exatamente o cenário que você descreve e apresenta um formato para quaisquer novos cabeçalhos de extensão (se algum for definido) com os quais caixas intermediárias como a sua serão capazes de trabalhar, pelo menos por algum tempo.

Lembre-se de que a intenção não é estender o IPv6 criando novos cabeçalhos de extensão, mas adicionando novas opções de destino. Deve ser trivial, ou pelo menos muito mais fácil, para você lidar com opções de destino desconhecidas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.