Chapter 12Application and Network ResourceAccess ControlMasum Z. Hasan12.1     IntroductionThere is a need for controlling...
248                                                                        M.Z. Hasanenhance security and effective functi...
12    Application and Network Resource Access Control                               249integrated ARAC and NRAC and networ...
250                                                                          M.Z. HasanFig. 12.1 Generic RAC flow• Resource...
12     Application and Network Resource Access Control                                        251Fig. 12.2 Network example...
252                                                                         M.Z. HasanFig. 12.3 ARAC flow   Each applicatio...
12    Application and Network Resource Access Control                              253     Consider the network shown in F...
254                                                                                 M.Z. HasanFig. 12.4 802.1x-based NRACI...
12    Application and Network Resource Access Control                              255     identified and configuration temp...
256                                                                     M.Z. HasanFig. 12.5 Queue servicingFig. 12.6 Netwo...
12   Application and Network Resource Access Control                              257Fig. 12.7 Firewall policy exampleFig....
258                                                                      M.Z. Hasanare embedded within the network device ...
12   Application and Network Resource Access Control                            259network devices. For example, in the us...
260                                                                        M.Z. Hasanabove). The ALGs do not usually inspe...
12   Application and Network Resource Access Control                             26112.8     ConclusionApplication and net...
262                                                                                     M.Z. HasanReferences 1. IEEE 802.1...
Upcoming SlideShare
Loading in …5

Network embedded management and applications


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Network embedded management and applications

  1. 1. Chapter 12Application and Network ResourceAccess ControlMasum Z. Hasan12.1 IntroductionThere is a need for controlling accesses to enterprise resources by human andnonhuman entities for effective and secure functioning of an enterprise. Typicalresource access control (RAC) involves the following functions:1. Authentication: An entity is allowed or denied access to a resource based on entity’s identity and credentials.2. Authorization: Once the entity is authenticated, further access control may be performed, where the entity is allowed or denied access to subresources or to perform certain actions on the resource. For example, once an entity is authenti- cated into a DB server, it may be authorized to access and manipulate (create, read, update, or delete) certain DB tables or their entries, but not other tables. Another example, an entity is authenticated into a network (such as an enterprise intranet), then authorized into certain segments of the intranet (authorized into proper VLAN). RAC typically is divided into two categories: application, server, and storage (orISO/OSI layer 7: L7) level RAC (Application RAC or ARAC) and network (layers1 to 3: L1–3) level RAC (NRAC). By employing detail use cases, we will discussthe functioning of both ARAC and NRAC. The frameworks1 used for these two levels of RACs are usually separate. Butintegration or interoperation of ARAC and NRAC (A/NRAC) frameworks will1 We refer to a framework to cover the following: software, hardware components (resource embed-ded or not), and systems, including operations support and management systems, protocols, andmessaging formats. A proper framework is needed to support a particular feature (which in thiscase is A/NRAC).M.Z. Hasan, Ph.D. (*)Cisco Systems, 170 West Tasman Drive, San Jose CA 95134, USAe-mail: masum@cisco.comA. Clemm and R. Wolter (eds.), Network-Embedded Management 247and Applications: Understanding Programmable Networking Infrastructure,DOI 10.1007/978-1-4419-6769-5_12, © Springer Science+Business Media New York 2013
  2. 2. 248 M.Z. Hasanenhance security and effective functioning of an enterprise. For example, when auser 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, whichis separate from the NRAC. Without proper integration of ARAC and NRAC(A/NRAC), it will be difficult to enforce certain policies that enhance security. Forexample, a policy may dictate that if the user is accessing from a particular networksegment (remote or wireless), then certain actions on the sensitive server will not beauthorized. 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 relevantpolicy management frameworks or systems. The policies are specified in a policyspecification language (PSL). There is no single widely accepted industry standardPSL. The OASIS XACML (eXtensible Access Control Markup Language) [2] is anexample of an ARAC (authorization) PSL. The Cisco Common Classification PolicyLanguage (C3PL) [3] is an example of an NRAC PSL. The policy model used inthese PSLs differs substantially. But it is possible to define a generic policyspecification model and its elements (subject, resource, etc.). We will discuss amodel, where the PSL elements will have extended scope so that both ARAC andNRAC policies can be specified via a common PSL. The PSL elements are based onthat of XACML. Note that we do not propose any specific language, rather a genericdefinition 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 apolicy enforcement point (PEP). The access control decision is made by the PDP byexecuting multiple policies configured by a policy administrator. The PEP thenenforces the decision. The PDP and PEP can be distributed. PDP typically residesoutside of the resource access to which is being controlled, whereas the PEP residesembedded within the resource, such as an application or server or a network, whichincludes router, switch, network appliance, or network OS (control, data, andembedded management planes). In certain cases, PDP can be embedded within theresource concerned. An application or ARAC PEP usually resides in the applicationresource being access controlled. But it may be possible to embed an ARAC PEP inthe network. We will discuss aspects of network-embedded NRAC PEP (such asPEPs for enforcing network QoS within a network device) and network-based ornetwork-embedded ARAC PEP (such as firewall ALG: application level gateway).The above concepts will be discussed employing detail use cases and with the aid ofsequence diagrams showing interactions between PDP, PEP, and other componentsor 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 anduse cases are discussed in Sect. 12.3. In Sect. 12.4, we discuss NRAC, whichincludes NRAC related to controlling user or (mobile) device access to network andNRAC applied on packets as they traverse through network resources. ARAC andNRAC joint operation is covered in Sect. 12.5, which includes interoperable or
  3. 3. 12 Application and Network Resource Access Control 249integrated 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. RAC FrameworkA 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 theXACML, 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. 4. 250 M.Z. HasanFig. 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 thenetwork. 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 andFig. 12.2 a PDP has to manage access control policies for multitude of resources
  5. 5. 12 Application and Network Resource Access Control 251Fig. 12.2 Network examplethat include different types of resources (many different types of application andnetwork resources). Hence instead of having a PDP for each type of resource, suchas one for web servers and another for DB servers, it is better to support a RACdeployment architecture where the PDP is centralized2 and consolidated for manyresource types in an enterprise.12.3 Application RACThe application resource access control deals with application, server, and storageor 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-specificprotocol may be used, such as the example shown in Fig. 12.3, where the protocolis 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 DBserver will interpret the message (e.g., COM_QUERY “sql stmnt” [5]) carried in theprotocol, 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. 6. 252 M.Z. HasanFig. 12.3 ARAC flow Each application type (as shown in Fig. 12.2) may have its own native and uniquefeatures, 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 intoan application feature agnostic component if standard-based framework (such as theXACML for authorization function of RAC or other standard) is supported.12.4 Network RACIn 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 networktraffic (IP packets, Ethernet frames, etc.). Controlling user or end device access toan 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 tohuman user or end device access control to network.12.4.1 User Access Control to NetworkWhen a subject (a human user via a computer) attempts access to a network (enterpriseintranet or any network segment), the PEP in a network access device3 (NAD), to whichthe subject’s device is connected to, enforces network access control policies with theaid 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. 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 andPIP and network PEP policies (possibly as configuration or configuration templates)into NADs. Assume that Employee 1 attempts access to his enterprise network.
  8. 8. 254 M.Z. HasanFig. 12.4 802.1x-based NRACIf his computer supports 802.1x [1] supplicant4 and his network supports802.1x-based access, then the policy execution sequence will be as shown inFig. 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 be4 A supplicant is a component of IEEE 802.1x that resides in an end device that attempts access toan enterprise network. An authenticator (a PEP) of IEEE 802.1x resides in an NAD that interceptsframes from the supplicant (subject) and forwards it to a PDP (a RADIUS sever) using the RADIUSprotocol [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. 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 and partner’s computer IP address has been identified as, then an ACL (access con- trol list) “permit ip host” 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 PacketFrom 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 isset as a VLAN, source MAC, or IP address in packets or frames originating from thesubject’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 thecontext 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 bemapped to some other context, such as a VLAN mapped to MPLS VPN VRF [7] orcertain IP header packet information, for example, DSCP or ToS QoS markinginformation [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)-specificnetwork policies (QoS, ACL, Firewall, etc.) can be applied at various segments ofthe network. The context of a packet does not necessarily have to be a user or an enddevice specific, rather application or service specific. For example, all VoIP (Voiceover IP) packets are policies controlled on network links (proper bandwidth andQoS 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 toaccess 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. 10. 256 M.Z. HasanFig. 12.5 Queue servicingFig. 12.6 Network QoS policy example2. 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. 11. 12 Application and Network Resource Access Control 257Fig. 12.7 Firewall policy exampleFig. 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 notconform to the PSL model described above. The PEP enforcing network policies (QoS, ACL, etc.) obviously is embedded ina network device. The PDP for network policy control may also be embedded in anetwork device or network OS. For example, as shown in Fig. 12.8, the NRAC PEPs
  12. 12. 258 M.Z. Hasanare embedded within the network device interfaces (interface cards), whereas thePDP 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 OperationNRAC and ARAC frameworks are typically separate. But it is possible to integratethem 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 NRACWe describe the above two options via use cases. The use case in Fig. 12.9 showsthat once the application resource authorization decision is made, the PDP cancommunicate network policy (configuration) decision as obligation to relevantFig. 12.9 Integration of ARAC and NRAC
  13. 13. 12 Application and Network Resource Access Control 259network devices. For example, in the use case, if the subject is about to insert alarge amount of data in a DB, then the network policy may guarantee, limit, orshape bandwidth at relevant locations of network. Another example, when securityincidence is detected by an application PEP, an obligation policy may dictate thatrelevant network ports are blocked for the subject (IP address or IP addressprefix).12.6 Network-Based or Network-Embedded ARACA use case involving network-based or embedded ARAC PEP is shown inFig. 12.10. As we have described above, application-specific PEPs typically reside withinthe application resource being access controlled. But it is possible to embed ARACPEPs in appropriate locations of a network. Existing firewalls already support theso-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 (sourceIP, destination IP, source port, destination port, protocol). The ALGs can also keeptrack of incoming dynamic ports (e.g., for data channels of the protocols mentionedFig. 12.10 Network-based ARAC
  14. 14. 260 M.Z. Hasanabove). The ALGs do not usually inspect deep into the packets as an applicationPEP 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 CloudWe provide a brief overview of how the ARAC and NRAC concepts discussedabove can be applied in a Cloud environment. The A/NRAC concepts discussed will mostly apply in the case of an enterpriseIT-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 anumber 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 thatis not enough. Looking at the concepts and use cases discussed above, it should beobvious 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 extendeddefinition we provided above) management, network contexts, and policies (VLAN,ACL, QoS, etc.).
  15. 15. 12 Application and Network Resource Access Control 26112.8 ConclusionApplication and network resource access control is very important for effective andsecure 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 ARACand 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. Employingdetail 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 witheach other to support a common framework for L1 to L7 integrated resource accesscontrol. Note that integration or interoperation does not preclude existence of sepa-rate administration domains. A PEP (ARAC or NRAC) by nature is embeddedwithin the resource being access controlled. We have shown how embedded andnon-embedded RAC components interact with each other for managing and enforc-ing RAC. Typically, an application ARAC PEP is embedded within the applicationresource being access controlled. In certain cases, it may be beneficial to embedARAC PEPs in proper locations of a network, such as a firewall or any networklocation away from network segments with sensitive resources. We have shown usecases for network-embedded ARAC PEP. We have also discussed briefly how theA/NRAC concepts described can be applied in a Cloud environment. Further R&D is needed for advanced integration of ARAC and NRAC, whichamong other issues should include a standard and common model for policyspecification and language. The XACML could be a starting point to look into. Asshown above, there are wide varieties of protocols and message formats that areused for interactions between subject and PEP, and PEP and PDP. A common andstandard wrapper protocol and messaging standard will be desirable. It should beobvious that configurability and programmability are two different features. A usercan 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 usuallymissing from network devices. A programmable network or network device willfacilitate programmable PEPs to be deployed in a network on demand and any time(postdeployment of the network device). Programmable ARAC PEP is especiallydesirable, for example, consider firewall ALG (which is an ARAC PEP) discussedabove. An enterprise that has deployed a firewall with limited set of ALG supportmay 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 thefirewall.
  16. 16. 262 M.Z. HasanReferences 1. IEEE 802.1x. 2. XACML (eXtensible access control markup language). tc_home.php?wg_abbrev=xacml 3. Cisco common classification policy language. access/cisco_router_and_security_device_manager/24/software/user/guide/C3PL.html 4. Remote Authentication Dial In User Service (RADIUS), RFC 2865. rfc2865 5. MySQL protocol. 6. Configuration guidelines for DiffServ service classes, RFC 4594. rfc4594 7. MPLS VPN VRF. 8. NIST definition of cloud. 9. Hasan MZ et al (2011) Seamless cloud abstraction, models and interfaces. In: Proceedings of the ITU/IEEE Kaleidoscope conference, Cape Town10. Hasan MZ et al (2011) Network abstraction for enterprise and SP class cloud: seamless cloud abstraction and interfaces, IETF draft. Clouds/draft-rfc-seamless-Cloud-masum-01.txt