There are several state machines defined in Section 8.2 of IEEE 802.1X
- 2004.

The combination of Supplicant PAE state machine and Supplicant Backend
state machine are comparable to PaC state machine in PANA.  Similarly,
the combination of Authenticator state machine and Authenticator
Backend state machine are comparable to PAA state machine in PANA.
The two Backend state machines in 802.1X are direct interface to EAP
state machines, taking care of processing EAP messages.

For example, the 802.1X Supplicant PAE state machine consists of the
following states:

LOGOFF, DISCONNECTED, CONNECTING, AUTHENTICATING, AUTHENTICATED,
RESTART, S_FORCE_AUTH, S_FORCE_UNAUTH and HELD.

The Supplicant Backend state machine takes effect while the Supplicant
PAE state machine is in state AUTHENTICATING.

Very roughly speaking, the combination of CONNECTING, RESTART and
AUTHENTICATING states corresponds to authentication and authorization
phase in PANA.  AUTHENTICATED state corresponds to access phase in
PANA.

Yoshihiro Ohba


On Mon, Mar 05, 2007 at 12:19:03PM +0100, Mark Townsley wrote:
> Alper Yegin wrote:
> >>If EAP was simply being transported, I don't know why PANA would even
> >>need to know whether it was an "auth" "reauth" "authz" or otherwise.
> >>    
> >
> >PANA, much like other EAP transport protocols (e.g., IEEE 802.1X, IEEE
> >802.16e PKMv2) has a state machine. None of these protocols are like "IP",
> >or "UDP" -- i.e., stateless, such that you transmit payloads as they come
> >without holding or using any associated state. 
> >
> >IEEE 802.1X and IEEE 802.16e PKMv2 have state machines.
> >  
> Later in this email I asked specifically if you could provide a 
> comparison of the PANA phases/states with that of 802.1x or some other 
> commonly used EAP transport. Could you provide that?
> 
> Thanks,
> 
> - Mark
> >Alper
> > 
> >
> >
> >
> >
> >
> >  
> >>-----Original Message-----
> >>From: Mark Townsley [mailto:[EMAIL PROTECTED]
> >>Sent: Monday, March 05, 2007 12:00 PM
> >>To: Alper Yegin
> >>Cc: [email protected]
> >>Subject: Re: Message type reduction (AD comment)
> >>
> >>Alper Yegin wrote:
> >>    
> >>>>>>the message types to major PANA state transitions or specific
> >>>>>>            
> >>functions
> >>    
> >>>>>>(like ping), and the AVPs as options within the state change or
> >>>>>>function.
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>In order to better understand what you are suggesting, can you please
> >>>>>
> >>>>>          
> >>>>tell
> >>>>
> >>>>        
> >>>>>us what we need to change in our current design? Given that:
> >>>>>
> >>>>>- We have phases (handshake, authentication and authorization, access,
> >>>>>re-authentication, termination).
> >>>>>- Each phase has a set of expected message types and specific flows
> >>>>>
> >>>>>          
> >>>>(e.g.,
> >>>>
> >>>>        
> >>>>>handshake: PCI, PSR, PSA; termination: PTR, PTA; etc.).
> >>>>>
> >>>>>
> >>>>>          
> >>>>But do you need authentication phases in PANA if you focus on being a
> >>>>transport for EAP and let EAP handle the  authentication phases? I
> >>>>        
> >>could
> >>    
> >>>>certainly be wrong here, but at the surface it seems that this is a lot
> >>>>of duplicate state between layers.
> >>>>
> >>>>        
> >>>The phases I listed above are the "PANA phases". Two of the phases (auth
> >>>      
> >>and
> >>    
> >>>authz, and re-auth) involve running (transporting) full "EAP sessions"
> >>>      
> >>(from
> >>    
> >>>the beginning of the EAP authentication to the end). Other phases are
> >>>      
> >>more
> >>    
> >>>about maintaining the PANA session, and they do not involve in
> >>>      
> >>transporting
> >>    
> >>>EAP at all.
> >>>
> >>>      
> >>If EAP was simply being transported, I don't know why PANA would even
> >>need to know whether it was an "auth" "reauth" "authz" or otherwise.
> >>    
> >>>None of the level of details in these phases deals with "EAP
> >>>      
> >>authentication
> >>    
> >>>phases" or "EAP method authentication phases". Those are completely
> >>>encapsulated inside the aforementioned two PANA phases.
> >>>
> >>>      
> >>That is good to hear.
> >>    
> >>>The encapsulation is EAP_method/EAP/PANA (much like
> >>>EAP_method/EAP/any_other_transport).
> >>>
> >>>      
> >>It would help me a lot if you could provide an example of how the PANA
> >>phases relate to other EAP transports. For example, does 802.1x or even
> >>PPP have similar states as PANA?
> >>    
> >>>A specific EAP method has its own phases and a state machine.
> >>>It is completely wrapped inside EAP with its own phases and state
> >>>      
> >>machine.
> >>    
> >>>And that in turn is completely wrapped inside PANA with its own phases
> >>>      
> >>and
> >>    
> >>>state machine.
> >>>
> >>>I hope this makes sense.
> >>>
> >>>      
> >>It does, and I hope you can see that I am trying to drill down at the
> >>heart of whether PANA truly needs all of the phases and states that it
> >>has. If it doesn't, then perhaps we can take more steps at simplification.
> >>
> >>- Mark
> >>    
> >
> >  
> 
> _______________________________________________
> Pana mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana

Reply via email to