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
<draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org>, such that all
co-authors receive your feedback).
FWIW, this I-D is being discussed on the IETF opsec wg list
(<opsec@ietf.org>, <https://www.ietf.org/mailman/listinfo/opsec>).
Thanks!
Best regards,
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"
- 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.
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 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
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.
Hi, David,
Thanks so much for your feedback! -- Comments in-line....
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,
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....
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,
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
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
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.
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
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
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
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
I've said my piece. Belittle it to your detriment.
-Bill
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.
- 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.
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