Alper Yegin wrote:
In our design, we chose to have a separate dedicated message per action,
rather than using fewer messages and decorating each with appropriate
flags
and AVPs to mean different things.
For example, we could say "if the session lifetime is set to 0 in PANA-
Foo
message, it means the peer shall terminate the session". This could
replace
the "PANA-Termination-Request". But it'd get us into trouble as we need
to
define various permutations of AVPs, flags, and their values to define
the
semantics of each message. With the separate message types, boundaries
are
cleaner, IMHO. Comments?
It's not about the number of messages alone, number of AVPs alone, etc.
It's how all the different permutations are combined. As you imply here,
the message header, the message types, the AVPs, etc. are a hierarchy,
and one can draw the lines in different places. IMHO, the message header
should be best left to context lookup and transport (reliability and
sequencing) and message verification (hashing and the like) functions,
Are you suggesting we do not include "Message Type" in the PANA header?
This, alone, is probably not a big deal either way - certainly not worth
changing at this stage.
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.
- 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.
- 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
