| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Paul,
There
seems to be a certain amount of overlap between the terms "an association", a "a
secure association", the wireless primitive "associate", and other
operations that might be referred to as associations/bindings which I for one
find a little confusing.
There
are two reasonable definitions for a port - (1) a port is nothing but an MSAP or
MILSAP - i.e. a MAC (Internal Layer Service Access Point) - i.e a
local association/binding between a MAC (Internal Sublayer) Service Client
and the MAC (internal Sublayer Service) Provider (2) a port is a name for or
identification of a collection of Entities that are bound together and comprise
at least one MSAP or MILSAP, and no more than one MILSAP that binds to a Bridge
Relay Entity. I believe the latter is more useful, as it explains how the Port
can always be given a MAC Address (the MAC address of an associated MSAP where
higher layer Entities attach) while a MILSAP is not directly addressable and
hence doesn't have to have a MAC Address bound to it. (I'll leave the definition
of "a binding' out for now).
So
just as in the wired world a Port can exist before a wire is plugged into it,
and a Port can be added to a System on demand (like plugging a new card into the
system backplane). A port (on a bridge, I can't speak for a standardized
wireless AP) can certainly exist before any wireless primitive 'associate"
occurs. It just has MAC status parameters (.1D Clause 6.4.2)MAC_Enabled and
MAC_Operational FALSE. It can certainly be identified, by a MAC Address bound to
an MSAP supported by the Port, and can support higher layer entities (like an IP
station) above that MSAP.
So the
questions for roving (I use the term to avoid suggesting that anything is going
to move from the point of view of IP, or that there is any telephony technology
involved) appear to me to be as follows ( I assume that the roving station - the
rover - can receive from the AP that it is about to rove to - I'll call
this AP "the peg" and I am going to assume that it behaves exactly like a
standard bridge - 'cause I can't speak for standardized
APs):
a)
What entity does the peg use to transmit advertisments that the rover receives
and uses to make the decision to rove to the peg (to peg
out)
which
is closely tied to:
b)
when does the wireless port appear/when is it and the resources
(counters/records etc) created on the wireless bridge
and
c)
what is the address used for advertisments.
I
thought that were are 3 possible sets of answers to the above questions that
coherently preserve network and network management behavior, however the
following seems much the best as it avoids having a number of rovers contend for
the same port.
Set
1
--------
a.
Advertisements do not come from the port on the peg, but from a distinct higher
layer entity on the peg. They are destination addressed to a group MAC address,
of the type that is filtered by bridges and carry a source MAC address assigned
to the higher layer entity in the peg. It is a complete mistake for the
roamer (and for any bridge that might confuse the advertisments with the
existence of a shared media link of the ordinary type) to learn this source
address, and we should make sure that this is clear - using an address in this
way (not port associated) runs the risk of fouling up accessibility of the
address. There is no point in attempting to send a frame through the bridge
network to this address. The advertisment should contain a system address for
the peg - preferably as an IP address plus port number - which can be used by
the rover through its current association.
b. The
rover contacts the peg through the IP address in the advertisment, using its
current connection through another AP, and the peg creates the port or
allocates an existing port specifically for this rover with parameters supplied
by the rover (if the rover doesn't peg out soon the peg will withdraw the port,
destroy it or use it for another rover).
c. The
rover associates with the port and can receive further parameters and conduct
any remaining dialogue through the uncontrolled port necessary to gaining access
through the controlled/authorized port. In particular the uncontrolled port is
used for the rover to send its first "I've arrived message".
Mick
If the
rover can both send and receive messages to and from the peg as if it were using
shared media before forming an insecure one-to-one association with the peg then
the above answers might change.
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of CONGDON,PAUL (HP-Roseville,ex1) Sent: Friday, August 22, 2003 8:39 AM To: 'Johnston, Dj'; mick_seaman@ieee.org Cc: LinkSec Subject: RE: [LinkSec] updated handoff presentation So the
big question for me is, how do we deal with the port in the roaming wireless
world if it needs to be instantiated before the association actually
exists? Does the port you are talking about fit this model? In
other words, before I roam to the new AP, the association doesn't exist yet, so
neither does the port. How do I create it before the association
takes place, so I can quickly open the controlled port part when the
supplicant finally does show up and associate? This is the pre-auth
problem...
Paul
|