Generic AAA* based Bandwidth on Demand EVL at UIC meeting Leon Gommans * Authentication Authorization & Accounting EVL at UIC meeting Chicago 18/10/2002 Leon Gommans Advanced Internet Research Group University of Amsterdam lgommans@science.uva.nl

Content Goals and basic list of requirements. Lightpath and Lightpath control concepts Generic AAA concepts High level design and operation of proof of concept. Example of a simple request message and policy. - Next work items Content: First this presentation will say a few words about the relationship between the DataTAG WP4 description and the associated WP4.2 task description as to validate the context of the work. Recent discussions within the Projects Board have indicated such a need. Then we will show some light on the underlying concepts and some definitions of what we mean with a Lightpath and Generic AAA. Based on these concepts we have identified a testbed that allows us to play with one of the models based of these fundamental concepts. This presentation will also show some of the involved messages and policies including some technical details. Arie Taal and Bas van Oudenaarde are the guys who handle the design details and technical implementations.

Goal Allow a provisioned Lightpath to by-pass a regular internet connection. Internet connection becomes control channel. Motivation: Routed networks are too expensive if requested bandwidth is in the order of the traffic generated by a nations NRN TCP stack & transport channel needs tailored behavior to make optimal use of a high speed ( GB ), high delay (>100ms) channel Modifications generates Internet “unfriendly” TCP traffic. Firewalls do (not yet) statefully inspect 10 GB/S streams without delays or performance implications. Single Packet drop causes severe performance hits. Memory buffers in routers/switches are a concern when the road gets smaller. Thes considerations have been used to identify the need for this project: This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side. If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified. Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored. Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance. The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA. The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario. The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

Rough requirements list. Allow lightpath usage in a “demand driven” fashion. Allow “hard” or “soft” pre-allocation. Must support allocation and usage across multiple domains. Must be integrated into middleware e.g. by allowing provisioned by-pass model to be supported by GridFTP. Raised this with GGF Data Transport RG (Bill Allcock). Allow authorized VO’s or individual users to discover available lightpaths (e.g. via a OGSA/WS style interface). Allow authorized users (with a certain role within the VO) to pre-allocate and use bypass for a limited amount of time and with limits on the allocated bandwidth. Must integrate with existing authentication & user (role based) authorization system: Looking into EDG VOMS. Thes considerations have been used to identify the need for this project: This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side. If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified. Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored. Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance. The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA. The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario. The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

Rough requirements list. Must hide complexity from user. Conceptually the user must perform the process in 3 basic steps after login: Pre-allocate either manually or automatically thru a scheduling system -> system issues an authorization. Allow the job to allocate the network resource whereby it uses the authorization. Once the job is finished, the authorization is handed back so resources can be freed. User (or scheduling system) must be allowed to change the reservation if the process flow so dictates. Allocating user may be different from ultimate user. Allocating user may subdivide capacity amongst users. Must ultimately support Grid Economic Services Architecture features to allow ad hoc creation. Must ultimately provide Grid Accounting records for billing in contract situations. Thes considerations have been used to identify the need for this project: This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side. If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified. Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored. Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance. The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA. The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario. The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

Design considerations. Group in Amsterdam does focus on deploying Generic AAA (RFC2903/RFC2904) concepts to handle authorization of lightpath. Group members were authors. Best suited to handle policy based authorization in a dynamic fashion either to build AuthZ tokens or process requests which contain AuthZ tokens. Note AuthZ may itself also contain policies. Authorizations between administrative domains must be done at a fairly high-level. Don’t want to address low level networking problems (path finding/setup) as vendors and researchers like ICAIR are already active in this area Need to identify role, messages and policies that are handled by Generic AAA components as part of the overall “workflow”. Thes considerations have been used to identify the need for this project: This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side. If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified. Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored. Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance. The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA. The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario. The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

Lightpath Def*: Any uni-directional point to point connection with effective guaranteed bandwidth Examples of LightPaths: * Analog wavelength on a CWDM or DWDM system * STS channel on a SONET or SDH circuit * ATM CBR circuit * Diff serv “gold” service on a packet based network * Gigabit Ethernet over dedicated fiber strand * Definition by Bill St. Arnoud of Canarie In a recent workshop at Canarie, Bill St. Arnaud introduced a term called a “Lightpath”. The definition most people seem to be happy with is “Any uni-directional point to point connection with effective guaranteed bandwidth.” Bill argued that a Lightpath could be implemented using various network technologies such as CWDM, DWDM, STS channels on a SONET/SDH circuit, ATM CBR circuit, A dedicated Diffserv Gold channel or GBE channels. Within our group at UvA, research is done into the formal representation of fiberconnections and its associated equipment. A mathematical representation using directed graphs with edges and vertrices are currently investigated as one way to present a network of switches and links. Some fundamental concepts are important to recognize: We identified 2 different classes of models: the Union and the Daisy Chain model.

Onion Lightpath model Domain Y DomainY Domain X Domain X Selector Switch Distributor Switch Domain X DomainY Domain X Selector Switch Distributor Switch Domain Y The Union model is most applicable in situation where a provider offers connections across its domain and possibly use underlying domains to provide connections. To the outside world the model appears to have an ingress and an egress switch with a connection in between. The connection in between may subsequently be formed by another Union model configuration thus from a recursive definition of this type of network. Domain X and Y in above picture each independantly control a set of ingress and egress switches. This observation is the significant differentiator between this model and the Daisy Chain model, explained on the next slide.

Daisy Chain Lightpath model Domain A Domain B Domain C Domain D The Daisy Chain model is more typical for customers feeding into a network or (facing it in a uni-directional fashion) drain from the network. In this model a domain consist out of one (or more) ingress switches or one (or more) egress switches. Although the physical ownership of the involved fiber may be different, in our model we assume that the “control” ownership of a fiber is attached to the outgoing port of the ingress switch or the incomming port of an egress switch. When a conflict of interest arises, the ingress switch takes precedence as shown in above picture. Note that by doing this, althoug a fiber cable, housing multiple pairs, is typically own by a single party – the control ownership may be from multiple parties.

Daisy Chain & Onion Domain A Domain B Domain X Domain C Domain D DomainY Domain X

Onion control model AAA Domain AAA engine must control Seector Switch Distributor Switch Domain X Domain Y AAA Domain AAA engine must control both selector and distributor switch and Interconnecting network

Daisy chain control model Selector Switch Distributor Switch Domain A Domain B AAA AAA Domain AAA engine must control the selector or distributor switch and one of the AAA Servers must control intermediate network

Generic AAA 5 years ago a AAA server was known as a server supporting dail-in boxes thru the RADIUS protocol (at IETF). IETF42 (in same hotel as GGF6) held first AAA BOF as it was recognized AAA could be used in other type of applications. Amsterdam group has been participating on defining concepts for Generic AAA since march 1999 when AAA WG was formed at IETF-44 Work became IRTF subject end of 1999 (AAA ARCH RG). ID’s that became RFC’s 2903 – 2906 were submitted after the Adelaide IETF march 2000. RFC’s describe framework, architecture, example applications and requirements. Optical Networking within grid environment is a research application for Generic AAA.

RFC 2904 Generic AAA Framework basic principles 1 1 User User 2 User 4 2 2 1 3 3 3 Service Service Service 4 4 Pull sequence NAS (remote access) RSVP (network QoS) Agent sequence Agents, Brokers, Proxy’s. Push sequence. Tokens, Tickets, AC’s etc. 3 fundamentally different user initiated authorization sequences. Note: RFC2904 does not show step 5 – service access.

Generic AAA Framework AAA AAA User Service User Home Organization 3 4 AAA User Service Provider 2 1 5 Service 6 Separating the User Awareness from the Service yield Roaming Models: Example roaming pull model.

Generic AAA Framework AAA AAA AAA User Service Service User Home Organization AAA AAA User Service Service AAA Client Service Provider A Service Provider B Distributed Services Models allow many types and combination of authorization sequences ..

Generic AAA Architecture – RFC2903 Fundamental idea’s inspired by work of the IETF RAP WG that in RFC 2753 describes a framework for Policy-based Admission Control. Foundation for COPS Policy Decision Point The point where policy decisions are made. Policy Repository Request Decision Policy Enforcement Point The point where the policy decisions are actually enforced. Basic Goal Generic AAA: Allow policy decisions to be made by multiple PDP’s belonging to different administrative domains.

Generic AAA Architecture – RFC2903 PDP Rule Based Engine Archieve goal by by separating the logical decision process from the application specific parts within the PDP. Policy Repository Application Specific Module Request Decision Policy Enforcement Point

Example of Generic AAA Architecture – RFC2903 Rule Based Engine Rule Based Engine Rule Based Engine Policy Repository Policy Repository Policy Repository Application Specific Module Application Specific Module Application Specific Module Contracts Budgets Users AAA Server AAA Server AAA Server User Bandwidth Broker Purchase Dept. Registration Dept. (Virtual) User Organization QoS Enabled Network Service Bandwidth Provider Service Organization

A C B D Generic AAA (RFC2903) based Bandwidth on Demand Policy DB 192.168.1.5 192.168.2.3 192.168.2.4 192.168.1.6 A 802.1Q VLAN Switch Enterasys Matrix E5 802.1Q VLAN Switch Enterasys Matrix E5 C 1 GB SX B D Policy DB AAA AAA Request iGrid2002

A C B D Generic AAA (RFC2903) based Bandwidth on Demand Policy DB 192.168.1.5 192.168.2.3 192.168.2.4 192.168.1.6 A 802.1Q VLAN Switch Enterasys Matrix E5 802.1Q VLAN Switch Enterasys Matrix E5 C 1 GB SX B D Policy DB AAA AAA Request iGrid2002

Next Setup using vendor provided network provisioning system Managed Optical Connection Service IP A A 802.1Q VLAN Switch Enterasys SS6000 802.1Q VLAN Switch Enterasys SS6000 C IP C IP B B Cisco CTM D IP D AAA BoDServ Content: First this presentation will say a few words about the relationship between the DataTAG WP4 description and the associated WP4.2 task description as to validate the context of the work. Recent discussions within the Projects Board have indicated such a need. Then we will show some light on the underlying concepts and some definitions of what we mean with a Lightpath and Generic AAA. Based on these concepts we have identified a testbed that allows us to play with one of the models based of these fundamental concepts. This presentation will also show some of the involved messages and policies including some technical details. Arie Taal and Bas van Oudenaarde are the guys who handle the design details and technical implementations.

Example XML Lightpath request <AAARequest version="0.1" type="BoD" >   <Authorization>       <credential>          <credential_type>simple</credential_type>          <credential_ID>JanJansen</credential_ID>          <credential_secret>#f034d</credential_secret>       </credential>   </Authorization>   <BodData>       <Source>192.168.1.5</Source>       <Destination>192.168.1.6</Destination>       <Bandwidth>1000</Bandwidth>       <StartTime>now</StartTime>       <Duration>20</Duration>   </BodData> </AAARequest>

Policy (significant part) executed by AAA Rule Based Engine ASM::RM.CheckConnection( Request::BodData.Source, Request::BodData.Destination ) && ( Request::BodData.Bandwidth <= 1000 ) then ASM::RM.RequestConnection( Request::BodData.Destination, Request::BodData.Bandwidth, Request::BodData.StartTime, Request::BodData.Duration ; Reply::Answer.Message = "Request successful" else Reply::Error.Message = "Request failed"

Design Details Onion model was chosen for first implementation. Single AAA engine controls both ingress and egress switch by creating 802.1Q VLAN’s using the dot1Q Bridge MIB extentions via SNMP. 1 GB channel between switches carry 802.1Q tagged ethernet frames. An 802.1Q trunk can carry up to 4096 VLAN’s. End stations register with AAA engine and subsequently send request to reach other stations (pointed to via its public IP address). By-pass communication channel uses a private IP address space. Destinations are identified by main IP address.

Technical Implementation XML/SOAP messages for request/reply (to prepare for a future web services interface) RBE: JAVA code running as Servlet. Uses Apache Axis to handle SOAP messages. ASM: JAVA code currently running in Java context of RBE. Currently investigating how it could run separately e.g. as Java Bean or using CORBA. More technical details: Bas van Oudenaarde: oudenaar@science.uva.nl and Arie Taal: taal@science.uva.nl

Upcomming work: Separate ASM and RBE and allow ASM’s to be loaded/unloaded dynamically. Implement pre-allocation mechanisms (based on GARA – collaboration with Volker Sander). Create ASM for other B/W manager (e.g. Alcatel BonD, Cisco CTM, Level-3 Ontap) Create ASM to talk to other domain: OMNInet Allow RBE’s to talk to each other (define messages). Integrate BoD AAA client into middleware eg by allowing integration with GridFTP and integration with VOMS authentication and user authorization system. Build WS interface abstraction for pre-allocation and subsequent usage.

Thank you ! Lgommans@science.uva.nl