Distributed/End-Point Firewall Control BOF (defcon)
Thursday, March 20 at 0900-1130
================================
CHAIR: Ravi Sahita <ravi.sahita@intel.com>
Angelos Keromytis <angelos@cs.columbia.edu>
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.
