> >> 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. 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. The encapsulation is EAP_method/EAP/PANA (much like EAP_method/EAP/any_other_transport). 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. > > - Message type is carried in the PANA header > > - Each message type is defined to include certain set of AVPs (e.g., > PSR: > > EAP, Algo). > > > I'm trying to come to grips with how the design got as complex as it > has, while still not meeting some of the basics of what an EAP transport > would call for if one were to design a perfect custom transport for it. > Realizing that all messages were sent reliably when this isn't required > by EAP itself was certainly a trigger for me heading down this path - I > wish I had noticed that earlier. Alper > > - Mark > > > > > > >> Finally, since PANA is effectively a transport protocol for > >> EAP, EAP should be treated as a Payload which can be carried over the > >> protocol's different modes of transport with as little linkage to the > >> state of PANA beneath as possible. I don't see any of these lines > >> clearly drawn, which may be the source of some of your headaches at > this > >> stage. > >> > > > > > > > > > >>>>> Another optimization allows optionally carrying the first > >>>>> EAP Request/Response message in PANA-Start-Request/Answer message > >>>>> > >> as > >> > >>>>> described in Section 4.3. > >>>>> > >>>>> > >>>>> > >>>> Another optimization. I'm feeling very sorry for the poor > >>>> > > implementor... > > > >>> We could remove that. > >>> > >>> > >> I'm not sure you want to, I would think that it would be the preferred > >> method of operation in fact. > >> > >> Now, if you completely decouple your PANA states from the type of EAP > >> message being carried, and position the EAP message as something that > >> can effectively show up as a Payload AVP at anytime, then perhaps you > >> can have the best of both worlds here. > >> > > > > Alper > > > > > > > > > > > > > > > >> - Mark > >> > > > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
