2. 248 M.Z. Hasan
enhance security and effective functioning of an enterprise. For example, when a
user attempts access to her enterprise intranet (via a laptop), the IEEE 802.1x [1]-
based NRAC may control the access. Once the access to the network is granted,
accesses to, for example, a sensitive server may be controlled via an ARAC, which
is separate from the NRAC. Without proper integration of ARAC and NRAC
(A/NRAC), it will be difficult to enforce certain policies that enhance security. For
example, a policy may dictate that if the user is accessing from a particular network
segment (remote or wireless), then certain actions on the sensitive server will not be
authorized. The integration will also be useful in a Cloud computing (Cloud) envi-
ronment. Integrated or interoperable A/NRAC and Cloud RAC will be covered.
Accesses to resources are typically controlled via policies managed by relevant
policy management frameworks or systems. The policies are specified in a policy
specification language (PSL). There is no single widely accepted industry standard
PSL. The OASIS XACML (eXtensible Access Control Markup Language) [2] is an
example of an ARAC (authorization) PSL. The Cisco Common Classification Policy
Language (C3PL) [3] is an example of an NRAC PSL. The policy model used in
these PSLs differs substantially. But it is possible to define a generic policy
specification model and its elements (subject, resource, etc.). We will discuss a
model, where the PSL elements will have extended scope so that both ARAC and
NRAC policies can be specified via a common PSL. The PSL elements are based on
that of XACML. Note that we do not propose any specific language, rather a generic
definition of PSL elements.
A policy management framework may have multiple (execution or functional)
components. Two of the major components are a policy decision point (PDP) and a
policy enforcement point (PEP). The access control decision is made by the PDP by
executing multiple policies configured by a policy administrator. The PEP then
enforces the decision. The PDP and PEP can be distributed. PDP typically resides
outside of the resource access to which is being controlled, whereas the PEP resides
embedded within the resource, such as an application or server or a network, which
includes router, switch, network appliance, or network OS (control, data, and
embedded management planes). In certain cases, PDP can be embedded within the
resource concerned. An application or ARAC PEP usually resides in the application
resource being access controlled. But it may be possible to embed an ARAC PEP in
the network. We will discuss aspects of network-embedded NRAC PEP (such as
PEPs for enforcing network QoS within a network device) and network-based or
network-embedded ARAC PEP (such as firewall ALG: application level gateway).
The above concepts will be discussed employing detail use cases and with the aid of
sequence diagrams showing interactions between PDP, PEP, and other components
or entities.
The rest of the chapter is organized as follows: RAC policy management frame-
work, including definition of PSL elements, is discussed in Sect. 12.2. ARAC and
use cases are discussed in Sect. 12.3. In Sect. 12.4, we discuss NRAC, which
includes NRAC related to controlling user or (mobile) device access to network and
NRAC applied on packets as they traverse through network resources. ARAC and
NRAC joint operation is covered in Sect. 12.5, which includes interoperable or
3. 12 Application and Network Resource Access Control 249
integrated ARAC and NRAC and network-based or network-embedded ARAC.
The aspects of RAC in Cloud are covered in Sect. 12.6. We conclude in Sect. 12.7.
12.2 RAC Framework
A framework to support A/NRAC consists of the following core components:
• A/NRAC policy management framework, which includes the following:
○ Policy specification language (PSL)
○ Policy execution components consisting of the following (distributed) com-
ponents (we focus on aspects of PDP and PEP only):
– Policy Decision Point (PDP): A PDP is a policy execution component that
interprets or executes policies specified in a PSL to make decisions. A PDP
typically resides outside the resource, access to which is being controlled.
– Policy Enforcement Point (PEP): A PEP is the policy execution compo-
nent that enforces policy decisions. A PEP is embedded in the resource,
access to which is being controlled.
– Policy Information Point (PIP): A PIP stores various information about
entities and resources (such as an enterprise directory).
– Policy Administration Point (PAP): A PAP is used by policy administra-
tors to manage RAC policies.
• Protocols or messaging used to convey access control information, including
policy information between various components of A/NRAC, such as 802.1x [1]
and RADIUS [4] for NRAC
The policy specification elements are as follows, which are based on that of the
XACML, but definitions are extended to cover both ARAC and NRAC:
• Subject: A subject is a human or nonhuman entity that attempts to access and
manipulate resources. The subject may include other (nonhuman) logical enti-
ties, such as automated systems, software programs, applications, IP packets or
resources, etc. A few examples of extended definition of a (logical) subject is
provided below:
– A resource: Consider a web server (WS) or an application executing on the
WS (in the DMZ: demilitarized zone of an enterprise). A RAC policy may
dictate that the WS is not allowed direct access to a DB server located in a data
center. In this case, the WS is a subject with respect to the DB server. In other
words, a resource assumes the role of a subject. A policy specification will
explicitly identify it as a subject (as will be shown below). In the same way, a
human user is identified by a name or ID or credentials; a logical subject can
be identified accordingly, for example, by an IP address or an IP address and
port combination or a URI (Universal Resource Identifier).
– A logical entity: An IP packet or Ethernet frame (discussed further below).
4. 250 M.Z. Hasan
Fig. 12.1 Generic RAC flow
• Resource: A resource is an entity access to which is controlled. A resource does
not necessarily have to be a single or tangible entity. It can be a logical and aggre-
gated entity. For example, an enterprise intranet or network segment can be a
resource. A resource can have subresources (hierarchical or containment rela-
tionship with parent resource) to which RAC policies may be applied. For exam-
ple, Router/Switch → Link → Queue → Priority Queue or DB Server → DB
instance → A Table.
• Action: Actions, such as create/read/write/update/delete/access that a subject is
attempting to perform on the resources.
• Policy Rule Condition: Conditions on subjects and resources that should be
checked by PDP or PEP before performing specified actions.
• Effect: If policy condition is satisfied, then the policy may dictate that the
requested action is allowed, denied, or indeterminate.
• Obligation (PEP Policy): If the action is allowed or denied, what other actions
are performed on the resources at the enforcement point (enforced by the PEP).
<this is fine > For example, if a subject is allowed (effect) the requested write
action on a resource, then the (PEP) policy may dictate that further action (obli-
gation) is performed by the PEP, such as log the action in a file with associated
data or email a message that the action has been performed. Another example, if
a subject is allowed access to a network, then the PEP is obligated (via PEP
policy) to place the subject (packets or frames originating from subject’s device)
on a particular VLAN.
A generic RAC execution flow is shown in Fig. 12.1.
As we show later, the PDP and PEP components can be distributed over the
network. A PEP is embedded within the resource, access to which is being con-
trolled, whereas a PDP may or may not be embedded. As shown in Fig. 12.1 and
Fig. 12.2 a PDP has to manage access control policies for multitude of resources
5. 12 Application and Network Resource Access Control 251
Fig. 12.2 Network example
that include different types of resources (many different types of application and
network resources). Hence instead of having a PDP for each type of resource, such
as one for web servers and another for DB servers, it is better to support a RAC
deployment architecture where the PDP is centralized2 and consolidated for many
resource types in an enterprise.
12.3 Application RAC
The application resource access control deals with application, server, and storage
or L7 resource access control. An example of an ARAC policy is as follows:
• Subject: A DB user, such as a physician.
• Resources: A DB server and medical record tables.
• Action: Write on a table.
• Policy Rule Condition: If the subject ID/group = “physician” && Computer_
IP_address = “192.168.10.*”.
• Effect: Permit.
• Obligation: Encrypt data before writing and log the action.
When a subject accesses a resource (over the network), an application-specific
protocol may be used, such as the example shown in Fig. 12.3, where the protocol
is the MySQL protocol [5]. When a subject attempts access (a DB in this example)
and perform action on the resource (DB table), the PEP embedded within the DB
server will interpret the message (e.g., COM_QUERY “sql stmnt” [5]) carried in the
protocol, extract content, and send it to the PDP for policy decision.
2
Note that “centralized” does not preclude use of distributed or clustered architecture.
6. 252 M.Z. Hasan
Fig. 12.3 ARAC flow
Each application type (as shown in Fig. 12.2) may have its own native and unique
features, such as data structure or model, protocol, or messaging format supported.
Hence there is a need for application-specific PEP. The PDP can be separated into
an application feature agnostic component if standard-based framework (such as the
XACML for authorization function of RAC or other standard) is supported.
12.4 Network RAC
In this section, two aspects of NRAC are discussed: controlling human or end device
(such as a mobile device) access to network and access control applied on network
traffic (IP packets, Ethernet frames, etc.). Controlling user or end device access to
an enterprise network is known as the network access control or NAC. We general-
ize NAC as NRAC to cover any network resource access control, in addition to
human user or end device access control to network.
12.4.1 User Access Control to Network
When a subject (a human user via a computer) attempts access to a network (enterprise
intranet or any network segment), the PEP in a network access device3 (NAD), to which
the subject’s device is connected to, enforces network access control policies with the
aid of an NRAC PDP. We provide a few use cases and relevant policies below.
3
A NAD is an access switch or a wireless access point.
7. 12 Application and Network Resource Access Control 253
Consider the network shown in Fig. 12.2 and the following policy specifications:
1. Policy 1:
(a) Subject: Employee 1.
(b) Resources: Networks (network segments): Intranet, Internet, and Cloud;
Servers: All.
(c) Action: The subject attempts access to specified resources anytime.
(d) Policy Rule Condition: If subject belongs to a group authorized to the
specified resources, then apply effect.
(e) Effect: Permit access request.
(f ) Obligation (network PEP policy): Allow the subject on VLAN 10 (allows
access to all the resources above, assuming that all the network segments are
on or reachable via the VLAN 10). The subject is assigned Gold priority in
the network, that is, any packet or frame originating from the subject’s
device is marked by the PEP with proper QoS marking [6], and they are
queued on a network interface queue allocated for Gold priority.
2. Policy 2:
(a) Subject: Employee 2.
(b) Resources: Networks (network segments): enterprise intranet only; Servers:
HR servers.
(c) Action: The subject attempts access to specified resources anytime.
(d) Policy Rule Condition: If subject belongs to a group authorized to the
specified resources, then apply effect.
(e) Effect: Permit access request.
(f ) Obligation (network PEP policy): Allow subject on VLAN 30 and apply
Silver QoS.
3. Policy 3:
(a) Subject: Partner.
(b) Resources: Networks (network segments): Server 1 only and public
Internet.
(c) Action: The subject attempts access to specified resources anytime.
(d) Policy Rule Condition: If subject device IP address = “10.10.20.*”, then
apply effect (assuming the IP address is from a preassigned partner pool).
(e) Effect: Permit access request.
(f ) Obligation (network PEP policy): Allow subject on VLAN 50 and apply
Bronze QoS.
Above policy and user information has to be configured into relevant PDP and
PIP and network PEP policies (possibly as configuration or configuration templates)
into NADs. Assume that Employee 1 attempts access to his enterprise network.
8. 254 M.Z. Hasan
Fig. 12.4 802.1x-based NRAC
If his computer supports 802.1x [1] supplicant4 and his network supports
802.1x-based access, then the policy execution sequence will be as shown in
Fig. 12.4 (details of the protocols involved is outside the scope).
A few notes based on the discussion above:
• The policy execution framework is distributed with multiple components distrib-
uted over the network, where the NRAC PEPs are embedded within the network
devices and the PDP is centralized. In the later section, we will show that certain
NRAC PDP can be embedded in a network device (network OS control, data, or
management plane).
• A policy specification may have multiple components, the main policy compo-
nent is executed in PDP and the local enforcement policies are executed in PEP.
The obligation is the local PEP policy.
• Policies are configured statically but applied dynamically. PEP or obligation
policies may also be instantiated dynamically from a configuration template and
then applied. For example, in the above examples, a subject-specific VLAN or
QoS is configured dynamically when the subject is granted access into the
network. Subject-related parameters (such as IP or MAC address) might be
4
A supplicant is a component of IEEE 802.1x that resides in an end device that attempts access to
an enterprise network. An authenticator (a PEP) of IEEE 802.1x resides in an NAD that intercepts
frames from the supplicant (subject) and forwards it to a PDP (a RADIUS sever) using the RADIUS
protocol [4]. The authenticator then enforces PEP policies based on the decision from the PDP.
This is a simplified description; details are outside the scope.
9. 12 Application and Network Resource Access Control 255
identified and configuration template instantiated dynamically. For example,
consider the policy 3 above. If Server 1 IP address is 10.10.20.2 and partner’s
computer IP address has been identified as 10.10.30.5, then an ACL (access con-
trol list) “permit ip host 10.10.30.5 10.10.20.2” will be instantiated and applied
dynamically at the NAD port connecting the subject’s computer. Once the sub-
ject logs out or stays inactive (for specified duration), the instantiation may be
removed dynamically.
12.4.2 Access Control Applied to Packet
From the perspective of policy application on IP packets or Ethernet or other frames,
a packet or frame can be considered a (logical) subject. A packet or frame may
“belong” to a subject, human, or end device, where the context about the subject is
set as a VLAN, source MAC, or IP address in packets or frames originating from the
subject’s device. The packet or frame (in what follows, we will refer to packet only)
with the context set then becomes a subject. As a packet traverses through a net-
work, policies such as QoS or ACL may be applied on the packet based on the
context in the packet. Through the course of packet’s traversal through various net-
work segments (L2, L3, MPLS, Optical, NAT, etc.), the original context may be
mapped to some other context, such as a VLAN mapped to MPLS VPN VRF [7] or
certain IP header packet information, for example, DSCP or ToS QoS marking
information [6] copied to the outer header of an IPSEC tunnel packet. The map-
pings preserve the context of the subject so that subject (or subject group)-specific
network policies (QoS, ACL, Firewall, etc.) can be applied at various segments of
the network. The context of a packet does not necessarily have to be a user or an end
device specific, rather application or service specific. For example, all VoIP (Voice
over IP) packets are policies controlled on network links (proper bandwidth and
QoS policies applied). In order to provide a consistent model of policy manage-
ment, we can consider a packet identified by its context(s) as a subject attempting to
access network resources (such as links, queues, or network segments).
We provide a few use cases below:
1. Policy 1: Apply QoS policy on packets.
(a) Subject: Any packet.
(b) Resource: A router/switch interface (link).
(c) Action: Access to interface. The subject is attempting access to an
interface.
(d) Policy Rule Condition: If packet is marked (context) with (DiffServ [6])
DSCP = EF (Expedited Forwarding) or five tuple (source address, destination
address, source port, destination port, protocol number) in the subject
matches with specified rule (ACL), then apply effect.
(e) Effect: Permit packet into the interface.
(f) Obligation: Place subject onto the priority Q on the interface (as shown in
Fig. 12.5).
10. 256 M.Z. Hasan
Fig. 12.5 Queue servicing
Fig. 12.6 Network QoS policy example
2. Policy 2: Apply firewall policy on packets.
(a) Subject: Any packet.
(b) Resource: Firewall interface (“inside” or protected side).
(c) Action: Access to resource. The subject is attempting access to the resource
(cross the “inside” interface of a firewall).
(d) Policy Rule Condition: If URL in the HTTP packets contains exe/com/bat.
(e) Effect: Deny the subject through the interface.
(f) Obligation: Reset connection and log action (firewall PEP performs this
action).
11. 12 Application and Network Resource Access Control 257
Fig. 12.7 Firewall policy example
Fig. 12.8 Network-
embedded PDP
Examples of policy specifications for Policy 1 and 2 above using Cisco C3PL [3]
are shown in Fig. 12.6 and Fig. 12.7, respectively. Note that the specifications do not
conform to the PSL model described above.
The PEP enforcing network policies (QoS, ACL, etc.) obviously is embedded in
a network device. The PDP for network policy control may also be embedded in a
network device or network OS. For example, as shown in Fig. 12.8, the NRAC PEPs
12. 258 M.Z. Hasan
are embedded within the network device interfaces (interface cards), whereas the
PDP that controls policies on multiple interfaces is embedded in the control or man-
agement plane of a network OS.
12.5 ARAC and NRAC Joint Operation
NRAC and ARAC frameworks are typically separate. But it is possible to integrate
them in two ways:
1. Integrate or interoperate frameworks and operations of ARAC and NRAC.
2. Network-based or network-embedded ARAC capabilities.
12.5.1 Integrated or Interoperable ARAC and NRAC
We describe the above two options via use cases. The use case in Fig. 12.9 shows
that once the application resource authorization decision is made, the PDP can
communicate network policy (configuration) decision as obligation to relevant
Fig. 12.9 Integration of ARAC and NRAC
13. 12 Application and Network Resource Access Control 259
network devices. For example, in the use case, if the subject is about to insert a
large amount of data in a DB, then the network policy may guarantee, limit, or
shape bandwidth at relevant locations of network. Another example, when security
incidence is detected by an application PEP, an obligation policy may dictate that
relevant network ports are blocked for the subject (IP address or IP address
prefix).
12.6 Network-Based or Network-Embedded ARAC
A use case involving network-based or embedded ARAC PEP is shown in
Fig. 12.10.
As we have described above, application-specific PEPs typically reside within
the application resource being access controlled. But it is possible to embed ARAC
PEPs in appropriate locations of a network. Existing firewalls already support the
so-called ALG (application level gateway), such as SQL*Net, FTP, H.323, SIP, etc.
But these (state-based) firewalls usually check five fields of TCP/UDP traffic (source
IP, destination IP, source port, destination port, protocol). The ALGs can also keep
track of incoming dynamic ports (e.g., for data channels of the protocols mentioned
Fig. 12.10 Network-based ARAC
14. 260 M.Z. Hasan
above). The ALGs do not usually inspect deep into the packets as an application
PEP will do. There are the challenges in embedding ARAC PEPs inside the net-
work, which includes the following:
• Deep packet inspection (DPI) is a technically challenging task.
• States (such as TCP states) should be managed in intermediate points in network
where network-based ARAC PEPs are deployed.
• There are too many applications and relevant protocols and messaging formats,
including the ones that are proprietary and vendor specific.
• Traffic may be encrypted (unless connections are terminated and decrypted at the
points where ARAC PEPs are embedded).
12.7 RAC in Cloud
We provide a brief overview of how the ARAC and NRAC concepts discussed
above can be applied in a Cloud environment.
The A/NRAC concepts discussed will mostly apply in the case of an enterprise
IT-owned and IT-operated private Cloud [8]. In the case of a hybrid Cloud [8–10],
where an enterprise consumes resources from a public Cloud [8], there can be a
number of options:
1. An enterprise can use its ARAC/NRAC systems to authorize a subject to the
Cloud, including what kind of action the subject can perform in the Cloud. For
example, a subject can be authorized into a public Cloud when the subject logs
onto the network using the NRAC framework described in Sect. 12.4.1, where
the PEP policy (obligation) authorizes the subject onto a specific VLAN, traffic
in which is allowed into a public Cloud (as shown in Fig. 12.2) used by the sub-
ject’s enterprise. Once in the Cloud, further authorization may be necessary, such
as whether the subject is authorized to create a VM in the Cloud or not. The latter
capability requires integration of enterprise NRAC/ARAC with that of the Cloud
(the details of how to achieve this effectively is beyond the scope and a topic of
further investigation or research).
2. A public Cloud provider can offer ARAC/NRAC services for the resources that
enterprise subjects use. An enterprise ARAC/NRAC can then be interfaced with
this service.
Note that typical solutions support a single sign-on (SSO) mechanism. But that
is not enough. Looking at the concepts and use cases discussed above, it should be
obvious that ARAC and NRAC are not just about human user’s identity and creden-
tial management (as in SSO frameworks) but also about resource (in the extended
definition we provided above) management, network contexts, and policies (VLAN,
ACL, QoS, etc.).
15. 12 Application and Network Resource Access Control 261
12.8 Conclusion
Application and network resource access control is very important for effective and
secure functioning of an enterprise. We have discussed policy management frame-
works used to support A/NRAC in an enterprise, focusing on policy execution com-
ponents PDP and PEP and policy specification elements. The frameworks for ARAC
and NRAC evolve separately (especially as a consequence of separation of enter-
prise administration domains, such as compute, storage, network, security, WAN,
etc.). We have shown that integrated or interoperated ARAC and NRAC will facili-
tate advanced RAC, including advance security for resource access. Employing
detail use cases, we have shown why and how ARAC and NRAC should have com-
mon policy management model and how they can be integrated or interfaced with
each other to support a common framework for L1 to L7 integrated resource access
control. Note that integration or interoperation does not preclude existence of sepa-
rate administration domains. A PEP (ARAC or NRAC) by nature is embedded
within the resource being access controlled. We have shown how embedded and
non-embedded RAC components interact with each other for managing and enforc-
ing RAC. Typically, an application ARAC PEP is embedded within the application
resource being access controlled. In certain cases, it may be beneficial to embed
ARAC PEPs in proper locations of a network, such as a firewall or any network
location away from network segments with sensitive resources. We have shown use
cases for network-embedded ARAC PEP. We have also discussed briefly how the
A/NRAC concepts described can be applied in a Cloud environment.
Further R&D is needed for advanced integration of ARAC and NRAC, which
among other issues should include a standard and common model for policy
specification and language. The XACML could be a starting point to look into. As
shown above, there are wide varieties of protocols and message formats that are
used for interactions between subject and PEP, and PEP and PDP. A common and
standard wrapper protocol and messaging standard will be desirable. It should be
obvious that configurability and programmability are two different features. A user
can configure a PDP or PEP with policies specified in a policy specification lan-
guage. But users can configure policies related to existing features only. With pro-
grammability, support for new features can be programmed, a capability usually
missing from network devices. A programmable network or network device will
facilitate programmable PEPs to be deployed in a network on demand and any time
(postdeployment of the network device). Programmable ARAC PEP is especially
desirable, for example, consider firewall ALG (which is an ARAC PEP) discussed
above. An enterprise that has deployed a firewall with limited set of ALG support
may want to inspect a new application it has deployed. If the firewall was program-
mable, the enterprise could program an ARAC PEP (ALG) and deploy on the
firewall.
16. 262 M.Z. Hasan
References
1. IEEE 802.1x. http://www.ieee802.org/1/pages/802.1x.html
2. XACML (eXtensible access control markup language). http://www.oasis-open.org/committees/
tc_home.php?wg_abbrev=xacml
3. Cisco common classification policy language. http://www.cisco.com/en/US/docs/routers/
access/cisco_router_and_security_device_manager/24/software/user/guide/C3PL.html
4. Remote Authentication Dial In User Service (RADIUS), RFC 2865. http://tools.ietf.org/html/
rfc2865
5. MySQL protocol. http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol
6. Configuration guidelines for DiffServ service classes, RFC 4594. http://tools.ietf.org/html/
rfc4594
7. MPLS VPN VRF. http://en.wikipedia.org/wiki/VRF
8. NIST definition of cloud. http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf
9. Hasan MZ et al (2011) Seamless cloud abstraction, models and interfaces. In: Proceedings of
the ITU/IEEE Kaleidoscope conference, Cape Town
10. Hasan MZ et al (2011) Network abstraction for enterprise and SP class cloud: seamless cloud
abstraction and interfaces, IETF draft. http://trac.tools.ietf.org/area/app/trac/attachment/wiki/
Clouds/draft-rfc-seamless-Cloud-masum-01.txt
![248 M.Z. Hasan
enhance security and effective functioning of an enterprise. For example, when a
user attempts access to her enterprise intranet (via a laptop), the IEEE 802.1x [1]-
based NRAC may control the access. Once the access to the network is granted,
accesses to, for example, a sensitive server may be controlled via an ARAC, which
is separate from the NRAC. Without proper integration of ARAC and NRAC
(A/NRAC), it will be difficult to enforce certain policies that enhance security. For
example, a policy may dictate that if the user is accessing from a particular network
segment (remote or wireless), then certain actions on the sensitive server will not be
authorized. The integration will also be useful in a Cloud computing (Cloud) envi-
ronment. Integrated or interoperable A/NRAC and Cloud RAC will be covered.
Accesses to resources are typically controlled via policies managed by relevant
policy management frameworks or systems. The policies are specified in a policy
specification language (PSL). There is no single widely accepted industry standard
PSL. The OASIS XACML (eXtensible Access Control Markup Language) [2] is an
example of an ARAC (authorization) PSL. The Cisco Common Classification Policy
Language (C3PL) [3] is an example of an NRAC PSL. The policy model used in
these PSLs differs substantially. But it is possible to define a generic policy
specification model and its elements (subject, resource, etc.). We will discuss a
model, where the PSL elements will have extended scope so that both ARAC and
NRAC policies can be specified via a common PSL. The PSL elements are based on
that of XACML. Note that we do not propose any specific language, rather a generic
definition of PSL elements.
A policy management framework may have multiple (execution or functional)
components. Two of the major components are a policy decision point (PDP) and a
policy enforcement point (PEP). The access control decision is made by the PDP by
executing multiple policies configured by a policy administrator. The PEP then
enforces the decision. The PDP and PEP can be distributed. PDP typically resides
outside of the resource access to which is being controlled, whereas the PEP resides
embedded within the resource, such as an application or server or a network, which
includes router, switch, network appliance, or network OS (control, data, and
embedded management planes). In certain cases, PDP can be embedded within the
resource concerned. An application or ARAC PEP usually resides in the application
resource being access controlled. But it may be possible to embed an ARAC PEP in
the network. We will discuss aspects of network-embedded NRAC PEP (such as
PEPs for enforcing network QoS within a network device) and network-based or
network-embedded ARAC PEP (such as firewall ALG: application level gateway).
The above concepts will be discussed employing detail use cases and with the aid of
sequence diagrams showing interactions between PDP, PEP, and other components
or entities.
The rest of the chapter is organized as follows: RAC policy management frame-
work, including definition of PSL elements, is discussed in Sect. 12.2. ARAC and
use cases are discussed in Sect. 12.3. In Sect. 12.4, we discuss NRAC, which
includes NRAC related to controlling user or (mobile) device access to network and
NRAC applied on packets as they traverse through network resources. ARAC and
NRAC joint operation is covered in Sect. 12.5, which includes interoperable or](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)