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: