subject:"Re\: Requirements for IPv6 Firewalls"

On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu eu...@imacandi.net wrote:
 On Thu, Apr 17, 2014 at 11:45 PM, George Herbert george.herb...@gmail.com
 wrote:
 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.


 That's why you have gazzilions of IP addresses in IPv6, so you don't need to
 NAT anything (among other things). I don't understand why people cling to
 NAT stuff when you can just route.

Hi Eugeniu,

That's correct: you don't understand. Until you do, just accept: there
are more than a few folks who want to, intend to and will use NAT for
IPv6. They will wait until NAT is available in their preferred
products before making any significant deployment efforts.

The main drivers behind the desire for NAT in IPv6 you've heard
before, but I'll repeat them for the sake of clarity:

1. Easier to manage the network if the IPv4 and IPv6 versions are
identical but for the IP addresses. Would've been even easier if the
IP addresses were identical too, but that ship sailed more than a
decade ago.

2. Risk management - developing a new operating posture for a new
protocol is high risk. Translating the existing posture is lower risk.
In most places the existing posture includes extensive NAT. The number
of IPv4 networks in which no NAT is employed is vanishingly small.

3. Renumbering - works about as well in IPv6 as in IPv4, which is to
say badly. And doubling down on the addresses assigned to hosts is
still half baked -- a worthwhile idea but needs more time in the
kitchen.

4. Defense in depth is a core principle of all security, network and
physical. If you don't practice it, your security is weak. Equipment
which is not externally addressable (due to address-overloaded NAT)
has an additional obstruction an adversary must bypass versus an
identical system where the equipment is externally addressable (1:1
NAT, static port translation and simple routing). This constrains the
kinds of attacks an adversary may employ.


Feel free to refute all four points. No doubt you have arguments you
personally find compelling. Your arguments will fall on deaf ears. At
best the arguments propose theory that runs contrary to decades of
many folks' experience. More likely the arguments are simply wrong.

Either way, you need NAT in the firewall products or you need some
miracle application, the desire for which compels folks to move past
the rationale above. Do you see the latter happening any time soon?
Neither do I.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Timothy Morizot

On Apr 18, 2014 10:04 AM, William Herrin b...@herrin.us wrote:
 That's correct: you don't understand. Until you do, just accept: there
 are more than a few folks who want to, intend to and will use NAT for
 IPv6. They will wait until NAT is available in their preferred
 products before making any significant deployment efforts.

Actually, the few like you will hold off until they are behind the curve,
then scramble to catch up. Good luck with that strategy!

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Mike Hale

Depends on your definition of behind the curve.  You could make the
argument that folks who aren't IPv6 ready now are behind the curve.  A
weak argument considering IPv4 works perfectly fine for those of
'behind the curve'.

I agree with Bill.  You can poopoo NAT all you want, but it's a fact
of most networks and will continue to remain so until you can make a
compelling case to move away from it.

On that note, it's awesome that Fernando is seeking feedback this
early in the game.  Kudos to you sir.

On Fri, Apr 18, 2014 at 10:15 AM, Timothy Morizot tmori...@gmail.com wrote:
 On Apr 18, 2014 10:04 AM, William Herrin b...@herrin.us wrote:
 That's correct: you don't understand. Until you do, just accept: there
 are more than a few folks who want to, intend to and will use NAT for
 IPv6. They will wait until NAT is available in their preferred
 products before making any significant deployment efforts.

 Actually, the few like you will hold off until they are behind the curve,
 then scramble to catch up. Good luck with that strategy!



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: Requirements for IPv6 Firewalls

Le 2014-04-18 13:25, Mike Hale a écrit :
 I agree with Bill.  You can poopoo NAT all you want, but it's a fact
 of most networks and will continue to remain so until you can make a
 compelling case to move away from it.

Does that mean all IPv6 firewalls should support NAT?

Remember, we're aiming for a base set of requirements applying to all
IPv6 firewalls.

Simon

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 1:31 PM, Simon Perreault si...@per.reau.lt wrote:
 Le 2014-04-18 13:25, Mike Hale a écrit :
 I agree with Bill.  You can poopoo NAT all you want, but it's a fact
 of most networks and will continue to remain so until you can make a
 compelling case to move away from it.

 Does that mean all IPv6 firewalls should support NAT?

 Remember, we're aiming for a base set of requirements applying to all
 IPv6 firewalls.

Your document specifies Enterprise firewalls. Frankly I think that's
wise. Consumer and enterprise users have very different needs and very
different cost points.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 1:15 PM, Timothy Morizot tmori...@gmail.com wrote:
 On Apr 18, 2014 10:04 AM, William Herrin b...@herrin.us wrote:
 That's correct: you don't understand. Until you do, just accept: there
 are more than a few folks who want to, intend to and will use NAT for
 IPv6. They will wait until NAT is available in their preferred
 products before making any significant deployment efforts.

 Actually, the few like you will hold off until they are behind the curve,
 then scramble to catch up. Good luck with that strategy!

You know, you zealots are playing this stupid. You've already won: no
NAT in consumer devices means that when (if) IPv4 starts its decline,
nat traversal will leave consumer-focused software. And sooner or
later there will be a consumer app that business has to have.

The only way you can snatch defeat from the jaws of victory is if IPv6
fails to launch. Look around you. IPv6 use on the Internet, actual
use, is still barely in the single digits. If you let us get used to
extending IPv4 with carrier NAT, markets and so on you lose
everything. And if you think the math says that can't happen, you
badly underestimate folks' ingenuity.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

Le 2014-04-18 13:35, William Herrin a écrit :
 Does that mean all IPv6 firewalls should support NAT?

 Remember, we're aiming for a base set of requirements applying to all
 IPv6 firewalls.
 
 Your document specifies Enterprise firewalls. Frankly I think that's
 wise. Consumer and enterprise users have very different needs and very
 different cost points.

Over here we have no use for IPv6 NAT. We have our own PI space. I
suspect many other enterprises would be in a similar situation.

I totally get your position, but I don't see how it can justify an
Internet-wide requirement.

Simon

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Mike Hale

Many enterprises probably are in the same position, but a whole lot of
them aren't.

Maybe this comes down to should versus must.  I don't think all
IPv6 firewalls must support NAT, but they should.

On Fri, Apr 18, 2014 at 10:40 AM, Simon Perreault si...@per.reau.lt wrote:
 Le 2014-04-18 13:35, William Herrin a écrit :
 Does that mean all IPv6 firewalls should support NAT?

 Remember, we're aiming for a base set of requirements applying to all
 IPv6 firewalls.

 Your document specifies Enterprise firewalls. Frankly I think that's
 wise. Consumer and enterprise users have very different needs and very
 different cost points.

 Over here we have no use for IPv6 NAT. We have our own PI space. I
 suspect many other enterprises would be in a similar situation.

 I totally get your position, but I don't see how it can justify an
 Internet-wide requirement.

 Simon




-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault si...@per.reau.lt wrote:
 Le 2014-04-18 13:35, William Herrin a écrit :
 Your document specifies Enterprise firewalls. Frankly I think that's
 wise. Consumer and enterprise users have very different needs and very
 different cost points.

 Over here we have no use for IPv6 NAT. We have our own PI space. I
 suspect many other enterprises would be in a similar situation.

 I totally get your position, but I don't see how it can justify an
 Internet-wide requirement.

As I understand your document, you're trying to scope a set of minimum
required features for a firewall that will be able to describe itself
as RFC whatever compliant. The idea is for folks working for large
enterprises to be able to use such a tag as a discriminator for
potential purchases. Since a pretty humongous number of them are using
NAT with IPv4 and are likely to want to do so with IPv6, leaving that
out of the required feature list seems counter-productive to your goal
of a document which has utility to them.

Besides, you have spam control and URL filtering in there. Do you
seriously propose that spam control and URL filtering rank above NAT
on the *firewall* requirements list?

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Gary Buhrmaster

On Fri, Apr 18, 2014 at 3:02 PM, William Herrin b...@herrin.us wrote:

 The main drivers behind the desire for NAT in IPv6 you've heard
 before, but I'll repeat them for the sake of clarity:

5. Some industries (PCI compliance) *require* NAT as part of
the audit-able requirements.  Yes, that should get changed.
But until it does, (at least some) enterprises are going to
be between a rock and a hard place.

As Bill says, the place to get this fixed is not to tell the
enterprises they are doing it wrong, but to change the
requirements that auditors measure against.  I would cheer
the effort to engage those bodies to get them to understand
that NAT is not the way (for it is not).  This does not mean
ignore the problem.  It does not mean to tell people they
are doing it wrong.  It means active engagement with such
organizations.  And it is hard, policy type, work,

Re: Requirements for IPv6 Firewalls

Le 2014-04-18 14:00, William Herrin a écrit :
 On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault si...@per.reau.lt wrote:
 Le 2014-04-18 13:35, William Herrin a écrit :
 Your document specifies Enterprise firewalls. Frankly I think that's
 wise. Consumer and enterprise users have very different needs and very
 different cost points.

 Over here we have no use for IPv6 NAT. We have our own PI space. I
 suspect many other enterprises would be in a similar situation.

 I totally get your position, but I don't see how it can justify an
 Internet-wide requirement.
 
 As I understand your document, you're trying to scope a set of minimum
 required features for a firewall that will be able to describe itself
 as RFC whatever compliant. The idea is for folks working for large
 enterprises to be able to use such a tag as a discriminator for
 potential purchases. Since a pretty humongous number of them are using
 NAT with IPv4 and are likely to want to do so with IPv6, leaving that
 out of the required feature list seems counter-productive to your goal
 of a document which has utility to them.
 
 Besides, you have spam control and URL filtering in there. Do you
 seriously propose that spam control and URL filtering rank above NAT
 on the *firewall* requirements list?

Well, it's not *my* document, but I'm very interested in it.

IMHO it should not be a shopping list of features that people might
want. The goal should not be to be a base for RFPs.

IMHO, what the IETF can do is recommend a set of behavioural traits that
make IPv6 firewalls behave like good citizens in the Internet ecosystem.
Meaning that a firewall that obeys those requirements will not break the
Internet. For example, passing ICMPv6 Too Big messages is important to
not break the Internet.

I think we can get consensus on such requirements, and I think it would
fit the IETF's role. A feature shopping list, not so much.

Simon

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault si...@per.reau.lt wrote:
 IMHO, what the IETF can do is recommend a set of behavioural traits that
 make IPv6 firewalls behave like good citizens in the Internet ecosystem.
 Meaning that a firewall that obeys those requirements will not break the
 Internet. For example, passing ICMPv6 Too Big messages is important to
 not break the Internet.

That would either be a very short document or a document so
ideologically loaded that it has no technical utility. The Internet is
pretty resilient. There isn't much a firewall can do to break it.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

Le 2014-04-18 14:20, William Herrin a écrit :
 On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault si...@per.reau.lt wrote:
 IMHO, what the IETF can do is recommend a set of behavioural traits that
 make IPv6 firewalls behave like good citizens in the Internet ecosystem.
 Meaning that a firewall that obeys those requirements will not break the
 Internet. For example, passing ICMPv6 Too Big messages is important to
 not break the Internet.
 
 That would either be a very short document or a document so
 ideologically loaded that it has no technical utility. The Internet is
 pretty resilient. There isn't much a firewall can do to break it.

In IETF we routinely use the phrase breaking the Internet to mean
something rather more limited than breaking all of the Internet. There
are tons of things firewalls can do, and some do today, that would be
considered breaking the Internet.

FYI, we had a similar document targeted at CGNs:

http://tools.ietf.org/html/rfc6888

From the abstract:

   This document describes behavior that is required of those multi-
   subscriber NATs for interoperability.  It is not an IETF endorsement
   of CGNs or a real specification for CGNs; rather, it is just a
   minimal set of requirements that will increase the likelihood of
   applications working across CGNs.

That is exactly the kind of requirements I am thinking of when I say
not breaking the Internet. Still, there were a few feature shopping
list requirements that crept into that RFC. It's far from perfect.

Simon

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 2:32 PM, Simon Perreault si...@per.reau.lt wrote:
 Le 2014-04-18 14:20, William Herrin a écrit :
 That would either be a very short document or a document so
 ideologically loaded that it has no technical utility. The Internet is
 pretty resilient. There isn't much a firewall can do to break it.

 In IETF we routinely use the phrase breaking the Internet to mean
 something rather more limited than breaking all of the Internet. There
 are tons of things firewalls can do, and some do today, that would be
 considered breaking the Internet.

 FYI, we had a similar document targeted at CGNs:

 http://tools.ietf.org/html/rfc6888

Excluding references and remarks RFC 6888 is 8 pages long with 15
total requirements. Short.

I'll let the firewall document's authors speak for themselves about
their document's purpose. In the abstract, they said: ''This has
typically been a problem for network operators, who typically have to
produce a Request for Proposal from scratch that describes such
features.''

That says, discriminator for potential purchases to me. What's your take?

I agree that a don't break the Internet' firewall requirements
document could have utility. But that doesn't appear to be this
document. And if done well, such a document would be short just like
RFC 6888.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Doug Barton


On 04/18/2014 12:57 AM, Enno Rey wrote:

I fully second Sander's input. I've been involved in IPv6 planning in a number of very 
large enterprises now and_none_  of them required/asked for (66/overloading) NAT for 
their firewall environments. A few think about very specific deployments of NPTv6 like 
stuff for connections to supplier/partner networks (to map those to their own address 
space) but these are corner cases not even relevant for their firewalls.


How many of those networks were implementing with IPv6 PI space? My 
experience has been that those customers are not interested in IPv6 NAT, 
but instead utilize network segmentation to define internal vs. 
external.


OTOH, customers for whom PI space is not realistic (for whatever 
reasons, and yes there are reasons) are very interested in the 
combination of ULA + NTPv6 to handle internal resources without having 
to worry about renumbering down the road.


Doug

Re: Requirements for IPv6 Firewalls

Le 2014-04-18 14:57, William Herrin a écrit :
 Excluding references and remarks RFC 6888 is 8 pages long with 15
 total requirements. Short.

Given the trend toward ever-fluffier RFCs, I'll take that as a
compliment. :)

 I'll let the firewall document's authors speak for themselves about
 their document's purpose. In the abstract, they said: ''This has
 typically been a problem for network operators, who typically have to
 produce a Request for Proposal from scratch that describes such
 features.''
 
 That says, discriminator for potential purchases to me. What's your take?

I agree with your interpretation, and I disagree with the intent.

 I agree that a don't break the Internet' firewall requirements
 document could have utility. But that doesn't appear to be this
 document. And if done well, such a document would be short just like
 RFC 6888.

Full agreement.

Simon

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Jim Clausing

And maybe I'm just dense, but ho one has been able to tell me how I 
accomplish this in IPv6 without NAT, I have the requirement in certain 
circumstances to transparently redirect all outbound DNS (well, on TCP or 
UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers.  No, 
simply blocking it at the firewall and making the user fix the problem 
is not an option (especially when the problem is created by malware).  It 
is a simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? 
Not flaming or anything, but I really want to know how I'm supposed to 
accomplish that in the ideal IPv6 world with no NAT?


--
Jim Clausing
GIAC GSE #26, GREM(G), CISSP
GPG fingerprint = A507 774A 39D6 A702 9F7C  8808 3D13 77B8 AACD 848D

On or about Fri, 18 Apr 2014, Simon Perreault pontificated thusly:


Le 2014-04-18 14:57, William Herrin a écrit :

Excluding references and remarks RFC 6888 is 8 pages long with 15
total requirements. Short.


Given the trend toward ever-fluffier RFCs, I'll take that as a
compliment. :)


I'll let the firewall document's authors speak for themselves about
their document's purpose. In the abstract, they said: ''This has
typically been a problem for network operators, who typically have to
produce a Request for Proposal from scratch that describes such
features.''

That says, discriminator for potential purchases to me. What's your take?


I agree with your interpretation, and I disagree with the intent.


I agree that a don't break the Internet' firewall requirements
document could have utility. But that doesn't appear to be this
document. And if done well, such a document would be short just like
RFC 6888.


Full agreement.

Simon

Re: Requirements for IPv6 Firewalls



On 4/17/14 8:51 PM, Matthew Kaufman matt...@matthew.at wrote:

While you're at it, the document can explain to admins who have been
burned, often more than once, by the pain of re-numbering internal
services at static addresses how IPv6 without NAT will magically solve
this problem.


http://datatracker.ietf.org/doc/rfc6879/

This document analyzes events that cause renumbering and describes
   the current renumbering methods.  These are described in three
   categories: those applicable during network design, those applicable
   during preparation for renumbering, and those applicable during the
   renumbering operation.


Lee


Matthew Kaufman

(Sent from my iPhone)

 On Apr 17, 2014, at 4:20 PM, Brandon Ross br...@pobox.com wrote:
 
 On Thu, 17 Apr 2014, Sander Steffann wrote:
 
 Also, I note your draft is entitled Requirements for IPv6 Enterprise
 Firewalls. Frankly, no enterprise firewall will be taken seriously
 without address-overloaded NAT. I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.
 
 I disagree. While there certainly will be organisations that want such
a 'feature' it is certainly not a requirement for every (I hope most,
but I might be optimistic) enterprises.
 
 And I not only agree with Sander, but would also argue for a definitive
statement in a document like this SPECIFICALLY to help educate the
enterprise networking community on how to implement a secure border for
IPv6 without the need for NAT.  Having a document to point at that has
been blessed by the IETF/community is key to helping recover the
end-to-end principle.  Such a document may or may not be totally in
scope for a firewall document, but should talk about concepts like
default-deny inbound traffic, stateful inspection and the use of address
space that is not announced to the Internet and/or is completely blocked
at borders for all traffic.
 
 Heck, we could even make it less specific to IPv6 and create a document
that describes these concepts and show how NAT is not necessary nor wise
for IPv4, either.  (Yes, yes, other than address conservation.)
 
 -- 
 Brandon Ross  Yahoo  AIM:
BrandonNRoss
 +1-404-635-6667ICQ:
2269442
 Skype:
brandonross
 Schedule a meeting:  http://www.doodle.com/bross

Re: Requirements for IPv6 Firewalls



On 4/17/14 11:51 AM, William Herrin b...@herrin.us wrote:


Also, I note your draft is entitled Requirements for IPv6 Enterprise
Firewalls. Frankly, no enterprise firewall will be taken seriously
without address-overloaded NAT. I realize that's a controversial
statement in the IPv6 world but until you get past it you're basically
wasting your time on a document which won't be useful to industry.

You've said this before, and it is still an absurdly over-broad statement.
Many security professionals have deployed enterprise firewalls to their
satisfaction without NAT-PT.

We had this debate, what, a month ago?  Your position hasn't changed.  No
new use cases have emerged.  Are we done here?

Lee

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Eugeniu Patrascu

On Fri, Apr 18, 2014 at 6:02 PM, William Herrin b...@herrin.us wrote:

 On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu eu...@imacandi.net
 wrote:
  On Thu, Apr 17, 2014 at 11:45 PM, George Herbert 
 george.herb...@gmail.com
  wrote:
  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.
 
 
  That's why you have gazzilions of IP addresses in IPv6, so you don't
 need to
  NAT anything (among other things). I don't understand why people cling to
  NAT stuff when you can just route.

 4. Defense in depth is a core principle of all security, network and
 physical. If you don't practice it, your security is weak. Equipment
 which is not externally addressable (due to address-overloaded NAT)
 has an additional obstruction an adversary must bypass versus an
 identical system where the equipment is externally addressable (1:1
 NAT, static port translation and simple routing). This constrains the
 kinds of attacks an adversary may employ.


Let's make it simple:

Scenario (A) w/ IPv4
[Internet] - Firewall Public IP :80/TCP - DNAT to Internal IP Address
:80/TCP

Scenario (B) w/ IPv6
[Internet] - FIrewall - Host w/ Routable IP Address :80/TCP


In scenario (A) I hide a server behind a firewall and to a simple
destination NAT (most common setup found in all companies).
In scenario (B) I have a firewall rule that only allows port 80 to a
machine in my network.


Explain to me how from a security standpoint Scenario (A) is better than
scenario (B).


Defense in depth, to my knowledge - and feel free to correct me, is to have
defenses at every point in the network and at the host level to protect
against different attack vectors that are possible at those points. For
example a firewall that understands traffic at the protocol level, a
hardened application server, a hardened application, secure coding
practices and so on depending of the complexity of the network and the
security requirements.


 Feel free to refute all four points. No doubt you have arguments you
 personally find compelling. Your arguments will fall on deaf ears. At
 best the arguments propose theory that runs contrary to decades of
 many folks' experience. More likely the arguments are simply wrong.


Just because some people have decades of experience, it doesn't mean they
are right or know what they are doing.


Eugeniu

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Eugeniu Patrascu

On Fri, Apr 18, 2014 at 10:49 PM, Jim Clausing jim.claus...@acm.org wrote:

 And maybe I'm just dense, but ho one has been able to tell me how I
 accomplish this in IPv6 without NAT, I have the requirement in certain
 circumstances to transparently redirect all outbound DNS (well, on TCP or
 UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers.  No,
 simply blocking it at the firewall and making the user fix the problem is
 not an option (especially when the problem is created by malware).  It is a
 simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? Not
 flaming or anything, but I really want to know how I'm supposed to
 accomplish that in the ideal IPv6 world with no NAT?


Nothing stops you from using NAT :)

This discussion got a bit off track. I'm not saying NAT should be banned
completely, I'm saying that with IPv6 we can actually simplify things a lot
get rid of all hacks we had to do in the network do get services up and
running (e.g. using a firewall's public ip address to hide several distinct
services behind it on different hosts, like web, dns, smtp etc).

I believe in simplicity, and now IPv6 for me makes things simple: I can
have all the IP addresses I want and do not need to use hacks to get things
working because no one would give 2048 IPv4 addresses just to do stuff with
them and run lots of servers with public IP addresses.

Re: Requirements for IPv6 Firewalls



On 4/17/14 4:45 PM, George Herbert george.herb...@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

Re: Requirements for IPv6 Firewalls



On 4/18/14 4:33 PM, George Herbert george.herb...@gmail.com wrote:

If William and I fight that fight, lose it, and come back and tell you
They won't go because insufficient NAT you need to listen.  I've fought
this in a dozen places and lost 8 of them, not because I don't know v6,
but
because the clients have inertia and politics around security posture
changes (and in some cases, PCI compliance regs).


IPv6 evangelists are used to fighting inertia.
PCI, however. . . anyone have any contacts there?

Lee

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 6:36 PM, Lee Howard l...@asgard.org wrote:
 Some operators want NAT.  Some don't.  There are loud voices on both
 sides. Consensus seems slightly against.

Hi Lee,

Some operators want NAT. That's it. End of discussion. This isn't a
consensus question. Some operators want NAT. Period. Full stop.
They'll hold off deploying and when IPv6 is sufficiently valuable,
they'll pay someone to give them NAT. Regardless of whether the
consensus of the IETF approves.

These are the folks who made Gauntlet and its transparent proxies the
#1 firewall product back during the bubble. They don't see the
Internet the way you do.

And if there are more of them than you think, IPv6 won't achieve
sufficient value, won't reach critical mass. Then you'll really REALLY
be stuck with NAT.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Matt Palmer

On Fri, Apr 18, 2014 at 06:37:28PM -0400, Lee Howard wrote:
 On 4/18/14 4:33 PM, George Herbert george.herb...@gmail.com wrote:
 
 If William and I fight that fight, lose it, and come back and tell you
 They won't go because insufficient NAT you need to listen.  I've fought
 this in a dozen places and lost 8 of them, not because I don't know v6,
 but
 because the clients have inertia and politics around security posture
 changes (and in some cases, PCI compliance regs).
 
 IPv6 evangelists are used to fighting inertia.
 PCI, however. . . anyone have any contacts there?

If you get to talk to them, they'll probably look at you funny and say,
whatchoo talkin' 'bout?.  PCI DSS *does not require NAT*.  Anyone who
says differently is selling something (probably a NAT box).  You can refer
to the source documents yourself -- they're freely available
(https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf, for
example).  As a testimonial, we run a no-NAT environment and got full PCI
compliance with nary a twitch of the eyebrow.  Didn't even have to argue the
toss with anyone.

- Matt

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Matthew Kaufman

Ignoring security, A is superior because I can change it to DNAT to the new 
server, or DNAT to the load balancer now that said server needs 10 replicas, 
etc. 

B requires re-numbering the server or *if* I am lucky enough that it is reached 
by DNS name and I can change that DNS promptly, assigning a new address and 
adding another firewall rule that didn't exist.

Matthew Kaufman

(Sent from my iPhone)

 On Apr 18, 2014, at 3:19 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
 
 On Fri, Apr 18, 2014 at 6:02 PM, William Herrin b...@herrin.us wrote:
 
 On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu eu...@imacandi.net
 wrote:
 On Thu, Apr 17, 2014 at 11:45 PM, George Herbert 
 george.herb...@gmail.com
 wrote:
 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.
 
 That's why you have gazzilions of IP addresses in IPv6, so you don't
 need to
 NAT anything (among other things). I don't understand why people cling to
 NAT stuff when you can just route.
 
 4. Defense in depth is a core principle of all security, network and
 physical. If you don't practice it, your security is weak. Equipment
 which is not externally addressable (due to address-overloaded NAT)
 has an additional obstruction an adversary must bypass versus an
 identical system where the equipment is externally addressable (1:1
 NAT, static port translation and simple routing). This constrains the
 kinds of attacks an adversary may employ.
 Let's make it simple:
 
 Scenario (A) w/ IPv4
 [Internet] - Firewall Public IP :80/TCP - DNAT to Internal IP Address
 :80/TCP
 
 Scenario (B) w/ IPv6
 [Internet] - FIrewall - Host w/ Routable IP Address :80/TCP
 
 
 In scenario (A) I hide a server behind a firewall and to a simple
 destination NAT (most common setup found in all companies).
 In scenario (B) I have a firewall rule that only allows port 80 to a
 machine in my network.
 
 
 Explain to me how from a security standpoint Scenario (A) is better than
 scenario (B).
 
 
 Defense in depth, to my knowledge - and feel free to correct me, is to have
 defenses at every point in the network and at the host level to protect
 against different attack vectors that are possible at those points. For
 example a firewall that understands traffic at the protocol level, a
 hardened application server, a hardened application, secure coding
 practices and so on depending of the complexity of the network and the
 security requirements.
 
 
 Feel free to refute all four points. No doubt you have arguments you
 personally find compelling. Your arguments will fall on deaf ears. At
 best the arguments propose theory that runs contrary to decades of
 many folks' experience. More likely the arguments are simply wrong.
 Just because some people have decades of experience, it doesn't mean they
 are right or know what they are doing.
 
 
 Eugeniu

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
 On Fri, Apr 18, 2014 at 6:02 PM, William Herrin b...@herrin.us wrote:
 4. Defense in depth is a core principle of all security, network and
 physical. If you don't practice it, your security is weak. Equipment
 which is not externally addressable (due to address-overloaded NAT)
 has an additional obstruction an adversary must bypass versus an
 identical system where the equipment is externally addressable (1:1
 NAT, static port translation and simple routing). This constrains the
 kinds of attacks an adversary may employ.

 Let's make it simple:

 Scenario (A) w/ IPv4
 [Internet] - Firewall Public IP :80/TCP - DNAT to Internal IP Address
 :80/TCP

 Scenario (B) w/ IPv6
 [Internet] - FIrewall - Host w/ Routable IP Address :80/TCP


 In scenario (A) I hide a server behind a firewall and to a simple
 destination NAT (most common setup found in all companies).
 In scenario (B) I have a firewall rule that only allows port 80 to a machine
 in my network.


 Explain to me how from a security standpoint Scenario (A) is better than
 scenario (B).

So your question is: how does one variant of being externally
addressable (simple routing with a packet filter or perhaps a stateful
firewall) differ from another variant of being externally addressable
(static inbound port translation)? Hell man, I don't like seeing these
in IPv4 let alone IPv6. But when I'm asking a guy to make a much
bigger leap of faith, like implementing IPv6, I don't plan to distract
him with the fact that he's taken NAT=good from the situation where
it's probably true and applied it to a situation where its value is
more dubious.


 Defense in depth, to my knowledge - and feel free to correct me, is to have
 defenses at every point in the network and at the host level to protect
 against different attack vectors that are possible at those point.

And a heart attack is that you clutch your chest and fall over dead.
You describe what defense in depth looks like, not what it is.

Defense in depth is that you have a fence and a security guard and a
spotlight. And a locked door, an alarm system and a safe too. But you
don't just have the fence, the door and the safe, a single form of
protection at each point. That would be a shallow defense.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread George Herbert

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 l...@asgard.org wrote:



 On 4/17/14 4:45 PM, George Herbert george.herb...@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

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 7:06 PM, William Herrin b...@herrin.us wrote:
 On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
 Defense in depth, to my knowledge - and feel free to correct me, is to have
 defenses at every point in the network and at the host level to protect
 against different attack vectors that are possible at those point.

 And a heart attack is that you clutch your chest and fall over dead.
 You describe what defense in depth looks like, not what it is.

 Defense in depth is that you have a fence and a security guard and a
 spotlight. And a locked door, an alarm system and a safe too. But you
 don't just have the fence, the door and the safe, a single form of
 protection at each point. That would be a shallow defense.

Put more succinctly: depth isn't where you place the defenses, it's
how many defenses times the quality of each defense that an adversary
has to slip past. If an adversary has to bypass three defenses, that's
more shallow than if he has to bypass the same three and three more.
Whether all six are at the perimeter or half are at the perimeter two
are at the host and one is in the application is only indirectly
relevant to the depth of your defense.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

On Fri, Apr 18, 2014 at 6:10 PM, Lee Howard l...@asgard.org wrote:
 On 4/17/14 11:51 AM, William Herrin b...@herrin.us wrote:
Also, I note your draft is entitled Requirements for IPv6 Enterprise
Firewalls. Frankly, no enterprise firewall will be taken seriously
without address-overloaded NAT. I realize that's a controversial
statement in the IPv6 world but until you get past it you're basically
wasting your time on a document which won't be useful to industry.

 You've said this before, and it is still an absurdly over-broad statement.

Hi Lee,

That tends to happen when one takes a nuanced topic involving the
intersection of technology with human social behavior and boils it
down to two sentences. Perhaps I could have said, taken seriously by
enough of your target audience without.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Glen Turner

Fernando,

Perhaps the document should have opened with a disclaimer that it is impossible 
to describe the full customer requirements for a firewall and thus a customer 
can reasonably add additional requirements. Then everyone knows where they 
stand and we avoid stupid (perhaps contractual) arguments that a firewall is 
acceptable solely because it meets this IETF publication.

The document varies between specification and advice. My view is that it that 
as it stands the document is too specific to a particular type of firewall in a 
particular type of network to be anything other than advice, and should remove 
words such as specify.  My view is that there is scope for a different 
document -- or a much later revision of this document -- which actually 
specifies the minimum acceptable behaviour of a IPv6 network boundary firewall.

You need an copyeditor. Expressions such as
  but at times has also meant that a number of important/basic
  features have remained unimplemented by major firewall vendors,
  or that aforementioned features have not behaved as expected.
are simply a poor use of the language.

REQ GEN-5.
Benchmarking is far too vague. Replace with a list of tests.

REQ GEN-10
This is a requirement for the author of this specification. You should
take that requirement and implement it throughout the document, and
have a corresponding SNMP MIB which SHOULD be implemented. Counters
we can't retrieve are pointless.

REQ GEN-20
Define basic access control list. Is that drop-and-count on destination
address prefix? That would be the understanding based on the use of that
term in Cisco IOS for IPv4.

REQ GEN-30
Which transport layers are required for stateless inspection? TCP? UDP? OSPF?

REQ GEN-50
This should not be a general requirement at all. There are good reasons not
to use TCP proxying, not the least of which is the load on the firewall.

REQ GEN-70
Doesn't allowing ACLs meet the uRPF requirement for non-routers? Is a vendor
which supports ACLs automatically compliant? If not, state so.

REQ GEN-80
Redirection of HTTPS traffic independent of other traffic is a specific
feature for content providers not justifying a MUST for all firewalls.

REQ SPC-10
This requirement squibs the most important single statement you can make
about a IPv6 firewall: defining ICMP types which SHOULD be forwarded and
those which SHOULD NOT when crossing a network boundary. This was a major
issue for IPv4 and requires greater depth for IPv6 then is given here.

REQ SPC-20
List the extension headers which SHOULD and SHOULD NOT be filtered by default
when crossing a network boundary.

REQ SPC-30:
List the routing headers which SHOULD and SHOULD NOT be filtered by default
when crossing a network boundary.

REQ SPC-40
List the options which SHOULD and SHOULD NOT be filtered by default when
crossing a network boundary.

REQ SPC-50
This requirement need much more work, as the specification is handwaving.

REQ SPC-70
Cannot be implemented in anything but a simplistic network. ICMPv6 errors
can come from anywhere on the forwarding path between the firewall and the
host. The firewall cannot tell if a ICMPv6 from an unknown address is on
the forwarding path for a connection. All it can do is validate uRPF, which
is already a requirement.

REQ SPC-80
Duplicate requirement

REQ SPC-90
Poorly expressed. Rephrase in terms of packet parsing.

REQ SPC-100
Rewriting Hop Limit? If you are going to proceed with the requirement then
*reducing* Hop Limit is the only safe behaviour, and the only which a
firewall SHOULD be required to support. If you are doing this to hide
topology then the firewall manufacturer can reduce Hop Limit to the next
lowest in a predefined set of values.

Setting Hop Limit to an arbitrary value MAY be possible, and that should
be accompanied by a note pointing out that this can lead to network failure
unless all topologies containing the firewall are loop-free at all times.


Why should a firewall support VPNs at all? Maybe you need to be clearer
about the applicability of each section to a product. Do you mean that
if a firewall implemented VPNs it must do so meeting these requirements?

REQ VPN-20 is dynamic multipoint VPNs really a MUST for all VPN servers?
You are saying that is it not possible for their to be a valid VPN design
which does not include dynamic multipoint VPN. You'll excuse my doubt on
that point.

REQ VPN-60 needs more work. Some environments require certificates and keys
to be manually altered.


DOS. There are a lot of must be able to protect against which is handwaving.

REQ DoS-70. This introduces a new requirement for filtering on VLAN or MPLS.
That requirement needs to be higher in the document, not hidden.

REQ DoS-80. I contest the MUST participate in blackhole infrastructure. There
seems to be an assumption in this document that all valid IP firewalls designs
are for use on Internet-connected networks. Ditto REQ DoS-85.

REQ DoS-100. Underspecified. Or is detected the limit of

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Dobbins, Roland


On Apr 19, 2014, at 1:20 AM, William Herrin b...@herrin.us wrote:

 There isn't much a firewall can do to break it.

As someone who sees firewalls break the Internet all the time for those whose 
packets have the misfortune to traverse one, I must respectfully disagree.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Jeff Kell

On 4/18/2014 9:53 PM, Dobbins, Roland wrote:
 On Apr 19, 2014, at 1:20 AM, William Herrin b...@herrin.us wrote:

 There isn't much a firewall can do to break it.
 As someone who sees firewalls break the Internet all the time for those whose 
 packets have the misfortune to traverse one, I must respectfully disagree.

If end-to-end connectivity is your idea of the Internet, then a
firewall's primary purpose is to break the Internet.  It's how we
provide access control.

If a firewall blocks legitimate, authorized access then perhaps it
adds to breakage (PMTU, ICMP, other blocking) but otherwise it works.

As to address the other argument in this threat on NAT / private
addressing, PCI requirement 1.3.8 pretty  much requires RFC1918
addressing of the computers in scope...  has anyone hinted at PCI for IPv6?

Jeff

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread TheIpv6guy .

On Fri, Apr 18, 2014 at 6:53 PM, Dobbins, Roland rdobb...@arbor.net wrote:

On Apr 19, 2014, at 1:20 AM, William Herrin b...@herrin.us wrote:

There isn't much a firewall can do to break it.

As someone who sees firewalls break the Internet all the time for those whose
packets have the misfortune to traverse one, I must respectfully disagree.

;

Yep. I have seen many more security / availability events caused by a
firewall tipping over than anything else. Firewalls tend to be put in
as single points of failure so that there is one point of inspection /
policy enforcement. And, HA pairs are generally a joke. 2 failure
mode i have seen: Firewall ALG saw a SIP packet option that it did
not like, so it reloaded itself. In the process, it reflected the
session state with fatal information to it's HA mate, which
immediately failed. Same story with SYN floods, too many sessions
coming in, FW cannot keep up with figuring out what is good, what is
bad... Kablamoo. The firewall is the weakest link in the chain.

Oh, and, then there is this... where the firewall, which is the one
point of security control is in fact an open tap to your entire
network

http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140110-sbd

But, it leads to clever things like this where home routers get
hijacked as proxies...for whatever ...
http://danmcinerney.org/how-to-exploit-home-routers-for-anonymity/

I think stateful network based firewalls are more harm than good and I
would like host and applications to be the ultimate front line of
defense. To each their own. Just a data point.

Enjoy

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Luck is the residue of opportunity and design.

-- John Milton

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Dobbins, Roland


On Apr 19, 2014, at 9:04 AM, Jeff Kell jeff-k...@utc.edu wrote:

 It's how we provide access control.

Firewalls  'access control'.

Firewalls are one (generally, very poor and grossly misused) way of providing 
access control.  They're often wedged in where stateless ACLs in hardware-based 
routers and/or layer-3 switches would do a much better job, such as in front of 
servers:

https://app.box.com/s/a3oqqlgwe15j8svojvzl

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Matt Palmer

On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote:
 As to address the other argument in this threat on NAT / private
 addressing, PCI requirement 1.3.8 pretty much requires RFC1918 addressing
 of the computers in scope...  has anyone hinted at PCI for IPv6?

1.3.8 lists use of RFC1918 address space as one of four possible
implementations, immediately after the phrase may include, but are not
limited to.  I don't interpret that as pretty much requires RFC1918.

Now, if you'd like to claim that 1.3.8 is completely useless, I won't argue
with you -- it's security-by-obscurity of the worst possible form.  But
don't blame PCI compliance for any inability to deploy IPv6, because it just
ain't true.

- Matt

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Enno Rey

Hi,

On Fri, Apr 18, 2014 at 11:59:04AM -0700, Doug Barton wrote:
 On 04/18/2014 12:57 AM, Enno Rey wrote:
  I fully second Sander's input. I've been involved in IPv6 planning in a 
  number of very large enterprises now and_none_  of them required/asked for 
  (66/overloading) NAT for their firewall environments. A few think about 
  very specific deployments of NPTv6 like stuff for connections to 
  supplier/partner networks (to map those to their own address space) but 
  these are corner cases not even relevant for their firewalls.
 
 How many of those networks were implementing with IPv6 PI space?

all of them



 My 
 experience has been that those customers are not interested in IPv6 NAT, 
 but instead utilize network segmentation to define internal vs. 
 external.
 
 OTOH, customers for whom PI space is not realistic (for whatever 
 reasons, and yes there are reasons) are very interested in the 
 combination of ULA + NTPv6 to handle internal resources without having 
 to worry about renumbering down the road.

true. it's just we don't see many of those (actually I've yet to encounter a 
single one) and it could be debatable if they belong to Enterprise networks 
(which is in the title of the ID).

best

Enno





 
 Doug
 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Jeff Kell

On 4/18/2014 10:10 PM, Dobbins, Roland wrote:
 On Apr 19, 2014, at 9:04 AM, Jeff Kell jeff-k...@utc.edu wrote:

 It's how we provide access control.
 Firewalls  'access control'.

 Firewalls are one (generally, very poor and grossly misused) way of providing 
 access control.  They're often wedged in where stateless ACLs in 
 hardware-based routers and/or layer-3 switches would do a much better job, 
 such as in front of servers:

I call BS...  what do you expect closes the gap, host firewalls?  Most
3rd party crap has no firewalls and gets no specific rules for local
LANs or authorized users.

Firewalls are front-line defense, for the crap that is too generic /
misconfigured to protect itself.  And there are tons of these.

Anyone ever pentested you?  It's an enlightening experience.

Jeff

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Dobbins, Roland


On Apr 19, 2014, at 10:29 AM, Jeff Kell jeff-k...@utc.edu wrote:

 I call BS...

You can 'call' it all you like - but people who actually want to keep their 
servers up and running don't put stateful firewalls in front of them, because 
it's very easy to knock them over due to state exhaustion.  In fact, it's far 
easier to knock them over than to knock over properly-tuned naked hosts.

Also, you might want to search the NANOG email archive on this topic.  There's 
lots of previous discussion, which boils down to the fact that serious 
organizations running serious applications/services don't put stateful 
firewalls (or 'IPS', or NATs, et. al.) in front of their servers.

The only way to secure hosts/applications/service against compromise is via 
those hosts/applications/services themselves.  Inserting stateful middleboxes 
doesn't actually accomplish anything to enhance confidentiality and integrity, 
actually increases the attack surface due to middlebox exploits (read the 
numerous security notices for various commercial and open-source stateful 
firewalls for compromise exploits), and has a negative impact on availability.

Again, take a look at this preso:

https://app.box.com/s/a3oqqlgwe15j8svojvzl

And take a look at pp. 17-18 of this preso:

https://app.box.com/s/ko8lk4vlh1835p36na3u

I've seen 3mb/sec of spoofed SYN-flooding take down a supposedly 20gb/sec 
stateful firewall due to state exhaustion in about 2 minutes; I've seen 6kpps 
of HOIC take down a supposedly 10gb/sec load-balancer due to state-table 
exhaustion in 60 seconds.  Each of those devices required an ~30-minute hard 
reboot - and those are just two of too many examples to keep track of, heh.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Jimmy Hess

On Fri, Apr 18, 2014 at 10:02 AM, William Herrin b...@herrin.us wrote:

It would appear point (5)  in favor of NAT with IPv6 is the only point
that has any merit there.   (1) to (4) are just rationalizations.
None of (1) to (4) are the reasons IPv4 got NAT, none are valid, and
none are good reasons to bring NAT to IPv6  or use NAT in designs of
IPv6 networks.

You could also add as good reasons..   (6) Requirement for NAT based
on personal preference,  and...

(7) You don't need this NAT function anymore,  is not a good reason
to 'withhold the feature as a design and implementation option'.  --
IPv6 is clearly not as mature as IPv4, when my IPv4 router has
greater flexibility in translation options
---

(1) to (4) are just excuses for people who want NAT to not admit the
real reasons which are illogical,  BUT  still important.

 (5) is quite valid.   Also, you  cannot fight it.   When you have
customers  that demand NAT, even though there is absolutely no sound
reason for NAT anymore. The users will still buy whatever gives
them the feature they deemed important,  based on their experience
with IPv4.


The fact of the matter is,  the demand has irrational sources
contributing:  comfort and change-aversity  and loss-aversity.

People want to keep and not lose their IPv4 or their IPv4 features.
They expect to cherrypick IPv6's advantages   and not lose any
functionality from V4 or have any extra work to do,  or re-thinking of
their understanding of IP networking to be doing.

So if you are building IPv6 firewall SW,  you should definitely
include any NAT functionality  you believe that many of your potential
customers will demand.

The fact is...  as a product vendor to move the maximal number of
people to the IPv6 paradigm: you are still going to have to cater to
people with IPv4-like thinking.

Therefore...  I fully expect all the NAT features of IPv4  to have an
IPv6 equivalent appearing.


 1. Easier to manage the network if the IPv4 and IPv6 versions are [...]
 2. Risk management - developing a new operating posture for a new [...]
 3. Renumbering - works about as well in IPv6 as in IPv4, which is to [...]
 4. Defense in depth is a core principle of all security, network and [...]
5.
 Feel free to refute all four points. No doubt you have arguments you
 personally find compelling. Your arguments will fall on deaf ears. At
 best the arguments propose theory that runs contrary to decades of
 many folks' experience. More likely the arguments are simply wrong.

--
-JH

Re: Requirements for IPv6 Firewalls

2014-04-18 Thread Peter Kristolaitis



On 4/18/2014 11:29 PM, Jeff Kell wrote:
Anyone ever pentested you? It's an enlightening experience. Jeff 


At a previous job, we hired a company (with CISSP-certified pentesters) 
to do a black box pentest of our network.


Things I was enlightened by:

- It's OK to work in a highly technical field with no technical 
background.  The pentester they sent couldn't get Backtrack running on 
the machine we had provided to him because the onboard video didn't 
support 32-bit color under Linux (IIRC, a P4-era Dell desktop).  The 
concept of reading log files to find out what was wrong was completely 
foreign to him, as was the required 1-line fix in the X11 config.


- It's OK to not report a horribly insecure box to the client if you're 
stupid or lazy.  We had set up a honeypot box on our network to see if 
the pentester would find it, and despite tons of log evidence showing 
that he both found the box and the weak services... no mention of it was 
made on the report submitted to us.  Needless to say, this made the 
entire report suspect, and my boss had great pleasure in yelling at the 
vendor when I brought it to her attention.


- It's OK to not know anything at all about the tools you're using to do 
the job.  The pentester called us because he was getting weird nmap 
results and couldn't grok them (and insisted that we had given him the 
wrong IP addresses).  The reason?  A firewall that dropped unwanted 
traffic.  Seriously.  CISSP certified and he couldn't figure out how to 
detect firewalls that have a default-drop policy.


- It's OK to rely only on automated tools and blindly trust their 
output.   No attempts at targeted attacks were made, despite being 
specifically asked and authorized to do destructive testing against our 
test servers.  We KNEW from our own testing that there were some SQL 
injection and buffer overflow holes there (again, some even placed on 
purpose to see what he'd find), and his automated tools didn't find them 
so he assumed everything was fine.


And that's just SOME of the stuff from that particular experience. 
Enlightening?  Yes.  I now do my own pentesting, because I'd rather not 
waste $20K+ on a report of questionable quality done by someone who may 
or may not know how to run nmap, let alone more technical 
application-level attacks.


There are undoubtedly some good pen-testers out there that are worth 
every dime they charge.  However, like every other technical speciality, 
there are a LOT of really, really, really terrible practitioners.
Shelling out big money to hopefully find the former in a field of mostly 
the latter is bound to be an exercise in both frustration and misspent 
resources.

RE: Requirements for IPv6 Firewalls

2014-04-17 Thread Dustin Jurman

Fernando,

I did not see:

- packets per second
- Firewall Level
- Hosts level
- packet size information
- Average for FW of all Network hosts
- Negotiated Between Hosts  

I apologize if I missed it.  

Dustin


Dustin Jurman
CEO
Rapid Systems Corporation 
1211 N. West Shore Blvd. Suite 711
Tampa, FL 33607
Ph: 813-232-4887
Cell: 813-892-7006 
http://www.rapidsys.com
Building Better Infrastructure  








-Original Message-
From: Fernando Gont [mailto:ferna...@gont.com.ar] 
Sent: Thursday, April 17, 2014 6:30 AM
To: NANOG
Subject: Requirements for IPv6 Firewalls




Folks,

A few months ago we published an IETF I-D with requirements for IPv6 firewalls.

Based on the feedback received since then, we've published a revision of the 
I-D:
http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-01.txt

If you have any feedback/thoughts, please do let us know (please CC c, such 
that all co-authors receive your feedback).

FWIW, this I-D is being discussed on the IETF opsec wg list (op...@ietf.org, 
https://www.ietf.org/mailman/listinfo/opsec).

Thanks!

Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 
84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Dobbins, Roland


On Apr 17, 2014, at 7:35 PM, Dustin Jurman dus...@rseng.net wrote:

 - packets per second
   - Firewall Level
   - Hosts level

This is getting into QoS territory . . .

 - packet size information

Concur - packet-length.

   - Average for FW of all Network hosts

This isn't very operationally useful, IMHO.

   - Negotiated Between Hosts  

I'm not sure what this means?

But classifiers for everything in the IP, TCP, UDP, and ICMP headers, along 
with packet length, makes a lot of sense.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread David Newman

On 4/17/14, 5:51 AM, Dobbins, Roland wrote:

 - packets per second
  - Firewall Level
  - Hosts level
 
 This is getting into QoS territory . . .
 
 - packet size information
 
 Concur - packet-length.

The use of RFC 2544-esque metrics for firewall performance testing
mostly benefits ill-informed or unscrupulous firewall marketeers, who
send 1500-byte UDP packets and then brag about excellent performance.

For firewalls handling TCP traffic, upper-layer traffic metrics such as
HTTP object size, concurrent connection capacity, and connection setup
rate are a lot more meaningful.

The RFC 2544/2889 approach is OK if you only ever use your firewall as a
router or a switch. The performance of a firewall used as an L2-L7
device should be measured with L2-L7 traffic.

dn

Re: Requirements for IPv6 Firewalls

On Thu, Apr 17, 2014 at 6:30 AM, Fernando Gont ferna...@gont.com.ar wrote:
 A few months ago we published an IETF I-D with requirements for IPv6
 firewalls.

 Based on the feedback received since then, we've published a revision of
 the I-D:
 http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-01.txt

Hi Fernando,

The feedback I would offer is this: You missed. By a lot.

For one thing, many of the requirements are vague, like REQ APP-20.
I've mitigated spam by allowing the operator to configure static
packet filters for the bad guy's netblock, right? Requirements must
be precise. Where you can't make it precise, drop it to a should.

And why is spam mitigation a firewall requirement in the first place?
Traditionally that's handled by a specialty appliance, largely because
it's such a moving target.

Also, I note your draft is entitled Requirements for IPv6 Enterprise
Firewalls. Frankly, no enterprise firewall will be taken seriously
without address-overloaded NAT. I realize that's a controversial
statement in the IPv6 world but until you get past it you're basically
wasting your time on a document which won't be useful to industry.

Take it back to the drawing board. You're not there yet.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Dobbins, Roland


On Apr 17, 2014, at 10:26 PM, David Newman dnew...@networktest.com wrote:

 For firewalls handling TCP traffic, upper-layer traffic metrics such as HTTP 
 object size, concurrent connection capacity, and connection setup rate are a 
 lot more meaningful.

I'm referring here to the ability to use packet-length as a classifier in a 
policy, not about bps/pps/tps/cps, et. al., apologies for being unclear.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Fernando Gont

Hi, David,

Thanks so much for your feedback! -- Comments in-line

On 04/17/2014 12:26 PM, David Newman wrote:
 
 The use of RFC 2544-esque metrics for firewall performance testing
 mostly benefits ill-informed or unscrupulous firewall marketeers, who
 send 1500-byte UDP packets and then brag about excellent performance.
 
 For firewalls handling TCP traffic, upper-layer traffic metrics such as
 HTTP object size, concurrent connection capacity, and connection setup
 rate are a lot more meaningful.
 
 The RFC 2544/2889 approach is OK if you only ever use your firewall as a
 router or a switch. The performance of a firewall used as an L2-L7
 device should be measured with L2-L7 traffic.

Are you referring to this text from our document?


REQ GEN-5:
   The firewall MUST include performance benchmarking documentation.
   Such documentation MUST include information that reflects firewall
   performance with respect to IPv6 packet, but also regarding how
   IPv6 traffic may affect the performance of IPv4 traffic.  The
   aforementioned documentation MUST be, at the very least,
   conditionally-compliant with both [RFC3511] and [RFC5180] (that
   is, it MUST support all MUST requirements in such documents, and
   may also support the SHOULD requirements in such documents).
 
  NOTE: This is for operators to spot be able to identify cases
  where a devices may under-perform in the presence of IPv6
  traffic (see e.g. [FW-Benchmark]).  XXX: This note may be
  removed before publication if deemed appropriate.


Because he RFCs we reference do require to make the measurements as you
describe...

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Fernando Gont

Hi, William!

Thanks so much for your feedback! One meta comment: this document is an
Internet-Draft, not an RFC. It's just the second version (-01) we have
published... so it's not meant to be there. The reason for posting the
I-D here was so that I could get your input as early in the production
of this document as possible.

Comments in-line

On 04/17/2014 12:51 PM, William Herrin wrote:
 
 The feedback I would offer is this: You missed. By a lot.
 
 For one thing, many of the requirements are vague, like REQ APP-20.
 I've mitigated spam by allowing the operator to configure static
 packet filters for the bad guy's netblock, right? Requirements must
 be precise. Where you can't make it precise, drop it to a should.

Ok, will expand REQ APP-20...



 And why is spam mitigation a firewall requirement in the first place?
 Traditionally that's handled by a specialty appliance, largely because
 it's such a moving target.
 
 Also, I note your draft is entitled Requirements for IPv6 Enterprise
 Firewalls. Frankly, no enterprise firewall will be taken seriously
 without address-overloaded NAT. 

Just double-checking: you're referring to NAT where the same address is
mployed for multiple hosts in the local network, and where the
transport-protocol port needs to be re-written by the NAT device?
(i.e., a NAT-PT)


 I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.

That's certainly controversial in the IPv6 world, but I have no problem
with that. This sort of input (even much better if more people weigh) in
is exactly what we're looking for. Such that when we apply the
corresponding changes, and folks from other circles complain about them,
I can point them to this sort of discussion.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Sander Steffann

Hi Bill,

 Also, I note your draft is entitled Requirements for IPv6 Enterprise
 Firewalls. Frankly, no enterprise firewall will be taken seriously
 without address-overloaded NAT. I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.

I disagree. While there certainly will be organisations that want such a 
'feature' it is certainly not a requirement for every (I hope most, but I might 
be optimistic) enterprises.

Cheers,
Sander

RE: Requirements for IPv6 Firewalls

2014-04-17 Thread Dustin Jurman

Always interesting responding to a NANOG thread.  

- the approach is from an end user than service provider. The firewall operator 
would be more interested in identifying PPS for attacks / compromised hosts VS 
QOS but I supposed it could be used for QOS as well.  (Not my intent) So today 
we have NAT'd firewalls that overload a particular interface, IMHO since 
properly implemented V6 should not use NAT I would want my FW vendor to allow 
me to see what's going on PPS wise via the dashboard function.  Most V4 
firewalls do this today at an interface level. 

- Average packet size for all hosts would allow operator to make a 
determination and set thresholds for new forms of attacks and exploits.  
(Thinking forward once applications take advantage of V6)  

- MTU Negotiated Between Hosts - Since this happens between endpoints in v6 
this could be help identify tunnels in the network / changes in WAN topology..  
Not like we haven't seen that before.  While a change in flight should create a 
drop.. when the session reestablishes it could resize.  

Dustin jurman
 

-Original Message-
From: Dobbins, Roland [mailto:rdobb...@arbor.net] 
Sent: Thursday, April 17, 2014 8:51 AM
To: NANOG
Subject: Re: Requirements for IPv6 Firewalls


On Apr 17, 2014, at 7:35 PM, Dustin Jurman dus...@rseng.net wrote:

 - packets per second
   - Firewall Level
   - Hosts level

This is getting into QoS territory . . .

 - packet size information

Concur - packet-length.

   - Average for FW of all Network hosts

This isn't very operationally useful, IMHO.

   - Negotiated Between Hosts  

I'm not sure what this means?

But classifiers for everything in the IP, TCP, UDP, and ICMP headers, along 
with packet length, makes a lot of sense.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Requirements for IPv6 Firewalls

On Thu, Apr 17, 2014 at 12:15 PM, Fernando Gont ferna...@gont.com.ar wrote:
 Thanks so much for your feedback! One meta comment: this document is an
 Internet-Draft, not an RFC. It's just the second version (-01) we have
 published... so it's not meant to be there.

Hi Fernando,

I apologize; my tone was out of line.


 On 04/17/2014 12:51 PM, William Herrin wrote:
 Also, I note your draft is entitled Requirements for IPv6 Enterprise
 Firewalls. Frankly, no enterprise firewall will be taken seriously
 without address-overloaded NAT.

 Just double-checking: you're referring to NAT where the same address is
 mployed for multiple hosts in the local network, and where the
 transport-protocol port needs to be re-written by the NAT device?
 (i.e., a NAT-PT)

Correct. The other NAT, the one described in RFC 1631, is rather unloved.


 I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.

 That's certainly controversial in the IPv6 world, but I have no problem
 with that. This sort of input (even much better if more people weigh) in
 is exactly what we're looking for. Such that when we apply the
 corresponding changes, and folks from other circles complain about them,
 I can point them to this sort of discussion.

Here's the drill: From an enterprise security perspective, deploying
IPv6 is high risk. I have to re-implement every rule I set on my IPv4
addresses all over again with my IPv6 addresses and hope I don't screw
it up in a way that lets an adversary wander right in. That risk is
compounded exponentially if the _initial_ deployment can't follow an
identical security posture to the IPv4 system. Without availability of
the kind of NAT present in the IPv4 deployment, I have a problem whose
solution is: sorry network team, return when the technology is mature.

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.

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Eugeniu Patrascu

On Thu, Apr 17, 2014 at 9:05 PM, William Herrin b...@herrin.us wrote:


 Here's the drill: From an enterprise security perspective, deploying
 IPv6 is high risk. I have to re-implement every rule I set on my IPv4
 addresses all over again with my IPv6 addresses and hope I don't screw
 it up in a way that lets an adversary wander right in. That risk is
 compounded exponentially if the _initial_ deployment can't follow an
 identical security posture to the IPv4 system. Without availability of
 the kind of NAT present in the IPv4 deployment, I have a problem whose
 solution is: sorry network team, return when the technology is mature.


It's a bigger risk to think that NAT somehow magically protects you against
stuff on the Internet.
Also, if your problem is that someone can screw up firewalls rules, then
you have bigger issue in your organization than IPv6.

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.

Eugeniu

Re: Requirements for IPv6 Firewalls

On Thu, Apr 17, 2014 at 2:32 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
 It's a bigger risk to think that NAT somehow magically protects you against
 stuff on the Internet.

You are entitled to your opinion and you are entitled to run your
network in accordance with your opinion.

To vendors who would sell me product, I would respectfully suggest
that attempts to forcefully educate me as to what I *should want*
offers neither a short nor particularly successful path to closing a
sale.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Valdis . Kletnieks

On Thu, 17 Apr 2014 14:50:01 -0400, William Herrin said:

 To vendors who would sell me product, I would respectfully suggest
 that attempts to forcefully educate me as to what I *should want*
 offers neither a short nor particularly successful path to closing a
 sale.

Which is why you reject vendors that forcefully cram IP down your throat
and insist on X.25 support as well, right?


pgpmxJ1Cle6UP.pgp
Description: PGP signature

Re: Requirements for IPv6 Firewalls

2014-04-17 Thread Timothy Morizot

On Apr 17, 2014 3:07 PM, valdis.kletni...@vt.edu wrote:

 On Thu, 17 Apr 2014 14:50:01 -0400, William Herrin said:

  To vendors who would sell me product, I would respectfully suggest
  that attempts to forcefully educate me as to what I *should want*
  offers neither a short nor particularly successful path to closing a
  sale.

 Which is why you reject vendors that forcefully cram IP down your throat
 and insist on X.25 support as well, right?

And speaking as the IPv6 transition lead at a large enterprise who has
already deployed IPv6 in our Internet connection points (including
firewalls) and made significant internal deployment progress, we would have
rejected out of hand any firewall vendor who tried to sell us some
proprietary, non-standard, IPv6 'NAT66' implementation. By its nature, it
would have lacked any meaningful comparative benchmarks, objective tests,
or any way to ensure a proper or secure implementation. At the IP level, we
want our perimeter products to conform to the standards.

Scott

Re: Requirements for IPv6 Firewalls