Re: [pcp] #62: Client-driven or server-driven auth retransmissions

[Sam Hartman <[e-mail]>]

Hi.
Yoshi and I have had several rounds of discussing EAp retransmissions in
the ABFAB working group.
My understanding of the situation has improved.

Retransmission of an EAP request will always happen I've been describing
this issue incorrectly when I brought it up in the PCP group.

The question is what is used to trigger retransmissions, not what party
does the retransmission.

The authenticator (PCP server/PAA) has the EAP request packet as part of
security state it maintains.

The question is whether the authenticator has a timer that causes it to
retransmit the request.  That's what the default behavior in EAP is.

Alternatively, the EAP specification (RFC 3748) allows that timer to be
set to infinite.  In that case, the lower layer (PCP or PANA) is taking
responsibility for reliability.

If the lower layer is handling reliability,  then you can use whatever
trigger you like.
You can have a timer on the server.
Alternatively, you can have a timer on the client and retransmit the
request on the server when you receive a duplicate response.

So, no matter what option you pick, the server is required to hold the
state.
The potential advantage of picking client-triggered retransmits is that
it may make it easier to match an existing implementation.

We could really use input from PCP implementations about whether having
the authentication retransmit timer on the client is easier than the
server.