Subject: 56th IETF Meeting - Distributed/End-Point Firewall Control BOF (defcon)

From: [email-masked]
Date: Thu, 06 Mar 2003 12:09:29 -0500

Distributed/End-Point Firewall Control BOF (defcon)

Thursday, March 20 at 0900-1130
================================

CHAIR:  Ravi Sahita <[email-masked]> 
        Angelos Keromytis <[email-masked]>

Mailing Lists:
General Discussion: [email-masked] 
To Subscribe: send email to [email-masked] 
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.