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

From: "Alper Yegin" <[email-masked]>
Date: Sat, 10 Feb 2007 02:27:04 +0200

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

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?

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

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

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

Thinking more about what we can toss away... How about getting rid of
PANA-Error messages? We can include error AVPs in any response message if
the request message had an issue. If the response message has an issue, we
do nothing (silent discard).

Alper

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 10 Feb 2007 11:32:09 -0500

On Sat, Feb 10, 2007 at 02:27:04AM +0200, Alper Yegin wrote:
(snip)
> do nothing (silent discard).

I am wondering if we could remove not only PANA-Error message but also
error AVPs (Failed-AVP and Failed-Message-Header AVPs) and protocol
error result codes described in Section 8.8.2) entirely.  These are
mostly for debugging purpose and we could deal with them by silent
discard and error logging.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Feb 2007 13:45:26 +0100

> discard and error logging.
While certainly verbose, I didn't find this a particularly complex part
of your protocol. Debugging tools are generally a good thing,
particularly with such a complex combination of messages and state
machine. If you end up simplifying your state machine and set of
messages, then reducing the number of possible errors to report on may
very well follow naturally.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Feb 2007 15:01:46 +0100

> There are really 9 message types (answers are using the same message type
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.
> semantics of each message. With the separate message types, boundaries are
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.

> 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.
> PANA exchange. And the reason for a dedicated PSR is the aforementioned
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. I'm feeling very sorry for the poor implementor...
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

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 16 Feb 2007 15:44:42 +0200

Let me further separate threads. This one issue is relatively standalone,
and orthogonal to the format re-structuring you are suggesting.

> session that is somehow unique across the administrative domain.

The session is still on the same PAA. PaC is the one changing address. 

I think you are referring to the case when we needed to globally unique
session identifiers. I don't see a need for such a thing in this case.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 16 Feb 2007 15:50:57 +0200

Here is another spin-off thread...

> payload can be carried on your first PANA message effectively proves this.

Once the PaC discovers the PAA via DHCP, it can send a message (PCI) to the
PAA. But that message cannot carry any EAP payload, as EAP must be initiated
by the PAA per RFC 3748. 

As for the need for PANA-Start, that goes back to your format re-structuring
suggestion. I'd like to think more about it.

Alper

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Feb 2007 12:16:02 +0100

Alper Yegin wrote:
>>>> 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
>>     
Well, if the PAA is using the PAC source IP, port, and ID to identify 
the session when control messages arrive, then you cannot allow the 
control messages to come from different source PAC addresses.
> session identifiers. I don't see a need for such a thing in this case.
I'm trying to remember who assigns the ID. If it is always the PAA, then 
yes you are OK here.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Feb 2007 12:18:46 +0100

Alper Yegin wrote:
>>>> 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
>>     
Yes, its the PSR not the PCI. Apologies.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 19 Feb 2007 18:40:12 +0200

> control messages to come from different source PAC addresses.

PANA session is identified by the "PANA session-id" alone, not "source
address + session-id".

> I'm trying to remember who assigns the ID. If it is always the PAA, then

Yes, PAA assigns the session-id.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 19 Feb 2007 21:01:15 +0200

> sequencing) and message verification (hashing and the like) functions,

Are you suggesting we do not include "Message Type" in the PANA header?

> 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.).
- Message type is carried in the PANA header
- Each message type is defined to include certain set of AVPs (e.g., PSR:
EAP, Algo).

> Finally, since PANA is effectively a transport protocol for

Alper

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Feb 2007 17:41:24 -0500

Alper Yegin wrote:
>>> rather than using fewer messages and decorating each with appropriate
>>>       
>> flags
>>     
>>> 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?
>>>
>>>       
This, alone, is probably not a big deal either way - certainly not worth 
changing at this stage.
> 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.
> - Each message type is defined to include certain set of AVPs (e.g., PSR:
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

>>>>>    EAP Request/Response message in PANA-Start-Request/Answer message
>>>>>           
>> as
>>     
>>>> Another optimization. I'm feeling very sorry for the poor
>>>>         
> implementor...
>   
>>> We could remove that.
>>>
>>>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 20 Feb 2007 02:58:56 +0200

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

Alper