Requirements for IPv6 Firewalls

Fri Apr 18 22:36:15 UTC 2014

On 4/17/14 4:45 PM, "George Herbert" <george.herbert at gmail.com> wrote:
>
>> There's a fair argument to be made which says that kind of NAT is
>> > unhealthy. If its proponents are correct, they'll win that argument
>> > later on with NAT-incompatible technology that enterprises want. After
>> > all, enterprise security folk didn't want the Internet in the
>> > corporate network at all, but having a web browser on every desk is
>> > just too darn useful. Where they won't win that argument is in the
>> > stretch of maximum risk for the enterprise security folk.
>> >
>> >
>> Any technology has associated risks, it's a matter of how you
>> reduce/mitigate them.
>> This paranoia thingie about IPv6 is getting a bit old.
>> Just because you don't (seem to) understand how it works, it doesn't
>>mean
>> no one else should use it.
>
>
>
>You are missing the point.
>
>Granted, anyone who is IPv6 aware doing a green-field enterprise firewall
>design today should probably choose another way than NAT.
>
>What you are failing is that "redesign firewall rules and approach from
>scratch along with the IPv6 implementation" usually is not the chosen
>path,
>versus "re-implement the same v4 firewall rules and technologies in IPv6
>for the IPv6 implementation", because all the IPv6 aware net admins are
>having too much to do dealing with all the other conversion issues, vendor
>readiness all across the stack, etc.

One of the things we (operator hat) like about IPv6 is that we get to
clean up the mess we made in IPv4. In many cases we've significantly
reduced the number of firewall rules or ACL lines, because we don't have
disaggregate blocks we have to stack up.

On my enterprise firewalls, I had a couple of DMZs, a couple of internal
networks, and policies for what could get where.  Firewalls referred to
objects of various kinds, some of which had multiple addresses listed;
putting servers with similar policies in a single /64 (or a /60 if I
needed separate VLANs) would have simplified things.  And the policy/rule
difference between net 10 addresses internally and GUA prefixes internally
is null.

So, yeah, you have to give your firewall administrator time to walk
through the rules and figure out what they ought to be in IPv6.  Your
firewall administrator has been wanting to clean up the rules for the last
two years, anyway. 

Even if the above doesn't apply to you, what rules do you have that you
can't copy?
* deny ICMP to any.  Can't do that.  Must allow at least some messages.
* deny (public address range) to (private address range) unless initiated
form inside.  Substitute external and internal prefixes.
* deny (outside) to (DMZ) except (port ranges).  Same in IPv6.
* deny (inside) to (DMZ) except (port ranges).  Same in IPv6.

As I recall, the rules were in place even when we used NAT.  If "no
thinking required" firewall administration is your goal, I'm not clear how
this interferes.

>
>Variations on this theme are part of why it's 2014 and IPv6 hasn't already
>taken over the world.  The more rabid IPv6 proponents have in fact shot
>the
>transition in the legs repeatedly, and those of us who have been on the
>front lines would like you all to please shut up and get out of the way so
>we can actually finish effecting v6 deployment and move on to mopping up
>things like NAT later.
>
>This is why listening to operators is important.

Some operators want NAT.  Some don't.  There are loud voices on both
sides. Consensus seems slightly against.
However, ULA + NPT works.

Lee