Subject: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options

From: <[email-masked]>
Date: Tue, 12 Mar 2013 11:44:07 +0100

Dear all,
 
http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:

================ 
   Because PCP messages with an unknown OpCode or Option can carry a
   hidden internal address or internal port which will not be
   translated:

   o  a PCP Proxy co-located with a NAT SHOULD reject by an
      UNSUPP_OPCODE error response a received request with an unknown
      OpCode;

   o  a PCP Proxy co-located with a NAT SHOULD reject by an
      UNSUPP_OPTION error response a received request with a mandatory-
      to-process unknown Option;

   o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
      process unknown Options from received requests before forwarding
      them.

   Rejecting unknown Options and OpCodes has the drawback of preventing
   a PCP Client to make use of new capabilities offered by the PCP
   Server but not supported by the PCP Proxy even if no IP address
   and/or port is included in the Option/OpCode.
================

The reasoning above assumes Options which convey an IP address (and/or port numbers) are naturally defined as mandatory-to-process option.

Reinaldo suggests the following modifications to the behavior currently defined in the I-D:

(1) A PCP Proxy inserts a "this message was proxied" when sending back to the client. Therefore if PCP client detects that the mappings are not working as it should, it has a hint as to why.

(2) The client conveys that some options in this message carry IP addresses and need proxy processing (some IP addresses might not need any Proxy processing).It does not need to say which options, a bit is fine. Therefore a Proxy that could not process those options can send back a meaningful error such as "message can not be proxied because contains options with IP address and I do not know how"

Any thoughts?

Thanks.
Cheers,
Med

---

From: Dan Wing <[email-masked]>
Date: Tue, 12 Mar 2013 13:50:49 -0400

> http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:

Somewhat related, what is the desired behavior if a new opcode (not an option, but an opcode) is introduced, which is not understood by the in-home PCP proxy, and is intended to have no function in that device, but is useful for the next-hop PCP server (e.g., in the DS-Lite AFTR).

I am thinking the PCP proxy should just proxy anything and everything.  I am not convinced a "this was proxied" message is really helpful -- what would the PCP client do if that bit was set?

-d

> Thanks.
> Cheers,
> Med
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 13 Mar 2013 03:22:27 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2013 4:14 PM
> To: [email-masked]
> Subject: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
> 
> Dear all,
> 
> The reasoning above assumes Options which convey an IP address (and/or port
> numbers) are naturally defined as mandatory-to-process option.
> 
> (1) A PCP Proxy inserts a "this message was proxied" when sending back to the
> client. Therefore if PCP client detects that the mappings are not working as
> it should, it has a hint as to why.

Yes, that would help for debugging purposes to know that the user's home router is using a PCP proxy implementation that does not understand these new opcode or  option and it's time to upgrade. Rejecting the PCP request with the above error codes but without "this message was proxied" would indicate that the error is from my ISP PCP server that does not understand this new opcode or option and there is no problem with the PCP capable home router.

> 
> (2) The client conveys that some options in this message carry IP addresses
> and need proxy processing (some IP addresses might not need any Proxy
> processing).It does not need to say which options, a bit is fine. 

If PCP client could signal with each option that IP address is conveyed or not (let's say using a flag at a fixed offset in the option), so that PCP proxy can identify that though it's a unknown option to the PCP proxy, but has mandatory-to-process bit set to 1 and since it does not contain IP address - PCP proxy forwards the option to the upstream PCP server. 

--Tiru.

> Therefore a
> Proxy that could not process those options can send back a meaningful error
> such as "message can not be proxied because contains options with IP address
> and I do not know how"

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 08:43:25 +0100

Hi Dan,

Please see inline
Cheers,
Med

>-----Message d'origine-----
>De : Dan Wing [mailto:[email-masked]] 
>Envoyé : mardi 12 mars 2013 18:51
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & 
>Unknown Options
>
>
>> The reasoning above assumes Options which convey an IP 
>address (and/or port numbers) are naturally defined as 
>mandatory-to-process option.
>> 
>> (1) A PCP Proxy inserts a "this message was proxied" when 
>sending back to the client. Therefore if PCP client detects 
>that the mappings are not working as it should, it has a hint 
>as to why.
>> 
>> (2) The client conveys that some options in this message 
>carry IP addresses and need proxy processing (some IP 
>addresses might not need any Proxy processing).It does not 
>need to say which options, a bit is fine. Therefore a Proxy 
>that could not process those options can send back a 
>meaningful error such as "message can not be proxied because 
>contains options with IP address and I do not know how"
>> 
>> Any thoughts?
>
>Somewhat related, what is the desired behavior if a new opcode 
>(not an option, but an opcode) is introduced, which is not 
>understood by the in-home PCP proxy, and is intended to have 
>no function in that device, but is useful for the next-hop PCP 
>server (e.g., in the DS-Lite AFTR).

Med: The current text recommends to not proxy it when co-located with a NAT. The current text says also this may prevent from introducing new opcode. There is a choice to make here. I'm listing below some directions (without quoting my preferred one):
 
1* encourage introducing new opcode but a failure may be encountered
1.1* the client is not notified about the reason of the failure
1.2* the client is notified this is rejected because of the presence of the proxy
1.3* the client can indicate whether it wants its message to be proxied even if not known to the proxy: an example would be to define a new option (e.g., PREFER_PROXY). The behaviour of the client will need to be defined to specify what are the triggers which will let a client insert such option.

2* discard the opcode and send a notification to the client to be aware the reason for the failure.

>
>I am thinking the PCP proxy should just proxy anything and 
>everything.  I am not convinced a "this was proxied" message 
>is really helpful -- what would the PCP client do if that bit was set?

Med: I understand you are voting for (1.1).

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 08:47:35 +0100

Hi Tiru,

Please see inline
Cheers,
Med 

>De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
>Envoyé : mercredi 13 mars 2013 04:22
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Objet : RE: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & 
>Unknown Options
>
>address (and/or port
>> Reinaldo suggests the following modifications to the 
>behavior currently
>> defined in the I-D:
>> 
>sending back to the
>Yes, that would help for debugging purposes to know that the 
>user's home router is using a PCP proxy implementation that 
>does not understand these new opcode or  option and it's time 
>to upgrade. Rejecting the PCP request with the above error 
>codes but without "this message was proxied" would indicate 
>that the error is from my ISP PCP server that does not 
>understand this new opcode or option and there is no problem 
>with the PCP capable home router.
>
>> 
>carry IP addresses
>If PCP client could signal with each option that IP address is 
>conveyed or not (let's say using a flag at a fixed offset in 
>the option), so that PCP proxy can identify that though it's a 
>unknown option to the PCP proxy, but has mandatory-to-process 
>bit set to 1 and since it does not contain IP address - PCP 
>proxy forwards the option to the upstream PCP server. 

Med: The same result can be done by defining a new option (e.g., PREFER_PROXY) to instruct the proxy to relay the message to the next server. No?

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 15 Mar 2013 08:11:14 +0000

>>that the error is from my ISP PCP server that does not

It would not, right? It is not an interception proxy. The message goes
directly to the first PCP Server/Proxy. The client only knows its first
PCP Proxy and nothing else.

Returning an error (without the Proxy bit) seems fine.

>Med: The same result can be done by defining a new option (e.g.,
>PREFER_PROXY) to instruct the proxy to relay the message to the next
>server. No?
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 15 Mar 2013 08:48:00 +0000

> Sent: Friday, March 15, 2013 1:18 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: RE: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
> 
> Hi Tiru,
> 
> Please see inline
> Cheers,
> Med
> 
> Med: The same result can be done by defining a new option (e.g., PREFER_PROXY)
> to instruct the proxy to relay the message to the next server. No ?

A new PCP option (e.g., PROXY_EXCEPTION) can be defined that carries the list of options in the message that PCP proxy can ignore processing. The PCP proxy logic could be - If an option is mandatory-to-process but unknown and is present in the exception list then PCP proxy will not return error and forward the PCP request with these unknown options. But if there is a PCP option which is mandatory-to-process and not in the exception list then PCP Proxy should return the error like you have already mentioned in the draft.

--Tiru.

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 09:51:38 +0100

Re-,

The PROXY_EXCEPTION you are proposing seems to not solve the issue of an unknown opcode. 

If we have to go in that direction, which is not clear yet and this is why I initiated this thread, we need a solution which covers both unknown options and unknown opcodes.

Cheers,
Med

>Envoyé : vendredi 15 mars 2013 09:48
>A new PCP option (e.g., PROXY_EXCEPTION) can be defined that 
>carries the list of options in the message that PCP proxy can 
>ignore processing. The PCP proxy logic could be - If an option 
>is mandatory-to-process but unknown and is present in the 
>exception list then PCP proxy will not return error and 
>forward the PCP request with these unknown options. But if 
>there is a PCP option which is mandatory-to-process and not in 
>the exception list then PCP Proxy should return the error like 
>you have already mentioned in the draft.
>
>--Tiru.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 15 Mar 2013 08:57:02 +0000

> From: Reinaldo Penno (repenno)
> Sent: Friday, March 15, 2013 1:41 PM
> To: [email-masked]; Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
> 
> 
> 

If the error has more information it can help the client figure out if the error is from the PCP capable home router or ISP PCP server and would help in debugging purposes or else someone has to log into the PCP capable home router and ISP PCP server, enable debugs to figure out the PCP server returning the error.

--Tiru.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 15 Mar 2013 09:14:14 +0000

> Sent: Friday, March 15, 2013 2:22 PM
> If we have to go in that direction, which is not clear yet and this is why I
> initiated this thread, we need a solution which covers both unknown options
> and unknown opcodes.

For opcodes we can have a local configuration on the PCP proxy (exception list) that defines which opcodes can be ignored by the PCP proxy and forwarded to upstream PCP server. we can use similar technique for options also but I think options get added frequently than opcodes, so PROXY_EXCEPTION can help for options.

HTTP proxies typically use exception list to ignore processing unknown HTTP methods.

Regards,
Tiru.