Cooperation in Cooperation in Wireless NetworksWireless Networks

Andrea G. ForteHenning SchulzrinneNovember 14, 2005

Why Cooperation ? (1/3)Why Cooperation ? (1/3)

Same tasks Layer 2 Handoff Layer 3 Handoff Authentication Multimedia Session Update

Why Cooperation ? (2/3)Why Cooperation ? (2/3)

Same Information Topology (failover) DNS Geo-Location Services (Other networks)

Why Cooperation ? (3/3)Why Cooperation ? (3/3)

Same goals Low Latency QoS Load Balancing Admission/Congestion Control Service Discovery

Support for real-time multimedia Fast L2 Handoff

Scanning delay Authentication

802.11i, WPA, 802.1x Fast L3 Handoff

Subnet change detection IP address acquisition time

Fast Session Update SIP re-INVITE

ProblemsProblems

Cooperative RoamingCooperative Roaming Multicast

Security Reachability TTL (scopes in

IPv6)

Multicast Group

Layer 2 Handoff - Layer 2 Handoff - OverviewOverview

Mobile station All APs

Probe request (broadcast)

Probe response

New APAuthentication request

Authentication response

Association request

Association response

Scanning delay

Authentication delay

Association delay

Layer 2 Handoff - DelaysLayer 2 Handoff - Delays

Scanning Introduces more than 90% of the total

handoff delay (open system). It is the most power consuming part

of the handoff process.

Authentication WEP (broken) 802.11i, WPA

Mobile Node’s CacheMobile Node’s Cache

Current AP (KEY)

Best AP Second best AP

MAC A MAC B MAC C

Channel 1 Channel 11 Channel 6

Gateway D Gateway E Gateway F

+

LEASE FILE

L2 + L3 information

Random waiting time The information exchanged in the NET_INFO

multicast frames is:

APs {BSSID, Channel}SUBNET IDs

Layer 2 Cooperation (1/3)Layer 2 Cooperation (1/3)R-MN Station

sNET_INFO_REQ

NET_INFO_RESP

Layer 2 Cooperation (2/3)Layer 2 Cooperation (2/3) A MN sends a NET_INFO_RESP frame if it

has at least one AP in common with the R-MN’s cache.

If the MN does not have at least one AP in common, it can: Discard the INFO_REQ frame without any

further action Send an INFO_RESP frame but only if no one

else has already sent the same information Send an INFO_RESP frame but with a lower

priority than the one sent by a MN which follows the “one AP in common” rule.

Layer 2 Cooperation (3/3)Layer 2 Cooperation (3/3)

When a MN either than R-MN receives a NET_INFO_RESP it will perform two tasks: Check if someone is lying

(fix it!) Populate a temporary cache structure

(cache “chunks” – Bit Torrent)

Layer 3 HandoffLayer 3 Handoff

Subnet detection Information exchanged in NET_INFO

frames IP address acquisition time

Other STAs can cooperate with us and acquire a new IP address for the new subnet on our behalf while we are still in the OLD subnet.(Not delay sensitive!)

Cooperative IP Acquisition Cooperative IP Acquisition (1/2)(1/2)

R-MN has to discover the STAs that can help in this task (A-STA)

R-MN StationsASTA_DISCOV

(m)

ASTA_RESP (u)

m: multicast

u: unicast

R-MN builds a list of A-STAs for each possible next subnet

Cooperative IP Acquisition Cooperative IP Acquisition (2/2)(2/2)

R-MN can cooperate with A-STAs to acquire the L3 information it needs

R-MN A-STA

IP_REQ (Client ID)

.

.

DHCP Server

DHCP_OFFER (client ID)

DHCP_ACK

IP_RESP (New IP)

R-MN builds a list of {Gateway, IP address} pairs, one per each possible subnet it might move to next

Cooperative Authentication Cooperative Authentication (1/4)(1/4)

Cooperation in the authentication process itself is not possible as sensitive information such as certificates and keys are exchanged.

STAs can still cooperate in a mid-call mobility scenario to achieve a seamless L2 and L3 handoff regardless of the authentication model used.

Cooperative Authentication Cooperative Authentication (2/4)(2/4)

In IEEE 802.11 networks the medium is “shared”. Each STA can hear the traffic of other STAs if on the same channel.

Packets sent by the non-authenticated STA will be dropped by the infrastructure but will be heard by the other STAs on the same channel/AP.

Cooperative Authentication Cooperative Authentication (3/4)(3/4)

One selected STA (RN) can relay packets to and from the R-MN for the amount of time required by the R-MN to complete the authentication process.

The R-MN needs to: Discover the available RNs for a given AP

(Similar procedure to the one used for A-STAs)

Select an RN and start the relaying of packets after the L2 handoff.

Cooperative Authentication Cooperative Authentication (4/4)(4/4)

In order to select an RN the R-MN sends a RELAY_REQ multicast frame.

RELAY_REQ format:

AP_ID(AD_ID)

R-MNMAC

address

CNMAC and

IP

RNMAC and

IP

RELAY_REQ frame is received by all the STAs in the multicast group (or a subset), including the CN and the RN

Security Issues (1/2)Security Issues (1/2) A malicious MN might try to re-use the

relaying mechanism over and over without ever authenticate. Each RELAY_REQ allows an RN to relay

packets for a limited amount of time RELAY_REQ frames are multicast. All STAs

can help in detecting a bad behavior RNs can detect if the R-MN is performing

the normal authentication or not. Authentication failure can also be detected

Security Issues (2/2)Security Issues (2/2)

Countermeasures work only if we can be sure of the identity of a client MAC spoofing

A possible solution to MAC spoofing attacks is to perform authentication and encryption at the multicast group level

Other ApplicationsOther Applications In a multi-domain environment Cooperative

Roaming (CR) can help in choosing AP/domain according to roaming agreements, billing, etc.

CR can help for admission control and load balancing, by redirecting MNs to different APs and/or different networks.

CR can help in discovering services (encryption, authentication, bit-rate, Bluetooth, UWB, 3G)

CR can provide adaptation to changes in the network topology (802.11h)

CR can help in the interaction between nodes in infrastructure and ad-hoc/mesh networks.

ConclusionsConclusions

Cooperation among stations allows seamless L2 and L3 handoffs for real-time applications

Completely independent from the authentication mechanism used

It does not require any changes in either the infrastructure or the protocol

It does require many STAs supporting the protocol and a high degree of mobility

Suitable for indoor and outdoor environments

Sharing information Power efficient