One document matched: draft-sahita-defcon-reqs-00.txt
Network Working Group Ravi Sahita
Internet Draft Priya Govindarajan
Category: Standards Track Intel Corp.
Expires August 22, 2003
Distributed/End-Point Firewall Control (DEFCon) Requirements
draft-sahita-defcon-reqs-00.txt
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the requirements for the architecture and a
distributed framework for end-point firewall control (DEFCon). This
draft also discusses requirements for the individual pieces in the
framework.
Perimeter firewalls are predominant in enterprise networks but do
not provide the protection a mission critical network needs against
misuse or abuse from nodes inside the network. Additionally, A
wireless infrastructure makes every host vulnerable since in that
case access is not fundamentally restricted by infrastructure.
Likewise, traffic is increasingly being encrypted end-to-end using
SSL, IPSec, etc. where viruses/worms/confidential information can
also be hidden from the security components. This requires the
perimeter firewall to become a man-in-the-middle for all secure
sessions, which breaks the end-to-end principle and thus renders
many protocols useless since they are inevitably blocked.
A host-based firewall on nodes in the enterprise network protects
the network from inside out. This approach does not preclude
perimeter firewalls. Instead, it provides defense-in-depth and
reduces the load on perimeter firewalls. The host-based approach
also upholds the end-to-end theme since it allows traffic to be
securely encrypted end-to-end and yet assures safety from
infection, compromise and attack.
1. Introduction
Perimeter firewalls are software or hardware entities applying
various forms of ACLs to network traffic exiting or entering a
controlled network. These transit nodes tend to be a bottleneck due
to amount of traffic they handle. Also, traffic that is internal to
the network does not touch the transit nodes. These firewalls have
no control over this traffic. State based protocols that use random
ports for data transfer after the control messages are exchanged
also cause perimeter firewalls to be additionally complicated and
require extensive state keeping. As e-commerce transactions become
cost-effective and prevalent, there is a need to open parts of the
enterprise network to customers and/or suppliers, this dictates an
[Page 1]
DEFCon Requirements February 2003
additional layer of complexity. End-to-End encryption of traffic is
affected due to the perimeter firewalls having to proxy the secure
connections.
This document describes the requirements for DEFCon and the various
elements that constitute the framework. Using this approach, the
security policies can be defined in a flexible but secure way to be
corporate wide as well as tailored to specific sections of the
network. Business relationships can be translated to dynamic rules
installed possibly as a overlay, without change in the baseline
security rules of other nodes.
In this document, Section 2 describes the terms used in this
document and other related documents. Section 3 defines the overall
architectural requirements of a DEFCon based network. Section 4
discusses the requirements for the components in the framework.
Section 5 describes the expected typical operational of the DEFCon
framework. Section 7 outlines security requirements for the DEFCon
framework.
2. Terminology
The following terms are defined for use in this requirements draft
and other related drafts.
2.1. DEFCon rule
A set of fields that are used to classify the application traffic
entering or exiting a DEFCon based host. [2] defines this as, a set
of terms and/or criteria used for the purpose of separating or
categorizing. This is accomplished via single-or multi-field
matching of traffic header and/or payload data. Rules have
associated actions. On a rule match, corresponding actions are
taken on the traffic.
2.2. DEFCon action
A set of possible actions that can be taken on a packet after it
has been classified. [2] defines action as, definition of what is
to be done to enforce a policy rule, when the conditions of the
rule are met. Policy actions may result in the execution of one or
more operations to affect and/or configure network traffic and
network resources.
2.3. Firewall
A software or hardware entity that applies a set of access control
rules to network traffic.
2.4. End-Point Firewall
A firewall on an end-point (client or server) in an administrative
domain of a network that applies security policies to network
traffic entering or exiting that end-point.
2.5. DEFCon control-point
An OA&M (operations, administration and management) function that
allows administrators to setup firewall rules for firewalls on
network end-points. This function also receives state information
[Page 2]
DEFCon Requirements February 2003
from the end-point firewalls under its control. Multiple such
control points may exist for scalability reasons.
2.6 Alert/Audit server
A service in the DEFCon framework that receives audit or alert
information from authenticated end-points. This service may
summarize this information and present it to one or more control
points to take action.
2.7. DEFCon end-point
A component in the DEFCon framework that is controlled by the
DEFCon control point. This component receives the access control
rules from such a control-point. This component also reports state
to the control point that it is associated with or a preconfigured
alert/audit server.
2.8. DEFCon protocol
Data structures that are used to communicate messages between a
DEFCon end-point and a DEFCon control-point.
2.9. DEFCon or Distributed/End-Point Firewall CONtrol
A framework for Distributed/End-point Firewall CONtrol. This
framework includes multiple end-points, possibly in different
domains within an overall administrative domain, controlled by an
administrative control-point in the same network. This framework
also defines the protocols used for communication between the
control-point and the end-point firewalls. It also enforces the
security requirements to meet the overall requirements.
2.10. DEFCon association
The process by which a DEFCon end-point associates with a DEFCon
control-point.
2.11. DEFCon enrollment
The process by which a DEFCon end-point registers with the domain
to which it belongs. This decoupled registration should enable end-
points to be associated with control-points.
2.12. DEFCon rule conflict resolution
The process by which a DEFCon end-point detects rule conflicts due
to incorrect or overlapping specification of rules.
2.13. DEFCon rule validation
The process by which a DEFCon control-point validates the set of
rules on the end-point firewalls under its control. This capability
can be used to check network rule compliance.
2.14. DEFCon feedback
The process by which a DEFCon control-point recognizes events from
other control-points or from the end-point firewalls under its
control and applies state changes to a set of end-point firewalls
or communicates the state information to another control-point to
take action.
[Page 3]
DEFCon Requirements February 2003
3. DEFCon Architecture Requirements
3.1 High level architecture
+--------------------------------+
| |
| DEFCon end-point |
| |
| +--------------------------+ |
| | OS application component | |
| | | |
| +--------------------------+ |
| / \ | |
| | \ / |
| +----------------------------+ |
| | NIC Driver | |
| | +----------------------+ | |
| | | Local Rules | | |
| | +----------------------+ | |
| +----------------------------+ |
| / \ | |
| | | |
| +----|---------------|-------+ |
| | | NIC \ / | |
| | +----------------------+ | |
| | | Remote Rules | | |
| | +----------------------+ | | +------------------------+
| | / \ | | | | DEFCon control-point |
| | | | | | | |
| | +--|--+ +-\ /--+ | | | +------------------+ |
| | | | | | | | | | control-point | |
| | | Rx | | Tx | | | | | | |
| | +-----+ +------+ | | | +------------------+ |
| +----------------------------+ | | |
+--------------/ \---------------+ +---------/ \------------+
| | | |
---------------\ /-------------------------------\ /-------------
Network
Figure 1: High level view of the DEFCon architecture
There are multiple end-points in a network. The DEFCon architecture
hence consists of multiple end-point firewalls. These end-point
firewalls must be controlled by an administrative control-point.
The communication between the remote control-point and the end-
point firewall must be authenticated, should be encrypted and must
have integrity control. An assumption is that the group of end-
point firewalls associated with a control-point belongs to some
logical group in the network. This logical group may be a VLAN, a
subnet or some other ad-hoc group established via other mechanisms.
The association of an end-point firewall with a control-point must
be done securely via deterministic rules defined in the protocol
requirements section.
To achieve a scalable architecture, a control-point must also be
capable of controlling another control-point lower in hierarchy.
With this capability a high level security operations center could
control a set of remote control-points that in turn control the
end-point firewalls in their domain. This approach breaks up the
manageability of large domains into smaller problems. However, this
approach has additional security implications. The communication
[Page 4]
DEFCon Requirements February 2003
protocol used MUST account for secure communication between a
master control-point and a slave control-point. The association of
a slave control-point with a master control-point must be done
securely via deterministic rules defined in the protocol
requirements section.
Another way to achieve a scalable architecture is to have a
directory based or publisher-subscriber architecture. In this case,
a control-point must be capable of securely talking to authorized
directory services for the domain. The end-points would be setup to
receive security rules from the directory service that they come
under by way of where they connect to the network.
On the end-point side, the firewall may be designed as an embedded
component, a local component or a combination. The local component
is typically under the control of a local application. Parts of the
embedded component may be de-coupled from the operating system for
added security [5]. An authorized local application should be able
to query the end-point using a standard interface using the same
underlying mechanisms that the remote control-point would use.
3.2. Architecture Component Requirements
This section explains the component requirements of the decoupled
DEFCon end-point and control-point so that multiple deployment
scenarios can be achieved. It covers only the functional aspects of
the sub-components. The security requirements are covered in a
separate section.
+------------------------------------------------------------+
| Control-point internal components |
+------------------------------------------------------------+
| Scriptable translation layer |
|------------------------------------------------------------|
| DEFCon Extensible Text Based Data Model |
|------------------------------------------------------------|
| RPC abstraction layer | OOB | DB |
|--------------------------------------------| Config | i/f |
| Other | Directory | Alert/ | InterCP |i/f | |
| RPC i/f | RPC i/f | Acct i/f | i/f | | |
+--- ^------+------^-----+------^---+----^---+----^----+--^--+
| | | | | |
<----+ <-------+ --------+ <---+ +----> +-->
Rules/ Rules/ Alerts/ Control OOB/Cfg DB
Status Status Acct Point State
Figure 2: Decoupled DEFCon Control-point sub-components
The control-point exposes interfaces to provide services to the
DEFCon end-point and other DEFCon control-points.
- An rpc interface is used to send rules to an end-point or to
receive rules from another control-point. RPC operations should be
abstracted out via an interface and should map to various rpc
mechanisms for example an interface to a directory service, or some
other protocol.
- An alert/accounting interface is shown to allow separate
accounting or alert collection via a different channel.
[Page 5]
DEFCon Requirements February 2003
- An Out of band (OOB) configuration interface is envisioned for
security setup, association (see terminology), discovery setup or
even manual configuration. The control-point interface is to enroll
as a controlled node with another control-point.
- The db interface allows interfacing the control-point to a
database to store historic information. The database could also be
used to store control-point user accounts or other related data.
- The DEFCon Extensible Text Based Data Model shown above models
the data exchanged by the interfaces, i.e., rules/policies, alerts
and auditing information.
- The Scriptable translation layer can be used to map the data
model to various presentation methods for the end-point or for the
control-point.
- The internal components of the control-point may be logical
components responsible for mapping rules to end-points, console
components, components responsible for correlating alerts/auditing
information.
Rules/ Alerts/ OOB Config/
Rules Status Acct State
<----+ <--------+ <------+ <-----+
| | | |
+--- \/-----+------\/----+---|-----+----\/---+
| Other | Directory | Alert/ | |
| RPC i/f | RPC i/f | Acct i/f| OOB |
|----------------------------------| Config |
| RPC abstraction layer | i/f |
+--------------------------------------------+
| End-point daemon |
|--------------------------------------------|
| DEFCon Extensible Text based Data Model |
|--------------------------------------------|
| Scriptable translation layer |
|--------------------------------------------|
| End-point internal components |
+--------------------------------------------+
Figure 3: Decoupled DEFCon end-point sub-components
The end-point exposes interfaces to provide services to the DEFCon
control-point and access services on DEFCon control-points.
- The rpc operation interfaces is used by the end point to interact
with a DEFCon control-point.
- The end-point daemon shown on the end-point allows a lightweight
control-point to contact it and query it (remotely or locally using
same underlying mechanisms).
- A separate interface is shown for alerts and/or accounting
information.
- An Out of band (OOB) configuration interface is envisioned for
security setup, association and other possibly manual
configuration.
[Page 6]
DEFCon Requirements February 2003
- The DEFCon Extensible Text Based Data Model shown above models
the data exchanged by the interfaces, i.e., rules/policies, alerts
and auditing information.
- The Scriptable translation layer can be used to map the data
model to the implementation methods at the end-point.
- The internal components of the end-point may be logical
components responsible for enforcing the rules, for example, packet
classifier module, encryption/decryption module, connection
tracking module etc.
3.3 Example Deployment Scenarios
This section presents example deployment scenarios of the DEFCon
framework and covers only the functional aspects. The security
requirements are covered in a separate section. Note that these are
example deployment scenarios and are not mandated. The DEFCon end-
point and control-point are de-coupled to allow various deployment
scenarios.
3.3.1. Scenario A: Hierarchical deployment
- Whenever a DEFCon end-point is to be introduced into the network,
it is manually or using an enrollment procedure configured with
security keys created using OOB configuration interfaces and the
control-point's hostname and certificate. The control-point stores
the end-point's unique identifier (MAC address or some other id),
the associated keys and other required pre-configuration. This
information should be kept confidential.
- Once the end-points are connected to the network, they obtain the
domain DEFCon control control-points IP address using DNS (assuming
the DNS is not compromised), and using the pre-configured keys
associates with the control-point using the rpc interface. During
association the end-point may provide the control-point with
dynamic run time information (for example, what random port the
end-points local daemon will listen on for some time period)
- The control-point in turn may be registered with another control-
point thus creating a hierarchy of control-points using the Inter
Control-point interface.
- The Control-point can now contact the end-point's local daemon
whenever it needs to push rule updates to the end-point using the
rpc interface. Before rules are sent down to the end-point, it must
verify the identity of the control-point using its pre-
configuration information (performed earlier). Once this is done,
the end-point should acknowledge the connection. The DEFcon
control-point optionally can query the state of the DEFCon end-
point platform (Need separate section/draft on verifying integrity
of end-point for DEFCon). If rules could not be deployed in a
complete transaction, there should be failsafe policies in place
that will cause the end-point to be able to rollback or to not be
able to communicate.
- The end-point can send alerts or accounting information using the
Alerts interface to the control-point it is connected to or to a
central pre-configured site for alerts.
[Page 7]
DEFCon Requirements February 2003
- In this model, due to the possible large number of end-points, a
persistent connection is not maintained between the control-point
and end-point. However, if required such a persistent connection
can be maintained.
- Any change in control-point installed rules must be reported
using the alert interface. The control-point must periodically
connect to the end-point and verify the state of end-points that it
is handling and if any inconsistency is found - be able to install
high priority rules to block the end-point to protect the network.
- When a DEFCon end-point is shutting down, it sends an unsolicited
message to the control-point it is associated with to signal a
disassociation. It may even send an audit message to an auditing
server.
3.3.2. Scenario B: Directory service based deployment
- The DEFCon control-point, once connected to the directory service
securely, can define security rules for abstract groups / roles /
users in a policy directory service.
- When DEFCon end-points are introduced to the network, they obtain
the domain directory service information using DHCP (assuming it is
not compromised), and after exchanging authenticating information
with the directory service can get security rules using the
directory interface.
- The control-point can check the status on the directory service
for specific groups to see if the rules were successfully deployed
or can setup change notification mechanisms (if available). If
rules could not be deployed during registration in a complete
transaction, there should be failsafe policies in place that will
cause the end-point to not be able to communicate.
- The control-point can now push rule changes to the directory
service using the directory interface, which will get applied when
the end-point either registers the next time or immediately if
change notification is available. The end-point can send alerts or
accounting information using the Alerts interface to a pre-
configured site for alert collection and correlation. Any change in
control-point installed rules must be reported to the alert server.
- When a DEFCon end-point is shutting down, it un-registers with
the directory service and group that it belongs to. It may even
send an audit message to an auditing server.
3.3.3. Scenario C: Standalone deployment (remote or local)
- In this case, the administrator may have knowledge of the DEFCon
end-points running in the network, or may try to discover the
assigned IP addresses via some other mechanism or may be local on
the machine where the end-point is running.
- Also, another assumption is that, when a DEFCon end-point is to
be introduced into the network, it is manually or though an
enrollment process, configured by administrators with keys created
using an OOB configuration interfaces and the control-point's
hostname/IP and certificate. The control-point stores the end-
point's unique identifier (MAC address or some other id), the
[Page 8]
DEFCon Requirements February 2003
associated unique keys and other required pre-configuration (for
example what random port the end-point daemon is listening on).
- The DEFCon control-point attempts to contact the DEFcon end-
point's local daemon registered with it using the configured
information using the rpc interface. Note that the end-point never
initiates the connection to the control-point. Like in Scenario A,
before rules are sent down to the end-point the end-point must
verify the identity of the control-point using its pre-
configuration (performed earlier).
- Once the control-point is connected to the end-point's local
daemon, it can get the current rule configuration of the end-point.
Using the rpc interface the control-point can push rules to the
end-point. The DEFcon control-point optionally can also query the
state of the DEFCon end-point and the platform it is running on.
- The end-point can send alerts or accounting information using the
Alerts interface to the control-point it is connected to or to a
pre-configured site for alerts.
- When the DEFCon control-point is done querying the end-point for
the security audit, it must send an unsolicited message to the end-
point using the rpc interface to signal a teardown of the session.
3.3.4. Comparison of models
Hierarchical model
+ Scalable (by hierarchy)
+ Tightly closed loop
+ Transactional
- Complex security requirements
- Harder deployment (new system)
- vendor lock-in
- Difficult to debug
Directory Based model
+ Scalable (control & end point operation in parallel)
+ Easier incremental deployment (admin zones)
+/- Queries for globally interesting, relatively static,
structured info
+ Attribute level security
- Change notification may not be available
- Transactions may not be available
- writes are slow
De-coupled components based architecture
+ Can use existing technologies for incremental deployment
+ Allows per-device query as the simplest model
+ Allows building of both of the above models
- Models cannot be mixed
4.1. Component Requirements
4.1.1. DEFCon protocol functional requirements
4.1.1.1 The protocol state machine for the end-point must be
isolated such that the local driver/applications cannot access the
protocol state machine or any data received by the protocol state
machine.
[Page 9]
DEFCon Requirements February 2003
This ensures that the firewall rules of the domain are not visible
to the local users of the host. Also, this ensures that the rules
are not blocked from deployment in any way.
4.1.1.2 After a cold start, the protocol must allow for the DEFCon
end-point to be associated with the control-point for the domain
(or subnet) it belongs to via a secure mechanism.
4.1.1.3 The discovery mechanism in the protocol MUST be secure so
that a rogue control-point cannot get a DEFCon end-point under its
control. On the other hand, a rogue DEFCon end-point MUST not be
able to connect to the control-point.
4.1.1.4 Due to any failure if the DEFCon end-point looses
connectivity with the control-point it is associated with, the
system should fail safely and disable traffic from entering or
leaving the end-point, except from the control-point.
4.1.1.5 Network traffic MUST NOT be allowed to pass through the
DEFCon end-point until it is associated successfully with a
control-point in the domain.
4.1.1.6 The transport between the DEFCon end-point and a control-
point must be reliable and connection-oriented so that interaction
between the DEFCon end-point and the control-point is
transactional. This connection need not be persisted.
4.1.1.7 The DEFCon end-point MUST be connected to only one control-
point at any given time.
4.1.1.8 The protocol MUST allow the control-point to be connected
to multiple DEFCon end-points.
4.1.1.9 The DEFCon end-point and the domain control-point MUST
exchange regular heartbeat messages securely to ensure that
connectivity (with the correct entities) is maintained.
4.1.1.10 The security mechanism used for communication should be
self-updating so that sampling based attacks over time can be
defeated. However the security mechanism should not be so
computationally intensive such that it becomes a mechanism for a
DoS attack.
4.1.1.11 All data exchanged over the protocol should be
authenticated.
4.1.1.12 All data exchanged over the protocol should be encrypted.
[Page 10]
DEFCon Requirements February 2003
4.1.1.13 All data exchanged over the protocol should be checked for
integrity.
4.1.1.14 The data exchanged over the protocol should be based on an
extensible and independent data model. No protocol operations
should be expressed in data.
4.1.1.15 The control-point MUST be able to push rules and rule
updates to the DEFCon end-point.
4.1.1.16 The DEFCon end-point must report the status of all
operations performed by the control-point via a message.
4.1.1.17 The protocol MUST allow a control-point to renew operation
with a stable state in the case of power loss or other failure on
the end-point or the control-point.
4.1.1.18 The protocol MUST ensure that the rules pushed to the
DEFCon end-points in a message are transaction oriented, and hence
are applied fully or an error is reported.
4.1.1.19 The control-point MUST be able to query any DEFCon end-
point for its current state and configuration.
4.1.1.20 The DEFCon end-point must be able to report its state
changes or events to the control-point in an unsolicited manner.
4.1.1.21 Once a session is established, the protocol MUST only
enable the control-point to break the connection, the DEFCon end-
point MUST not be able to close the connection via the protocol.
Note that the DEFCon end-point may be physically disconnected which
may cause the connection to be abruptly broken.
4.1.1.22 The protocol must have version identification to account
for updates to the standard for interoperability.
4.1.1.23 The protocol must be able to carry rule-sets describing
traffic filters based on header fields and generic patterns to be
looked for in traffic.
4.1.1.24 The protocol must be able to specify for which direction
of traffic the rules are applied at.
4.1.1.25 The protocol must be able to operate in different modes.
I.e., between a DEFCon end-point and a control-point and between a
control-point and another control-point (for example a Security
Operations Center or SOC communicating with a control-point). This
is to build scalability into the system.
[Page 11]
DEFCon Requirements February 2003
4.1.1.26 The protocol must include mechanisms to mitigate replay
attacks on control messages.
4.1.1.27 Rule conflicts MUST not be handled by the protocol. These
are dependent on the data (rules) that is pushed from the control-
point and should be handled by the control-point logic. In cases
where such conflicts can only be detected by the end-point
appropriate errors should be reported.
4.1.1.28 The DEFCon protocol should be light weight so that it can
be implemented in embedded devices if required.
4.1.1.29 From a management perspective, the DEFCon protocol should
be simple to integrate into an application and deploy. This will
ensure low administrative overhead and fewer chances of bugs in
implementation.
4.1.1.30 The protocol should be designed for extensibility, so that
future enhancements to the data model can be carried without any
protocol changes.
4.1.2. Interface Requirements
Operational interface:
Open End-point: DEFCon control-point --> DEFCon end-point
Query Capability: DEFCon control-point --> DEFCon end-point
Install Rules: DEFCon control-point --> DEFCon end-point
Update Rules: DEFCon control-point --> DEFCon end-point
Remove Rules: DEFCon control-point --> DEFCon end-point
Shutdown End-point: DEFCon control-point --> DEFCon end-point
<TBD>
Alert/Acct Interface:
Alert Control-point: DEFCon end-point --> DEFCon/Alert control-
point
<TBD>
OOB Configuration Interface
Verify End-point: DEFCon control-point --> DEFCon end-point
<TBD>
4.2. DEFCon end-point requirements
Typically, a DEFCon end-point will be instantiated at end-hosts or
end-host NICs under the domain administration - called "controlled"
[Page 12]
DEFCon Requirements February 2003
end-points. In some cases though, end-hosts may not be under
network administrative control. For example, a guest mobile node.
Hence, a DEFCon end-point can be instantiated at:
- A controlled end-point.
- On ports of LAN switches to handle guest end-points.
A DEFCon end-point should implement the following features at a
high level:
- Stateless filtering of packets based on layer 2,3,4 headers
- Stateless filtering of packets based on layer 7 content
- Stateful filtering of protocols using header and payload data
- Couple Application level information to security policies. Use
local state information available to the end-point, such as:
- File signatures, version numbers and patch information
- Network information that is available locally - for example
DNS server address, proxy servers, Bump in the wire
Appliance addresses etc.
- Ability to condition traffic leaving the end-point.
- Platform security parameters when available
- Platform user information, for example, User ID, credentials
- Local services like Virus scanners, event logs, host
intrusion detection engines.
- Mobile-IP state information on mobile nodes
- The DEFcon end-point should support the framework to
offload/perform tasks using trusted software/hardware components.
For example:
- Host intrusion detection
- Virus scanning
- User authentication
- Deep packet inspection
- Encryption/decryption
- MAC/stateless header filtering
- A DEFCon end-point should be able to support virtual machine
software which create multiple virtual end-points on a platform.
- A DEFCon end-point should be able to support multiple disjoint
configurations so that it is possible to switch configurations
efficiently.
- The end-point should be able to receive an entire configuration
and apply it in an atomic fashion.
<TBD>
4.3. DEFcon Language requirements
[Page 13]
DEFCon Requirements February 2003
The DEFcon data model should support the following requirements:
4.3.1. Data Types
- Support following data types:
- 16 bit integers (signed, unsigned)
- 32 bit integers (signed, unsigned)
- 64 bit integers (signed, unsigned)
- 8 bit value (byte or unsigned char)
- Arrays of above types
- Ability to define constants
4.3.2. Stateless filtering
- Support basic protocol header field based classification. This is
the traditional ACL based packet filtering without maintaining any
session state information.
4.3.3. Stateful filtering
- Rich enough to express stateful protocol behavior. The sub
requirements for this are:
- Ability to extract packet data using offsets
- Ability to classify packets based on headers and payload
content
- Define and manipulate state associated with a traffic flow.
- Intercept packets based on filters. One example application
of this is to intercept packets corresponding to the reverse
traffic flow for a protocol.
- Express events to be raised to DEFcon end-point application
or control-point.
- Route packets to sub components.
4.3.4. Actions
- Actions to be taken on packets/streams. Example actions are:
- Accept
- Drop
- Reject
- Redirect (to other end-point)
- Alert
- Route (to sub component)
- Log.
Ability to specify multiple actions on packets/streams should be
supported.
4.3.5. Application layer rules
- Express application level (or application layer) rules in
addition to simple header based filters. See DEFcon end-point
requirements for example list of local state information that could
be used.
[Page 14]
DEFCon Requirements February 2003
4.3.6. Loops
- Ability to define simple Loops. For example, to iterate over a
list of IP addresses or email addresses.
4.3.7. Memory allocation
- Memory Allocation should be implicit only. The data model should
support operations leading to fixed memory allocation and
associated use. For example special abstract data types like
'table', 'packet' and 'connection'. Packet generation could be an
issue here.
4.3.8. Functions and Macros
- Ability to define simple, non-recursive, generic functions and
macros to modularize and reuse components and to define libraries.
Ability to report error codes from functions.
4.3.9. Scope of rules
-Ability to define the scope of DEFCon rules with basic meta-
variables like - Direction, interface and host.
4.3.10. Operators
- Support operators to define expressions:
- Temporal operators
- Arithmetic operators
- Logical operators
- Binary operators
- Relational operators
- Set operators
- String operators
4.3.11. Special operators
- Support additional operators on special abstract data types. For
example 'packet', 'table' and 'connection'
-The following 'table' operations should be supported:
- creation of a state table, and associated multi-field
indexes
- destruction of a table
- addition of entries to table
- removal of entries from table using indexes
- updates to table entries using indexes
- queries on tables using indexes. Issue: should SQL like
queries be supported?
- timer operations associated with table entries such as
- set / refresh /reset timer
4.3.12. Route packets
- Ability to offload tasks to registered and/or trusted components.
4.3.13. Conditions
- Ability to express simple "if then else" conditional expressions
[Page 15]
DEFCon Requirements February 2003
4.4. Remote DEFCon control-point requirements
<TBD>
6. Security Requirements
Since the motivation for this work is primarily around security
control, the following sections are to discuss the security
requirements around each component of the DEFCon framework in
detail. The Secure association section covers security requirements
for the various phases in the typical operation.
6.1 DEFCon Protocol
Data carried over the DEFCon protocol is required to be encrypted,
authenticated and have integrity information.
The protocol must protect against replay attacks by using challenge
response type messages and/or nonces. If this is not done a rogue
end-point could hijack an existing DEFCon association.
Integrity is required to ensure that DEFCon messages are not
accidentally or maliciously altered or destroyed. Without data
integrity enforcement a rogue control-point could alter the
messages sent by the valid control-point and setup wrong rules on
the DEFCon end-points under the control-points control and could
potentially cause a denial of service attack on the entire network.
The protocol must encrypt the messages to ensure confidentiality of
DEFCon rules. If encryption is not used in an un-trusted
environment, anybody can sniff the packets and know the current
rule-base being used by the administrator and plan attacks.
Security methods used should not be computationally intensive (or
in other words should be able to handle end-point association
requests at wire speed) since that would cause bogus messages to
perform a denial of service on the DEFCon framework.
6.2 DEFCon end-point
The DEFCon end-point should fail safely on an authorization failure
from a control-point. These failed attempts should be logged via
one-way events to the local OS and/or an alert server.
Authentication is also needed from the DEFCon end-point to the
control-point. Also the confidentiality of the rules being pushed
to an end-point may have to be maintained.
Some level of flow control is needed on the enrollment process,
since multiple rogue end-points could inundate an enrollment server
thus causing valid end-points to not be able to register.
<TBD>
6.3 DEFCon control-point
[Page 16]
DEFCon Requirements February 2003
Authentication is needed from the DEFCon control-point to the
DEFCon end-point. If the control-point is not authenticated, it
could remove all rules from the remote end-point and render the
framework useless.
<TBD>
6.4. Security requirements for typical operation
6.4.1. Enrollment
- Administrators pre-configures the NIC firmware w/ keys and
DEFCon control-point identity
- Using directory services
6.4.2. State verification (optional)
- verifying end-point firmware and end-point code integrity
- using trusted platforms to get a software snapshot of the system
and comparing against expected snapshot (on standard IT builds)
6.4.3. Session key generation
6.4.4. Rule deployment
6.4.5. End-point Alerts and Audit Reports
6.5 Handling non-DEFcon end-points in the network
<TBD>
7. References
7.1 Normative References
7.2 Informative References
[1] S. Bradner, "Key words to use in the RFCs",
RFC 2119. Mar 1997.
[2] Westernized, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and
S. Waldbusser, "Terminology for Policy-Based Management", RFC
3198, November 2001.
[3] Bellovin, S.M., "Distributed Firewalls", Login, November 1999,
pp. 37-39
[4] Bellovin, S.M., Smith, J., Keromytis, A., Loannidis, S.,
"Implementing a Distributed Firewall",
http://www.cis.upenn.edu/~angelos/Papers/df.ps
[Page 17]
DEFCon Requirements February 2003
[5] Payne, C., Markham, T., "Architecture and applications for a
distributed embedded firewall" Computer Security Applications
Conference, 2001. ACSAC 2001. Proceedings 17th Annual, 2001
Page(s): 329 -336
[6] Markham, T., Payne, C., "Security at the network edge: a
distributed firewall architecture" DARPA Information
Survivability Conference & Exposition II, 2001. DISCEX '01.
Proceedings, Volume: 1 , 2001 Page(s): 279 -286 vol.1
8. Authors' Addresses
Ravi Sahita
Intel Corp.
2111 NE 25th Avenue
Hillsboro, OR 97124
Email: ravi.sahita@intel.com
Priya Govindarajan
Intel Corp.
2111 NE 25th Avenue
Hillsboro, OR 97124
Email: priya.govindarajan@intel.com
9. Acknowledgements
Thanks to David Durham, Pankaj Parmar and Priya Rajagopal for their
in-depth review and comments.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
[Page 18]
DEFCon Requirements February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Table of Contents
Abstract...........................................................1
1. Introduction....................................................1
2. Terminology.....................................................2
2.1. DEFCon rule...................................................2
2.2. DEFCon action.................................................2
2.3. Firewall......................................................2
2.4. End-Point Firewall............................................2
2.5. DEFCon control-point..........................................2
2.6 Alert/Audit server.............................................3
2.7. DEFCon end-point..............................................3
2.8. DEFCon protocol...............................................3
2.9. DEFCon or Distributed/End-Point Firewall CONtrol..............3
2.10. DEFCon association...........................................3
2.11. DEFCon enrollment............................................3
2.12. DEFCon rule conflict resolution..............................3
2.13. DEFCon rule validation.......................................3
2.14. DEFCon feedback..............................................3
3. DEFCon Architecture Requirements................................4
3.1 High level architecture........................................4
3.2. Architecture Component Requirements...........................5
3.3 Example Deployment Scenarios...................................7
3.3.1. Scenario A: Hierarchical deployment.........................7
3.3.2. Scenario B: Directory service based deployment..............8
3.3.3. Scenario C: Standalone deployment (remote or local).........8
3.3.4. Comparison of models........................................9
4.1. Component Requirements........................................9
4.1.1. DEFCon protocol functional requirements.....................9
4.1.2. Interface Requirements.....................................12
Operational interface:............................................12
Alert/Acct Interface:.............................................12
OOB Configuration Interface.......................................12
4.2. DEFCon end-point requirements................................12
4.3. DEFcon Language requirements.................................13
4.3.1. Data Types.................................................14
4.3.2. Stateless filtering........................................14
4.3.3. Stateful filtering.........................................14
4.3.4. Actions....................................................14
4.3.5. Application layer rules....................................14
4.3.6. Loops......................................................15
4.3.7. Memory allocation..........................................15
4.3.8. Functions and Macros.......................................15
4.3.9. Scope of rules.............................................15
4.3.10. Operators.................................................15
4.3.11. Special operators.........................................15
4.3.12. Route packets.............................................15
4.3.13. Conditions................................................15
4.4. Remote DEFCon control-point requirements.....................16
6. Security Requirements..........................................16
6.1 DEFCon Protocol...............................................16
[Page 19]
DEFCon Requirements February 2003
6.2 DEFCon end-point..............................................16
6.3 DEFCon control-point..........................................16
6.4. Security requirements for typical operation..................17
6.4.1. Enrollment.................................................17
6.4.2. State verification (optional)..............................17
6.4.3. Session key generation.....................................17
6.4.4. Rule deployment............................................17
6.4.5. End-point Alerts and Audit Reports.........................17
6.5 Handling non-DEFcon end-points in the network.................17
7. References.....................................................17
7.1 Normative References..........................................17
7.2 Informative References........................................17
8. Authors' Addresses.............................................18
9. Acknowledgements...............................................18
Full Copyright Statement..........................................18
Acknowledgement...................................................19
Table of Contents.................................................19
[Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 10:35:10 |