Re: [pcp] issue#61: Unsolicited reauthentication

I realized I missed the additional text on the issue tracker:

Should a client need to remain reachable in order to defend/retain its mappings?

Alper> Depends on the deployment. The "architecture/protocol design" shall not assume the client needing to remain reachable in order to defend its mappings.

Alper> Supporting "re-authentication" in the "arch/protocol design" does not imply otherwise.
Alper> Even though re-auth is supported in the design, deployment can decide to use it or not.
Alper> This is a deployment decision. Not to be dictated by the protocol design.

Consider case where client periodically goes to sleep but wants the mapping to exist whenever it's awake. Is this scenario important?

On Nov 5, 2012, at 1:21 PM, Alper Yegin wrote:

> 
> 
> Would it be desirable to support unsolicited re-authentication?
> 
> – May depend on answer to issue #60 – is there a need to renew authentication information when no requests are being issued?
> 
> Alper> As we discovered over the mailing list, there are cases where the PCP server sends unsolicited messages to the PCP client (e.g., when the mapping lifetime is updated). Such messages too need to be secured. So, tossing the PCP SA as soon as the first PCP request/response is completed after the EAP authentication does not work. PCP SA is needed later too. 
> 
> Alper> Besides, I don't understand why you'd want to toss the PCP SA away. Keep it around because you are likely to need it even at least for the subsequent requests from the PCP client. 
> 
> Alper> And, finally, RADIUS and Diameter support EAP re-authentication initiated by the AAA server. Unless we explicitly forbid that, they are there to be supported by any EAP lower-layer. 
> 
> 
> Or is it preferable to wait until a new mapping request is issued, and start a new authentication process then, if needed?
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp