Re: [pcp] Server's auth policy discovery

[Margaret Wasserman <[e-mail]>]

On Oct 12, 2012, at 8:44 AM, Alper Yegin wrote:
> 
> As for dealing with discovery for PANA port-sharing, either:
> - We agree that it's OK for all clients to start with "no auth", or

What does this mean?  There are two cases I can think of where a client might "start with" an authenticated request:

1) Where a client is configured to do so.
or
2) Where a client is attempting to renew a mapping that was originally granted via an authenticated request.

How can we say, in either case, that the client should start with "no auth"?

> - We use a DHCP-based solution (I know you are not happy with this), or
> - We use an ANNOUNCE-based auth policy discovery solution
> 
> At least one of these would handle the issue.

I think I am confused about what problem you are trying to solve here...

If a client sends an authenticated request in either of the encapsulated cases (PANA or PCP-Specific), an error will be returned (by the PCP server) indicating (to the PCP client) that the opcode is not supported, and the client will know that authentication is not supported.  If the client is willing to try an unauthenticated request, it can do so at that time.

The only problem that I am aware of is for the demux case, because the error will not be returned to the process that is actually trying to do the authentication (the PANA client_ -- it will go back to the PCP client.  Therefore, the PANA client might keep retrying, even though the PCP server has returned an error.  Also, the PCP client needs to include special handling of the "unsupported version" error that occurs when authentication is being attempted, so that it knows to try an unauthenticated request.  

Margaret