Cooperation in Wireless Networks

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

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

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

4. Why Cooperation ? (3/3) • Same goals • Low Latency • QoS • Load Balancing • Admission/Congestion Control • Service Discovery

5. Problems • 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

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

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

8. 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) • 802.11i, WPA

9. Mobile Node’s Cache • L2 + L3 information + LEASE FILE

10. R-MN Stations NET_INFO_REQ NET_INFO_RESP Layer 2 Cooperation (1/3) • Random waiting time • The information exchanged in the NET_INFO multicast frames is: APs {BSSID, Channel} SUBNET IDs

11. 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.

12. 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)

13. 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!)

14. R-MN Stations ASTA_DISCOV (m) m: multicast u: unicast ASTA_RESP (u) Cooperative IP Acquisition (1/2) • R-MN has to discover the STAs that can help in this task (A-STA) • R-MN builds a list of A-STAs for each possible next subnet

15. Cooperative IP Acquisition (2/2) • R-MN can cooperate with A-STAs to acquire the L3 information it needs DHCP Server R-MN A-STA DHCP_OFFER (client ID) IP_REQ (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

16. 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.

17. Cooperative Authentication (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.

18. 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.

19. Cooperative Authentication (4/4) • In order to select an RN the R-MN sends a RELAY_REQ multicast frame. • RELAY_REQ format: RELAY_REQ frame is received by all the STAs in the multicast group (or a subset), including the CN and the RN

20. 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

21. 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

22. 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.

23. 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