Re: [pcp] Capability discovery

[Sam Hartman <[e-mail]>]

>>>>> "Alper" == Alper Yegin <[e-mail]> writes:

    Alper> Let's look at the whole space and see where the issue arises.

    Alper> 1. PANA tunneling No problem.
Agreed. If by tunneling you mean encapsulation.

    Alper> 2. PANA port-sharing (side-by-side)

    Alper> 2.1. DHCP-based PCP server discovery Not a problem, we can
    Alper> easily define auth_requirement as an attribute of the PCP
    Alper> server.

I don't think this is a reasonable thing to do.
It requires the DHCP servenr to be aware of capability changes in the
PANA server.
I think DHCP is good for discovering the identities of services, but not
for capability discovery.

    Alper> 2.2.d. Client supports auth, server does not support auth.
    Alper> Earlier example to cause an issue was when the client starts
    Alper> with auth, and the server does not understand what was going
    Alper> on (server would think the client is talking version PCP
    Alper> 128).

    Alper> But, we can easily require "clients that do not know the
    Alper> server's capability and policy" to start with "no auth" and
    Alper> see what happens.  Either the PCP goes thru, which is fine;
    Alper> or the client receives a PCP auth error in which case it
    Alper> learns to go back and try with auth.

This does not work for clients who have a security requirement of
requiring authentication even if the server does not require this.
If the client wants integrity protection of the response, this is
important.

For example the client can have confidence that its mapping is created
and that the response is not spoofed.
For nat traversal, this is not a big deal.
For firewall policy changes this can be a huge deal.