penetrating ipv6 firewalls for peer-to-peer connections

[mariuszp]

Some on this forum may be familiar with "UDP Hole Punching" to establish direct connections between 2 hosts behind separate NATs. In IPv6, there is no need for NAT, but certainly for a firewall. In some cases, such as peer-to-peer connections, reconfiguring the firewall may be too much effort for the average user.

But in IPv6, there is no address or port translation going on, so hole punching seems much easier: after a relay server lets 2 hosts exchange their IPv6 addresses, both hosts send a "CONNECT" message to each other over UDP. One of the hosts' firewalls will effectively send the CONNECT before receivng a CONNECT, so the received CONNECT will look like a response and pass through the firewall. You can then reply with an ACK to establish full duplex communication.

I dont have 2 IPv6 networks to test this with at the moment, so i ask you if you see any problems with this, and perhaps test it if you have the resources to do so.

Alao note that it seems like simply sending a UDP pakcet from a certain port to a different port on another machine is enough to "open" that port for the remote machine. Is this a security problem and can it be prevented?

Discuss

[Nable]

I don't get your problem. Firewall either allows (passes through) the packet or drops it. What hole-punching are you talking about? Without NAT there are only two options: either two hosts are able to communicate with each other from the very beginning or packets are dropped and they cannot communicate directly at all (except through the 3rd host that is accessible to both of them due to some strange admin decision).

[Combuster]

So basically you're stating that,
1: By default, sending UDP packets from inside to outside is allowed, but not from outside to inside.
2: UDP packets sent outside add an allow rule to the firewall using the exact source and dest ip:port (but swapped to match return traffic)
3: The firewall doesn't translate addresses or ports.
(4: If the rule generated in #2 hasn't been used for a certain period, remove the rule)

This essentially mean that any communication must be initiated from the inside network. And yes, for the lack of translation, you could punch holes and make connections with these rules. It requires cooperation between the peers and to know of each other what to connect to. If there's no cooperation, there will be no bidirectional communication.

Importantly, a host can't actively punch holes in the remote firewall, because it can't trigger rule #2 from the outside, and there's no other way to allow incoming traffic. Therefore this is not a security issue.
In order to receive packets from a host a local machine must have established permission for incoming traffic by sending a packet to the specified port and ip. There are a number of options here:
1: The client is purposefully connecting. This can be either intended behaviour for peering, or it can be a form of coercion, indicating an exploit elsewhere, and thus not at issue here.
2: The attacker can guess a functional source/dest host/ip, and forge a packet accordingly. This is easy when you're able to intercept communications. Otherwise you have to
a: Brute force the 16-bit source port
b: Get the device's MAC address, or at least a valid IP (if the host is properly configured it will not initiate connections from the mac-based IP, but not everybody does that)
c: Guess a service that's being used. If you do a bit of research DNS servers are for instance easy to guess.
d: Hope there's no address forgery filtering on the route.
(e: know that such a packet will actually have effect on the host, though this only matters post-firewall)
This is considered difficult, but not impossible. The receiving network software (point e) is where the security should eventually be completed.

If the firewall doesn't do full host+host+port+port matching, like you see used in many NAT-to-NAT punching with an intermediate, you get increasingly less difficulties figuring a-d, and this certainly is an unnecessary increase of slack in security.

[mariuszp]

@Combuster: I wasn't saying (in the first 2 paragraphs) that this is a problem; only wondered if this is actually a plausible method for holepunching. I now realise that this isn't a security problem either since you essentially need both sides' consent to punch holes. This could be a very reliable method for eastablishing peer-to-peer connections, so VoIP and similar services could become much faster and not have problems with various types of NAT!

@Nable: What you're describing is a STATELESS firewall, I was referring to a STATEFUL firewall.

I see a sort-of paradox though: software on a host can punch holes for potential attackers, if it gets there through some kind of exploit. But then again, even without a firewall, for malicious packets to do any damage, there must be software already running on the machine that needs to be exploitable anyway. So what benefit does the firewall really give?

NOTE: My ISP from whom I'm switching away soon (BSkyB) is deploying IPv6 on consumer networks by the end of this year, and my router implements exactly the stateful firewall I spoke of. (I don't actually have an assigned IPv6 prefix yet though).

[davidsmith0143]

you could use this link : http://www.brynosaurus.com/pub/net/p2pnat/