Distributed/End-Point Firewall Control BOF (defcon) Thursday, March 20 at 0900-1130 ================================ CHAIR: Ravi Sahita Angelos Keromytis Mailing Lists: General Discussion: disfi@lists.intel.com To Subscribe: send email to listserv@lists.intel.com In Body: subscribe disfi DEFCon Charter: Perimeter firewalls (pfws) are predominant but do not provide the protection against misuse or abuse from nodes inside the network. Pfws are a potential bottleneck when applying security rules for aggregated network traffic. Stateful protocols cause additional complexity for pfws. There is a need to open or partition parts of the network to allow or avoid interaction between specific users. Wireless infrastructures make every host vulnerable since here access is not fundamentally restricted by infrastructure. Traffic is increasingly being encrypted end-to-end hiding viruses/worms/confidential information from pfws. This either requires the pfw to become a proxy for secure sessions causing performance and security problems, or be rendered ineffective. The pfw approach breaks the e2e principle and thus renders many protocols useless since they are inevitably blocked network wide. Using end-point firewalls (epfws) network security rules can be specified with a finer granularity and control, to partition specific parts of the network. Rule specification can be made simpler by targeting end-points instead of aggregation points only at the perimeter. The epfw approach does not preclude the perimeter approach instead it adds to the security by introducing another perimeter at the end-point. The epfw framework also enables interesting network configurations without changes in the baseline security rules. The epfw approach upholds the e2e theme and can still try to keep the node (and the network) safe from compromise and attack. Epfws also have the following additional advantages due to being on the end-point instead of an intermediary: - An epfw may have access to traffic in the clear (after decryption). - An epfw may have access to varying levels of state information. - Typically, an epfw will have to deal with a smaller number of security rules (as compared to a pfw) - Epfws by definition can provide a defense for wired and wireless nodes to attacks from inside or when roaming outside the network perimeter. The working group will tackle the following work items: - A problem statement document for DEFCon. - An applicability statement for the DEFCon framework. - An architectural requirements document for the components in the framework. This document will cover the following topic regarding components, protocol and language: - Security (mutual authentication of control-points and end-points, integrity and confidentiality of rules and other pre-configuration issues) - Distributed versus Central control approaches and example deployment scenarios. - Scalability Considerations (potentially large number of epfws) - Co-ordination of epfw control-points and end-points with other security devices - Co-existence of non-DEFCon nodes in a DEFCon framework and co-existence of DEFCon nodes not-conforming to the DEFCon framework. - Using and leveraging trusted platforms when available. - Topology independent rule specification, translation and distribution. Handling rule conflicts. - Extensible Text Based Data Model requirements. - Interface and functionality compliance requirements of components. - DEFCon Protocol requirements. - Considerations for various end-point platforms with varying levels of firewalling capabilities, processing capabilities, virtual machine software support etc. - Informational documents as necessary to describe current approaches for this area and examples of how the framework may be implemented. - Extensible Text Based Data model for endpoint firewall rules language and associated semantics - DEFCon Protocol and associated semantics. Security requirements are an important facet of all the documents since the idea behind using epfws is to enhance security. Also, Protocol and data model/language requirements will ideally lead to choosing or extending if possible, already existing work. A new protocol and/or data model/ language will be designed only if none is found suitable. The working group will not define: -Requirements that dictate how a particular function is implemented. For example, a function may be implemented in hardware or software as long as it meets the interface and functional requirements as specified in the architecture requirements documents. -Protocols to communicate requests between applications and pfws and other middle boxes since that area is being investigated by MidCom. The group will co-ordinate with other relevant working groups to extend or reuse applicable work. Proposed Goals and Milestones for Working Group: April 03 - Submit I-D for DEFCon problem statement to IESG for Informational RFC publication. May 03 - Submit I-D for DEFCon applicability statement for Informational RFC publication. June 03 - Submit I-D DEFCon architecture requirements to IESG for Informational RFC publication. August 03 - Submit I-D DEFCon Extensible Text Based Data Model. /Rule Language to IESG for Standard RFC publication. August 03 - Submit I-D DEFCon Protocol specification to IESG for Standard RFC publication.