Draft S.F. Wu, F. Zhao, C. Shin Internet Engineering Task Force UC Davis File: draft-wu-pana-dpac-framework-00.txt H. Johnson Expires August 2003 BTH R.C. Guo, T.J. Liu, K.P. Fan ITRI J. Fu Motorola Feburary 2003 A Framework for Data Packet Access Control (DPAC) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. This Internet Draft expires August 24, 2003. 1. Abstract This informational draft describes the DPAC (Data Packet Access Control) framework, potentially under PANA, to efficiently control "data packets" to access the network. Instead of using potentially more expensive crypto-based mechanisms such as IPSec (layer 3) or IEEE 802.11i (layer 2), DPAC introduces the possibility of using and negotiating a range of light-weight per-data-packet source authentication methods to control the data packets from PANA Clients (PaC). In DPAC, each data packet sent from PaCs to Enhanced Point (EP) can be classified, with high probability, as either valid or invalid. Furthermore, under this framework, it is possible for EP and PAA to account reliably on the network usage of each PaC. 2. Terminology Device Identifier (DI): The identifier is used by the network as a handle to control and police the network access of a PANA client. Depending on the access technology, identifier might contain any of IP address, link-layer address, switch port number, etc. of a device. PANA authentication agent keeps a table for binding device identifiers to the PANA clients. Identity (UID): This information is used to identify the user and to authenticate the PaC. Identity, as an example, could be NAI as specified in RFC-2486 [NAI]. Edge Subnet or Link: An edge subnet or link is the immediate IP subnet that is available to an interface of the device for network access. Access/Edge Router: An access/edge router is a router present in the edge subnet. Enforcement Point (EP): An EP is a node that is capable of filtering packets sent by the PaC to the access/edge router using the DI information authorized by PAA. PANA Client (PaC): A PaC is an entity in the edge subnet which is wishing to obtain network access from a PANA authentication agent within the same network. A PANA client is associated with a device and a set of credentials to prove its identity within the scope of PANA. PANA Authentication Agent (PAA): A PAA is an entity in the edge subnet whose responsibility is to authenticate the PANA client (PaC) (but NOT the data packets from the PaC after this authentication process) and grant network access service to the device. Lease: A lease regulates how often PaC will need to re-authenticate itself to PAA after the successful initial authentication. The lifetime of lease is negotiated by PAA and PaC during the initial authentication. For example, a lease between a PAA and a PaC can be 30 minutes, 8M bytes or 2^12 packets. Please note that, in order to implement/enforce leases correctly for byte and packet counts, it is important to have accurate per data packet source accoutability. 3. Why DPAC (Data Packet Access Control)? Usage-based accounting has been widely accepted as better schemes than flat rate in term of resource utilization [ACCOUNT]. AAA protocols, such as Radius [RADIUS] and Diameter [DIAMETER], have been designed to include usage attributes. Usage-based accounting may be charming to ISPs as well as their customers since ISPs will be able to not only utilize their resource efficiently but charge fairly as well. ISPs should be able to authenticate and count the packets in order to count the cost. Authenticating and counting packets is critical to guarantee accounting correctness and prevent resource stealing. To conduct usage based accounting, both users and packets need to be authenticated. Typical process of authentication/access control is to create an access control filter list and add the authenticated user identity (usually the IP or MAC address). However, in the PANA environment, the layer 2 links are not always non-shared medium, which makes the Denial-of-Service, replay, spoofing, eavesdropping attack launched more easily and easily counteract the efforts that were made in the authentication between PaC and PAA. Without packet level authentication, attackers can easily sniff and then spoof the authenticated address to gain access and steal the resource. Therefore, under PANA, it is critical for an EP to determine whether a particular data packet should be allowed to enter the charged service network. The EP needs to decide conceptually, first, the originator (a PaC) of this data packet, and second, whether this PaC still has a valid lease. The second part has been well addressed by the PANA working group, while the solution to the first part is still unclear. For example, using the source address (either layer 2 or 3) as the identification mechanism is obviosuly insecure. While source address spoofing is not technically too difficult to achieve, a more serious problem might be denial of service attack. For instance, if a lease is 2^12 packets, the attacker can send junk packets with the spoofed address (or simply replay) to deny the network access from a valid PaC. On the other hand, using strong "per data packet" authentication mechanisms such as IPsec between PaC and EP might be too expensive. Many applications today have already applied some end-to-end integrity, authenticity, and confidentiality protection for their critical information being sent through the Internet (e.g., IPsec, TLS/SSL, and SSH). Adding yet another authentication or encryption security association between EP and PaC might be a significant overhead for certain light-weight devices such as PDAs. On the other hand, we observe that, in practice, it is not absolutely necessary to prevent every invalid packet entering the charged service network. In trading off overhead with security (in the sense of network access -- NOT confidentiality or integrity, which should be protected in an end-to-end fashion), it might be practically acceptable to have at most X% bad packets being allowed to enter the charged network. Furthermore, if indeed an attacker tries to aggressively and maliciously gain network access, the system will be able to detect such an intention and dynamically boost the security to a higher level. This leads to the possibility of applying a range of "weak but inexpensive" crypto functions to prevent the bad packets entering the network with different probabilities. 4. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 5. The DPAC Framework Under DPAC, we define three functional modules: ANM (Authentication Mode Negotiation), SAO (Source Authentication Options), and IDRS (Intrusion Detection and Response System). 5.1. Authentication Mode Negotiation (AMN) Similar to other security association negotiations (such as IKE), in DPAC, a negotiation process is needed for PaC and EP to choose the same security mechanism for their communication. This negotiation can driven by either policies or IDRS. In the latter case, the IDRS might report some warnings to the EP, for instance, which might result a change the authentication mechanisms. 5.2. Source Authentication Options (SAO) For many applications, end-to-end encryption and authentication will guarantee the integrity and confidentiality. Therefore, it is possible to "weaken" the authentication mechanisms. For instance, one particular weak authentication procotol might be a few secure random bits related to the source address of the packet. 5.3. Intrusion Detection and Response System (IDRS) A unique module under DPAC is IDRS (Intrusion Detection and Response System). Most existing framework emphasizes on intrusion prevention, and, intrusion detection is usually treated as a second class citizen. But, based on our experience, a system integrating both prevention and detection will not compromise the security, while it might reduce a big overhead when the attacks are not happending. In DPAC, we focus on detecting: (1). whether some malicious user wants to use the network without being athenticated. (2). whether some malicious user tries to deny the service from other valid customers. The detection of these two types of attacks is very important. These inputs will help greatly in deciding the appropriate response to certain traffic anomalies. More importantly, with IDRS, the authentication option can be designed as "detectable" -- meaning that, while the EP cannot block some attacks, it can accurately detect that some bad behavior has occured. 6. Security Consideration Based on the DPAC framework, we have designed and implemented a system called SOLA, which uses "secure random bits" to control the network access. The following analysis is based on our particular implementation of the DPAC framework. 6.1 Replay attack The malicious PaC may sniff some packets sent from valid PaC before and then replay them. However, a window scheme similar with IPSec will be maintained on the side of EP to resist this attack. 6.2 DoS attack The malicious PaC may try to flood the forged packets to EP. However, what EP needs to do is just to compare the authentication data. If it doesn't match, EP simply drops the packets. The DoS attack targeted at EP will not cause problems. 6.3 Spoofing The malicious PaC may try to spoof the valid PaC by guessing the authentication Data and analyzing the authentication data collected before. However, the possibility for it to guess correctly is only 1/2^32. Also the random bits are generated by some "good" random number generators, such as G-SHA, BBS, MS, etc. The test results published before show no flaws are detected. Also if the malicious PaC keeps guessing the Authentication Data, EP can easily detect such kind of abnormal situation and then invoke the alert. 6.4 Malicious Dropping and Interception EP can detect the packet loss though observing the sequence number. And it will compare the statistics result with the sample, if it exceeds the predefined threshold, it will alert the PaC or take some other actions. 6.5 Eavesdropping and Falsification For those who care about the integrity and privacy of data they are sending, the best way is to do end-to-end security by IPSec. SOLAL3 doesn't stop using IPSec. However, SOLA correctly avoids creating the complicated SA between PaC and EP and lets the PaC decide whether it is needed and choose how to protect the security of data while at the same time preventing the most common and critical risks taking place in point of view of ISP. 7. Remarks References [RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [DIAMETER] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base Protocol", draft-ietf-aaa-diameter-15.txt, IETF work in progress, Oct 2002. [NAI] B.Aboba, M.Beadles, "The Network Access Identifier", RFC 2486, Jan 1999. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [ACCOUNT] C. Mills, G. Hirsch, G. Ruth, "Internet Accounting Background", RFC1272, November 1991 Authors' Information S. Felix Wu, Fan Zhao, Charlie Shin Computer Security Laboratory Department of Computer Science, University of California, Davis Davis, CA 95616 USA Email: {sfwu, fanzhao, yjshin}@ucdavis.edu Henric Johnson BTH Kroscona, Sweden Email: hjo@bth.se Jui-Chung Kuo, Tzong-Jye Liu, Kuo-Pao Fan Computer and Communication Lab. Industry Technology Research Institute Hsin-Chu, Taiwan ROC Email: {rckao, tjliu, kpfan}@itri.org.tw Judy Fu Motorola Internet Lab Motorola Email: AZF002@motorola.com