PF submission stuck waiting for nearly 4 years

Zirias said:
I now better assume you're making this up ... right? :eek:
Click to expand...
But it's pure & plain, simple aristhotelian logic applied: We do what you requested, and it points us to a source that in contrast you call unreliable & misleading... Well, your last posts were more substantial & hopefully we can continue that way. This topic is too important & does not deserve a discussion spiked with personal taunts. If you feel there is one against you, please just ignore it & keep on with relevant infos & hints. Thx in advance, sincerely yours, Mjölnir
 
Well, yep, maybe I assumed too much, thinking everyone knew about the reputation of Gibson in this field ;) Still Google (and sorry, it's the only search engine I use cause I'm quite satisfied with the quality of the results) also delivers more than enough better resources...
 
For crying out loud, I look away for two seconds and there's two pages worth of bickering about who's right or wrong. Take that elsewhere please.
 
SirDice said:
For crying out loud, I look away for two seconds and there's two pages worth of bickering about who's right or wrong. Take that elsewhere please.
Click to expand...
Well, complaints like issued in this thread come from this idea of NAT as something "helping security", which it isn't and never has been and I think it's REALLY important to understand this misconception. The patch here aims to *improve* NAT, and given the declared goal of NAT, which is *enabling* connections, it does exactly that.

Snarky responses don't help. And sure, I had my share, sorry for that.
 
Zirias said:
Uh, a classic, if YOU don't understand something, it's magically everyone. Only serves for self-assurance of course. But for that great secret what to search for, maybe try "NAT security". Surprise.
Click to expand...
Honestly, I don't understand the whole quarrel either.

Zirias said:
thinking everyone knew about the reputation of Gibson in this field
Click to expand...
Seriosly, no.
 
Ok, finally, something concrete.

The first link is mostly semantics and basically arguing that an opponent could get this information elsewhere. They could, but just scanning the network is way easier and NAT makes it harder. A firewall could also make it harder. So, why not make it harder?

This goes back to my earlier point: IPv6 rollouts did not have a bullet point sort of feature of "Use this to get the obfuscation features you got with NAT." You're not going to get the same sort of features, though, by putting everything directly on the network and then firewalling them and the tradeoffs were not compelling to people. You can watch computers blink on and off the network if they're connected directly and correlate them to people and devices. Sure, you could block ICMP and other ping-ish techniques, but now you're "breaking things" like NAT (I don't know if you care about this distinction or not). Is there a name for a comprehensive "prevent people from telling if this IP is online" firewall rule? That's the kind of bullet point sort of thing people need to know to make decisions. I got this "feature" from NAT, what do I have to do to get it from this new setup? Arguments like "you don't need this feature" aren't particularly compelling to people if they don't have to do something.

Yes, NAT isn't "a firewall" but it has a lot of properties of one. People understand those properties and want them. "Hurr durr you should use a firewall with REAL rules" is not helpful. What are these "real" rules and do the people even want them? That's the only reason I chimed in here.

My personal issue with IPv6 vs NAT was the MAC addresses and how by default, you were going to have to know if your network firewall was going to keep your MAC LAN-local or configure a firewall on the computer (before OSes got wise and started randomizing them). I can't imagine telling people that they should configure a firewall before using a computer so people won't deduce their computer vendor and track them across the internet. IPv4 NAT provided this "feature" by default and it is/was very fiddily to get the same feature out of a firewalled-direct-connect IPv6 setup.

The second link has the appropriate caveat "certain situations." You need to know which server the client is connected to, spoof the IP, and luck into the client currently listening. Unless I'm mistaken, I don't think any firewall configuration is going to prevent this problem any better than NAT.
 
So, this is mixing up a lot of aspects and also repeating the NAT misconception. Let's just address the main points:

* "Privacy" by hiding your IP address? Doesn't make any sense. Still, plain SLAAC is just ONE method to assign IPv6 addresses. Of course, it's the most simple one that will work in any setup.
* NAT does not prevent something, but enable something. To make NAT work at all, you need connection tracking, which also works without NAT. It isn't bullet-proof (yep, that's the whole point) and I bet any consumer router offering IPv6 will still do exactly that by default (while blocking inbound traffic that wasn't tracked before).
 
I didn't use the word privacy, so I don't know what you are talking about.

"Connection-tracking, incoming block-by-default firewall" is kind of a mouthful to have people look for, but I guess at least it would mean something.
 
So, we're there again where I should have stopped writing to this thread in the first place. Will do so now. It just doesn't make any sense :/
 
The question is not so much whether or not NAT was designed to provide security, although asymmetric NAT surely does improve security. The question is whether games or other applications that employ techniques to punch holes into your firewall can be considered well behaved networking applications at all. I for one surely wont tolerate such behaviour from any network application. Many games in the past used fixed (or even configurable) ports for communications, so you could just set up a port forwarding on your router and be done with it. Nowadays game developers seem to be under the impression that setting up a port forwarding is way beyond the skillset of their target audience, so they resort to using crappy p2p networking implementations like steamworks and the like, with no user configurability whatsoever, that uses ephemeral ports on both sides, thereby creating a firewall admin's nightmare (as in: it just doesn't work if you do not open up ALL ports).
 
Just my 2¢: msplash, you've been choosing your words kinda awkward, to say it politely... While IMHO Zirias was arguing sensibly, you didn't. I do have some basic knowledge in networking, but still I have to & want to learn more; now one who presumably knows more than me is gone. Thx a lot.
 
Well, I will reply on that one:
mickey said:
The question is not so much whether or not NAT was designed to provide security, although asymmetric NAT surely does improve security.
Click to expand...
That's the thinking I consider kind of dangerous, cause this "security" is a byproduct of the shortcomings of NAT, and improving NAT will then decrease this kind of "security". The objective of NAT is to allow as many packets as possible to find their target.
mickey said:
The question is whether games or other applications that employ techniques to punch holes into your firewall can be considered well behaved networking applications at all. I for one surely wont tolerate such behaviour from any network application. Many games in the past used fixed (or even configurable) ports for communications, so you could just set up a port forwarding on your router and be done with it. Nowadays game developers seem to be under the impression that setting up a port forwarding is way beyond the skillset of their target audience, so they resort to using crappy p2p networking implementations like steamworks and the like, with no user configurability whatsoever, that uses ephemeral ports on both sides, thereby creating a firewall admin's nightmare (as in: it just doesn't work if you do not open up ALL ports).
Click to expand...
That however is a rant I can relate with, but I'd argue it's not really tied to NAT. As a firewall administrator, you maybe want to open up a specific port on a specific machine for UDP to allow a specific game to communicate. Whether you have to "forward" this port or not won't change anything in principle. A better NAT might remember a mapping automatically, so you don't have to explicitly forward something, but you still have to allow this communication. Thinking IPv6: You won't have/need NAT, but you'd probably still block any incoming packets by default and you still want to allow packets to a specific UPD port on a specific machine for exactly THAT game.

So, what's really annoying is this idea not to be able to configure the port used by a game, and games (and other software) trying to "punch holes" automatically, by just "tricking" any connection tracking. If you rely on connection tracking for your IPv6 firewall ruleset, you will have the exact same problem with software behaving that way.

I think the complaint should be towards software behaving that way, cause yes, this software will stop working with a restrictive ruleset in place on your firewall box, whether you use NAT or not. It shouldn't be an argument against improving NAT in a way so it can automatically route more packages correctly. Please just decouple filtering from NAT.

tl;dr: Yes, NAT *implies* some filtering by nature, but this will differ depending on the NAT implementation, you can never be sure about it, you shouldn't rely on it: it's a bug, not a feature. Use actual filtering for filtering.
 
Zirias said:
That however is a rant I can relate with, but I'd argue it's not really tied to NAT. As a firewall administrator, you maybe want to open up a specific port on a specific machine for UDP to allow a specific game to communicate. Whether you have to "forward" this port or not won't change anything in principle. A better NAT might remember a mapping automatically, so you don't have to explicitly forward something, but you still have to allow this communication. Thinking IPv6: You won't have/need NAT, but you'd probably still block any incoming packets by default and you still want to allow packets to a specific UPD port on a specific machine for exactly THAT game.

So, what's really annoying is this idea not to be able to configure the port used by a game, and games (and other software) trying to "punch holes" automatically, by just "tricking" any connection tracking. [...].

I think the complaint should be towards software behaving that way, cause yes, this software will stop working with a restrictive ruleset in place on your firewall box, whether you use NAT or not. It shouldn't be an argument against improving NAT in a way so it can automatically route more packages correctly. Please just decouple filtering from NAT.
Click to expand...
Games or other network applications behaving this way are bad by design. Steamworks for example uses libjingle to find a workable connection from a set of candidates, this employs STUN which simply cannot work with a symmetric NAT, it also leaks private IP addresses and there is nothing whatsoever that could be configured by a user. In the end, the only connection that has a chance to succeed if you are behind a symmetric NAT is via a relay server, whch might introduce additional latency and that is exactly the opposite of what you'd want for the purpose of gaming.
 
Definitely a braindead thing. Although I understand the motivation to offer some "automatic" behavior when operated by someone with no knowledge at all, behind your typical consumer router. If there is no alternative way to just tell this thing "listen on port XX", it's broken crap.

All I'm saying is, this isn't really related to NAT, it will give you headaches configuring your firewall without NAT as well.
 
There was this successor to STUN, I forgot it's name? I had that when configuring XMPP. I'm dialing in on WWAN (like a stupidphone). With my current ISP that's IPv4 only & they do NAT me on 10.x.y.z...
Bah :( PS: thx 4 join(1)ing again.
 
Zirias said:
Definitely a braindead thing. Although I understand the motivation to offer some "automatic" behavior when operated by someone with no knowledge at all, behind your typical consumer router. If there is no alternative way to just tell this thing "listen on port XX", it's broken crap.

All I'm saying is, this isn't really related to NAT, it will give you headaches configuring your firewall without NAT as well.
Click to expand...
I might be mistaken here as I don't use that kind of crap, but my guess is that even consumer grade routers these days more and more use symmetric NAT. There is nothing wrong with automatic approaches in general, as long as developers give the user at least the option to make it work, when these mechanisms fail.
 
mickey said:
I might be mistaken here as I don't use that kind of crap, but my guess is that even consumer grade routers these days more and more use asymmetric NAT. There is nothing wrong with automatic approaches in general, as long as developers give the user at least the option to make it work, when these mechanisms fail.
Click to expand...
They use it for IPv4 as there is just no other option. They nowadays support IPv6, of course without NAT. And ISPs offer more and more "ds-lite" where you get IPv4 only through a tunnel (over v6) with a private address that is *again* NAT'ed at the ISP.

My point was: The problem is not NAT, you'll have the same problems without it, if it means you have to allow all incoming traffic to a host, just so a stupid game there is able to do direct connections (which are necessary for gaming performance). I totally agree: any of these "automagic" strategies should be optional.

edit: CGNAT (carrier-grade NAT) might also be a somewhat interesting topic here, because you'd probably never want your ISP to do filtering for you, right? So, for CGNAT, it's even more crucial to route as many packets as possible to limit the impact. I'd bet any ISP offering IPv4 through CGNAT would implement the RFC linked in the OP ;)
 
On that privacy topic to hide a machine from ICMP: even this me with healthy sciolism can write a rule for my "personal FreeBSD firewall" (standard firewall_type=workstation) that answers ICMP of my ISP (to debug a problem should they need to), and deny all others. That's really simple. Of course, now that they NAT me, that makes no sense, but when they give me IPv6, I could do that easily.
 
Thanks, I think that "privacy" argument against IPv6 has always been a red herring. The "privacy" NAT "offers" is the same kind of unintended by-product as the implied filtering. Not sure what good blocking ICMP(v6) would do, but sure you can do that. If you want to "hide" your internal hosts, RFC4941 has a canonical solution (using random host-parts that change regularly).
 
To take this thread back on-topic: I have no plans to spend time on this patch.
It's a large change in a very complex section of the pf code, and the use case and utility of it are not clear to me.

Realistically that means it's not going to get picked up. There's essentially no one else working on pf right now.

If you really need this change there are a couple of things you can do: improve the argument for the change (i.e. demonstrate a need, a use case not covered without it) and add tests for it. Tests are very helpful in persuading me that the change is safe and won't break anything else. Also, continued engagement from the author of the patch would also be helpful, because it demonstrates that when there's fallout from it I'm not going to be the only one trying to figure that out.
 
This statement is very understandable. I'm not the author of the patch nor do I need what it provides, but I assume the "need" is just to improve NAT, and I guess beneficiaries would be exactly these applications that expect incoming UDP packages and use a random port for their communication, so of course you could argue they're "broken by design"… The key is that you send out a packet from port a, mapped to port b on the NAT host to remote host X, then a packet sent from remote host Y to port b on your NAT box WILL be forwarded to port a of your internal box. Of course, if you could just configure your application to use a fixed port, you could just configure a fixed mapping on your NAT box instead (which would help sane filtering rules a lot). Still, what it does is to improve functionality of NAT.

Totally understand the request for thorough automated testing though, to avoid breakage. Whoever needs this functionality should probably contact the author of the patch asking for that.
 
One can argue that the patches "score" relates to that RFC4787's acceptance & employment. I.e. if it's not widely employed, forget the patch. But if it's not a "niche-product", we could try to figure out reliable tests.
 
You must log in or register to reply here.
Back
Top