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

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: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Apr 18, 2014, at 1:04 AM, Dustin Jurman <dustin@rseng.net> wrote:

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

This is a telemetry function (separately, I noted IPFIX functionality should be included).

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

Again, this is a telemetry function, not a policy function.

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

Yet again, a telemetry function. The MTU negotiation itself is irrelevant; the resultant packet-size is relevant, from a classification point of view. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

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: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Thu, Apr 17, 2014 at 9:05 PM, William Herrin <bill@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

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?

On Thu, Apr 17, 2014 at 4:04 PM, <Valdis.Kletnieks@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?

I've said my piece. Belittle it to your detriment. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Thu, Apr 17, 2014 at 11:32 AM, Eugeniu Patrascu <eugen@imacandi.net>wrote:

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

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. 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. -- -george william herbert george.herbert@gmail.com

In message <53504C18.7050406@matthew.at>, Matthew Kaufman writes:

On 4/17/2014 1:45 PM, George Herbert wrote:

...

This is why listening to operators is important.

Why start now? After all, most of the useful input operators could have provided would have been much more useful at the beginning.

Matthew Kaufman

NAT from a firewall perspective is "default deny in". As far as I can tell no one is arguing that a firewall should not support that. Now mangling the addresses and ports is not a firewall's job. Its never has been a firewall's job. That is what a NAT box does. Now sometimes a NAT and Firewall are implemented in the same hardware and people fail to make the distinction. As for doing the same as v4 in a firewall for v6, only a idiot would do that, as it will often break IPv6. There are rules, often deployed in v4, that are mostly harmless to IPv4 but will totally break IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Thu, Apr 17, 2014 at 11:45 PM, George Herbert <george.herbert@gmail.com>wrote:

On Thu, Apr 17, 2014 at 11:32 AM, Eugeniu Patrascu <eugen@imacandi.net>wrote:

...

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

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.

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.

You treat IPv6 like the only protocol running and design the implementation taking that into consideration. Where necessary you publish AAAA records and so only devices/services that are IPv6 aware will be accessed over IPv6, all others can stay on IPv4 until they are migrated. It works wonderful. This idea of matching IPv4 1:1 to IPv6 is not the way to go.

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.

I don't get this paragraph. From my perspective, if you want IPv6 you can do it. From all the organizations I get in contact and ask about IPv6 is the lack of knowledge and interest that puts a stop to the deployment, nothing else. Eugeniu

On Apr 18, 2014 10:04 AM, "William Herrin" <bill@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!

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

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

On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault <simon@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault <simon@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Fri, Apr 18, 2014 at 2:32 PM, Simon Perreault <simon@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

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

On Apr 19, 2014, at 1:20 AM, William Herrin <bill@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Apr 19, 2014, at 9:04 AM, Jeff Kell <jeff-kell@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Apr 19, 2014, at 10:29 AM, Jeff Kell <jeff-kell@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On 19 Apr 2014, at 20:08, George William Herbert <george.herbert@gmail.com> wrote:

On Apr 18, 2014, at 9:10 PM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:

...

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,

I don't know where you find ideas like this.

From real world.

There are stateful firewalls in the security packages in front of all the internet facing servers in all the major service providers I've worked at. Not *just* stateful firewalls, but they're in there.

There’s no sense in putting stateful firewall in front of DNS server, unless the DNS server is underperforming, and then it should be exchanged and not protected by stateful firewall. You can try to protect mail/WWW servers with stateful firewalls, but it often achieves nothing but makes the firewalls weakest link in the setup. And tuning it to perform reasonably well in normal and peak traffic is usually not achievable. In case of DDoS attack, the stateful firewall goes out first. I’ve seen them burn too. To protect high-performance services, you do stateless filtering + NetFlow based QoS policies, or shunt to dedicated DDoS filtering boxes. Adding state where it’s not needed, is sign of bad design. And just because a lot of people do that, doesn’t make it any better. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net

On Apr 19, 2014, at 11:44 AM, Jimmy Hess <mysidia@gmail.com> wrote:

There is not widespread use of stateful firewall units with the stateful element as a single point of failure in front of large public web farms.

I have 20-30,000 counterexamples in mind that I worked with directly in the last decade. And "SPOF" is changing the goalposts; nobody single-strings anything at scale. -george william herbert george.herbert@gmail.com Sent from Kangphone

On Sun, Apr 20, 2014 at 4:27 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:

On Apr 20, 2014, at 2:32 AM, George William Herbert < george.herbert@gmail.com> wrote:

...

I have 20-30,000 counterexamples in mind that I worked with directly in the last decade.

People do stupid things all the time - but generally, it's hard to do them at scale.

Just go watch government at work :)

It seems to me you are saying we should get rid of firewalls and rely on applications network security. This is so utterly idiotic I must be misunderstanding something. There are a few things we can count on in life, death, taxes, and application developers leaving giant security holes in their applications. -----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Saturday, April 19, 2014 12:10 AM To: nanog@nanog.org Subject: Re: Requirements for IPv6 Firewalls 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.

On Tue, Apr 22, 2014 at 2:55 PM, Brian Johnson <bjohnson@drtel.com> wrote:

Eric,

If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that.

Roland's saying basically: 1) if you deploy something on 'the internet' you should secure that something 2) the securing of that 'thing' should NOT be be placing a stateful device between your users and the 'thing'. In a simple case of: "Put a web server on the internet" Roland's advice breaks down to: 1) deploy server 2) put acl on upstream router like: permit tcp any any eq 80 deny ip any any 3) profit The router + acl will process line-rate traffic without care. -chris

I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths.

- Brian

...

-----Original Message----- From: Eric Wieling [mailto:EWieling@nyigc.com] Sent: Tuesday, April 22, 2014 1:16 PM To: Dobbins, Roland; nanog@nanog.org Subject: RE: Requirements for IPv6 Firewalls

It seems to me you are saying we should get rid of firewalls and rely on applications network security.

This is so utterly idiotic I must be misunderstanding something. There are a few things we can count on in life, death, taxes, and application developers leaving giant security holes in their applications.

-----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Saturday, April 19, 2014 12:10 AM To: nanog@nanog.org Subject: Re: Requirements for IPv6 Firewalls

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.

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.

On Apr 20, 2014, at 8:52 PM, Seamus Ryan <s.ryan@uber.com.au> wrote:

Similarly if most of the time I just need to protect my relatively simple network by implementing a few separate zones I will get a firewall, im not going to deploy expensive stateless devices that can push a billion pps everywhere and send flow stats to expensive DDoS mitigation hardware *cough* arbor *cough* just so I can protect against an attack that many only happen a few times a year.

I'm talking about stateless ACLs on hardware-based routers and switches for enforcing network access policies - nothing to do with Arbor. Arbor doesn't make routers or switches. Stateful firewalls make servers far more vulnerable to DDoS (and to compromise, for that matter; they broaden the attack surface amazingly) than they would be without deploying stateful firewalls. Vendors of commercial DDoS mitigation solutions [full disclosure: I work for a vendor of such solutions] who wish to drum up business should be *encouraging* organizations to deploy stateful firewalls, not discouraging them from doing so. Anyone who knows me knows that I do *not* violate NANOG rules (or the rules of any other community list) by pushing commercial solutions. What I advocate is for folks to avoid spending extra money and time and effort in order to negatively impact their security posture, and instead utilize their existing investments in network infrastructure devices to enforce network access policies via stateless ACLs, as well as to deploy reaction/mitigation tools such as S/RTBH and flowspec. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Apr 20, 2014, at 10:15 PM, Seamus Ryan <s.ryan@uber.com.au> wrote:

It was more a friendly stab at the way DDoS mitigation providers push their products; stateless router + ddos appliance = problem solved, throw everything else out

<http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On 4/18/14 10:16 PM, "Matt Palmer" <mpalmer@hezmatt.org> wrote:

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

It's not clear whether those are alternatives or should all be employed. An auditor will tend to recommend all of them.

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.

"Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks." https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf Based on my experience with compliance auditors, they won't understand many of the words in this sentence, and will assume NAT and RFC1918. They can often (but not always) be taught, but you have to take the time to explain how IPv6 works, and how you prevent a reconnaissance attack. Many enterprise network administrators are not up to this task, unfortunately. ULA + NPT66 should be pretty easy to explain, both technically, and as a method of demonstrating compliance. However, preventing outbound route leaks of more-specifics, and blocking inbound recon attacks/probes *should* be equally compliant. Lee

On Sat, Apr 19, 2014 at 5:04 AM, Jeff Kell <jeff-kell@utc.edu> wrote:

On 4/18/2014 9:53 PM, Dobbins, Roland wrote:

...

On Apr 19, 2014, at 1:20 AM, William Herrin <bill@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?

1.3.8: Do not disclose private IP addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to: - Network Address Translation (NAT) - Placing servers containing cardholder data behind proxy servers/firewalls or content caches - Removal or filtering of route advertisements for private networks that employ registered addressing - Internal use of RFC1918 address space instead of registered addresses.

From what I see in the requirement it says "don't let people on the outside know that your webserver has 192.168.100.200 as an IP address", not that you should NAT everything.

Also if you are lucky enough to have lots of IPv4 addresses and assign them to all your servers/devices in your PCI compliant infrastructure this requirement (1.3.8) will not even apply to you. Eugeniu

On Sat, Apr 19, 2014 at 2:29 PM, joel jaeggli <joelja@bogus.com> wrote:

On 4/18/14, 7:04 PM, Jeff Kell wrote:

...

PCI requirement 1.3.8 pretty much requires RFC1918 addressing of the computers in scope...

It does not

You are correct. In theory. However, for those organizations that have chosen to use a firewall with NAT rather than apply one of the other alternatives, the practice says that to implement IPv6, the firewall they want needs to do NAT. Again, telling someone that they are doing it wrong (and that they should change) will not be successful. Especially if the network people do not talk to the systems people, and do not talk to the applications people, and do not talk to the auditors.... Not that any organization would be so stove-piped. Perhaps there should be a I-D BCP about not stove-piping organizations too. And, while PCI compliance was the straw-man, I have seen other audit results that called out a lack of using NAT too (even though they, also, should not have done so; it was the policy that they should have called out. But that would require real understanding rather than a checklist). Gary

* Simon Perreault:

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?

In the sense that they "MUST be able to provide email filtering features": yes.

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

The document has more than just base requirements.

On Fri, Apr 18, 2014 at 1:15 PM, Timothy Morizot <tmorizot@gmail.com> wrote:

On Apr 18, 2014 10:04 AM, "William Herrin" <bill@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On 4/18/14 4:33 PM, "George Herbert" <george.herbert@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

On Fri, Apr 18, 2014 at 3:02 PM, William Herrin <bill@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,

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 <eugen@imacandi.net> wrote:

...

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

On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu <eugen@imacandi.net> wrote:

...

On Thu, Apr 17, 2014 at 11:45 PM, George Herbert < george.herbert@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

On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu <eugen@imacandi.net> wrote:

On Fri, Apr 18, 2014 at 6:02 PM, William Herrin <bill@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

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 [...]

On Fri, Apr 18, 2014 at 10:02 AM, William Herrin <bill@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. 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

On Fri, Apr 18, 2014 at 6:36 PM, Lee Howard <Lee@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

From: George Herbert <george.herbert@gmail.com> Date: Friday, April 18, 2014 7:11 PM To: Lee Howard <Lee@asgard.org> Cc: Eugeniu Patrascu <eugen@imacandi.net>, "draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org" <draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org>, "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Requirements for IPv6 Firewalls

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.

What arrogance? I think I assert that IPv6 is time-consuming. There is no "deploy IPv6" button. fwiw, I do have enterprise network experience.

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.

Yes. Any publicly-traded company will have this because their auditors require it. I would think that companies without this documentation are probably not ready to deploy a new protocol. I concede that tracing the rules to the requirements is a hard one in practice (and a PITA in operational practice), but I don't think it's required to be able to map IPv4 rules to IPv6 rules.

Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE.

To clarify: are you asserting that IPv6 uptake in enterprises is slow, which is a sign of inertia, and the reason is that firewalls are poorly documented and therefore we must have IPv6 NAT? Maybe "lack of (perceived) business need" is the reason more enterprises don't have IPv6. Š

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.

I don't agree that things are failing. I would absolutely like to see enterprises adopt IPv6. Maybe at this stage enterprises with no firewall documentation are not good candidates for dual-stack. Those do seem to me to be the kind of clients who are likely to blame IPv6 for any problem, and insist it be turned off before any other troubleshooting. Lee

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

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. Matthew Kaufman (Sent from my iPhone)

On Apr 17, 2014, at 4:20 PM, Brandon Ross <bross@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-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross

To the Comcast v6 Team, Thank you for enabling my CMTS for v6 in Colchester, VT Works great! Thanks, -Mike Michael T. Voity Network Engineer University of Vermont

Please don't reply to a message on the list and change the subject line. Doing so causes your new topic to show "under" the previous one for those using mail readers that thread properly, and may cause your message to be missed altogether if someone has blocked that thread. Instead, save the list address and start a completely new message. hope this helps, Doug

I think I got you to say "NAT" Matthew Kaufman (Sent from my iPhone)

On Apr 17, 2014, at 7:05 PM, Timothy Morizot <tmorizot@gmail.com> wrote:

On Apr 17, 2014 7:52 PM, "Matthew Kaufman" <matthew@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.

If you're worried about that issue, either get your own end user assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix translation) at the perimeter. That's not even a hard question.

On 18-4-2014 8:57, Matt Palmer wrote:

On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote:

...

On Apr 17, 2014 7:52 PM, "Matthew Kaufman" <matthew@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.

If you're worried about that issue, either get your own end user assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix translation) at the perimeter. That's not even a hard question.

Why use NAT-PT in that instance? Since IPv6 interfaces are happy running with multiple addresses, the machines can have their publically-accessable address and also their ULA address, with internal services binding to (and referring to, via DNS, et al) the ULA address; when you change providers, the publically-accessable address changes (whoopee!), but the internal service address doesn't.

Sounds good in theory, I tried it but it got ugly really fast. Before you know it you have a layers of obfuscation, and even more work to get it to work right. That's really not a good argument for the general IPv6 case. Then there's the issue of making not just hosts do address selection but bringing that down to making applications choose address selection. As a admin I really don't want to go there. I just want a central point where I can pass, block or redirect. Just keep it as simple as possible, but not simpler. A host with a IPv4 and GLA IPv6 address is as complicated as you want it. The only case I see for NPt is for cheap multi wan where you have the primary prefix on your "LAN" and perform NPt for that prefix when it goes out the "3G" stick. Note that you would still need the same (delegated) prefix size on both connections (e.g. /64, /56 or /48) What is also nice is that in the case of NPt the firewall rules for both "WAN" and "3G" can be the same as the destination address (after performing NPt) is still the same. "Manageable". Kind regards, Seth

On 18/04/2014 01:51, Matthew Kaufman 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.

it's magic. There's no need to explain, silly! Nick

Hi, Brandon, On 04/17/2014 08:20 PM, Brandon Ross 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.

Are you argung against of e.g. "default-deny inbound traffic"? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Hi, On Thu, Apr 17, 2014 at 06:55:24PM +0200, Sander Steffann wrote:

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.

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". best Enno

Cheers, Sander

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

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

On 4/17/14 11:51 AM, "William Herrin" <bill@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