Subject: [pcp] pcp auth requirements

From: Alper Yegin <[email-masked]>
Date: Tue, 30 Apr 2013 10:22:33 +0300

c.  If a server wants to send an unsolicited message, but the
          previous security association has expired

          1.  The server can continue to use the same SA to protect
              messages pertaining to that mapping, even if the SA is
              technically expired.

"Expired" means "do not use (even if its still hanging around)". 
We not only do not need to use expired SAs, but also using something expired in any sense is plain wrong -- unless someone wants to redefine what "expired" means.
 
              -  Such server notifications will not change state in the
                 PCP client.

              -  The notification could be a trigger for the client to
                 re-authenticate.  

Here the document is getting into some solution description.

And as for such a solution:

Instead of sending a notification that is protected with an expired SA to mean "re-authenticate", why not send an explicit message that says "re-authenticate"?
What is gained by appearing to use an expired SA (but in fact not really using it! because the payload of the notification is not consumed by the receiver).

                 For example, if the server indicates
                 that external IP address/port has changed, the PCP
                 client can then re-authenticate with the server to
                 confirm if the external IP address/port for the mapping
                 has indeed changed.

          2.  The server can optionally trigger re-authentication with
              the client.

Yes, that's the solution. If the server has something to send to the client, and there's no live SA, then the server first needs to trigger re-auth, setup a fresh SA, then send whatever it wants to send to the client.

Alper