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

From: <[email-masked]>
Date: Wed, 22 May 2013 11:26:37 +0200

Re-,

Many thanks for all of you who provided a feedback for this point. As a conclusion of this discussion, below a proposed change:

OLD:

7. PCP Proxy Co-located with a NAT Function

   When the PCP Proxy is co-located with a NAT function, it MUST update
   the content of received requests with the mapped port number and the
   address belonging to the external interface of the PCP Proxy (i.e.,
   after the NAT operation) and not as initially positioned by the PCP
   Client.  For the reverse path, PCP responses MUST be updated by the
   PCP Proxy to replace the internal port number to what has been
   initially positioned by the PCP Client.  For this purpose the PCP
   Proxy MUST have an access to the local NAT state maintained locally.
   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.

NEW:

7.  PCP Proxy Co-located with a NAT Function

   When the PCP Proxy is co-located with a NAT function, it MUST update
   the content of received requests with the mapped port number and the
   address belonging to the external interface of the PCP Proxy (i.e.,
   after the NAT operation) and not as initially conveyed by the PCP
   Client.  For the reverse path, PCP responses MUST be updated by the
   PCP Proxy to replace the internal port number to what has been
   initially positioned by the PCP Client.  For this purpose the PCP
   Proxy MUST have an access to the local NAT state maintained locally.

   By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
   to-process unknown Options.  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.

   Because PCP messages with an unknown OpCode or mandatory-to-process
   unknown Options can carry a hidden internal address or internal port
   which will not be translated, A PCP Proxy MUST be configurable to
   disable relaying unknown OpCodes and mandatory-to-process unknown
   Options.  If the PCP Proxy is configured to disable relaying unknown
   OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST
   behave as follows:

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

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

If there is no objection, this change will be include in the next version of the spec.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>[email-masked]
>Envoyé : mardi 12 mars 2013 11:44
>À : [email-masked]
>Objet : [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>
>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
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 25 May 2013 01:53:43 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 22, 2013 2:57 PM
> To: [email-masked]
> Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
> 
> Re-,
> 
> Many thanks for all of you who provided a feedback for this point. As a
> conclusion of this discussion, below a proposed change:
> 
> OLD:
> 

Looks good.

--Tiru.

---

From: Dan Wing <[email-masked]>
Date: Wed, 29 May 2013 10:39:14 -0700

On May 22, 2013, at 2:26 AM, [email-masked] wrote:

>   Options.  

The text needs to be clearer on the suggested default, and why the default is suggested.  Otherwise we will have proxies implemented that return an error for unknown opcodes, especially because there are several sentences explaining what MUST be done when returning an error.

I am still uncomfortable with how this will work in practice.  We need to think about a new opcode which has embedded ip address and port (somewhat like MAP or PEER) and how that could be successfully deployed with a PCP proxy compliant with this document.

-d

> If the PCP Proxy is configured to disable relaying unknown

---

From: <[email-masked]>
Date: Thu, 30 May 2013 08:36:32 +0200

Hi Dan,

>De : Dan Wing [mailto:[email-masked]]
>Envoyé : mercredi 29 mai 2013 19:39
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>
>
>The text needs to be clearer on the suggested default,

[Med] The default and justification are stated in the previous paragraph. 

 and why the default
>is suggested.  Otherwise we will have proxies implemented that return an
>error for unknown opcodes, especially because there are several sentences
>explaining what MUST be done when returning an error.
>
>
>I am still uncomfortable with how this will work in practice.  We need to
>think about a new opcode which has embedded ip address and port (somewhat
>like MAP or PEER) and how that could be successfully deployed with a PCP
>proxy compliant with this document.
>
>-d
>
>

---

From: Dan Wing <[email-masked]>
Date: Thu, 30 May 2013 07:38:36 -0700

> [Med] The default and justification are stated in the previous paragraph. 

I have thought about this some more, and I am concerned not with the wording, but that the industry will not be able to update the configuration of the millions of deployed PCP proxies to block a new opcode or a new mandatory-to-process option that really does need processing within the PCP proxy.  Additionally, PCP proxy developers will be worried about new opcodes which necessitate updating state in the PCP proxy, and will be reluctant to follow this part of the (eventual) RFC.

How about a different approach:  a proxy, when forwarding a PCP request, indicates whenever it does not support an opcode or does not support a mandatory-to-process option that it is proxying.  This indication would be using a new option we would define in the pcp-proxy document, lets call it FORWARDED-WITHOUT-COMPREHENSION.  The final PCP server (which is not proxying) already has to understand any new opcode and any new mandatory-to-process option (or it will generate an error).  The PCP server, which is processing the new opcode or the new mandatory-to-process option must know the semantics of that new option (the poor PCP proxy does not), and if the semantics need PCP proxy involvement, it returns a new error we define, lets call that error NEEDS_PROXY_COMPREHENSION.  This technique has the advantage that PCP proxies don't need to be updated to block new opcodes or block new mandatory-to-process options.

-d

---

From: <[email-masked]>
Date: Thu, 30 May 2013 16:57:34 +0200

Re-,

Please see inline.
Cheers,
Med

>Envoyé : jeudi 30 mai 2013 16:39
>I have thought about this some more, and I am concerned not with the
>wording, but that the industry will not be able to update the configuration
>of the millions of deployed PCP proxies to block a new opcode or a new
>mandatory-to-process option that really does need processing within the PCP
>proxy. 

[Med] This is a configuration parameter which is available at the proxy. The user can change the config or it can be positioned using any device management protocol TR-69 by the provider (think about managed CPE case). For the remaining cases, this is more problematic.

 Additionally, PCP proxy developers will be worried about new
>opcodes which necessitate updating state in the PCP proxy, and will be
>reluctant to follow this part of the (eventual) RFC.

>
>
>How about a different approach:  a proxy, when forwarding a PCP request,
>indicates whenever it does not support an opcode or does not support a
>mandatory-to-process option that it is proxying.  This indication would be
>using a new option we would define in the pcp-proxy document, lets call it
>FORWARDED-WITHOUT-COMPREHENSION.  The final PCP server (which is not
>proxying) already has to understand any new opcode and any new mandatory-
>to-process option (or it will generate an error).  The PCP server, which is
>processing the new opcode or the new mandatory-to-process option must know
>the semantics of that new option (the poor PCP proxy does not), and if the
>semantics need PCP proxy involvement, it returns a new error we define,
>lets call that error NEEDS_PROXY_COMPREHENSION.  This technique has the
>advantage that PCP proxies don't need to be updated to block new opcodes or
>block new mandatory-to-process options.

[Med] This would work too, but I'm sure there will be a demand to have a configuration feature which will allow to reveal unsupported opcodes using FORWARDED-WITHOUT-COMPREHENSION. I'm not sure this alternative is better or worse compared to the one depicted in the proposed text.

>>>> If there is no objection, this change will be include in the next
>version
>>> of the spec.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> error such as "message can not be proxied because contains options
>with
>>> IP

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 30 May 2013 17:27:16 +0000

> From: Dan Wing (dwing)
> Sent: Thursday, May 30, 2013 8:09 PM
> To: [email-masked]
> Cc: [email-masked]
> I have thought about this some more, and I am concerned not with the wording,
> but that the industry will not be able to update the configuration of the
> millions of deployed PCP proxies to block a new opcode or a new mandatory-to-
> process option that really does need processing within the PCP proxy.
> Additionally, PCP proxy developers will be worried about new opcodes which
> necessitate updating state in the PCP proxy, and will be reluctant to follow
> this part of the (eventual) RFC.
> 
> 
> FORWARDED-WITHOUT-COMPREHENSION.  

This option FORWARDED-WITHOUT-COMPREHENSION would also have to indicate the new mandatory-to-process options in the PCP request the proxy did not understand. For example to handle the scenario where multiple new mandatory-to-process options are included, only some of them PCP proxy supports
and some of these options may or may not require PCP proxy processing.

> The final PCP server (which is not proxying)

If there are multiple PCP proxies b/w the PCP client and PCP server. If the upstream PCP proxy receives a PCP request with FORWARDED-WITHOUT-COMPREHENSION but understands all the mandatory-to-process options or the new opcode, the behavior of this proxy will also have to be defined.

--Tiru.

> already has to understand any new opcode and any new mandatory-to-process
> option (or it will generate an error).  The PCP server, which is processing
> the new opcode or the new mandatory-to-process option must know the semantics
> of that new option (the poor PCP proxy does not), and if the semantics need
> PCP proxy involvement, it returns a new error we define, lets call that error
> NEEDS_PROXY_COMPREHENSION. This technique has the advantage that PCP proxies
> don't need to be updated to block new opcodes or block new mandatory-to-
> process options.