Subject: [Mipshop] Review of draft-ietf-mipshop-80211fh-02.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Oct 2004 11:59:51 -0700 (PDT)

Section 3

"A given STA may be associated with one and only one AP at any given
point in time"

The requirement is actually that a STA can only be associated with a
single AP in an ESS.  Implementations are available that can maintain
associations to multiple ESSes simultaneously.  See:
http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm

"when a STA moves out of the coverage area of a given AP it must handover (re-
associate) with a new AP."

In practice, there is often no way to define the "coverage area" of an AP,
since radio propagation is somewhat unpredictable.  Since the handover and
rate adjustment algorithms are not standardized in 802.11, behavior can vary
quite widely.  See:
http://www.pdos.lcs.mit.edu/decouto/papers/kotz03.pdf
http://www.it.kth.se/~vatn/research/handover-perf.pdf
http://www.it.kth.se/~hvelayos/papers/TRITA-IMIT-LCN%20R%2003-02%20Handover%20in%20IEEE%20802.pdf

"they transport Ethernet-layer frames between the wireless medium and
the subnet."

802.11 APs do not exhibit the same forwarding behavior as IEEE 802
switches.  For example, a frame addressed to an unknown destination
received on the DS is not forwarded to the WM by an AP, whereas it would
be forwarded by a switch.

"Each subnet is implemented as a single LAN or VLAN."

802.11 has no such constraint; it is quite possible for multiple prefixes
to co-exist on a single VLAN.

"   Note that a handover from AP1 to AP2 does not require a change of AR
   because all three ARs are link-layer reachable from a STA connected
   to any AP1-5."

This assumes that the STA will be placed in the same VLAN on each of the
APs, once it has successfully authenticated.  This need not necessarily be
the case.

"  However, a handover from AP5 to AP6 would require a change of AR,
   because the STA would be attaching to a different subnet."

Where the APs implement dynamic VLANs as described in RFC 3580, a
distinction needs to be made between the VLANs that the AP is itself a
member of, and the VLANs that the AP can tag and untag packets too.  It is
quite possible for AP5 and AP6 to be members of different VLANs, and yet
for a STA moving between them to remain on the same VLAN.

"In this case, every change of AP would result in a necessary change of
AR"

Again, this is not necessarily the case if the AR is a "one armed router",
since the AP/AR could maintain membership in multiple VLANs.

Section 4

"    1. The STA performs a scan to see what APs are available.  The
        result of the scan is a list of APs together with physical
        layer information, such as signal strength. "

Some NICs may do scanning in the background, interleaving scans between
data packets.  This decreases the time required to roam if the performance
of the current AP proves unsatisfactory, but it imposes more of a burden
on the AP, since typically the STA places it in power save mode prior to
the scan, then once the scan is complete, returns to the AP channel in
order to pick up enqueued packets.  This can result in buffer exhaustion
on the AP, and attendant packet loss.

     2. The STA chooses one of the APs and performs a join to
        synchronize its physical and MAC layer timing parameters with
        the selected AP.

A STA will typically not choose another AP unless performance on the
current AP is unsatisfactory.  This is typically measured by packet loss,
not just signal strength, since studies show that packet loss is not all
that well correlated with either signal strength or distance:
http://www.pdos.lcs.mit.edu/~rtm/papers/p442-aguayo.pdf

So I think there is a step missing here.

Also, after two you should include an explicit rate adjustment step.
Studies have shown that rate adjustment can be quite time consuming as
well as unpredictable.  For example, see:
Alimian, A., "Roaming Interval Measurements",
11-04-0378-00-roaming-intervals-measurements.ppt,
IEEE 802.11 submission (work in progress), March 2004.

"     6. The new AP sends a Layer 2 Update frame on the local LAN
        segment to update the learning tables of any connected Ethernet
        bridges. "

Note that step 6 is incompatible with 802.11i, because it
results in the STA MAC address being inserted into the learning tables
prior to STA authorization to send or receive packets.  This enables a DoS
attack.

" Note that in some existing 802.11 implementations, steps 1-4 are
   performed by firmware."

While most existing 802.11 NICs handle steps 1, 2 and 4 in firmware,
WPA and WPA2 implementations handle step 3 within the operating system or
driver.

"This might make it impossible for the host to
take any actions (including sending or receiving IP packets) before
the handover is complete."

This would not do any good anyway, since in 802.11 infrastructure mode,
the AP will silently discard data packets unless the station is in State 3
(authenticated and associated).

"This would make it possible to,
e.g., perform step 1 far in advance of the handover and perhaps in
advance of any real-time traffic. "

The issue of scan/join separation is orthogonal to whether the function is
controlled by the driver, firmware or OS.  There are implementations (such
as Broadcom's) that do background scanning in firmware.

" Operation as an Independent BSS (IBSS) or "ad-hoc mode" [3] may also permit the
necessary control."

IBSS and or adhoc mode differs fundamentally from Infrastructure mode
(e.g. no Association exchanges), so that putting a NIC into this mode
frequently disables the ability of a STA to connect to an AP.

"   A change of BSS within an ESS may or may not require an IP-layer
   handover, depending on whether the APs are connected to different or
   the same IP subnets. "

This is a common misconception.  The VLANs which the APs are members of is
orthogonal to the ability of an AP to VLAN tag or untag frames.  So two
APs can each be on different subnets, but STAs roaming between them can
remain on the same VLAN.

"   Because beacon scanning takes on the order of a few hundred
   milliseconds to complete, and because it is generally not possible to
   send and receive IP packets during this time,"

The issue here is whether the STA is able to time reception of the Beacon
so that it can be off sending and receiving data, then switch channels,
catch the Beacon and go off and send and receive data again. 802.11k is
looking at extensions that enable this.

"and a handover directed to the apparently best AP from the old list may
fail."

It is also possible that the Association exchange will succeed, but the
connection will be unsuitable for passing data:
http://www.pdos.lcs.mit.edu/papers/grid:mobicom03/paper.pdf

"   Note that, aside from physical layer parameters such as signal
   strength, it may be possible to obtain all necessary information
   about neighboring APs by using the wildcard form of the RtSolPr
   message."

This function is now being supported by IEEE 802.11k's "Neighbor Report".
See: http://www.drizzle.com/~aboba/SITE/

"  A more targeted approach would allow the STA to
   scan, e.g., only one or two channels of interest, which would provide
   for much shorter interruption of real-time traffic.  However, such
   optimizations are currently outside the scope of 802.11
   specifications."

IEEE 802.11k makes it possible for stations to determine ahead of time
which channels are being utilized, so that scanning can be avoided on
unused channels.

Section 8

"The EAPOL exchange can output a master key,
   which can then be used to derive transient keys, which in turn can be
   used to encrypt/authenticate subsequent traffic."

Actually, the EAP exchange provides an MSK and EMSK.  This is not the same
as the "master key".

"this would enable
authentication to be done in advance of handover, which would both
protect the re-association message and allow fast resumption of
service after roaming."

802.11i as approved does not use pre-authentication derived keys to
protect Reassociation messages.  A new PAR is being considered for this
purpose.  Also, handoff functions such as "PMK caching" are distinct from
pre-authentication.

"However, because EAPOL frames carry only MAC-
layer instead of IP-layer addresses, this is currently only specified
to work within a single subnet, where IP layer handover mechanisms
are not needed anyway. "

Actually, the constraint is that an AP targetted for pre-authentication
must be a member of the same VLAN as the STA.  Note that an AP can itself
be a member of multiple VLANs.  This is a distinct capability from the
ability to VLAN tag and untag packets.

"This would introduce
additional handover delay while the 802.1X exchange takes place,
which may also involve round-trips to RADIUS or Diameter servers."

IEEE 802.11i provides for PMK caching, which enables APs attached to the
same WLAN switch to share a key cache.  In such a case, it is not
necessary for a new EAP exchange to take place before or after a
reassociation;  only the 4-way handshake need be completed.

Note that the PMK caching is orthogonal to VLAN management;  it is
possible for a STA to move between VLANs, yet avoid an EAP exchange by
successful PMKID negotiation and completion of the 4-way handshake.

References

   [3]  "Wireless LAN Medium Access Control (MAC) and Physical Layer
        (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition.

   [4]  "Port-Based Network Access Control", IEEE Std 802.1X-2001,
        October 2001.

   [7]  "Recommended Practice for Multi-Vendor Access Point
        Interoperability via an Inter-Access Point Protocol Across
        Distribution Systems Supporting IEEE 802.11 Operation", IEEE
        Std 802.11f/D4, July 2002.  Work In Progress.

I believe that the relevant standards are now 802.11-2003 and 802.1X-2004.
IEEE 802.11f has been ratified as a recommended practice.

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop