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

[<[e-mail]>]

Re-,

Please see inline.
Cheers,
Med

>-----Message d'origine-----
>De : Dan Wing [mailto:[e-mail]]
>Envoyé : jeudi 30 mai 2013 16:39
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [e-mail]
>Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>
>
>On May 29, 2013, at 11:36 PM, [e-mail] wrote:
>
>> Hi Dan,
>>
>>
>>
>>> -----Message d'origine-----
>>> De : Dan Wing [mailto:[e-mail]]
>>> Envoyé : mercredi 29 mai 2013 19:39
>>> À : BOUCADAIR Mohamed OLNC/OLN
>>> Cc : [e-mail]
>>> Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>>>
>>>
>>> On May 22, 2013, at 2:26 AM, [e-mail] wrote:
>>>
>>>> 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.
>>>
>>> The text needs to be clearer on the suggested default,
>>
>> [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. 

[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.

>
>-d
>
>
>>
>>
>> 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
>>>>  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 : [e-mail] [mailto:[e-mail]] De la part de
>>>>> [e-mail]
>>>>> Envoyé : mardi 12 mars 2013 11:44
>>>>> À : [e-mail]
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/pcp
>>>> _______________________________________________
>>>> pcp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pcp
>>