Authorization of a QoS Path based on Generic AAA. Leon Gommans, Cees de Laat, Bas van Oudenaarde, Arie Taal

Transcription

1 Abstract Authorization of a QoS Path based on Generic Leon Gommans, Cees de Laat, Bas van Oudenaarde, Arie Taa Advanced Internet Research Group, Department of Computer Science, University of Amsterdam. For data intensive Grid appications, such as shown at igrid2002, users may require short-ived guaranteed high bandwidth connections. These types of connections, providing a certain Quaity of Service QoS wi need to be authorized and provisioned, often through mutipe administrative domains. We present a case study of a Bandwidth on Demand service that provides a QoS path based on Generic Authorization, Authentication, Accounting, that represents a first step forward towards a muti domain soution. Keywords: QoS, Bandwidth on Demand; muti domain; Authentication Authorization Accounting 1. Introduction In this paper we discuss a middeware soution for the authorization of a Quaity of Service QoS path with a focus on high bandwidth. QoS represents vaue and, when used in an on demand fashion, needs poicy contro to aow cost effective usage. QoS path creation was first introduced with the Resource ReSerVation Protoco RSVP [1]. During the QoS path creation routers exchange RSVP requests and have the possibiity to pu a poicy decision from a poicy server using Common Open Poicy Service COPS [2]. In our approach a network of servers communicate Bandwidth on Demand BoD requests and use the agent sequence as defined in the Generic framework [3]. An advantage of the agent sequence is that the underying equipment does not have to carry as much inteigence as equipment using the sequence. Network equipment such as ayer 3 routers, ayer 2 switches or ayer 1 crossconnects are capabe of providing a QoS path with different eves of granuarity. Because of the agent sequence our focus is on a switchedike architecture as the more appropriate soution to authorize a QoS path. 2. Generic architecture An server may be invoved in handing one or more of three basic functions. The first function is Authorization of resource usage. Secondy, it verifies identities Authentication. Finay, the server may og key attributes of its functions so they can ater be used for Accounting purposes. The architecture of a Generic server is expained in [4]. We consider the authorization of a QoS path through mutipe administrative domains. As each administrative domain impements the authorization of its resources to an server, more than one server needs to communicate by means of requests in order to authorize a QoS path. A number of definitions exists for terms with respect to poicies, see for exampe [5] and [6]. In this paper we wi introduce the term Driving Poicy. In our appied mode, an server fetches a Driving Poicy when it receives an request. For each type of request there exists a corresponding Driving Poicy that instructs the server how to dea with the request, e.g. a Driving Poicy has to check the pre-conditions of the actions to be performed and how to dea with the post-conditions of these actions. We distinguish between specific actions and generic actions. Specific actions are performed by a so-caed Appication Specific Modue ASM, whereas generic actions are deegated to the generic part of an server. The provisioning of a path within a singe domain is typicay performed by an ASM. Providing the date is an exampe of a generic action. The modue that is responsibe to execute a Driving Poicy is the Rue Based Engine RBE and is contained in the Generic part of an server. Fig. 1 shows the different components of an server. The behavior of the generic part of an server is determined by the combination of Driving Poicies, ASM s and requests. This impies that behavior can be easiy adapted.

2 request / repy contro of the simpest eement. According to the used terminoogy, each QoS eement is a QoS component. Generic Driving Poicy ASM Fig. 1 The different components of an server. 3. Authorization / Contro modes In the context of Generic we consider a QoS path to be buid out of two eementary QoS eements: network nodes vertices and network inks edges, where the reevant parameters of a network node or network ink are under the contro of an server. This means that these parameters are governed by a set of poicies residing in the Poicy Repositories of the servers in contro. In genera a QoS path may span mutipe administrative domains. The foowing terminoogy is introduced to faciitate the mode discussion. We introduce the term QoS segment as the part of a QoS path that is under contro of a singe administrative domain. Each QoS eement is authorized by an server. Those eements of a QoS path beonging to a singe server are caed a QoS component. The server controing QoS eements shoud aso maintain the state of the assigned part of the QoS path condition. In this way, the whoe QoS path can be seen as a guaranteed end-to-end connection. Taking the simpest unidirectiona QoS path between two nodes, three different contros / authorization modes can be distinguished: Individua Contro, Partia contro, and Fu contro. 3.1 Individua Contro mode Each eement, network node or network ink, is managed individuay by an server. The servers execute their own and independent set of poicies. This mode offers individua Fig. 2 Individua Contro mode 3.2 Partia Contro mode. A singe set of poicies contros the usage of both a network node and its outgoing network ink fig. 3 or the set of poicies contros a network node and its incoming network ink fig. 4. This requires specific poicies to describe the negotiations with the neighboring eement. Both figures exist of two components. Fig. 3 Partia Contro mode with an outbound connection. Fig. 4 Partia Contro mode with an inbound connection.

3 3.3 Fu Contro mode. A singe server contros a three network eements of the simpe QoS path, i.e. the QoS component is a segment. Fig. 5 The Fu Contro mode. 4. Authorized path discovery. To show how an authorized QoS path through mutipe domains can be estabished, we make the foowing assumption. servers, especiay proxy servers have an underying mechanism that advertises the connections they can estabish. Athough not fuy researched yet by our group, we expect to be abe to re-use mechanisms such as BGP [7] or proposed extensions to this protoco that is referred to as Optica BGP to advertise reachabiity of networks within administrative domains. A purposey buid BGP ASM wi enabe an server to obtain a view on topoogy and discover which servers shoud be contacted aong the QoS path. Each server wi act as an agent or broker for its sub-domains. As the start for the setup of an authorized QoS path between two nodes, ΠD 0 and N n ΠD n, one of the contro modes shown in fig. 2-5 can be seected. If D 0 and D n are different administrative domains, the start situation wi be the simpest QoS path according to the Individua Contro mode or according to the Partia Contro mode. If D 0 and D n turn out to be the same administrative domain, a simpest QoS path according to the Fu Contro mode may aso be an appropriate choice. In genera mutipe domains are in pay, i.e. the network ink of the start situation wi be a ogica network ink instead of a physica network ink. Authorization of a QoS path between ΠD 0 and N n ΠD n is estabished through the foowing number of steps. Without oss of generaity we take the Fu Contro mode as the starting situation, with D 0 = D n and ogica network ink ~, see figure 6. and N n are authorized by 0, but for the ogica network ink ~ a physica soution must be found. ~ N n D 0 0,1 D 1 D 0 ~ N 2 2,n N n ,2 Fig. 6 The setup of a QoS path starting from the Fu Contro mode. 0

4 Therefore, 0 wi contact the server that advertises a connection between, N n. In fig. 6 it is 1,2 that advertised the required connection. Server 1,2 acts as a proxy server for two other servers: 1 and 2. 0 and 1,2 exchange requests to authorize the network inks 0,1 and 2,n. Fig. 6 shows that for the authorization of 0,1 1,2 resorts to 1 and for the authorization of 2,n 1,2 resorts to 2. This whoe process is started by a Driving Poicy residing at 0. According to the situation depicted in fig. 6 this process of authorization wi continue via 1, as this server sti contros a ogica network ink. As soon as a ogica network inks of the QoS path are authorized, this process of authorization has come to an end. The provisioning of the compete QoS path might be estabished by different approaches. One approach is to wait for provisioning unti the whoe QoS path is authorized. It is aso possibe to choose for an approach of successivey provisioning. More research is necessary to describe the roe of poicies in both of these approaches. 5. server authorization interactions For any QoS path a particuar server wi be the root of a decision network tree needed to authorize usage of the QoS eements invoved. A server interactions are poicy driven. Poicies may ask for a set of credentias or tokens to be present in the request that represents somebody ese s authorization or deegation of authority. For exampe these credentias or tokens may have been issued by an advance reservation system as a proof of a reservation. Poicies may invove parties in the decision that may or may not be hidden from the requesting party. For instance a budget- or payment authorization may be requested. Such checks may additionay invove parties unknown to the requestor. Next to the content of an request, that may need to carry a token or credentia that represents an authorization, aso the integrity, peer authenticity and sometimes confidentiaity of a request must be ensured. Here we rey on existing security mechanisms such as provided thru the GSS-API [RFC 2743] that offers support for these aspects. More specificay, tookits such as Gobus s Grid Security Infrastructure does aso rey on the GSS-API. Some eve of interoperabiity is offered when the GSS-API is depoyed with Pubic Key certificates issued by a GRID Certification Authority. The VOMS project [8], within the EU DataGRID and DataTAG project researches the definition of roes within Grid environments. Thru coaboration with the VOMS project we pan to integrate the concept of roes. A user roe may define that a particuar user is authorized to aocate bandwidth. 6. Case study For the case study presented we wi focus on scientific Grid users, who have a need for an ondemand high bandwidth QoS path. These users fa into a specific category of users that sets them far apart from reguar Internet users. Cassifying users for our purpose is a 3 dimensiona probem: The number of users can both be considered against the amount of bandwidth needed and the amount of destinations in need to be reached. In our case we are targeting a possibe soution for users that 802.1Q VLAN Swicth 1GB Optica 802.1Q VLAN Swicth Host A Host B Host C Host D Fig. 7 igrid 2002 demo setup

5 are both in need of very high amounts of bandwidth and are very imited towards the need to reach destinations. When considering the bandwidth usage ony, these users may fa into the category C as mentioned in the artice The rationae of Optica Networking [9]. Aso considering the fact that appications in this space may use appication specific adapted protocos to reach optima performance, this demonstration shows the authorization of a QoS path using ayer-2 switches. With data transfer programs such as GridFTP in mind, the shown configuration aows the creation of a by-pass channe that can be used as the data-channe in parae with the reguar Internet connection which in this case can be used as the contro channe. The actua technoogy choice for this mode was motivated by avaiabiity of ayer-2 switch technoogy donated by Enterasys Networks. The concept used however may be appied to any ayer 1, 2 or 3 technoogy that is capabe of creating QoS path.abstractions. The usage of the agent mode effectivey separates the contro pane and data forwarding pane. As most of the inteigence exists in the contro pane, depoyement of ess inteigent ayer 1 or 2 equipment in the data forwarding pane seems a more suitabe soution. In our test bed we have two 802.1Q VLAN switches interconnected by an optica fiber. Each switch connects two hosts, see fig. 7. The network ink is impemented as a Gigabit Ethernet connection. One of the hosts wi send an request for a BoD service via the reguar Internet to the server. The server wi fetch the BoD Driving Poicy that describes the pan of actions in order to achieve the authorization and provisioning of the connection. After success a QoS path is provisioned as a private network between the requesting hosts and the targeted host. More impementation detais are discussed the foowing section messages Both the top eve data objects to be carried in an protoco message and the various types of protoco messages have not formay been defined yet. Data objects and message types must be defined in an abstract way without regard to encoding. The message types defined coud be thought of as the Use Cases in the Unified Modeing Language sense for a generic server. The data objects specify what kinds of information can be routed among the servers in the Generic infrastructure. We have chosen to express the different types of messages in XML. The protoco consists of request-repy pairs. XML schemas define these request-repy pairs. An XML schema provides a means for defining the structure, content and the semantics of an XML document. In order to keep the discussion simpe an service request for bandwidth might ook ike: <Request type="bod" > <AuthorizationData> <Credentia> <Type>simpe</Type> <ID>JanJansen</ID> <Secret>#f034d</Secret> </Credentia> </AuthorizationData> <BodData> <Source> </Source> <Destination> </Destination> <Bandwidth>1000</Bandwidth> <StartTime>now</StartTime> <Duration>20</Duration> </BodData> </Request> The server returns a simpe answer to the invoker whether the authorization has succeeded or not. This answer is added as a text node to the XML repy shown beow: <Repy type="bod" > <Answer> <Message></Message> </Answer> </Repy> 6.2 Driving poicies In our poicy anguage a Driving Poicy is of the form IF Condition THEN ActionList ELSE ActionList '. The Driving Poicies can be expressed as nested if-then-ese structures, i.e. an if-then-ese structure might be part of a Condition as we as part of an Action List. As this is not the proper pace to fuy expain the poicy anguage we wi restrict ourseves to the exampe beow in order to convey its expressiveness. A Driving Poicy for an server that accepts the above request for bandwidth might ook ike:

6 IF ASM::Authorizer.authorize Request::AuthorizationData.Credentia. Type, Request::AuthorizationData.Credentia. ID, Request::AuthorizationData.Credentia. Secret THEN IF ASM::RM.CheckConnection Request::BodData.Source, Request::BodData.Destination THEN ActionList1 ELSE Repy::Answer.Message = "Request faied: Bad source or destination" ELSE Repy::Answer.Message = Request faied: Authorization not successfu. This Driving Poicy cas for authorization by an ASM caed Authorizer that contains a pubic method authorize. Three arguments have to be passed. The RBE can deduce that a arguments can be retrieved from the incoming request. If this ca returns a fase vaue the action in the ELSE-part instructs the RBE to add a fai text node to the XML repy. After success the ActionList of the THEN-part is executed. This ActionList contains a singe action, an if-thenese structure. A Resource Manager RM ASM is caed to check if a route between both end points of the QoS path can be estabished. In this fashion a number of pre-conditions are checked before the fina ca for bandwidth is made: RV = ASM::RM.BoD Request::SwitchData.Source, Request::SwitchData.Destination, Request::SwitchData.Bandwidth, Request::SwitchData.StartTime, Request::SwitchData.Duration By assigning the return vaue to the variabe RV, the return vaue is avaiabe in subsequent actions of the Driving Poicy. 6.3 ASM structure In our Bandwidth on Demand demonstration, we impemented a Resource manager ASM needed to deiver the BoD service. A Resource Manager RM ASM is responsibe for tracking the state and the discovery of the resources. The RM ASM aso guarantees QoS by avoiding oversubscribtion of the GigE network ink. For 802.1Q, the RM ASM administers the used VLAN tags to form the QoS path between the hosts. The RM ASM has aso awareness of the destinations based on the primary IP address of the end station and it is abe to discover the switch port the secondary interface is connected to. As such, the server does contro a simpe QoS path within a singe domain. 7. Concusions and future work The demonstrated case represents a first step into the usage of Generic for authorization within a singe domain. In this exampe a QoS path is authorized using a set of Driving Poicies executed by a RBE invoving ASM s. Generic mechanisms shoud aow the support of many combinations of different types of appications. Generic utimatey must support for exampe the combined authorization of a pay per view movie incuding QoS path based deivery across the network and a pizza to go aong with it. If one of these items cannot be deivered, the entire transaction shoud not be authorized to proceed. Athough such vision may not be reaized anywhere soon, it does set the direction for future work. The next steps wi be to put research into creating muti-domain scenario s invoving the pictured individua and partia contro modes to form more comprehensive networks. The path discovery functions that indicate which servers shoud be contacted does pay an integra roe. Further research wi aso be put into buiding compex decision networks where items such as scaabiity, stabiity and performance wi be investigated. Acknowedgements Enterasys Networks donated the equipment for this research. Leon Gommans and Bas van

7 Oudenaarde are funded by the IST Program of the European Union grant IST via the DataTAG project. Additiona funding was provided by the Dutch Nationa Research network SURFnet. The authors whish to thank the IRTF ARCHitecture Research Group for the fruitfu discussions, in particuar John Vobrecht and Dave Spence for their neverending coaboration. The authors woud ike to thank Joe Mambretti and Jeremy Weinberger for their support and contributions during igrid References [1] RFC2205 Resource ReSerVation Protoco RSVP Version 1 Functiona Specification, R. Braden et. a.,sept [2] RFC2748 The COPS Common Open Poicy Service Protoco, D. Durham et. a, Jan [3] RFC2904 Authorization framework, J. Vobrecht et. a. Aug [4] RFC2903 Generic Architecture, C. de Laat et. a. Aug [5] RFC3060 Poicy Core Information Mode -- Version 1 Specification, B. Moore et.a. Feb [6] A Poicy Description Language, J. Lobo et. a. Juy 1999 in proceedings of the American Association for Artificia Inteigence [7] RFC 1771 A Border Gateway Protoco 4 BGP-4, Y. Rekhter et. a. March [8] see references at project page at [9] The rationae of Optica Networking, Cees de Laat, Erik Radius, Steven Waace, IGRID2002 paper submitted to Future Generations Computer Systems, November 2002.