Subject: [pcp] Capability discovery

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Oct 2012 12:03:35 +0900

There has been a question on what to do when PCP client supports PCP
authentication
while PCP server does not, and vise versa. The same issue will exist for
future PCP extensions.

I would like to hear opinions whether defining a capability discovery
exchange
in PCP base specification ever makes sense, where the capability
discovery exchange is
expected to happen prior to any other PCP opcodes.

Best Regards,
Yoshihiro Ohba

---

From: <[email-masked]>
Date: Fri, 5 Oct 2012 07:56:55 +0200

Dear Yoshihiro,

FYI, this document proposes an option to retrieve the capabilities of the PCP-controlled device:
http://tools.ietf.org/html/draft-boucadair-pcp-capability-00

The current version does only describe whether the controlled device is NAT44, NAT46, NAT64, IPv4 FW, IPv6 FW, Port Range Router. 

This feature is defined as an option but can be elected to be defined as standalone OpCode. The capabilities set format can be modified to support new capabilities: e.g., authentication support, list of supported opcodes, etc. 

Saying that, IMHO we need further analyze what are the gains and the impacts on the PCP server to support such feature:

* Is it reducing exchanged messages? 
* Does it harm if we try an opcode no matter if the PCP server supports it or not?
* Reduce delay before establishing a session?
* Be a trigger to decide whether all available PCP Servers need to be contacted in // or select only one?

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Yoshihiro Ohba
>Envoyé : vendredi 5 octobre 2012 05:04
>À : [email-masked]
>Objet : [pcp] Capability discovery
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Oct 2012 15:57:25 +0900

So there are two ways for capability discovery:

- Use a PCP Opcode
- Use a PCP Option

If the WG has not decided which way to use for capability discovery,
I would have to mention the two ways in the two PANA I-Ds I am working on.

Is this OK?

Yoshihiro Ohba

---

From: <[email-masked]>
Date: Fri, 5 Oct 2012 09:41:12 +0200

Re-,

Mentioning the two ways is OK.
Still the main point is to assess the benefits of this option/Opcode. If in your draft you can discuss how it can be useful for the authentication case, this would be a good input.

Cheers,
Med 

>De : Yoshihiro Ohba [mailto:[email-masked]] 
>Envoyé : vendredi 5 octobre 2012 08:57
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] Capability discovery
>
>> FYI, this document proposes an option to retrieve the 
>capabilities of the PCP-controlled device:
>> The current version does only describe whether the 
>controlled device is NAT44, NAT46, NAT64, IPv4 FW, IPv6 FW, 
>Port Range Router.
>>
>> This feature is defined as an option but can be elected to 
>be defined as standalone OpCode. The capabilities set format 
>can be modified to support new capabilities: e.g., 
>authentication support, list of supported opcodes, etc.
>>
>> Saying that, IMHO we need further analyze what are the gains 
>and the impacts on the PCP server to support such feature:
>>
>> * Be a trigger to decide whether all available PCP Servers 
>need to be contacted in // or select only one?
>>
>>
>> Cheers,
>> Med
>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 5 Oct 2012 06:56:58 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoshihiro Ohba
> Sent: Thursday, October 04, 2012 8:04 PM
> To: [email-masked]
> Subject: [pcp] Capability discovery
> 
> while PCP server does not, and vise versa.

Yes, that problem needs to be solved.

> The same issue will exist for future PCP extensions.

I disagree that problem exists for PCP extensions.  The client can 
simply try to use the extension, and will either get back an error 
(e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will
not be included in the response (for options outside the mandatory-
to-process range).

> expected to happen prior to any other PCP opcodes.

I have not found that capability discovery is necessary.

-d

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 06 Oct 2012 00:14:16 +0900

(2012/10/05 22:56), Dan Wing wrote:
>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of
>> Yoshihiro Ohba
>> To:[email-masked]

In that case, the problem is specific to side-by-side PANA approach
which does not use PCP opcode/options.  Is this correct?

Yoshihiro Ohba

---

From: Dave Thaler <[email-masked]>
Date: Fri, 5 Oct 2012 17:42:07 +0000

Yoshihiro Ohba writes: 
> >> Sent: Thursday, October 04, 2012 8:04 PM To:[email-masked]
> >> authentication while PCP server does not, and vise versa.

Yes, I believe that's correct.

-Dave

---

From: Alper Yegin <[email-masked]>
Date: Fri, 5 Oct 2012 23:23:00 +0300

> Yes, I believe that's correct.

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

1. PANA tunneling
No problem. 

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

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

2.2. Implicit (non-DHCP-based) PCP server discovery (PCP server is the default gateway).

2.2.a. Client and server supports auth
No problem

2.2.b. Client does not support, server supports&requires auth
Not a problem. Server sends an error in response to unauthenticated request.

2.2.c. Client and server does not support auth
No problem

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

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

So, overall, there does not seem to be an issue. Am I missing something?

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 05 Oct 2012 16:31:23 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> 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.

---

From: Alper Yegin <[email-masked]>
Date: Sat, 6 Oct 2012 09:56:24 +0300

> for capability discovery.

That's so not true. 
DHCP is defined and used for not only delivering "identities" but also a whole bunch of configuration parameters.
Just browse any few DHCP RFCs, you'll see immediately.

> For firewall policy changes this can be a huge deal.

In this case you are already using DHCP for PCP server discovery (because firewall does not have to be on the first hop).
And with the PCP server attribute we provide in DHCP option, issue would be addressed.

(And if we were not using DHCP, then PANA client would timeout and indicate auth failure to the PCP client. Not as fast as figuring out the problem using DHCP, but still an acceptable result when dealing with misconfigured networks such as in this example)

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 Oct 2012 06:47:06 +0900

OK.  Then how about the following approches?

- For PANA encapsulation approach, we use what Dan mentioned, i.e., the client
simply try to use the extension and get an error from the server not supporing
the extension.

- For PANA side-by-side approach:

    The PCP client supporting PCP authentication MAY send an unauthenticated
    ANNOUNCE request prior to initiating PANA in order to know whether a PCP
    server supports PCP authentication.  A PCP server supporting PCP
    authentication SHALL return an unauthenticated ANNOUNCE response with
    (new) "AUTHENTICATION_REQUIRED" result code.  A PCP server not supporting
    PCP authentication SHALL return an unauthenticated ANNOUNCE response
    with "SUCCESS" result code.

Regards,
Yoshihiro Ohba