Cooperation in Wireless Networks Andrea G. Forte Henning Schulzrinne November 14, 2005

Why Cooperation ? (1/3) Same tasks Layer 2 Handoff Layer 3 Handoff Authentication Multimedia Session Update

Why Cooperation ? (2/3) Same Information Topology (failover) DNS Geo-Location Services (Other networks)

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 i, WPA, 802.1x Fast L3 Handoff Subnet change detection IP address acquisition time Fast Session Update SIP re-INVITE Problems

Cooperative Roaming Multicast Security Reachability TTL (scopes in IPv6) Multicast Group

Layer 2 Handoff - Overview Mobile station All APs Probe request (broadcast) Probe response New AP Authentication request Authentication response Association request Association response Scanning delay Authentication delay Association delay

Layer 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) i, WPA

Mobile Node’s Cache Current AP (KEY)Best APSecond best AP MAC AMAC BMAC C Channel 1Channel 11Channel 6 Gateway DGateway EGateway 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) R-MNStations NET_INFO_REQ NET_INFO_RESP

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) 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 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 (1/2) R-MN has to discover the STAs that can help in this task (A-STA) R-MNStations ASTA_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 (2/2) R-MN can cooperate with A-STAs to acquire the L3 information it needs R-MNA-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 (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 (2/4) In IEEE 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 (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 (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-MN MAC address CN MAC and IP RN MAC 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) 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) 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 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.

Conclusions 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