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 IEEE 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 T 1 T 2 T 3 T 4 T 5 Handover Starts here Session continues here Session OrientedSecurity Oriented < 100 ms >> 150 ms (!) Interruption delay T1: Beacon + Physical connection setup between the STA and the next AP/RGW T2: Messaging session parameters, including STAs 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 VU RGW 1 Mobility Broker (MB) CARD Server RGW 2 MIP VU CARD Client FA CARD Proxy FA CARD Proxy MIP CARD Client HA (of VU) ISP of VU Internet MB:Mobility Broker RG:Residential Gateway MIP: Mobile IP VU:Visiting User HA:Home Agent FA: Foreign Agent GFA:Gateway FA GFA AAA SIP proxy/ registrar HA AAA OBAN service provider

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 hand- off

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, b y 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: + = –Re-auth in same domain: + = –Re-auth in diff domain: + = 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. T 1 T 2 T 3 T 4 T 5 Handover startshere discontinued session (< 100ms) Session continues here Full Security established Continued, but insecure session (a few seconds), Securedand accounted traffic < 100 ms

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 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) Compensation functions also to account for conveyed STA traffic before successful RADIUS response. (STA traffic conveyed before a RADIUS reject (or timer elapse etc) cannot be accounted for). Authenticated & Associated Authenticated UnAssociated UnAuthenticated UnAssociated Pending_Authenticated Associated Class 1, 2 & 3 frames allowed Successful Authentication DeAuthentication Notification Class 1, 2 & 3 frames allowed Class 1& 2 frames allowed 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 based access networks