Background (skip ahead for question)
IPv4 needed NAT for address conservation. The firewalling properties of NAT were also beneficial for security. 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".
For a peer-to-peer UDP application, this requires an introducer server to do the NAT hole punching. For Client to connect to Server (both behind a firewalled NAT, FW), we need the following steps to happen:
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
IPv6 doesn't need NAT, but seems likely to be configured with similar firewall rules for home users (see references below).
My questions:
Q1: If the IPv6 firewall rules are just like the IPv4 NAT firewall rules (just without the address translation bit), then am I correct in thinking that a peer-to-peer application will still require exactly the same UDP hole punching process?
Q2: Are the default/out-of-the-box firewall rules for most home IPv6 routers just like the IPv4 NAT firewall rules as summarized at the top? If any are different, how so? Are there any that have default accept-all-incoming-packets behaviour?
References
These support the view that IPv6 home routers should/may have NAT-like firewall rules:
Switching to IPv6 implies dropping NAT. Is that a good thing?
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.
http://www.brynosaurus.com/pub/net/p2pnat/
IPv6 firewalls will still commonly block unsolicited incoming traffic by default, making hole punching useful even to IPv6 applications.
(following links disabled because I only have enough points to make 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. :/
However, these seem to suggest that there won't be any NAT-like firewall rules with IPv6, or that the hole punching process is unnecessary:
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
Before answering the questions, I'd like to address some of the assumptions in it.
The firewalling properties of NAT were also beneficial for security.
This is often-repeated, but simply not true; see below.
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".
These are not NAT rules, but stateful rules. Stateful rules are more secure than the old-style stateless rules that preceded them, because they are essentially adaptive; that is, the firewall's careful study of the outbound traffic permits it to make finer judgements about inbound traffic than mere port/address-based rules would allow.
It is certainly true that NAT firewalls are implicitly stateful, but it is important to recognise that statefulness is what you're after, not NAT, because NAT has a very bad reputation in certain corners of the ipv6 community, and there is as you have seen much resistance to implementing it in ipv6.
The UDP "introducer" process you describe is not restricted to NAT scenarios, but also applies whenever a service does not rely on a single well-known port number. RPC is the classic example, whereby services bind to a (semi-)random port, then register that port and their names with the portmapper, which does use a well-known port (111/TCP and 111/UDP). Clients wishing to connect contact the portmapper to find out which port their desired service is running on today, then initiate connections to that port. This is exactly what your diagram shows, and it happens millions of times every day on flat (non-NATted) networks all over the world which are running NFS.
As for your questions, question (1) should really read "If my ipv6 firewall is configured to refuse inbound UDP traffic without matching state, will my UDP client still need to initiate all arbitrary connections to external services". The answer, unfortunately, is "it depends". Stateful extensions such as the RELATED extension in iptables do allow firewalls to permit traffic that doesn't have simple matching state on the basis that a pre-existing connection has asked for this at the application layer - active-mode FTP being the classic example - but it requires a kernel module that understands the details of the protocol in question, and the deployment of end-to-end encryption makes such deep packet inspection increasingly hard. So, without such workarounds, the answer to question 1 is yes. This is equally true for TCP services without a well-known port number, by the way.
As for question (2), an exhaustive survey of SOHO equipment is probably outwith ServerFault's remit and capabilities, but I have not in many years seen a firewall appliance - v4 or v6 - that shipped with a default open configuration.
No comments:
Post a Comment