| Re: Issue 204: Peer-to-peer operation | <– Date –> <– Thread –> |
From: Jim Burns (jeb mtghouse.com)
|
|
| Date: Wed, 3 Dec 2003 14:07:29 -0600 (CST) | |
Hi folks, Comments below. Jim B.
Bernard Aboba wrote:
Our original assumption in the design of the .1X/EAP state machines was that EAP was a functional entity that could have multiple instantiations, one for each state machine. So, the current .1X design delivers the EAP frame once to each EAP machine (which looks like two deliveries of the same frame if there is a single EAP mux/demux layer).understand if it does. First question is when there is both an independent
supplicant and authenticator configured at the 802.1X layer, is there also a
corresponding independent EAP layer above each? I think the answer is yes.
I'd say that there is a single EAP layer on the host, but EAP
authenticator and peer layers will be present above that. This makes it
possible for the host to process traffic *both* for the EAP peer
(EAP Request (Code=1), Success (3), Failure (4)) and for the authenticator
(EAP Response (Code=2)). However, an EAP packet will only be processed
if there is a method registered corresponding to the Type code
in the packet *and* the method has registered with the EAP peer or
authenticator layer or both. So if a method has only registered with the
EAP peer layer and a packet destined for the authenticator layer is
received (e.g. Code=2), then that packet will be dropped.
The .1X transport does not filter the frames as EAP peer frames and EAP authenticator frames because there is no indication in the EAPOL header of the type of EAP frame being carried and their is no logic in .1X which is related to the EAP header.
So, we need to answer the question:
Is their a single EAP layer above the lower layer transport that does mux/demux?
Does the EAP layer assume there is a single channel to the lower layer transport or one for each of its EAP's state machine?
If the answer is that there is a single EAP layer that wants only one copy of the EAP frame then I believe there are several possibilities (all with consequences):
1. Add a mux/demux layer to the .1X standard that looks at the EAP header and directs only one copy of the frame to the correct .1X state machine. This is a layer violation and any changes to the EAP header will require a change to the .1X standard. I imagine that this will slow any changes just due to inter-standards bodies coordination.
2. Modify EAPOL to have a field that indicates which component generated it (Authenticator or Supplicant) and then add a mux/demux layer to the .1X standard that looks at this EAPOL header and directs the incoming frame appropriately. This has backwards compatibility problems. What do we do with a frame from an older version of .1X that does not have this field? (look at the EAP header? deliver the frame to both .1X machines (and hence deliver two copies to the mux/demux layer of EAP))
3. Alter the .1X state machines so that there is a single state machine that signals to EAP that an EAP frame is available, rather than have both .1X machines do this. This solves the problem in one direction -- EAP only gets one copy of the EAP frame and .1X did not cause a layer violation. Unfortunately, the .1X state machines will both transition as if an EAP frame had been seen and both will need a correct response from both EAP machines. Since the EAP mux/demux will only send the EAP frame to the correct EAP machine there will only be one response forthcoming and the .1X/EAP machines will be out of sync. If the mux/demux EAP machine when it delivered the frame to one EAP machine, at the same time signalled the other .1X machine it would get no response (sets eapNoResp for .1X supplicant or sets eapNoReq for the .1X authenticator) then I think this may solve the problem without layer violations, multiple frame deliveries or backwards compatibilty problems. This doesn't solve the other issue we seem to be discussing: both machines running, a mutual authentication EAP method is used between two of the machines so there is no need to run the two machines in the opposite direction.
As an aside, if there is a single EAP layer, then the control variables between the EAP layer and the .1X layer should have different names between the supplicant and authenticator (for instance, eapSuccess and eapFailure signaled from a single EAP layer is not meaningful since there is no context as to which machine is signalling success. Rather, the EAP layer will need to signal eapPeerSuccess or eapAuthSuccess, etc. Again, our assumption of an EAP instance per .1X state machine.
This means that EAP is to be treated as a network layer, rather than a functional component that can have multiple instantiations within a single network layer. Hence the requirement that it receive only a single stream of frames.
I believe the assumption from the 802.1X level is that a received EAP frame
is delivered to both supplicant and authenticator in this case, and would
thus be handed up to their respective EAP layers. The peer side would be
ignoring responses and the authenticator side would be ignoring requests. I
think this all works and I believe Jim Burns has walked these
scenarios.
There are not two EAP layers operating. This is like saying that an IPv4 host that is both a TCP initiator and listener has two IP stacks. The EAP layer is capable of demultiplexing traffic between the EAP peer and authenticator layers, using the Code field in the EAP packet.
The authenticator side would also be ignoring Success (3) and Failure (4)
packets.
---------------------------------------------------------
With regard to the other issue, namely, if both machines are running in a single entity and one of the machines successfully completes a mutual authentication method then how can this open the controlled port (without the other machine needing to complete successfully or complete at all for that matter):
In an attempt to clarify how EAP could control this, I have created a picture which attempts to show the variables that control the controlled port within the .1X state machine in the case that both machines are active:
********> This is an inter state-machine signal -----------> This indicates a data flow
+------------------------------------------------------------------+
| Higher Layer (EAP/AAA) |
+------------------------------------------------------------------+
| * ^ ^ * |
| * | | * |
EAP eapSuccess EAP EAP eapSuccess EAP
response eapFail request response eapFail request
| * success | * success
| * fail | * fail
| * | | * |
V V | | V V
+----------------------------------+ +----------------------------------+
| .1X Supplicant | | .1X Authenticator |
|switch (suppControlledPortControl)| |switch(authControlledPortControl) |
| Force Unauthorized: | | Force Unauthorized: |
| suppPortStatus = FALSE | | authPortStatus = FALSE |
| Force Authorized: | | Force Authorized: |
| suppPortStatus = TRUE | | authPortStatus = TRUE |
| Auto: | | Auto: |
| suppPortStatus = (eapSuccess | | authPortStatus = (eapSuccess |
| && | | && |
| portValid) | | portValid) |
+----------------------------------+ +----------------------------------+
^ ^
| |
+--------------------------------------|
|
V
+----------------------------------+ +----------------------------------+
| .1X Controlled Port | | .1X Uncontrolled Port |
| AuthControlledPortStatus | | |
| = portStatus | | |
| = (suppPortStatus && | | |
| authPortStatus) | | |
+----------------------------------+ +----------------------------------+
^ ^
| |
+-----------------+-------------------+
|
|
VI have taken a liberty with suppPortStatus and authPortStatus and indicated that they are directly set by eapSuccess...actually this is not 100% true, eapSuccess indirectly causes the setting of these variables, but for simplicity I have indicated as I have.
If the EAP/Higher layer detects that a mutual authentication has taken place on one of its machines set the .1X variable for the alternate machine (suppControlledPortControl or authControlledPortControl) to Force Authorized. Actually, there may be some issues with this, but this is the basic idea: EAP knows it no longer cares about the result from the alternate machine and wishes to open the controlled port despite that machine's result so it sets a variable forcing the result from that machine to TRUE. These two variables would need to be indicated as another inter state-machine variable in appendix F.
This is based on draft 7-2 of .1X. I just received the draft 8 of 1X in my inbox, but want to get this out to folks.
Later,
Jim B.
- RE: Issue 204: Peer-to-peer operation, (continued)
- RE: Issue 204: Peer-to-peer operation Bernard Aboba, November 25 2003
-
RE: Issue 204: Peer-to-peer operation CONGDON,PAUL (HP-Roseville,ex1), December 1 2003
-
RE: Issue 204: Peer-to-peer operation Nick Petroni, December 3 2003
- RE: Issue 204: Peer-to-peer operation Bernard Aboba, December 3 2003
- Re: Issue 204: Peer-to-peer operation Jim Burns, December 3 2003
-
RE: Issue 204: Peer-to-peer operation Nick Petroni, December 3 2003
Results generated by Tiger Technologies using MHonArc.