At a very high level, it is not clear what this document is set out to achieve
and what it really delivers.
Particularly section 2, I really cant tell what value that this section adds.
The document says it is a BCP, so should it have a set of requirements from a
firewall vendor and operator to be effective.
Without a set of requirements, this looks more like an informational document
than a BCP.
Specific comments below:
Section 1:
I would add the following about the generic nature of firewalls.
"Firewalls generally operate under the notion of trusted and untrusted network
domains.
For example, an enterprise that employs the firewall will be considered a
trusted domain.
Flows that are originated from the trusted domain is considered as untrusted.
The packets are filtered using static and dynamic policies as defined or
learned "
Nit:
An application-layer gateway (ALG) in front of a server creates a
perimeter between that server and the network it is connected to.
The ALG blocks some of the flows in the application protocol based
on policies such as "do not all traffic from this network" and "do
not allow the client to send a message of this type".
s/do not all/do not allow/
Layer 4: Most firewalls can filter based on TCP and UDP ports.
Many (but, frustratingly, not all) firewalls can also filter based
on transports other than TCP and UDP.
- Most L4 firewalls filter packets based on TCP sequence and ack numbers. This
essentially makes
the firewall a single point of failure and hence preventing asymmetric routing.
- Firewalls handle out of order fragments and in some cases reassembling the
fragments to be able to inspect the
L7 payload.
- When a firewall suspects an attack, it sends a reset to both ends to clean up
the connection. I personally don’t like that, but firewalls spoof these resets.
"Note that many firewall devices can only create policies at one or two of the
layers."
Can you please add some text on why that is the case or basis for the above.
Section 3.2:
The section introduces the outside and inside terminology without defining what
they are.
A terminology section may be necessary or some context of what outside and
inside are.
I would rather prefer trusted and untrusted instead of inside and outside,
respectively.
Section 4.
I would highlight the inability of firewall to do Deep Packet Inspection on
encrypted traffic and hence
Firewalls that look deep into the payload to make decisions are ineffective.
There are a lot of firewall capabilities that are useful to the operators like:
- Syn attacks can be avoided
Tiny fragment attacks
Should have logs turned on for major events.
Section 5
I think it is pretty useful to require the firewall vendors to align the
timeouts between NAT & Firewall, as they are deployed together.
Similarly a device that has both NAT & firewall should work in tandem when the
ALGs are deployed otherwise the applications wont work.
This can be in the section 4 too, as it requires the operators to understand
that these ALGs should be enabled for both NAT & Firewall.
Provide firewall logging facility of suspected attacks.
I don’t believe there is a standard firewall MIB, but that would be a useful
one to suggest too.
Firewalls do handle fragmented traffic and deal with out of order fragments.
It seems both sections 4 & 5 need some focused text on what the requirements
are from a vendor and from an operator.
Appendix A:
Their security is a side-effect of their design. [[[ MORE HERE about
the history and why some operators mistake the security policy of
NATs with firewalls. ]]]
I would suggest the following text for appendix A:
"Many NAT devices implement End-point dependent mapping [as defined in RFC
4787] and as a result,
only the flows that are originated from a trusted or inside domain, will result
in a NAT mapping creation. This mapping
Will have the destination address & port information, unless the return traffic
comes from the same destination address & port,
NAT will drop the packet. This is not because of a security policy but since
NAT's mapping database cannot find a matching entry.
This gives an illusion that NAT is a security feature by disallowing traffic
that was originated from outside.
For traffic originated from the untrusted domain, the NATs most likely wont
have a matching mapping entry to allow the traffic through and
hence the traffic is dropped."
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
