Alper Yegin wrote:
task at hand. For example, you effectively have 18 different PANA
message types for what is largely a lock-step transport of EAP messages.
There are really 9 message types (answers are using the same message type
with the 'R' bit set).
9 requests, and 9 answers. Particularly when you consider that the
answer messages may or may not piggyback EAP payloads, they effectively
operate like their own message types - resulting in their own state
transitions.
But, this is mostly semantics.
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,
the message types to major PANA state transitions or specific functions
(like ping), and the AVPs as options within the state change or
function. 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.
As yet another simplification, what if you allowed any authenticated
PANA message update the source IP/port? This would seem to be of
considerable help to NAT traversal (e.g., if the PaC is issuing a
periodic Ping). Also, it would mean that you don't have to define a
specific message (e.g., the Ping, or reauth, etc. would all do the trick
just fine).
I'm thinking this implicit semantics may hurt us down the road. There may be
valid reasons to send messages with different source addresses in the
future. I think a dedicated and explicit message type is better.
If you allow messages to come from different source addresses for the
same session, we are back to coordinating a context ID for the PANA
session that is somehow unique across the administrative domain.
2. With a little bit of work, I think you could eliminate the need for
the PCI and Pana-start messages. Using DHCP for discovery reduces the
need for these messages. In fact, one of the many "optimizations"
described here include carrying EAP directly in these messages,
existence proof that you don't need to provide your own handshake before
encapsulating EAP.
I couldn't understand how DHCP helps. PCI is needed to let PaC trigger the
PANA exchange. And the reason for a dedicated PSR is the aforementioned
design choice.
DHCP helps you to discover the PAA. Once you know the PAA, then you can
immediately send it an EAP message as a payload. The fact that the EAP
payload can be carried on your first PANA message effectively proves this.
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.
- Mark
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
