[pcp] EAP retransmits and re-authentication

[Sam Hartman <[e-mail]>]

I wanted to give the WG some final thoughts on the conversation Alper
and I  have been having.
This will probably be my last message on the topic as I think we're
basically at the point of diminishing returns.

>>>>> "Alper" == Alper Yegin <[e-mail]
g> writes:

On the topic of retransmits, we agree that under section 4.3 of RFC
3748, you can set the transmit timer to infinite.
I think we agree that this moves retransmits from within the EAP layer
to the EAP lower layer.


    Alper>   When run over a reliable lower layer (e.g., EAP over
    Alper> ISAKMP/TCP, as within [PIC]), the authenticator
    Alper> retransmission timer SHOULD be set to an infinite value, so
    Alper> that retransmissions do not occur at the EAP layer.


    Alper> Only when run over a reliable EAP lower layer, the EAP layer
    Alper> sets the timeout to infinity.  So, whether the rexmit is
    Alper> handled by the EAP layer, or the EAP lower layer, the PCP
    Alper> server will be sending retransmissions in your case.

It's actually fairly easy to move which side generates the
retransmission once you move it into the lower layer.
Note that the PCP server still needs to maintain the state of what EAP
request to send, but whether to send that can be based on what the
client sends.
That is, if the PCP state machine works better with client-driven
retransmits,
we can achieve that.
We do need authentication-session state in the server, and part of that
state is the unacknowledged eap-request if there is one.


With regard to re-authentication:

>>     Consider what happens in an AAA server. There, your EAP
>> server cannot (and is not supposed to) handle retransmits.
>> RADIUS at least is a lock-step protocol. Ignoring things like
    Alper> COA,


    Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an
    Alper> unsolicited message, more specifically for starting EAP
 
I'd like to draw the WG's attention to RFC 5176, which defines COA.
Section 4 explicitly mentions that COA cannot be used for starting
re-authentication.  Section 1.1 is an applicability statement explaining
why COA is not standards-track because of security and semantic
concerns.

As best I can tell only diameter has AAA support for re-authentication.
So, I'd like to draw our attention to RFC 4005, section 3.3 which
defines rules for diameter re-authentication.  That section explicitly
calls out re-authentication must be supported *if the underlying service
supports it*.  That is, re-authentication is OPTIONAL for a given
service like PCP, but if a given PCP server supports re-authentication
and diameter, then it needs to support re-authentication via diameter.
Section 3 of RFC 4072 (diameter over eap) confirms the guidelines of RFC
4005 apply.

Re-authentication being optional is definitely consistent with my
implementation experience.  I have no experience with diameter, but do
have a lot of experience with EAP implementations that consider
re-authentication optional.


This is all great news for the PCP community.  We can choose the
retransmission strategy that best meets the PCP implementations.  we can
choose to support re-authentication if it is useful, or decline to
support it if it is not.  If we don't choose to support
re-authentication then we can avoid the complexity.