Perfuração UDP ainda necessária no IPv6, mesmo sem NAT?

Question

Plano de fundo (pule para a pergunta)

O IPv4 precisava de NAT para a conservação de endereços. As propriedades de firewall do NAT também foram benéficas para a segurança. As regras de firewall IPv4 NAT são "bloquear pacote de entrada remote-address:port -> local-address:port , a menos que seja enviado pacote de saída local-address:port -> remote-address:port nos últimos X segundos".

Para uma aplicação UDP peer-to-peer, isto requer um servidor introdutor para fazer a perfuração do NAT. Para Client se conectar a Server (ambos por trás de um NAT com firewall, FW ), precisamos que as etapas a seguir sejam concluídas:

                           periodic
                          keep-alive
                Introducer <------>
Client    FW                  FW    Server
------------------------------------------
       request
     introduction
       -------> Introducer
Client    FW                  FW    Server
       --------------------->X
         request connection
------------------------------------------
                            notify
                         introduction
                    [Client address:port]
                Introducer ------->
Client    FW                  FW    Server
------------------------------------------
Client    FW                  FW    Server
       <---------------------------
                  hello
------------------------------------------
Client    FW                  FW    Server
       --------------------------->
            request connection
------------------------------------------
Client    FW                  FW    Server
       <---------------------------
             accept connection
------------------------------------------
Client    FW                  FW    Server
       <-------------------------->
            periodic keep-alive

O IPv6 não precisa de NAT, mas parece provável que seja configurado com regras de firewall semelhantes para usuários domésticos (consulte as referências abaixo).

Minhas perguntas:

Q1 : Se as regras de firewall IPv6 forem semelhantes às regras de firewall IPv4 NAT (apenas sem o bit de conversão de endereço), estou correto em pensar que um aplicativo ponto a ponto ainda exigir exatamente o mesmo processo de perfuração UDP?

Q2 : As regras de firewall padrão / out-of-the-box para a maioria dos roteadores IPv6 domésticos são semelhantes às regras de firewall NAT IPv4 conforme resumidas na parte superior? Se algum for diferente, como assim? Há algum que tenha o comportamento padrão de aceitar todos os pacotes de entrada?

Referências

Eles suportam a visão de que os roteadores domésticos IPv6 devem / podem ter regras de firewall semelhantes a NAT:

A mudança para o IPv6 implica a eliminação do NAT. Isso é bom?

The one big security gain you get with NAT is that it forces you into a default-deny configuration. In order to get any service through it, you have to explicitly punch holes. ... A correctly configured firewall provides exactly the same service as a NAT gateway.

link

IPv6 firewalls will still commonly block unsolicited incoming traffic by default, making hole punching useful even to IPv6 applications.

(seguintes links desativados porque eu só tenho pontos suficientes para fazer 2)
http://tools.ietf.org/html/rfc5128

Even a future "pure IPv6 world" may still include firewalls, which employ similar filtering behavior of NATs but without the address translation. The filtering behavior interferes with the functioning of P2P applications. For this reason, IPv6 applications that use the techniques described in this document for NAT traversal may also work with some firewalls that have filtering behavior similar to NATs.

http://stackoverflow.com/questions/4647633/nat-traversal-and-ipv6

Firewalls won't be going away anytime soon, c.f. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16 "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service". ... You can expect that ubiquitous firewalls will continue to interfere with application protocols and require you to do all the same basic traversal methods that IPv4/NAT entails in order to maintain state records in the middleboxes on your application paths.

http://news.ycombinator.com/item?id=8229327

People keep saying that instead of the NAT hack you should have native IPv6 with firewalling for the same or better level or protection. But doesn't a stateful IPv6 firewall introduce the same problems as NAT? Won't I still have to use keepalive packets or protocols like PCP to actually use P2P?

I'm also anxiously awaiting the rise of IPv6, but I'm guessing that -- in a sane world -- consumer routers will still default to a stateful firewall for IPv6, thus necessitating the continued need for hole punching. :/

No entanto, estes parecem sugerir que não haverá regras de firewall tipo NAT com IPv6, ou que o processo de perfuração é desnecessário:

http://www.raknet.net/raknet/manual/ipv6support.html

NAT Punchthrough is not necessary when using IPV6 exclusively. Provided that you know the IP address of the system, you can connect to that system directly even if that system is behind a router.

http://www.zerotier.com/blog/?p=226

It’s an ugly workaround to a fundamental limitation, and the sooner it’s rendered obsolete by IPv6 the sooner we can start really deploying a whole new generation of Internet protocols. ... Because NAT is almost always stateful, frequent keepalive packets are required to hold all connections open. ... If you don’t send a packet about once every 120 seconds (for typical NATs), your connection will be forgotten and will reset. Users behind NATs who use SSH have likely discovered this when attempting to leave SSH sessions open for a long time, and SSH (like most protocols) has a protocol keepalive option available as a workaround.

    

Answer 1

Antes de responder às perguntas, gostaria de abordar algumas das suposições nele contidas.

The firewalling properties of NAT were also beneficial for security.

Isso é freqüentemente repetido, mas simplesmente não é verdade; veja abaixo.

IPv4 NAT firewall rules are "block incoming packet remote-address:port -> local-address:port, unless sent outgoing packet local-address:port -> remote-address:port within the last X seconds".

Estas não são regras NAT, mas regras stateful . As regras com estado são mais seguras do que as regras sem estado de estilo antigo que as precederam, porque são essencialmente adaptativas; ou seja, o estudo cuidadoso do firewall sobre o tráfego de saída permite que ele faça julgamentos mais precisos sobre o tráfego de entrada do que as regras baseadas em porta / endereço permitiriam.

É certamente verdade que os firewalls NAT são implicitamente stateful, mas é importante reconhecer que statefulness é o que você procura, não NAT, porque o NAT tem uma reputação muito ruim em certos cantos do NAT. a comunidade ipv6, e você viu muita resistência a implementá-lo no ipv6.

O processo "introdutor" do UDP que você descreve não está restrito a cenários NAT, mas também se aplica sempre que um serviço não depende de um único número de porta conhecido. O RPC é o exemplo clássico, pelo qual os serviços se ligam a uma porta (semi) aleatória, então registram essa porta e seus nomes com o portmapper, que faz usar uma porta bem conhecida (111 / TCP e 111 / UDP). Os clientes que desejam se conectar, contatam o portmapper para descobrir em qual porta o serviço desejado está sendo executado, e iniciam conexões com essa porta. Isso é exatamente o que seu diagrama mostra, e isso acontece milhões de vezes todos os dias em redes planas (não-NATted) em todo o mundo que estão executando o NFS.

Quanto às suas perguntas, a pergunta (1) deve realmente ser lida " Se meu firewall IPv6 estiver configurado para recusar o tráfego UDP de entrada sem corresponder ao estado, meu cliente UDP ainda precisará iniciar todas as conexões arbitrárias com serviços externos ". A resposta, infelizmente, é " depende ". Extensões stateful, como a extensão RELATED em iptables , permitem que firewalls permitam tráfego que não possui um estado de correspondência simples, com base em que uma conexão preexistente solicitou isso na camada do aplicativo - sendo o FTP em modo ativo o exemplo clássico - mas requer um módulo de kernel que entende os detalhes do protocolo em questão, e a implantação de criptografia de ponta a ponta torna essa inspeção profunda de pacotes cada vez mais difícil. Portanto, sem tais soluções alternativas, a resposta à pergunta 1 é yes . Isso também é verdade para serviços TCP sem um número de porta conhecido.

Quanto à pergunta (2), uma pesquisa exaustiva dos equipamentos SOHO provavelmente está fora do alcance e da capacidade do ServerFault, mas em muitos anos não vi um dispositivo de firewall - v4 ou v6 - fornecido com uma configuração aberta padrão .