Is there going to be a new revision of this draft? It appears the draft has expired. I didn’t see any response to the comments I made a few months ago.
Senthil From: Senthil Sivakumar <[email protected]<mailto:[email protected]>> Date: Friday, March 1, 2013 8:43 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [OPSAWG] Comments on draft-ietf-opsawg-firewalls-01 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
