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

Sam,

Your description below did not capture DoS attack issue with 
client-driven retransmission that I mentioned.
It would be fair if you could mention it.

Yoshihiro Ohba

(2012/10/24 20:59), Sam Hartman wrote:
> 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.
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>