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)
  	        <draft-wu-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, 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