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.
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
Mick,
I think that is exactly what I'm proposing for
the Handoff group. 2 entities, one on the controlled port and one on the
uncontrolled port. They may actually be the same entity with an attachment
to both LSAPs, that is TBD.
The reasoning is that it benefits from all the
goodness that EAPoL benefits from. 802 Media independence and a clear
definition of the security state of the system (port open/ port
closed).
In my model, it would be a policy decision as to what information
or services were available on which port. Obviously some information would
need to be secured and some information, such as say service advertisments
("Come to my base station, Cheap bandwidth here!") would be better
unsecured and available expediently.
The answer to the question of whether we can retrofit such a clean
architecture into 802[11] is I believe 'yes' and yes its definition should
be orthogonal to linksec. If it is not possible, watch the handoff group
crash and burn :-).
Regards,
DJ
David Johnston
Intel Corporation
Chair, IEEE 802
Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503
380 5578 (Mobile)
Tel : 503 264 3855 (Office)
The general solution to this class of issues
seems fairly clear. Provide/define a protocol entity that attaches to
the/an Uncontrolled Port that is providing the attachment point for the
roving station.
Apart from the fact that that entity appears to
need to be able to read the current status of the Authorized/Controlled
Port (really as an optimization so that it doesn't have to conduct its
own further checks to guide its behavior - another and possibly better
solution might be to partition the overall functionality between such an
entity and a companion one that ataches to the Authorized Port, or to
define an entity which attaches to both), its definition ought to be
orthogonal to LinkSec.
Clearly with a roving type technology where
ports come and go an association (also quite properly known as a Port)
needs to be in place for such an entity to communicate with the roving
station. That association doesn't have to be secure
however.
Wired world:
Uncontrolled
Authorized
Port \ /
Port (secured association)
\ /
SecY
|
Port
(lower MSAP)
|
Unwired world:
Uncontrolled
Authorized
Port \ /
Port
\ /
SecY
|
Association
|
Mick
[I'm not saying that one can retrofit such a
clean architecture to 802.11 as currently defined.]
On Behalv of Dave Johnston: