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 Alert/Acct Interface: Alert Control-point: DEFCon end-point --> DEFCon/Alert control- point OOB Configuration Interface Verify End-point: DEFCon control-point --> DEFCon end-point 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. 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 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. 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. 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 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]