One document matched: draft-zhao-pana-dpac-framework-00.txt

Draft                                   F. Zhao, C. Shin, S.F. Wu
Internet Engineering Task Force                          UC Davis
File: draft-zhao-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)
  	        <draft-zhao-pana-dpac-framework-00.txt>


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, the object is, for each data packet sent from PaCs to
the Enhanced Point (EP), to classify, 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, layer 2 links are commonly
shared medium (e.g., ethernet, wireless lan), 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, 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 practically simple but 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 in many cases. 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). In other words, the payload should have been secured in an end
to end fashion. Adding yet another authentication or encryption
security association, only, between EP and PaC might be a significant
overhead and delay 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. For instance, it might be undesirable but perfectly OK, from
a business point of view, to allow 10% of the ISP's bandwidth being
stolen by some unknown attackers -- as long as the paid customers are
happy. 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 anyway), it might be practically acceptable
to have at most X% (being configured by administrative policies) 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 the DPAC framework, 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 as described in [SOLA].

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 other words, an
architectural trade-off between purely prevention (most likely using
some type of strong cryptographic building blocks through the whole
system/framework) and IDRS (using cryptographic mechanisms carefully
and plus some other mechanisms such self-stabilization) is the
performance, security, and implementation complexity.

In the DPAC framework, the vulnerabilities are comprehensive and well
defined. DPAC will not concern about confidentiality, authenticity,
and integrity of the payload. In particular, we focus on detecting
the following two types of attacks ONLY:
(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 module for these two types of attacks is very important
but not necessarily perfect. It is tolerable to accept a low degree of
either false negative or negative. In fact, it can be configured to
trade-off false negative (bad packets will go through) with false
positive (good packets will be dropped).  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

This is still a drafty draft. Our intention is to describe our
interest in realizing a practical network access control system for
the data packets.  Any comments and suggestions will be highly
appreciated.

References 

[SOLA]		Henric Johnson, "SOLA: A One-Bit Identify Authentication
		Protocol for Access Control in 802.11" in IEEE Globecom,
		November, 2002.
[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
	 Fan Zhao, Charlie Shin, S. Felix Wu
	 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