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

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

Reply via email to