Download The OBAN project and issues for standardisation

The OBAN project and issues for standardisation
Duration: 3 years
2004/1 – 2006/12
Budget/EC cont: 11/5 M€
14 partners coordinated by Telenor
•
4 telecom operators
(Telenor, Telefonica, Swisscom, France Telecom)
•
6 industrial partners
(Lucent(NL), Birdstep(N), ObexCode(N), Motorola(I),
EuroConcepts(I), Lucent(UK)
•
3 universities/institutes
Sintef(N), Techn. Univ. Berlin(D), ISMB(I)
•
1 national telecom regulator
NPT(N)
Abstract
•
This presentation introduces the concept of OBAN (Open
Broadband Access Network), an European funded project under
the IST 6th framework program.
•
The presentation focus on the mobility architecture and the
challenges introduced:
– Scalable and flexible mobility management in a cross Access Service
provider /Internet Service Provider scenario
– Handover for delay constrained services such as voice, video etc.
Rational behind
•
Wireless LANs have large
capacity and are often
poorly exploited
•
OBAN intends to
investigate how the public
can obtain access to these
resources and what kind of
services can be provided
over this network.
The concept contains numerous challenges
•
Mobility aspects – nomadic or continuous mobility
•
Security and authentication
•
Roaming agreements
– Between different network operators
– Between owners of Residential Gateways (RG)
•
How to match QoS in the legacy network with what can be
achieved in a wireless LAN and while traversing from RG to RG ?
•
How to deal with the large variety of terminals?
•
Interference between RGs and with other equipment – frequency
planning
•
Business models and commercial aspects
The Security & Mobility Challenge (1)
•
The security level expected for OBAN architecture has to coexist
with strong time and QoS constraints
•
A goal of 120 ms maximum handover latency implies that a full
authentication that involves several actors and ditto round-trip times
is not acceptable.
•
Fast handover requires an authentication mechanism that only
involves the terminal and the RGW.
•
Security in relation to fast re-authentication during handoff:
– Two potential solutions:
– delayed authentication,
– fast hand-over using Kerberos Tickets
The Security & Mobility Challenge (2)
•
No preprocessing of keys and session parameters by network to
prepare handover in advance.
– 2G and 3G does this by default
•
An STA in IEEE802.11 can only be associated with one AP at a time.
•
The mobile station must after sensing a beacon, negotiate with next
AP that again must performs a full RADIUS roundtrip with ISP to
handle AAA and security session
– In practice: a re-authentication (roaming) based on e.g. EAP will include a
full time consuming RADIUS roundtrip involving STA, AP, and ISP(s). In
addition; rerouting of traffic as well as 802.1X functions for port control and
crypto session establishment on radio link.
Handover task - time considerations
T1
T2
T3
T4
T5
Session
continues
here
Handover
Starts here
Interruption delay
Session Oriented
Security Oriented
< 100 ms
>> 150 ms (!)
T1: Beacon + Physical connection setup between the STA and the next AP/RGW
T2: Messaging session parameters, including STA’s ID / auth. info between the VU and the next AP/RGW.
T3: Processing of rerouting the traffic to and from STA via the new AP.
T4: AAA roundtrip for re-authentication of the STA between AP/RGW and H-ISP of the STA
T5: 802.1X port handling and TKIP/AES-based encryption of radio link between VU and AP
The high level architecture
Internet
ISP of VU
HA (of VU)
AAA
AAA
MB:
RG:
MIP:
VU:
HA:
FA:
GFA:
Mobility Broker
Residential Gateway
Mobile IP
Visiting User
Home Agent
Foreign Agent
Gateway FA
Mobility
Broker
(MB)
RGW 1
SIP proxy/
registrar
CARD
Server
HA
GFA
RGW 2
FA
CARD
Proxy
VU
OBAN service provider
FA
CARD
Proxy
MIP
MIP
CARD
Client
CARD
Client
VU
Mobility Broker
• A node serving a geographical area, composed of several RGWs
• Makes the access network look like a conventional WLAN/IP
network, such that standard mechanisms can be reused
• Simplify the hand-off complexity, and reduce signaling round trips
by managing mobility, security and QoS events locally during handoff
Fast Handover using Kerberos tickets
Using Kerberos tickets for fast and secure layer 2 authentication
•
The ticket consist primarily of an access key and an encrypted
timestamp with a key known to the issuer and the final recipient
– Issuer = Mobility Broker
– Final recipient = RGW
•
The ticket is issued to the client (user terminal) and encrypted with
a key that is in the possession of the client. (shared secret)
– The client uses the ticket for authentication towards the RGW
– Proves that is possesses the session key within the ticket, by
encrypting a challenge from the RGW with the session key
– RGW also checks that the timestamp is not expired
Fast Handover using Kerberos tickets
•
First time authentication
– No tickets => full authentication towards HAAA. i.e. Anything that generates a
session key (e.g. EAP – SIM)
– The final EAP SUCCESS is not proxied to the terminal but exchanged in the
Mobility broker with a Ticket-granting Ticket
– The terminal requests MB for a suitable set of tickets.
– EAP SUCCESS is then finally delivered
– The MB is geographically aware.
•
Successive re-auth
– Only between terminal and RGW
Fast Handover using Kerberos tickets
•
Delay estimation
– Network Authentication + MIP registration = total delay
– Full auth: <120-290ms> + <35-100ms> = <155-390ms>
– Re-auth in same domain: <10-40ms> + <25-45ms> = <35-85ms>
– Re-auth in diff domain: <10-40ms> + <35-100ms> = <45-140ms>
•
Standard compliance
– ”the full authentication” does not comply with the EAP requirement
regarding sequence of methods.
Delayed Authentication (1)
(Patent Pending)
•
Open 802.1x for user traffic as fast as possible, and before security
functions/authentication are completed.
•
Full AAA roundtrip to be executed while ongoing user traffic from STA.
T1
T2
T3
T4
T5
Session
continues
here
Handover
starts here
discontinued session
(< 100 ms )
< 100 ms
Secured and
accounted
traffic
Continued, but insecure session
,
(a few seconds)
Full
Security
established
Delayed Authentication (2)
•
New / Increased Security risks:
– Unaccounted user traffic for a few seconds
– No encryption on the radio link
– Potential DoS attacks (in addition to those already existing )
•
Countermeasures:
– Introduce a timer to limit the maximum pending time for a RADIUS
response (success or reject)
– Possible for AP to cache and block MAC addresses with repeated failing
attempts
– Policy selector: Monitor accounted vs unaccounted traffic and allow to
toggle back to standard 802.11 state machine (ie. standard policy) if
unaccounted level is bad. (toggle back after a configurable time)
Consequences
•
Introducing a new state:
Pending_Authenticated in the IEEE
802.1X State Model
•
Must allow for class 3 traffic (both
STA and AP)
•
•
Extra robustness functions to
minimize the new risks (timer, MAC
cache etc)
Successful
Authentication
Authenticated
& Associated
Class 1, 2 & 3
frames allowed
Class 1, 2 & 3
frames allowed
Compensation functions also to
account for conveyed STA traffic
before successful RADIUS
Pending_Authenticated
Associated
response.
(STA traffic conveyed before a
RADIUS reject (or timer elapse etc)
cannot be accounted for).
DeAuthentication
Notification
Authenticated
UnAssociated
Class 1& 2
frames allowed
UnAuthenticated
UnAssociated
Class 1
frames allowed
Possible gain
•
Applications with strict real-time requirements can be handled
more comfortably also in the mobile case
 increased popularity & New Business opportunities
•
Seamless functionality also delivered with high-speed broadband
– 2G/EDGE: max ~200 Kbit/s,
– 3G/UMTS ~400 Kbit/s,
– 802.11(): 1Mbit/s ++
•
Enabling true roaming for 802.11-based access networks