RE: FW: Request for BoF proposal.

["Sahita, Ravi" <ravi.sahita@intel.com>]

Hi Dinara,

Actually, I did request the bof before the deadline w/ the AD,
but Jeff had'nt replied to me, so I sent this email as a placeholder
I'm cc'ing Jeff so that he can chime in.

Ravi

-----Original Message-----
From: Dinara Suleymanova [mailto:dinaras@ietf.org] 
Sent: Wednesday, February 26, 2003 7:35 AM
To: Sahita, Ravi; iesg@ietf.org
Cc: Sahita, Ravi
Subject: Re: FW: Request for BoF proposal.


Ravi,

You had to have the AD approval for this BOF. We can not schedule your 
group without it.
And actually, the request came after the cut-off.

At 06:32 PM 2/25/03 -0800, Sahita, Ravi wrote:
>Hi,
>I had sent this request for a BoF to the security AD
>(Jeff Schiller) before the deadline, but have not
>heard back from him yet. Just sending in this request
>as a place holder.
>
>Ravi
>
>-----Original Message-----
>From: Sahita, Ravi
>Sent: Monday, February 24, 2003 11:05 PM
>To: Sahita, Ravi; 'Reinaldo Penno'; 'Angelos D. Keromytis'; 
>'jis@mit.edu'
>Cc: 'smb@research.att.com'; 'Sotiris Ioannidis'
>Subject: Request for BoF proposal.
>
>Jeff,
>
>I wanted to make a request to get a slot for a BoF session
>at the upcoming IETF meeting. The proposed charter is
>listed below. We have 3 drafts in existence today, and a public mailing 
>list at disfi@lists.intel.com (the subscription information is listed 
>below).
>
>Regards,
>Ravi
>
>Distributed/End-Point Firewall Control (DEFCon)
>
>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.