Activities

The purpose of this activity is to define the architecture and subsequently design, implement and test an AAA infrastructure to support policy based on-demand network resource provisioning and access control (or authorisation) across different administrative domains which are governed by Network Resource Provisioning Systems (NRPS) representing these domains. The research and development in this activity will address AAA related issues at all functional network planes: the Network provisioning plane, the Control plane and Data-forwarding plane.

Generic AAA Authorization Framework (GAAA-AuthZ) as described in RFC2904 and GFD.038 defines 3 basic authorization sequences: the push sequence where the user first requests an authorization decision from an authorization service, obtains some proof which s/he will next present to the resource in a service request; the pull sequence where the user directly submits a request to the resource and resource then request an authorisation decision from the authorization service; the agent sequence where the user and the resource delegate handling a service request to an agent. After the service request is authorized, the agent will provision the service.

AAA operational model for multidomain network resource allocation and provisioning can be described using one or more basic AAA sequences. These sequences may incorporate interactions with resource reservation and/or scheduling systems, (virtual or non-virtual) organizations providing user attributes etc.

• Polling sequence (P) when the user client polls all individual network domains to make a reservation.
• Relay (R) or hop-by-hop reservation when the user client contacts only the local network domain/provider and each consecutive domain provides path to the next domain.
• Agent (A) sequence when the User delegates network provisioning negotiation to the Agent that will do all necessary negotiations with all involved domains.

Figure 1 - Components involved into multidomain network resource provisioning and basic provisioning sequences

Figure 1 illustrates the major interacting components in a multi-domain provisioning scenario during two stages: network resource reservation and the reserved resource access. Access by dataflows to Network Elements (NEs) is controlled by a NRPS based on policy decisions made by a AAA service. Resource access control policy is enforced by placing a Policy Enforcement Point (PEP) at the entrance of the NRPS. Depending on the basic AAA-AuthZ sequence (push-, pull- or agent), the requestor can send an access request to the resource itself (NE), the resource control plane (NRPS) or AAA server which will act as a Policy Decision Point (PDP). The PDP identifies the applicable policy, collects the required context information and evaluates the request against the policy and makes a decision that can be used by the resource reservation system to assign the resource to the user or user request.

This activity will develop mechanisms to cryptographically bind data-flows to their origin or target applications and corresponding enforcement mechanisms when dataflow are sent over heterogeneous network infrastructure. Important component of such mechanisms is distribution of the key material between domains that allows creating overlay virtual infrastructure of the provisioned network. WP4 will work on an IETF ForCES based router extension that will act as a gateway between a general purpose IP network (e.g. campus network) and a dedicated GMPLS network, enforcing and providing tokens at both the IP and GMPLS side. It will allow the integration of token mechanisms inside GMPLS control plane layer using RFC2750 policy data object as a base.

The main part of this activity will be executed by UvA. UvA will work in cooperation with project partners to integrate AAA elements into target Phosphorus network provisioning systems and Grid-GMPLS in two forms as standalone AAA server and as GAAA Programming Interface (GAAAPI) which can be integrated into general Phosphorus middleware.

The Token Based Switch (TBS) based on ForCES architecture will be developed together with the University of Patras, Hitachi and other project partners.

This activity will use and contribute to the development of the Generic AAA Toolkit which is being developed in the framework of other projects such as Gigaport-NG and NextGrid.

Development of the GAAA-AuthZ middleware related components will be coordinated with other European projects such as EGEE and GEANT2 JRA3 and JRA5. This activity will also continue cooperation with the Internet2 OSCARS and DRAGON projects. The goal of such cooperation will be to achieve compatibility of the Phosphorus AAA infrastructure and those developed and currently used in other projects, namely GN2 eduGAIN, Internet2 Shibboleth, and EGEE VOMS attribute/federation services and access control infrastructure.

• Universiteit van Amsterdam
• Rheinische Friedrich-Wilhelms-Universität Bonn
• Research Academic Computer Technology Institute
• Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.
• Hitachi Europe SAS

Figure 2 - Authentication, Authorisation, Accounting (AAA) - brochures

Figure 3 - Supporting Communities in Programmable Grid Networks: gTBN - brochure (TNC'09)

Figure 4 - Authentication, Authorisation, Accounting (AAA) - brochure (TNC'09)