A generic data flow security model
El Khoury Hicham, Laborde Romain, Barrère François, Benzekri Abdelmalek
Chamoun Maroun Saint Joseph University Beirut, Lebanon
[email protected]
IRIT – University Paul Sabatier Toulouse, France
[email protected],
[email protected],
[email protected],
[email protected] Abstract— Network security policy enforcement consists in configuring heterogeneous security mechanisms (IPsec gateways, ACLs on routers, stateful firewalls, proxies, etc) that are available in a given network environment. The complexity of this task resides in the number, the nature, and the interdependence of the mechanisms. We propose in this paper a formal data flow model focused on detecting multi-layer inconsistencies between security mechanisms. This model is independent from specific security mechanisms to admit the security technology diversity and evolution.
II.
Keywords – network security; data flow modeling;
I.
A FORMAL DATA FLOW SECURITY MODEL
Our goal is to define a technology independent formalism to detect distributed inconsistencies (multi-mechanism, multilayered OSI). Our approach consists in a generic model of data flow; the treatments performed by network security mechanisms are then seen as functions applied on flows. Network security mechanisms are not only applied at a single network layer (firewalls and IPSec are both IP layer mechanisms). A global security solution is multi-level (crosslayer). For example, a VPN can be based on IPsec but also L2TP, SSL or SSH. Filtering can be done at the IP level through a firewall, at the data link layer via a switch, or at the application level by a dedicated gateway.
INTRODUCTION
Network security is inherently a distributed function that involves the coordination of a set of equipments each having specific capacities and security services. Any equipment (end and core devices) involved in security requires a precise configuration. This configuration, determining its behavior, has not only a local impact on the security service provided by the equipment but also affects the global network security. Inconsistency of security mechanisms, which indicates that two security configurations are contradictory, is therefore a major problem [1]. The problem of inconsistency can occur at two levels. At the local level, two rules at the same security mechanism on the same equipment may be incompatible (e.g. one filtering rule permits a data flows whereas another one on the same firewall blocks it). Inconsistency can be distributed too. In this case, the incompatibility of two rules can occur between different mechanisms on different equipment playing a role at different levels in the OSI layers (IPsec tunnels blocked by firewalls, HTTP proxy unable to filter HTTP traffic because it has been encrypted by an IPsec gateway, etc). This distributed inconsistency is much harder to cope with because it expects to consider the dependencies between different equipments and/or different mechanisms. It is therefore essential to develop tools to express and validate network security policies. One difficulty resides in the nature of network security information. How to express management information while taking into consideration constraints such as the heterogeneity of solutions, interdependencies between equipment, and the sustainability of the models confronted to the fast evolution of technologies? The right level of abstraction should be both independent of the security mechanisms and faithfully representative of the reality. To address this problem, we propose a formal model of data flow. A data flow is represented as a sequence of logical elements to match physical data flow. The security mechanisms are represented as functions handling these flows.
A. Analysis of the problem In concrete terms, a data flow is a contiguous set of bytes with variable size conveyed over a network. This sequence of bytes is divided into logical blocks according to encapsulation protocols. For example, a data flow corresponding to an HTTP request can be seen as < Ethernet protocol block, IP protocol block, TCP protocol block, HTTP protocol block >. The bytes in a logical block are not necessarily contiguous. Then, each protocol divides the associated block of bytes into fields in accordance to its description. For example, the control information of the Ethernet protocol is distributed into 14 bytes (destination MAC address, source MAC address, identifier of the encapsulated protocol) at the beginning of the frame and 4 bytes for the control field at the end. A data flow evolves during its journey through a network according to the security mechanisms configured on the network equipment, e.g.: • Adding new blocks of bytes. e.g., an IPsec gateway adds AH header between the IP block and the UDP/TCP block when AH is used in transport mode, • Removing blocks of bytes. e.g., an HTTP proxy removes the IP block when it receives a data stream, • Modifying fields. e.g., NAT changes the value of the source IP address field in the IP block or a router changes the time-to-live field, • Authenticating fields. e.g., the AH protocol authenticates certain fields of IP and all other fields of the encapsulated protocols, • Encrypt fields. For example, the ESP in transport mode encrypts the fields of the encapsulated protocols. In addition, the network security mechanisms perform these treatments according to a subset of data flow fields they can perceive. E.g., a basic stateless firewall analyses only the
1
protocol, IP source and IP destination fields in the IP block, and port source and destination fields in the UDP/TCP block.
III.
A treatment on a data stream is then seen as a particular function of ℱ in ℱ. This function represents the capability to modify the data flows. It can symbolize encryption protocols such as IPsec where one transform function adds some security services (e.g. confidentiality) and another removes it, or the NAT where only one transform function is concerned. As an example, we present the specification in our formalism of the Encapsulating Security Payload protocol (ESP) [2], which provides authentication and encryption of data carried in IP datagram. The Authentication Data (AD) field of ESP guarantees the integrity of the datagram. In the transport mode, ESP bounds the transport and data layers (Fig.1). ESP authenticates the data transported inside the IP datagram but not the IP header. In addition, it encrypts all the data from protocol transport layer.
B. Modeling data flows We propose a data flow model independent from the underlying protocols and able to anticipate future protocols. The difficulty consists in reaching the good level of abstraction between security mechanism independence and reality closeness. Foremost, we define our main entities: • is the set of possible attributes. An attribute ∈ , represents a couple where name is a field that can be found in a protocol, and value is its content, • is the set of protocols, i.e., the set of logical blocks. An instance of protocol ∈ is a couple where protoid= is the name of the protocol and an unique identifier and attributes is defined on the Power-set of , i. e. , ∈ ℙ, • ℰ = ℕ , is the set of finite sequences over . This set represents all encapsulation chain of protocols, i.e. sequences of logical blocks, • is the set of security algorithms addressing the encapsulation chain of protocols (for instance, DES, 3DES, HMAC-SHA1, etc.).
Original IP Header
TCP/UDP
Data
Authenticated Original IP Header
ESP Header
TCP/ UDP
Data
ESP Trailer
ESP Auth
Encrypted
Figure 1. IP datagram before and after applying ESP in transport mode
Our model considers protocols as logical blocks. So, we do not differentiate between the header and the tail of ESP. The application of ESP in transport mode on flow f= is the transformation function : ℱ → ℱ , generating the flow () = = < … , ip′, esp, p, … > , AUTHN , CONF′ where: • attributes(ip′) = attributes(ip)\{(proto, x)} ∪ {(proto, 50)} where 50 is the value of ESP protocol • AUTHN = AUTHN ∪ ⋃∀ ∈ ()\{} ad, esp, x, esp, s ∪ ⋃∀ ∈ ()| ∀ ∈ ad, esp, y, p, s indicating the integrity of every field of every protocol encapsulated by ESP is guaranteed by using security algorithm s . • CONF = CONF ∪ ⋃∀ ∈()\{,,} x, esp, s ∪ ⋃∀ ∈ ()| ∀ ∈ y, p, s . This indicates that every field of every protocol encapsulated by ESP is encrypted using security algorithm s
Definition: Formal definition of data flows Based on above definitions, we present the set of data flows as: ℱ ⊆ ℰ × AUTHN × CONF such that: • ℰ is the set of protocols (encapsulation chain of protocols), • AUTHN ⊆ ( × × × × ) represents the attributes of the data flow that have been authenticated such that , p , , p , ∈ AUTHN indicates that attribute of protocol p guarantees the integrity of attribute of protocol p via security algorithm , • CONF ⊆ BAG( × × ) represents the attributes of the data flow that have been encrypted, such that , , ∈ CONF indicates that attribute of protocol is encrypted via security algorithm . We used a multi-set1 because the same attribute can be encrypted several times by the same algorithm. Examples: Given the flow = e, AUTHN, CONF ∈ ℱ, e =< 1 , 2 >, ℎ 1 = (p, 1, α, v1, β, v2, γ, v3) and 2 = (p, 2, κ, v4, μ, v5): 1. If AUTHN = {}, and CONF = {} this data flow includes two encapsulated protocols for which no field is protected. 2. If AUTHN = κ, ଶ , γ, ଵ , sଵ , κ, ଶ , μ, ଵ , sଵ and CONF = {( , ଶ , ଶ )} . Then field in protocol p2 authenticates fields and in protocol p1 by algorithm and field in protocol p1 is encrypted by algorithm .
IV.
CONCLUSION
We have proposed in this article a formal model of data flow security where security mechanisms are represented as functions that transform data flow entities. Our future work will focus on defining a generic model of equipment configurations based on our data flow model in order to provide a generic network security conflict detection model. REFERENCES [1]
[2] 1
APPLICATION TO ESP IN TRANSPORT MODE
A multi-set is a set of elements where an element may appear several times.
2
R. Laborde, M. Kamel, F. Barrère, and A. Benzekri, “Implementation of a Formal Security Policy Refinement Process in WBEM Architecture”, Journal of Network and Systems Management, 15(2), 2007. S. Kent , “IP Encapsulating Security Payload (ESP)”, IETF RFC 4303, 2005.
3
