Transcript PowerPoint-presentatie

Generic AAA* based
Bandwidth on Demand
* Authentication Authorization & Accounting
EVL at UIC meeting
Chicago 18/10/2002
Leon Gommans
Advanced Internet Research Group
University of Amsterdam
[email protected]
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
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.
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.
Rough requirements list.
-
-
-
Must hide complexity from user. Conceptually the user
must perform the process in 3 basic steps after login:
1) Pre-allocate either manually or automatically thru a
scheduling system -> system issues an authorization.
2) Allow the job to allocate the network resource
whereby it uses the authorization.
3) 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.
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”.
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
Onion Lightpath model
Selector
Domain X
Switch
Selector
Switch
DomainY
Domain Y
Domain X
Distributor
Switch
Distributor
Switch
Daisy Chain Lightpath model
Domain A
Domain B
Domain C
Domain D
Daisy Chain & Onion
Domain A
Domain B
Domain X
Domain C
Domain D
Domain X
DomainY
Domain X
Onion control model
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
AAA
Domain A
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 supporting
dail-in boxes thru the RADIUS protocol (at IETF).
o IETF42 (in same hotel as GGF6) 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
1
1
User
AAA
4
3
2
Service
AAA
2
User
3
4
Service
Pull sequence
Agent sequence
Push sequence.
NAS (remote access)
RSVP (network QoS)
Agents, Brokers,
Proxy’s.
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
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
AAA
Service
Service
Service
Provider A
Service
Provider B
User
AAA
Client
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
Archieve goal by by separating
the logical decision process from
the application specific parts
within the PDP.
PDP
Rule
Based
Engine
Policy
Repository
Application
Specific
Module
Request
Decision
Policy
Enforcement
Point
Example of Generic AAA Architecture – RFC2903
Rule
Based
Engine
Policy
Repository
User
Application
Specific
Module
Rule
Based
Engine
Application
Specific
Module
AAA
Server
AAA
Server
Purchase Dept.
Bandwidth
Broker
QoS 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 (RFC2903) based Bandwidth on Demand
192.168.
1.5
192.168.
2.3
A
802.1Q
VLAN
Switch
1 GB SX
802.1Q
VLAN
Switch
192.168.
2.4
192.168.
1.6
C
Enterasys
Matrix E5
Enterasys
Matrix E5
B
D
Policy DB
AAA
Request
AA
A
iGrid2002
Generic AAA (RFC2903) based Bandwidth on Demand
192.168.
1.5
192.168.
2.3
A
802.1Q
VLAN
Switch
1 GB SX
802.1Q
VLAN
Switch
192.168.
2.4
192.168.
1.6
C
Enterasys
Matrix E5
Enterasys
Matrix E5
B
D
Policy DB
AAA
Request
AA
A
iGrid2002
Next Setup using vendor provided network
provisioning system
IP A
IP B
A
B
802.1Q
VLAN
Switch
Enterasys
SS6000
Managed Optical
Connection Service
Cisc
o
CT
M
AA
A
Bo
DSe
rv
802.1Q
VLAN
Switch
Enterasys
SS6000
C
D
IP C
IP D
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
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"
)
Design Details
o Onion model was chosen for first implementation.
o Single AAA engine controls both ingress and egress switch by
creating 802.1Q VLAN’s using the dot1Q Bridge MIB extentions
via SNMP.
o 1 GB channel between switches carry 802.1Q tagged ethernet
frames. An 802.1Q trunk can carry up to 4096 VLAN’s.
o End stations 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.
Technical Implementation
o XML/SOAP messages for request/reply (to prepare
for a future web services interface)
o RBE: JAVA code running as Servlet.
Uses Apache Axis to handle SOAP messages.
o 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.
o More technical details:
Bas van Oudenaarde: [email protected] and
Arie Taal: [email protected]
Upcomming work:
1) Separate ASM and RBE and allow ASM’s to be
loaded/unloaded dynamically.
2) Implement pre-allocation mechanisms (based on GARA
– collaboration with Volker Sander).
3) Create ASM for other B/W manager (e.g. Alcatel
BonD, Cisco CTM, Level-3 Ontap)
4) Create ASM to talk to other domain: OMNInet
5) Allow RBE’s to talk to each other (define messages).
6) Integrate BoD AAA client into middleware eg by
allowing integration with GridFTP and integration with
VOMS authentication and user authorization system.
7) Build WS interface abstraction for pre-allocation and
subsequent usage.
Thank you !
[email protected]