Generic AAA based Bandwidth on Demand MBNG workshop

  • Slides: 31
Download presentation
Generic AAA* based Bandwidth on Demand MB-NG workshop UCL London 20/02/2003 Leon Gommans Advanced

Generic AAA* based Bandwidth on Demand MB-NG workshop UCL London 20/02/2003 Leon Gommans Advanced Internet Research Group University of Amsterdam [email protected] uva. nl * Authentication Authorization & Accounting Research funded by

Content - Goals and basic list of requirements. - Lightpath and Lightpath control concepts

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. - Technical Design & Implementation: Bas.

Goal of Bo. D work at Uv. A. • Allow application demand to provision

Goal of Bo. D work at Uv. A. • Allow application demand to provision a L 1/L 2 network channel that does by-pass the regular internet connection. Regular Internet connection becomes control channel, L 1/L 2 network the transport channel. - Rationale is that above a certain level of: parallel required bandwidth / number of different destinations a Layer-3 Qo. S network will become too expensive. - I. e. the requested bandwidth is in the order of the traffic generated by a nations NRN and only a few destinations need such connectivity. Examples can be found in HEP, radio-astronomy etc. However AAA concepts can also be used for L 3 Diffserv connections

Other considerations -TCP stack & transport channel needs tailored behavior to make optimal use

Other considerations -TCP stack & transport channel needs tailored behavior to make optimal use of a high speed ( GB ), high delay (>100 ms) 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. -Single Packet drop in standard TCP causes severe performance hits - 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.

Rough requirements list. - Allow L 1, 2, 3 lightpath usage in a “demand

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 Grid. FTP. 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. Incorporation of topology awareness is of later concern.

Rough requirements list. - - Must hide complexity from user. Conceptually the user must

Rough requirements list. - - Must hide complexity from user. Conceptually the user must perform the process in 3 basic steps after login: 1) Pre-allocate thru a discovery and scheduling system -> Bo. D system issues authorization. 2) Allow own or delegated job to allocate the network resource whereby it uses the issued authorization. 3) 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. 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 or clearing and settlement.

Design considerations. - Group in Amsterdam does focus on deploying Generic AAA (RFC 2903/RFC

Design considerations. - Group in Amsterdam does focus on deploying Generic AAA (RFC 2903/RFC 2904) concepts to handle authorization of mainly L 1/L 2 lightpath. Group members were authors. Best suited to handle policy based authorization in a dynamic fashion either to build Auth. Z tokens or process requests which contain Auth. Z 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. Could work in parallel to GARA BB efforts to add policies to handling authorized provisioning of Qo. S tunnels.

Lightpath Def*: Any uni-directional point to point connection with effective guaranteed bandwidth Examples of

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

Control models In multidomain scenario’s you must have some awareness of the underlying high-level

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

Full Control model Selector Switch Domain X Domain. Y Domain X Distributor Switch

Full Control model Selector Switch Domain X Domain. Y Domain X Distributor Switch

Partial control model Domain A Domain B Domain C Domain D

Partial control model Domain A Domain B Domain C Domain D

Hybrid models Domain A Domain B Domain X Domain C Domain D Domain X

Hybrid models Domain A Domain B Domain X Domain C Domain D Domain X Domain. Y Domain X

Full control model Selector Switch Distributor Switch Domain X Domain Y AAA Domain AAA

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

Partial control model Selector Switch AAA Domain B Distributor Switch AAA Domain AAA engine

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

Generic AAA o 5 years ago a AAA server was known as a server

Generic AAA o 5 years ago a AAA server was known as a server supporting dail-in boxes thru the RADIUS protocol (at IETF). o IETF 42 (in same hotel as GGF 6) held first AAA BOF as it was recognized AAA could be used in other type of applications. o Amsterdam group has been participating on defining concepts for Generic AAA since march 1999 when AAA WG was formed at IETF-44 o Work became IRTF subject end of 1999 (AAA ARCH RG). o 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. o Optical Networking within grid environment is a research application for Generic AAA.

RFC 2904 Generic AAA Framework basic principles AAA User 2 1 4 3 Service

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

Generic AAA Framework AAA 3 User Home Organization 4 AAA User 1 6 2

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

Generic AAA Framework AAA User Home Organization AAA Service Provider A Service Provider B

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

Generic AAA Architecture – RFC 2903 Fundamental idea’s inspired by work of the IETF

Generic AAA Architecture – RFC 2903 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 – RFC 2903 Achieve goal by by separating the logical decision

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

Example of Generic AAA Architecture – RFC 2903 Rule Based Engine Policy Repository User

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

Generic AAA (RFC 2903) based Bandwidth on Demand 192. 168. 1. 5 192. 168.

Generic AAA (RFC 2903) based Bandwidth on Demand 192. 168. 1. 5 192. 168. 2. 3 A B 802. 1 Q VLAN Switch 1 GB SX 802. 1 Q VLAN Switch 192. 168. 2. 4 C Enterasys Matrix E 5 192. 168. 1. 6 D Policy DB AAA Request AA A i. Grid 2002

Example XML Lightpath request <AAARequest version="0. 1" type="Bo. D" > <Authorization> <credential> <credential_type>simple</credential_type> <credential_ID>Jan.

Example XML Lightpath request <AAARequest version="0. 1" type="Bo. D" > <Authorization> <credential> <credential_type>simple</credential_type> <credential_ID>Jan. Jansen</credential_ID> <credential_secret>#f 034 d</credential_secret> </credential> </Authorization> <Bod. Data> <Source>192. 168. 1. 5</Source> <Destination>192. 168. 1. 6</Destination> <Bandwidth>1000</Bandwidth> <Start. Time>now</Start. Time> <Duration>20</Duration> </Bod. Data> </AAARequest>

Policy (significant part) executed by AAA Rule Based Engine if ( ( ASM: :

Policy (significant part) executed by AAA Rule Based Engine if ( ( ASM: : RM. Check. Connection( Request: : Bod. Data. Source, Request: : Bod. Data. Destination ) && ( Request: : Bod. Data. Bandwidth <= 1000 ) ) ) then ( ASM: : RM. Request. Connection( Request: : Bod. Data. Source, Request: : Bod. Data. Destination, Request: : Bod. Data. Bandwidth, Request: : Bod. Data. Start. Time, Request: : Bod. Data. Duration ) ; Reply: : Answer. Message = "Request successful" ) else ( Reply: : Error. Message = "Request failed" )

L 2/L 3 Setup using GARA based network provisioning IP A IP B A

L 2/L 3 Setup using GARA based network provisioning IP A IP B A B GARA (multidomain) Qo. S network 802. 1 Q VLAN Switch Enterasys SS 6000 GAR A Band w Brok er VO MS AA A Bo DSe rv Enterasys SS 6000 C IP C D IP D

Grid Authentication VOMS Auth DB Role Request + Reply Pseudo Cert GARA Agent USER

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

J 2 EE, Apache –Axis Web Services – OGSA AAA protocol Managemnt & Document.

J 2 EE, Apache –Axis Web Services – OGSA AAA protocol Managemnt & Document. Management And Monitoring Standards Body Liaison + Architect. Policy Language CA, CA policy Authentication Devices, Protocol Security Run Time Env AAA Core Security Integration Accounting WP 2 manpwr WP 4 manpwr Billing, Clearing & Settlement User/ Organization Integration Service Control + Integration PKI, KERBEROS, VOMS Layer N networking Scheduling Advance Reservation Service Discovery and Ontology

Design considerations o Full control model was chosen for first implementation. o Single AAA

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

Related work: 1) Separate ASM and RBE and allow ASM’s to be loaded/unloaded dynamically

Related work: 1) Separate ASM and RBE and allow ASM’s to be loaded/unloaded dynamically using J 2 EE. 2) Implement pre-allocation mechanisms (based on GARA slot table) 3) Create ASM for Bandwidth Broker 4) Create ASM to find out high level domain topology (will be using hard coded info at first). 5) Allow RBE’s to talk to each other (define messages). 6) Integrate Bo. D AAA client into middleware eg by allowing integration with Grid. FTP and integration with VOMS authentication and user authorization system. 7) Build WS interface abstraction for pre-allocation and subsequent usage.

Technical Design and Implementation overview Bas van Oudenaarde

Technical Design and Implementation overview Bas van Oudenaarde

Thank you ! lgommans@science. uva. nl

Thank you ! [email protected] uva. nl