Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp

On Jul 23, 2013, at 11:08 PM, mohamed.boucadair@orange.com wrote:

> Hi Dan, 
> 
> The main reasons why we had that text are as follows:
> 
> * The PCP Proxy won't need to inspect every incoming packet. The current approach makes it easy to redirect PCP responses to the PCP proxy because PCP responses will be explicitly sent to its external IP address. 

I agree it is different to send the packet to the PCP proxy's public address than what I described.  However, ALG code in NATs and firewalls today are pretty capable of seeing the response traffic.  Thus what I am suggesting is not new.

> * In some scenarios, the address family of the internal IP address is not the same as the one available in the external interface of the PCP Proxy. A typical example is DS-Lite. As you know DS-Lite assumes plain IPv6 mode, internal PCP requests are received over IPv4 while external requests are sent over IPv6 without requiring in NAT. In such case, internal request cannot just be relayed to the next PCP server.

Why can't IPv4 PCP requests be sent over IPv4 (over the DS-Lite IPv6 tunnel), just like a IPv4 TCP SYNs?  I recall there was objection to that and a preference for sending the PCP requests over IPv6, but I am now worried the security implications of such a decision have not been fully considered.

What of scenarios where IPv6/IPv4 tunneling is not involved -- why does draft-ietf-pcp-proxy require the proxy insert THIRD_PARTY for those, too?  Just to make the proxy implementation less like an ALG (your first bullet)?

What are the security implications of a deployment where some subscribers have a PCP proxy and it adds THIRD_PARTY (legitimately) versus other subscribers who don't have a PCP proxy and someone on that subscriber's network (e.g., coffee shop, hotel) is abusing THIRD_PARTY (maliciously).  How would the service provider's PCP server differentiate between those two types of subscribers and know to allow one THIRD_PARTY but deny the other THIRD_PARTY?  The problem I see with the PCP proxy inserting THIRD_PARTY is the upstream PCP server is now doing something different than it was without a PCP proxy on the path -- the upstream PCP server has to understand and allow THIRD_PARTY.  Imagine a situation, all too common, where there are two NATs in a home ("look, a fancy blue LED, 802.1ac, and only $40.  My Internet will go really fast") and each is doing PCP proxying -- now the second one has to do PCP proxying, which it will be surprised to see from what it thought was an end host.

-d

> 
> Cheers,
> Med  
> 
>> -----Message d'origine-----
>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dan
>> Wing
>> Envoyé : mercredi 24 juillet 2013 03:41
>> À : pcp@ietf.org
>> Objet : [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp
>> 
>> I am trying to understand the difference between draft-ietf-pcp-proxy and
>> draft-cheshire-recursive-pcp.   One of the significant differences seems to
>> be if the proxy should function differently from an endpoint.  draft-ietf-
>> pcp-proxy has a proxy operating differently from an endpoint with the
>> sentence starting with "Nevertheless"
>> 
>>  6.  No NAT is Co-located with the PCP Proxy
>> 
>>  When no NAT is co-located with the PCP Proxy, the port numbers
>>  included in received PCP messages (from the PCP server or PCP
>>  client(s)) are not altered by the PCP Proxy.  Nevertheless, the PCP
>>  client IP Address MUST be changed to the address of the PCP Proxy and
>>  a THIRD_PARTY Option inserted to carry the IP address of the source
>>  PCP client.
>> 
>> The text is under-specified (as the PCP proxy can have have several
>> addresses, even if it is a firewall), but I don't know why the PCP proxy
>> needs to add the THIRD_PARTY option.  It could just send the packet as-is,
>> with the original source IP address.  The proxy will see the response just
>> as it will see the TCP SYNACK response to a TCP SYN.
>> 
>> WG thoughts?
>> 
>> -d
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp