Requirements for IPv6 Firewalls

Fri Apr 18 23:11:04 UTC 2014

Lee Howard:
>
> 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.

The arrogance in this assertion is amazing.

You're describing best practice.  Yes, of course, you should have well
documented technical and business needs for what's open and what's closed
in firewalls, and should have traceability from the rules in place to the
requirements, and be able to walk the rules and understand them and
reinterpret them from v4 to v6, to a new firewall vendor, etc etc.

Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE.

Policymakers baldly asserting that it should be otherwise does not change
reality on the ground in numerous enterprise customers.

You and the others are ascribing to me and William blame for this.  Shoot
the messenger all you want; all we're doing it relaying on why we've failed
to convert all our customers.  It's not because we don't understand
firewalls or v6.  It's because the real world is substantially messier,
often man-decades of work messier than you all assert it could possibly be.

Again - policy community blinders on understanding what real systems are
like out in the world has repeatedly shot the conversion in the legs.  If
you're going to start floating standards for this kind of stuff, then
listen to feedback on why things are failing.

On Fri, Apr 18, 2014 at 3:36 PM, Lee Howard <Lee at asgard.org> wrote:

>
>
> 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
>
>
>

-- 
-george william herbert
george.herbert at gmail.com