Subject: [Pana] Re: Message type reduction (AD comment)

From: Mark Townsley <[email-masked]>
Date: Mon, 05 Mar 2007 11:00:15 +0100

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-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 5 Mar 2007 12:52:24 +0200

> 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.

Alper

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 12:00 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: Message type reduction (AD comment)
> 
> Alper Yegin wrote:

---

From: Mark Townsley <[email-masked]>
Date: Mon, 05 Mar 2007 12:19:03 +0100

> 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
>>>>>> the message types to major PANA state transitions or specific
>>>>>>             
>> functions
>>     
>>>> transport for EAP and let EAP handle the  authentication phases? I
>>>>         
>> could
>>     
>>> 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.
>>>
>>>       
>>> None of the level of details in these phases deals with "EAP
>>>       
>> authentication
>>     
>>> 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.
>>>
>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 5 Mar 2007 23:33:56 -0500

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