Re: FW: Request for BoF proposal.

[Randy Bush <randy@psg.com>]

put me as sponsoring area director, please.

avoid conflicts for me and for smb, please.

and i know you did not need this at the last minute, so i owe you
one.

randy

> 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.
> 
> 
>