On Oct 18, 2010, at 10:52 AM, George Bonser wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Monday, October 18, 2010 9:25 AM To: George Bonser Cc: Henning Brauer; nanog@nanog.org Subject: Re: Only 5x IPv4 /8 remaining at IANA
Nobody is using dynamic nat pools to block inbound connections.
Many people are using dynamic NAT on top of stateful inspection where stateful inspection blocks inbound connections.
The good news is that stateful inspection doesn't go away in IPv6. It works just fine. All that goes away is the header mangling.
Exactly true but there are people out there who experience it as "dynamic nat prevents inbound connections". And the extent to which state is inspected varies widely on different gear (is it just looking for an ACK flag to determine an "established" connection or is it making sure that at least one packet has gone in the other direction first?).
Looking for an ACK flag isn't Stateful inspection. Stateful inspection involves comparison against a state table of known connections. People perceive many things that are combined as having the systemic effect without understanding which component actually performs which underlying function. In cases where that doesn't matter, it's not an issue. In IPv4, it didn't matter if people understood the difference between security provided by stateful inspection and security eliminated by NAT. Now, it matters because some people are claiming IPv6 is less secure as a result of the lack of NAT. This claim comes from the misunderstanding you have restated above.
At least with dynamic (overload) NAT, a packet had to travel in the opposite (outbound) direction in order to establish the NAT in the first place. Then with an "established" acl, the two things give you fairly
This is true of stateful inspection as well. Stateful inspection != static packet filters. It's not the same thing. The ACK flag test you describe above is a static packet filter, not stateful inspection.
decent assurance that things went as planned but are still not a substitute for packet inspection.
Again, this doesn't come form the overloaded NAT. It comes from the state table mechanism and the comparison of the packet against known flows in the state table. While NAT requires this underlying state table to function, there is nothing preventing implementation of that state table without NAT. Such an implementation is equally secure without NAT. In fact, it's slightly better because NAT destroys audit trail while SI without NAT does not.
It's really unfortunate that most people don't understand the distinction.
Concur.
IPv6 with SI is no less secure than IPv4 with SI+NAT.
Yup, the difference is going to be the extent to which the state is inspected in various gear. Again, I believe firewall vendors are going to see a windfall here.
You are confusing SI with Packet Filters. The technologies are different and it is, also, important to understand this distinction as well.
And to address your comment in an email subsequent to this one about accounting, I wholeheartedly agree. NAT can make it much more difficult to find what is causing a problem or even who is talking to whom.
Actually, that was Tony Hain's comment, but, yes, he's correct. Owen