PowerPointpresentatie

1
Generic AAA based Bandwidth on Demand MB-NG
workshop UCL London 20/02/2003 Leon
Gommans Advanced Internet Research
Group University of Amsterdam lgommans_at_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.
• - Technical Design Implementation Bas.

3

• Goal of BoD work at UvA.
• Allow application demand to provision a L1/L2
  network channel that does by-pass the regular
  internet connection. Regular Internet connection
  becomes control channel, L1/L2 network the
  transport channel.
• Rationale is that above a certain level of
• parallel required bandwidth / number of
  different destinations
• a Layer-3 QoS 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 L3
  Diffserv connections

4
Other considerations

• TCP stack transport channel needs tailored
  behavior to make optimal use of a high speed ( GB
  ), high delay (gt100ms) 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.

5

• 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 VOs 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.

6

• Rough requirements list.
• Must 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 -gt 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.
• 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.

7

• 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.
• Dont 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
  QoS tunnels.

8

• 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

9

• Control models
• In multidomain scenarios 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

10
Full Control model
Selector Switch
Distributor Switch
DomainY
Domain X
Domain X
Selector Switch
Distributor Switch
Domain Y
11
Partial control model
Domain A
Domain B
Domain C
Domain D
12
Hybrid models
Domain A
Domain B
Domain C
Domain X
Domain D
Domain X
Domain X
DomainY
13
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
14
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
15

• 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).
• IDs that became RFCs 2903 2906 were
  submitted after the Adelaide IETF march 2000.
  RFCs describe framework, architecture, example
  applications and requirements.
• Optical Networking within grid environment is a
  research application for Generic AAA.

16
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, Proxys.
Push sequence. Tokens, Tickets, ACs etc.
3 fundamentally different user initiated
authorization sequences. Note RFC2904 does
not show step 5 service access.
17
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.
18
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 ..
19
Generic AAA Architecture RFC2903
Policy Decision Point
Fundamental ideas 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 PDPs belonging to different
administrative domains.
20
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
21
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
Users
Contracts Budgets
AAA Server
AAA Server
AAA Server
User
Bandwidth Broker
Registration Dept.
Purchase Dept.
(Virtual) User Organization
QoS Enabled Network
Service
Bandwidth Provider
Service Organization
22
Generic AAA (RFC2903) based Bandwidth on Demand
192.168.1.5
192.168.1.6
192.168.2.3
192.168.2.4
802.1Q VLAN Switch Enterasys Matrix E5
A
C
802.1Q VLAN Switch Enterasys Matrix E5
1 GB SX
B
D
Policy DB
AAA
AAA Request
iGrid2002
23
Example XML Lightpath request ltAAARequest
version"0.1" type"BoD" gt  ltAuthorizationgt     
ltcredentialgt         ltcredential_typegtsimplelt/cr
edential_typegt         ltcredential_IDgtJanJansenlt/
credential_IDgt         ltcredential_secretgtf034dlt
/credential_secretgt      lt/credentialgt 
lt/Authorizationgt  ltBodDatagt     
ltSourcegt192.168.1.5lt/Sourcegt     
ltDestinationgt192.168.1.6lt/Destinationgt     
ltBandwidthgt1000lt/Bandwidthgt     
ltStartTimegtnowlt/StartTimegt     
ltDurationgt20lt/Durationgt  lt/BodDatagtlt/AAARequestgt
24
Policy (significant
part) executed by AAA Rule Based Engine if (
( ASMRM.CheckConnection(
RequestBodData.Source,
RequestBodData.Destination
) ( RequestBodData.Bandw
idth lt 1000 ) ) ) then ( ASMRM.RequestConne
ction( RequestBodData.Source,
RequestBodData.Destination,
RequestBodData.Bandwidth,
RequestBodData.StartTime,
RequestBodData.Duration )
ReplyAnswer.Message "Request
successful" ) else ( ReplyError.Message
"Request failed" )
25
L2/L3 Setup using GARA based network
provisioning
GARA (multidomain) QoS network
802.1Q VLAN Switch Enterasys SS6000
A
C
802.1Q VLAN Switch Enterasys SS6000
IP A
IP C
B
D
IP B
IP D
GARA Bandw Broker
AAA BoDServ
VOMS
26
WS Service Discovery
27
J2EE, Apache Axis Web Services OGSA AAA
protocol
Standards Body Liaison Architect.
Run Time Env
Management And Monitoring
Managemnt Document.
User/ Organization Integration
PKI, KERBEROS, VOMS
AAA Core
Policy Language
Security Integration
CA, CA policy Authentication Devices, Protocol
Security
Service Control Integration
Accounting
Layer N networking Scheduling Advance
Reservation Service Discovery and Ontology
WP 2 manpwr
WP 4 manpwr
Billing, Clearing Settlement
28

• Design considerations
• Full control model was chosen for first
  implementation.
• Single AAA engine controls both ingress and
  egress switch by creating 802.1Q VLANs 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 VLANs.
• End stations will 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.

29

• Related work
• Separate ASM and RBE and allow ASMs to be
  loaded/unloaded dynamically using J2EE.
• Implement pre-allocation mechanisms (based on
  GARA slot table)
• Create ASM for Bandwidth Broker
• Create ASM to find out high level domain topology
  (will be using hard coded info at first).
• Allow RBEs 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.

30

• Technical Design and Implementation overview
• Bas van Oudenaarde

31
Thank you ! lgommans_at_science.uva.nl