Generic AAA* based Bandwidth on Demand UKERNA meeting Amsterdam 24/04/2003 Leon Gommans

1. Generic AAA* based Bandwidth on Demand UKERNA meeting Amsterdam 24/04/2003 Leon Gommans Advanced Internet Research Group University of Amsterdam lgommans@science.uva.nl * Authentication Authorization & Accounting Research funded by

2. 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. • Integrated design

3. Goal of BoD work at UvA. • Allow application demand to provision a L1/L2/L3 network channel (Lightpath) that does by-pass the regular internet connection. • Regular Internet connection becomes control channel, the Lightpath the transport channel. • Connections must be authorized across multiple domains. • Rationale is that above a certain level of: • parallel required bandwidth / number of different destinations • a router based QoS network will become too expensive. • (AAA concepts can be used for L3 Diffserv connections however.)

4. Generic AAA (RFC2903) based Bandwidth on Demand 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

5. Other considerations • TCP stack & transport channel needs tailored behavior to make optimal use of a high speed ( GB ), high delay (>100ms) channel • Modifications tend to generate Internet “unfriendly” TCP traffic, that does not mix well unless routers are aware of the high bandwidth topology. Topology needs to be management somehow. • Limited memory buffer sizes in routers/switches do cause packet drops when the road “gets smaller” on long fat pipes. Equipment designed for MAN operation can not be in the chain. • Firewalls do not support extreme high bandwidth connections. • Possible option: Create dedicated channels that are intended to get utilized 100% for the required time. Cost model will determine if and when on-demand usage is required v.s. dedicated usage.

6. Rough requirements list. • Allow L 1, 2, 3 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 applications such as GridFTP. • Allow authorized VO’s or individual users to discover • available lightpath destination (e.g. Via OGSA/WS). • 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. • - Re-use vendor BoD capabilities and make them multi-domain.

7. Rough requirements list. • Hide complexity from user. Conceptually the user must perform the process in 3 basic steps after login: • Pre-allocate thru a discovery and scheduling system -> BoD system issues authorization. • Allow own or delegated job to allocate the network resource whereby it uses the issued authorization. • Once the job is finished, the authorization is handed back/invalidated so resources can be freed. • User (or scheduling system) must be allowed to change the reservation if the process flow so dictates. • Must ultimately support Grid Economic Services Architecture features to allow ad hoc creation. • Must ultimately provide Grid Accounting records for billing or clearing and settlement.

8. Design considerations. • Group in Amsterdam does focus on deploying Generic AAA (RFC2903/RFC2904) concepts to handle authorization of mainly L1/L2 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. • 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 are already active in this area. • Work in parallel to GARA BB efforts to add policies to handling authorized provisioning of QoS tunnels.

9. Lightpath • Def*: Any uni-directional point to point connection with effective guaranteed bandwidth • Examples of LightPaths: * L1: Analog wavelength on a CWDM or DWDM system • * L1: Gigabit Ethernet over dedicated fiber strand • * L2: STS channel on a SONET or SDH circuit * L2: ATM CBR circuit • * L2: MPLS VLAN * L3: Diff serv “gold” service on a packet based network • * Definition by Bill St. Arnoud of Canarie

10. Control models • In multidomain scenario’s you must have some awareness of the underlying high-level concept of the connection. • Must understand what piece of the conceptual connection the AAA entity is controlling: • Collector switch at the ingress and its connected networks or equipment • The link • Distributor switch at the egress and its connected networks or equipment

11. Full control model Selector Switch Distributor Switch Domain X Domain Y AAA Domain AAA engine must control both selector and distributor switch and Interconnecting network

12. Partial 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

13. Generic AAA • 5 years ago a AAA server was known as a server supporting dail-in boxes thru the RADIUS protocol (at IETF). • IETF42 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.

14. RFC 2904 Generic AAA Framework basic principles AAA AAA AAA 1 1 User 2 User User 4 2 2 3 1 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.

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

16. Generic AAA Framework AAA 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 ..

17. Generic AAA Architecture – RFC2903 Policy Decision Point 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 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.

18. Generic AAA Architecture – RFC2903 PDP Rule Based Engine Achieve 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

19. 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

20. 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>

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

22. L2 Setup using CTM ONS based network provisioning CTM driven network 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 VOMS AAA BoDServ

23. VOMS Auth DB Grid Authentication Role Request + Reply Pseudo Cert Slot Table USER A A A GARA Agent Advance Reservation request / reply BGP Topology advertisements + Reservation indications BB QoS Path request / reply QoS Networks Policy DB Path Provision indications WS + Service Discovery

24. Thank you ! lgommans@science.uva.nl