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

From: Pete McCann <[email-masked]>
Date: Tue, 12 Oct 2004 11:02:37 -0500

Hi, Bernard,

Thanks for your detailed feedback.

It seems that most of your comments relate to the level of detail with
which the 802.11 standards were specified; this was deliberately made
somewhat abstract to simplify the presentation.  However, I can make
another pass to accommodate some additional detail if the group thinks
it's warranted.

See below.

Bernard Aboba writes:
 > 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

The 802.11-1999 standard contains the following statement in Section 5.4.2.2:

  At any given instant, a STA may be associated with no more than one
  AP. This ensures that the DS may determine a unique answer to the
  question, “Which AP is serving STA X?” Once an association is
  completed, a STA may make full use of a DS (via the AP) to
  communicate. Association is always initiated by the mobile STA, not
  the AP.

Unless this changed in the 2003 version, it doesn't seem to qualify
the requirement to apply to a given ESS; however, I can understand
that if the DSs are completely separate there is no way to tell that
an MS is not associated with more than one ESS.  I can re-write the
statement.

 > "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

Yes, "coverage area" is a convenient metaphor, but I can quote
directly from the 802.11 standard, section 5.2:

  It is useful to think of the ovals used to depict a BSS as the
  coverage area within which the member stations of the BSS may remain
  in communication. (The concept of area, while not precise, is often
  good enough.) If a station moves out of its BSS, it can no longer
  directly communicate with other members of the BSS.

Do you really think this needs more elaboration in our document?

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

I think James brought this up because a previous version used the term
"bridge" which wasn't correct.  So, we used more neutral terms like
"relay" and "transport" which don't imply implementation of any
particular 802 spanning-tree algorithm.  The language used in the
802.11 standard is "the APs provide access to the DS" but I thought
that was a bit obtuse for our purposes.  Do you have a better text
suggestion?

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

Ok, but wouldn't each subnet be on one and only one VLAN?  That is, a
subnet is the set of nodes (with the longest common prefix) that are
reachable without traversing an IP routing hop.  I know the term
subnet has been problematic in a lot of IETF work, but I settled on
it as the least bad word for the concept we are trying to express here.

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

Ok, I will adjust the text to make the assumption clear.  The example
is just that (an example), so I think the case where you get placed on
a different VLAN will devolve into the handoff case (AP5->AP6
transition).

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

Argh.  Ok, I can state explicitly that the handoff example from
AP5->AP6 is a change of VLAN and therefore subnet (that follows,
right?).

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

Can you define that term "one armed router"?  I haven't heard it
before.

Again, I can qualify the example to state that the APs do not share
common 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.

Ah, ok.  This would have been valuable feedback during our discussion
of scanning implementations.

I can add a note with this elaboration (do you mind if I copy your
text almost verbatim?)

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

Yes, I guess there is an implicit step 0 where the STA somehow
recognizes the need for a handoff.  I can add this, along with your
caveats about the algorithms used to decide that a handoff is necessary.

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

I'll take a look at this and consider adding it.

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

Step 6 must happen at some point, right?  I think your comment boils
down to the fact that I left out step 4.5 where 802.1X runs.

I thought I saw a modification to the sequence of events in 802.11i
that deferred the step 6 until after 802.1X, but I can't seem to find
it right now in the latest version that I have...

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

I thought the WEP keys were typically pushed into the NICs; but, I
guess the WPA enhancements are more easily implemented in the driver?
By "WPA" you mean the TKIP stuff, right?

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

The important implication of the sentence is that you don't (in this
case) have much opportunity to carry out IP-layer sentence with the
*old* AP with which you *are* 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.

Ok, I can clarify the text.  The important idea is that unless the IP
stack has visibility to the scanning data prior to the handoff, it
won't be able to invoke FMIP in the most efficient mode.

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

Right, you wouldn't have an infrastructure with APs anymore, just an
ad-hoc collection of nodes talking to each other.  James pointed out
that there were some experimental setups that worked this way, so I
wanted to accommodate them here.  But, I doubt they would be used much
in real deployments.

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

Ok, I guess by "are connected to" I meant to add "either directly or
indirectly via VLAN tagging."  Is that acceptable?

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

Ok, I can add a reference to this work.

 > "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

That would be a pain.  I guess I can mention this as an exception or
failure case.

 > "   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/

How stable is this work?  How do you think it should be referenced by
the draft?

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

I guess the ongoing work in IEEE is catching up to us... 

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

Ok, I will change it to Master Session Key (MSK) and Extended Master
Session Key (EMSK).  These are both used in the subsequent four-way
handshake?

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

"PMK caching" means I would need to have visited that AP (or another
AP with a common back-end) previously, right?

I guess 802.11i RSN does not attempt to protect association or
reassociation messages at all, right?  But you could then go directly
into the 4-way handshake if you have done pre-authentication, right?

I will repair the text.

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

I guess I don't understand the difference between being a "member" of a
VLAN and being able to tag/untag packets... in both cases the VLAN is
reachable from the AP, right?  Are you saying that merely having the
ability to tag/untag packets does not make an AP reachable from a STA
that is on that VLAN?

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

How likely is it that two APs that are not on the same VLAN are
connected to the same switch?  I guess it could happen...

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

Only if the STA has been there before, or the AP shares a common
back-end with another AP the STA has visited, right?

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

I will update these.

-Pete

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