70 likes | 210 Views
Detection of Network Attachment (DNA) and Handoff ECSG. Bernard Aboba Microsoft July 2003. Problem Statement. Statement 1: There is a need to develop a handoff standard that allows a mobile terminal to optimize detection of network attachment (DNA) at Layer 3. Statement 2:
E N D
Detection of Network Attachment (DNA) and Handoff ECSG Bernard Aboba Microsoft July 2003 Bernard Aboba, Microsoft
Problem Statement • Statement 1: • There is a need to develop a handoff standard that allows a mobile terminal to optimize detection of network attachment (DNA) at Layer 3. • Statement 2: • There is a need to develop a handoff standard that permits a mobile terminal to switch between one point of attachment and another with minimal latency. Bernard Aboba, Microsoft
DNAv4 Model • “Hints” – non-definitive indications whether the host has connected to a previously encountered subnet • L2 hints: 802.11 SSID, Infrastructure/Adhoc, IEEE 802 LLDP traffic • L3 hints: IRDP • “Most Likely” point of attachment (POA) • Best guess, based on hints • By default: previous point of attachment • Reachability detection • ARP Request sent to “most likely” default gateway • Address re-acquisition • Used only if client retains a valid lease • DHCPREQUEST sent in INIT-REBOOT state Bernard Aboba, Microsoft
DNAv4 Strawman Proposal • Formulate “most likely” point of attachment • Is IPv4 LL ever “most likely” ? • Probably not • May wish to test reachability to all networks with valid IP leases prior to configuring an IPv4 LL address • Check for valid IP address lease (<T1) • If valid, perform reachability detection on default gateway of “most likely” network • If reachability succeeds, reuse address • Note: To handle movement between private networks, need to match *both* IP address and MAC address of default gateway • If reachability fails send DHCPREQUEST in INIT-REBOOT state • If no valid IP address lease, or no response to DHCPREQUEST after retransmission, go to INIT state • If DHCP fails, do we allocate IPv4 LL address? • Empirical evidence is that this is invalid much of the time, but it could be required. • If IPv4LL is allocated, how often do we attempt to obtain a routable IP address? Bernard Aboba, Microsoft
Issues with IEEE 802.11 “Hints” • SSID not a reliable indicator of subnet change • Lots of APs advertising “default” SSID • SSID -> subnet mapping not unique • IEEE 802.1X-2001 supports dynamic VLAN assignment • STAs within the same SSID may not be assigned the same VLANID • AP discovery mechanisms limited to coverage area • Since Beacon/Probe Responses not audible outside the coverage area, not possible to discover APs outside of the coverage area • Result: Handoff needs to be completed within the coverage overlap area • Virtual AP confusion • Station may become alarmed by sharing of PMK between Virtual APs within the same physical AP • Need physical AP identifier • “Link up” confusion • IEEE 802.11i defines two Association protocols! • Secure association protocol: 4-way + group key handshake • Insecure Association Protocol: Association/Reassociation • Result: state machine complexity, DoS vulnerabilities • IEEE 802.11i and IEEE 802.11f have different definitions of Association • IEEE 802.11f triggered on insecure Association/Reassociation • IEEE 802.11i triggered on secure association • Observed Results • Hosts assigning IPv4LL address when DHCP server is available Bernard Aboba, Microsoft
Potential Solutions • Subnet change indications • Subnet provided in last message of secure association protocol • Allows subnet to be learned prior to DNA • Allows for dynamic VLAN assignment • Virtual AP confusion • Physical AP identifier independent of BSSID • Discovery outside the coverage area • Addition of “Neighbor” IE to the Beacon/Probe Response • Provides BSSID of neighboring APs • Allows pre-authentication to be initiated outside coverage overlap area • “Link up” Confusion • Define a single “Link up” trigger in IEEE 802.11i: 4-way + group key handshake • Add Association/Reassociation fields to 4-way handshake to allow secure verification • Add “delete” message to 4-way handshake to allow for secure Disassociation/Deauthentication • Rename 4-way handshake + group key handshake to “secure association” • Treat insecure Association/Reassociation as vestigial if it cannot be removed Bernard Aboba, Microsoft
Motion • To straw poll on the proposed problem statements • - Problem Statement 1 • - Problem Statement 2 Bernard Aboba, Microsoft