Common Data Security Network (CDSN) Aftab Ahmad
Mona El-Kadi Rizvi
Stephan Olariu
Norfolk State University 700 Park Avenue Norfolk VA 23504 +1-757-823-8311
Norfolk State University 700 Park Avenue Norfolk VA 23504 +1-757-823-8311
Old Dominion University Norfolk VA 23529 +1-757-683-4417
[email protected]
[email protected]
[email protected]
in WEP/TKIP to AES as a required suite. The AES employed is block-oriented, together with message authentication code in the form of CCMP (Counter mode with Cipher block code with Message authentication code Protocol). With the help of preauthentication and key-caching, IEEE 802.11i is expected to perform reasonably well for operational environment. However, the exact performance of the protocol suite is not widely evaluated yet, and is a function of a variety of factors. The wireless LAN security is at the link level. In order to have trusted routing, transport and application interfaces, security mechanisms are needed at each level, as shown in Fig. 1.
ABSTRACT We present the idea of using a separate network that processes and enforces security in a data network. We briefly discuss various components of such a network, called common data security network (CDSN). We use the example of the IEEE 802.11i to determine one of the link level metrics of the proposed network, the fractional overhead for IEEE 802.1X and temporal key integrity protocol (TKIP).
Categories and Subject Descriptors C.2.0. [Computer-Communication Networks]: General, Security and Protection
General Terms Security, Wireless LANs, Security Architecture.
Keywords
Control plane
Data plane
Security plane
Control (e.g., SIP)
Applications
App. Security
TCP/UDP layer
TCP/UDP Security
ICMP/RSVP
IEEE 802.11i, TKIP, Common data security, security plane.
1. INTRODUCTION
ARP/RARP
Wireless network security has surfaced as a dominant concern recently. Businesses, scientists and governments share this concern. It follows naturally from dependence on wireless data networks for network access as well as local loop technology. The otherwise explosive success of Wi-Fi access can also be viewed as a failure of the security. Over 70% of initial deployment has been reported to be faulty due to open authentication and not requiring the implementation of WEP. To top it off, weaknesses in WEP (static key, short initialization vector, linearity of integrity check vector, etc) make things much worse [1]. Wi-Fi Alliance, however, closed most holes in WEP through the Wi-Fi Protected Access (WPA) [2]. It adopted temporal key integrity protocol (TKIP) that mixes the transient keys with the MAC addresses, provides a stronger Hash algorithm in the form of Michael [3] for data integrity, has increased the sequence numbers to a strong 48 bits, provided a key management mechanism by employing the use of a server, and mechanisms against forgeries and other attacks. The IEEE Work Group 11i (IEEE 802.11i) proposed a standard [4] in 2004 that includes TKIP as an option for compatibility with existing equipment. It switched gear on the cipher suite from RC4
IP layer
IP Security
Lower layer (LL) data
LL Security
Fig. 1. Conceptual protocol architecture for secure Internet.
Fig. 1 shows an architectural view of the Internet that consists of three planes (excluding network management), that is, user data plane, control plane and security plane. The figure has been drawn without an actual reference model, and therefore has an important omission, that is, there are no interfaces directly between adjacent security layers. The security plane is currently integrated with the data plane, and exposes the several problems. Therefore, it may be best to have a separate network infrastructure just for security. We make a proposal of such a network in this paper. The network is called as common data security network (CDSN). In Section 2, describe the layout of the security network architecture that could be deployed in a customizable fashion with the following characteristics: 1. Security among various network administrations can be negotiated and implemented. 2. Security for various applications can be customized according to individual application need. 3. Government regulations and policies can be applied in a visible way so that the user and the relevant Government agencies know their authority and limitations. In Section 3, we describe the components of CDSN. Section 4 discusses identifying security metrics that could be used in customizing security. In Section 5, we evaluate some metrics for IEEE 802.11i links. Section 6 will summarize the conclusions.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Q2SWinet’05, October 13, 2005, Montreal, Quebec, Canada. Copyright 2005 ACM 1-59593-241-0/05/0010...$5.00.
1
Common data security network (CDSN) Security processing station (SPS)
Source Network
Destination Network
Internetworking Cloud
Destination ? Source Security checkpoints (SCP)
Fig. 2. General layout of the common data security network.
realizing such mapping. These obstacles owe to the evolution of security mechanisms as well as characteristics and resources of each layer.
2. COMMON DATA SECURITY NETWORK (CDSN) The general layout of CDSN is shown in Fig. 2. The notion follows closely from the common channel signaling network of the popular circuit switched network, the PSTN. The network employs its own transmission sources shown as the upper cloud. There are two types of security servers; security check points (SCPs) that determine the stream security requirements based on source-destination address pairs and the security processing stations (SPSs) that are responsible for security enforcement in a local environment. The actual provision is provider-dependent and could be carried out in entirely connectionless or connection-oriented mode. In the next section, we elaborate more on the components of CDSN.
3.1.1 Evolutionary problems Security certificates, secure sockets, transport level security, IPSEC and link level security procedure were not developed with due consideration of one another. As a result a translation of one into another level did not evolved.
3.1.2 Layer characteristics Each layer provides a different set of functions, not all functions present in all layers. Therefore, security requirement for these functions may be different and a mapping from one to another may be a difficult task. For example, a choice of using or not using routing tables at IP level could be a requirement that cannot be translated to equivalent requirement at lower or high layers.
3. COMPONENTS OF CDSN There are quite a few major architectural components, namely SCPs, SPSs and the layer interfaces. The SPS may also act as policy servers for intranets, or such severs could be deployed separately, as explained later in this section. The security associations is a concept already used in the Internet as well as LAN security context. We will use the term security attributes and association (SAA) as an extension of security association and consider it a building block component.
3.1.3 Layer resources Each layer may define and manage its resources in a different way. For example, if flows of the same security level are queued separately, the number of queues implemented at each layer could be different. This problem is similar to the one described in Section 3.1.1 and also similar to the problem that is evident in QoS provisioning, say, using DiffServ architecture. There, even though the local area network standard IEEE 802.1Q defines as many service classes as the IP layer, but their meanings and implementation may differ. Fig. 3 summarizes above discussion. Thus, the security attributes and associations may be defined as a network-wide set of security levels and interfaces. If the security architecture is defined with same number of levels of security on each layer and same interfaces between each layers, the SAAs will reduce to a very simple description at any one layer (read application layer).
3.1 Security Associations and Attributes (SAAs) Every flow of data is expected to be handled with security ranging from minimal to maximum. There is a need to describe the level of security to be associated with every flow between two stations (IP level), transport entities (Transport level) or two applications (Application level). Ideally, if SAAs could be specified completely at the application level, they should be able to map to the lower layers easily. However, there are some obstacles to
2
Security level 1
Security level
...
Security level n
general; therefore analytical models for all the components of security layers are a pre-requisite to such an implementation. Another question in defining the cost of security is whether it should be defined from the damage done without it or from the overhead resources required to implement it. Apparently, the later approach is more prone to a business model, as the network providers sell capacity. Similarly, the level of security provided depends on the breakability of the respective protocols or algorithms. This is again a complex subject and a whole area of analysis (cryptanalysis) is dedicated to it without a uniform approach addressable to every mechanism1. Generally, there is a way to identify a cipher suite with the number of attempts required to break it, which is the level of security provided by it. In general, we can construct a measure, such as –log[p(t)] as the amount of security provided by a secure system (protocol, algorithm, etc.), where p is the probability that the system can be compromised in time t. The value of p(t) must be calculated from cryptanalysis of cryptographic mechanisms (e.g., cipher suites). The time t can be replaced by another parameters h, which is the number of attempts to break the system. In any case, a common sense assumption is to assume that the intruder has all the time in the world. In such case the value of interest is p(∞) = p. This will be modified for temporal key based algorithms, in which the keys have a finite lifetime τ. We can rewrite the above expression as p = p(τ) = p(∞). The cost of a protocol can best be described by the amount of resources it consumes. There are generally three types of resources consumed by any networking systems; transmission capacity, processor capacity and the storage capacity. Of these, the everfalling prices of memory chips has practically eliminated the last factor. The processor capacity (implementation complexity) is usually measured in terms of cycles per byte [5] and transmission capacity can be measured in terms of the protocol overhead (new packets plus the data packet headers). In order to have a single metric for cost, we need a relation between the two types of overhead. If the total transmission overhead is T(n) (defined as the number of security overhead bits per user n data bits without security), and N(n) is the processing overhead (defined as the number of processor cycles per n bits of data processing for security algorithm or protocol for n user/network data bits). Then, if C is the network capacity and H is the processor clock, the security overhead So(n) in seconds can be defined as:
Layer k+1 Security Interfaces
Security level 1
Security level
...
Security level m
Layer k
Fig. 3. Inter-layer security mapping.
3.2 Security Checkpoints (SCPs) The SCPs are devices that read the SAAs of the flows passing through a point on the network route. As a result of this checking, they could change the SAAs to reflect new values that can be executed in the next intranet or simply define filters to be followed based on the available implementations at the lower layers.
3.3 Security Processing Stations (SPSs) The security processing stations enforce intranet security policies as defined by the SCP or the intranet administration. The processing station implements security interfaces and filters. For example, for an intranet in which SPS receives packets from a wired connection and relays them on an IEEE 802.11 link, the SPS could provide the following functions: 0. Process the link layer security header. 1. Process the IPSEC header. 2. Based on interfaces between IEEE 802.11i and IPSEC, define a set of SAAs that includes IEEE 802.11 link.
4. CUSTOMIZING SECURITY Security can be customized either for the stations (IP-address pairs) or the applications (IP-addresses + TCP/UDP ports). The SPCs need to know the SAAs only once and start up a timer for the duration of the validity of the SAAs. The security requested could be specified either in terms of some holistic measure or by requesting certain specific security components and their values (e.g., 'IEEE 802.1X/RADIUS/EAP-MD5 authentication with a rekeying time of x seconds'). The later, that is, the exact specification of algorithms and their attributes, is easy to implement, but requires the application user to have the knowledge of all the available security resources, which is an unrealistic requirement. The former, i.e., giving a holistic view entails two important functions to be implemented, namely, a parameter set for user, such as amount of security, or cost of security, and subsequent translation of this parameter set into SAAs. Albeit being a complex mechanism, this is the only practical way. In fact, attributing cost to security is the only practical way for all users to work with, for application level or station level requests. We will discuss this topic in the rest of the section.
S o (n) =
T ( n) N ( n) +l C γH
(1)
Where in Eq(1), l is the pipelining effect (0 ≤ l ≤ 1) of transmission and processing, and γ is the fraction of the processor clock assigned to the security process (0 ≤ γ ≤ 1) by the operating system. Ideally, l = 0 and γ = 1, which would mean that the entire processing takes place while no data could be transmitted (l = 0) and the processor job queue was empty. In general if ρl is the link load and ρp is the processor load, then, l = 0 and γ = 1 with probabilities (1- ρl) and (1ρp) respectively2.
4.1 Cost Versus Level of Security
1
We are making this statement based on best guess. These values are approximate, for simplest conditions. In reality the processor may have a priority queue and the link protocol may result is a throughput much less than 100%, which will impact these probabilities.
The security system defined by any set of SAAs consists of a large number of protocols, algorithms, and perhaps systems. Each protocol or algorithm provides a different amount of security in
2
3
To summarize the above discussion, two metrics needed to estimate the ‘provisioning’ of security are the cost of security So(n) and the level of security –log(p). The cost can also be represented in terms of fraction of the transmission time Sf(n) that can be written as follows:
S f (n) =
S o ( n) n S o (n) + C
=
CS o (n) n + CS o (n)
5. EXAMPLE OF COST EVALUATION In this section, we will use the example of a popular access network (IEEE 802.11 and its extensions) and determine only the Sf(n) for one of the two cipher suites, the temporal key integrity protocol (TKIP) as per [8]. For brevity sake, we consider only the transmission overhead and leave the inclusion of processing time to future. One of the objectives of this section is in fact to have a closer look at the IEEE 802.11i with focus on TKIP and IEEE 802.1X. Also, we consider only the infrastructure type Wi-Fi with server based authentication due to the reason that Wi-Fi is viewed here as lower layers of the Internet instead of being an independent network.
(2)
It is quite possible that there are security protocols that have only fixed overheads, which makes Eq(2) independent of n. However, such systems will be rather simple, and obtain partial security, such as authentication with a fixed number of packets exchanged. It sounds plausible to have a relation between p and the security overhead; however, in practical deployment, the security algorithms do not have a relation between overhead and the amount of security provided3.
5.1 Robust Security Network (RSN) In IEEE 802.11i, the use of authentication based on IEEE 802.1X and key and data confidentiality based on TKIP (and CCMP) are considered under the umbrella name of robust secure network (RSN). The WEP, open authentication and shared-key authentication are retrospectively under the pre-RSN security provision. The pre-RSN security was not without its overhead albeit its weaknesses. The RSN security has a lot more overhead, including the establishing of RSN. This overhead includes RSN information in the Beacon frame if a station has its dot11RSNAEnabled parameter set to a value equal to True. Other frames, such as Re/Association Request and Probe Response have fields relating to RSN. An RSN information element (IE), shown in Fig. 4 has been added to the Probe Request. The size of the RSN IE is between 4 to 255 octets, or 32-2040 bits.
4.2 Effect of Layering Each layer could have many choices of the pairs {Sf(n), -log(p)}. For example, at IEEE 802.11i layer, choice between TKIP+802.1X, CCMP+802.1X will result in two options. Similar arguments can be made about IPSEC and higher layer. In fact, looking back at fig. 3, each security level box can be labeled with {Sf(n), -log(p)} pair. These labels can help determine the {Sf(n), log(p)} pairs for various intranets. Then, the SPSs can process packets according to the requested value of the security cost.
5.2 Access control in IEEE 802.11i The access control in IEEE 802.11i is based on IEEE 802.1X authentication and TKIP key management. The authentication phase consists of the exchange of extensible authentication protocol (EAP) [6] packets over an unauthenticated port (uncontrolled port). Once the authentication process is successful, a controlled port is made available through which the wireless station and access point can exchange data and other packets. The uncontrolled port is not available for user data packet exchange. Two key hierarchies, a pairwise key hierarchy and group key hierarchy are defined to generate and use keys for unicast and multicast transmissions. The pairwise key hierarchy protects unicast communications, while the later is for multicast communications. The two key hierarchies of master keys, the pairwise master key (PMK) and the group master key (GMK) are used in unicast and groupcast respectively. The pairwise key is a fix for lack of mutual authentication in WEP. It provides both the wireless station (supplicant) and the network (authenticator) a mechanism to authenticate each other. The GMK is used to generate the group temporal key. The temporal key (TK) is part of GTK. There are two types of authentications provided, one based on an authentication server (AS), such as based on RADIUS or Diameter, and other between two stations using pre-shared key (PSK), e.g., in an ad hoc network or a home/small business network. In case of use of an AS, a secure network is assumed between AS and the access point (AP). Fig. 5 shows the operational sequence.
4.2.1 Network provider interpretation The interpretation of the {Sf(n), -log(p)} pair varies from the affected party’s viewpoint. For the network provider, the challenge is to devise security levels easily understood by the user, and implemented on individual flows. Each SCP will determine one of these levels and the SPS will process them. Network administrations can also use re-enforcements at certain protocol layers through local policies or agreements with other network administrations. These re-enforcements could be used to determine a new set of SAAs when a flow passes through an Intranet.
4.2.2 The user’s perspective From the user’s perspective, not all data requires the same amount of security. For example, casual web surfing to get information on products or use common search engines does not warrant spending on security. Voice over IP (VoIP) may require only lower levels of security, not only because it is considered to be generally safe, but also because adding security may cut down the quality (unless additional cost is rendered). E-commerce may require the highest amount of security needed. User should be able to configure a fixed part of security as well as application specific parts.
3
Such a relationship exists for a given algorithm, e.g., increasing the key size renders more overhead and increasing the number of rounds in a cipher algorithm increases the processing overhead. In practice, however, the user does not have a choice and a fixed size of key and number of rounds are employed. However, we leave this question to be addressed in future.
4
Element ID
Length
Group cipher suite
Version
(1+1+2) Octets
Pairwise cipher suite
(4+2) Octets
Pairwise cipher suite list (4-m) Octets
Auth. and Key Management (AKM) suite count (2) Octets
AKM suite list (4-n) Octets RSN capabilities
PMKID
(2+2) Octets
Fig. 4. The RSN information element (IE) layout.
STA# j
AP# l
Fig. 6. EAPOL frame exchanged for server-based authentication. (Fig. 11b, page 15 of the standard) AS
in turn is the MSDU for the IEEE 802.11 MAC. This relation between the three types of protocols is shown in Fig. 7.
Authentication (Master Key - per session)
Derive PMK from MK, and Distribute it
5.2.1 The 4-Way Handshake Protocol 4-Way Handshake protocol completes the authentication process. This protocol is used to confirm the currency of PMK between associated STAs. Table 2 shows the messages used in 4-way handshake. The message number 3 includes one or two RSN information elements in the key data field of the EAPOL_Kep frame and GTK, which is assumed to be 256-bits in Table 2.
PMK only between STA# j and AP# l
Channel access using PMK
Derive and use PTK from PMK
30-octet IEEE 802.11 MAC Header
6-octet EAPOL Header Fig. 5. Relative position of master key (MK), pairwise master key (PMK) and pairwise transient key (PTK) in IEEE 802.11i.
4-octet EAP Header
The overhead in this type of authentication comes primarily from the exchange of the EAPOL packets. One typical sequence of exchange is reproduced from the standard in Fig. 6.
EAP data 4-Byte IEEE 802.11 MAC CRC
Table 1 shows a description of packets used in Fig. 6. Fig. 7. Load bearing hierarchy of IEEE 802.11/802.1X/EAP frames.
Table 1. Authentication overhead using IEEE 802.1X for server based environment. Number Direction Frame Frame Size 1. AP => STA EAP Request 64 octets 2. STA => AP EAP Response 64 octets 3. AP => AS Access request 64 octets 4. STA => AP EAPOL_Key 95 octets 5. AS => AP EAO Success/Keys 44 octets
No. 1. 2. 3. 4.
The EAP frames [7] consist of 32-bit header and zero of more bits of data field. The data field is of zero length for success/fail types. For request and response, it contains short phrase type data, which we assume to be 160 bits, equal to 20 ASCII characters. The EAP packet is a type of EAPOL (IEEE 802.1X) payload. The EAPOL
Table 2. 4-Way Handshake Messages Direction Frame Frame Size AP => STA EAPOL_Key 95+34 octets STA => AP EAPOL_Key 95+34 octets AP => STA EAPOL_Key 358-613 (+34) octets STA => AP EAPOL_Key 95 (+34) octets
In addition to the PMK, the authenticator also needs a confidence building protocol to send group temporal key (GTK) to the STA. It uses Group key handshake (GKH) protocol for this purpose. Like 4-way handshake, the GKH also utilizes EAPOL-Key frames.
5
The two messages exchanged are the same size as messages 3 and 4 in Table 2 they are shown again in Table 3. No. 1. 2.
5.4 Confidentiality Using TKIP As a result of successful authentication completion, the Controlled Port between a STA and AP is opened for data exchange. MAC PDUs can now be exchanged between STA and AP through this port. However, the PDUs could still be subject to eavesdropping due to the wireless nature of the medium. The IEEE 802.11i requires the implementation of advanced encryption system (AES)-based confidentiality if RSN support is claimed. The AES is used in counter mode (CTR) with cipher block chaining (CBC) including message authentication code (MAC). The resulting confidentiality protocol is termed as CCMP (CTR with CBCMAC Protocol). Optionally, IEEE 802.11 devices claiming IEEE 802.11i compliance could implement TKIP. TKIP uses the same cipher algorithm as WEP, that is, RC4 with sufficient reenforcements to get rid of all of its vulnerabilities4. While CCMP has been perhaps specified keeping future in mind, the TKIP takes care of the present state-of-technology. It makes possible the software upgrades of the current WEP-based equipment to TKIP.
Table 3. Group key handshake frames. Direction Frame Frame Size AP => STA EAPOL_Key 358-613 (+34) octets STA => AP EAPOL_Key 95 (+34) octets
5.3 Key Overheads All keys are generated for certain lifetime, and must be discarded and regenerated on expiry of the lifetime. The lifetime for the PMK is given by the management information base (MIB) parameter dot11RSNAConfig-PMKLifetime or by the authentication server (AS) from session timeout plus dot1xAuthTxperiod MIB parameter. The PTK and the GTK cannot have a lifetime longer than PMK. Another source of key overhead are the various key generation algorithms. Table 4 shows a list of key generation mechanisms.
5.4.1 TKIP Overhead
Table 4. Key generation mechanisms. Generation Comments mechanism PMK Server dependent, AS is assumed to be e.g., RADIUS trusted. server derives it PMK size = 255 octets. from AAA key. PTK Pseudo-random Size of PTK = 512 bits function using STA for TKIP (384 bits for and AP addresses CCMP). and random strings generated by STA and AP. KCK (key Part of PTK First 128 bits of PTK confirmation Used in 4-Way and key) Group Key Handshakes for origin authenticity. KEK (Key Part of PTK Second 128 bits of encryption PTK (128-255) key) Used in 4-Way and Group Key Handshakes for confidentiality. (TK) Part of PTK The last 256 bits in Temporal TKIP (or 128 in Key CCMP). Used for data confidentiality. GMK Random generator AP generates GMK. (Group Generates the group Master Key) key hierarchy. Could be re-initialized as configured in AP. GTK Pseudo-random Same role for multigenerator, AP and broad-casting as address and a PTK for unicasting. nonce. The information about GTK is distributed using KCK. GTK size = 256 for TKIP (128 for CCMP).
In a normal error-free data transmission, the TKIP overhead occurs in the form of processing and some MAC frame overhead. The frame overhead is shown in Table 5.
Key
Table 5. TKIP packet overhead fields (causing transmission overhead). TKIP frame Purpose Size field IV + Key ID Includes WEP seed, KeyID and 4 octets. part mixing (two TSC octets) Extended IV Extend the sequence numbers, 4 octets mixing MIC Michael hash output 8 octets ICV The WEP part of integrity check 4 octets
5.5 Total Overhead The actual overhead of IEEE 802.11i is a function of many factors, such as: 1. Size of the message(s) exchanged between a STA/AP pair for the lifetime of the master keys. 2. Channel conditions, as the errors in transmission will be reflected in MIC failures. 3. Hostility level, as the forgery attempts reclaim regeneration of keys and transmission outage. In the following, we make take a simple case, with one data packet (MSDU) handed over to IEEE 802.11 MAC, such as an email in the form of an IP packet. We consider only the transmission time overhead in terms of number of bits. The maximum overhead in octets from Tables 1, 2, 3 and 5 is 20+(647+129) + (647 +3×129) + 331. Adding to this the Probe overhead of RSN IE maximum size of 255 octets, we get a total number of octets overhead as 2416 octets or 19.328 kbits. However, if the MAC payload is greater than 2312 octets (18.496 kb), the overhead per frame is added, albeit the percentage overhead dropping down. Assuming unicast 4
The question is then why CCMP, and its inclusion was not widely predicted. The reason for making CCMP as the main cipher mechanism is that it has been incorporated as the latest information processing standard for non-classified sensitive data by NIST. Non-classified wireless data falls under this category.
6
traffic only, the per fragment overhead is really 20 octets (160 bits) after the first MAC PDU. This gives the following approximate equation (quantities represented in number of bits):
Security overhead So(n) = 19168 + n/18496 × 160
Each entry under ‘Security level’ constitutes one of the horizontal boxes in Fig. 3. Therefore by defining security levels on each layer, a ‘security profile’ can be defined for each call. Once properly evaluated, the last column of Table 6 should have the actual overhead (‘cost’) of security. Of course, for the user the best way to describe security level is to have the first column as shown, but for the network it will best be described by security parameters. This could be done either by SCP of the user domain or have a dedicated translator, just like converting QoS into bandwidth requirements at various layers. The next step is to define a mechanism of translating the security requirements from one layer to another and conveying this information between adjacent layers. Work needs to be done on this as the concept of ‘equivalence’ of security level at various layers does not exist (to the best knowledge of the author). A common-sense approach to this would be to label each security level with a number that describes how strong the security level is. Then, with the help of these numbers, the SCP could define various filters for a flow of packets at a particular intranet.
(3)
Where x is the smallest integer greater than x. The fractional overhead Sf(n) can be found from the following equation.
Sf(n) = SO (n)/[n + SO(n)]
(4)
Fig. 8 shows a plot of the overhead (PSoh = Percentage Security overhead ) as a function of n ranging between 1 to 80000 bits (01000 bytes). It is see from this figure that the overhead is significant and settles around 25% for large MSDUs that require five or more fragments. The main overhead is due the IEEE802.1X authentication and it remains dominant for the small size data packets starting from almost 100% to flattening to 25% neighborhood. This is a significant result, as it does not consider many factors, such as counter measures to attacks, key delays, lifetimes and channel errors. Some of these events could result in a complete outage of for one minute, followed by regeneration and redistribution of all keys.
7. CONCLUSION In this paper, we have proposed the idea of deploying a network just for security enforcement. Some of the architectural components of such a network, called common data security network (CDSN) have been presented. A mechanism of defining security level and cost for protocols have been presented. We also used the example of the IEEE 802.11i to evaluate the cost of the link layer security. In this on-going work, the next step is to complete the cost and level pairs for IEEE 802.11i, followed by IPSEC and application layer protocols of the Internet. Then, details of design the security checkpoint (SCP) and security processing stations (SPS) will be researched.
1
PSOh( n)
ACKNOWLEDGEMENTS
0 1
n
Thanks are due to Lakisha Dailey and Cynia Watson for assisting with some of the work in this paper.
80000
Fig. 8. Percentage overhead for a single packet communications with fragmentation.
REFERENCES
6. HOW TO USE SECTION 5
[1] William A. Arbaugh, Narendar Shankar and T.C. Justin Wan, “Your Wireless LAN Has no Clothes”, available at www.cs.umd.edu/~waa/wireless.pdf. [2] Michael Disabato, “Wi-Fi Protected AccessTM: Looking Down the Link” , Wi-Fi Protected AccessTM Web Cast, June 2003. [3] Niels Ferguson, “Michael: an improved MIC for 802.11 WEP”, IEEE 802.11, January 2002, http://grouper.ieee.org/groups/802/11. [4] IEEE P802.11/ANSI, “Part 11: Medium Access Control (MAC) and Physical Layer (PHY) specifications”, ANSI/IEEE Std 802.11, 1999. [5] Jesse Walker, “802.11 Security Series: Part II: The Temporal Key Integrity Protocol (TKIP)”, Intel Corp. www.ida.liu.se/~TDDC03/literature/wireless/links.html and also Intel website. [6] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson and H. Levkovets, “Extensible Authentication Protocol”, IETF RFC 3748, June 2004. [7] L. Blunk, J. Vollbrecht, “PPP Extensible Authentication Protocol (EAP)”, IETF Request for Comments: 2284, March 1998. [8] A. Ahmad, L. Dailey and C. Watson, “Security Overhead in Wireless LANs”, Applied Telecommunications Symposium, Spring Simulation Conference 2005, San Diego, April 2005.
The above section showed a simplified example of calculating transmission overhead for part of IEEE 802.11i standard. In practice, there are a number of options for combinations of security. Table 6 shows an example of various combinations provided using IEEE 802.11i. Table 6. Various offerings with IEEE 802.11i Security level Protocol suites Implication Minimal (preOpen Auth+no Little overhead RSN) encryption Light Open Auth+WEP Some overhead Medium Shared key Medium overhead Auth+WEP Strong (RSN) IEEE Overhead in 802.1X+TKIP Figure 6+Server overhead Strong IEEE Similar to above 802.1X+CCMP Strong IEEE 802.1X(reSignificant enforced)+CCMP overhead (certificate?)
7
