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

[Dan Wing <[e-mail]>]

On Jul 26, 2013, at 1:05 AM, [e-mail] wrote:

> Hi Dan,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Dan Wing [mailto:[e-mail]]
>> Envoyé : vendredi 26 juillet 2013 00:56
>> À : BOUCADAIR Mohamed OLNC/OLN
>> Cc : [e-mail]
>> Objet : Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp
>> 
>> 
>> On Jul 23, 2013, at 11:08 PM, [e-mail] 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.
> 
> [Med] I'm not saying this is not possible; the point is that it is much more simple to direct explicitly PCP traffic to the proxy rather than inspecting all incoming traffic. Remember there is no NAT in the case we are discussing here.

But there likely is a firewall, which has to process incoming TCP SYNs (in order to adjust its timers).



>  
> 
>> 
>> 
>>> * 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? 
> 
> [Med] The plain mode is what is implemented in most platforms I'm aware of, and it is the mode adopted by the WG.

> 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.
> 
> [Med] FWIW, there is a decent security analysis available at: http://tools.ietf.org/html/draft-ietf-pcp-dslite-00#section-3 

Yes, that reads very nice for DS-Lite.  I read it before my earlier message.

My concern is not DS-Lite, but draft-ietf-pcp-proxy which applies to all proxying scenarios including non-DS-Lite proxying.


> 
>> 
>> 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)?
> 
> [Med] Yes.
> 
>> 
>> 
>> 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).
> 
> [Med] The same issue can be raised without having the THIRD_PARTY because the malicious user can spoof the source IP address.

No, it's not the same issue.

If  a malicious user can spoof a source address that user can attack a multitude of protocols, and create mappings in a firewall or a NAT (by sending a TCP SYN or UDP packet towards the Internet).

If THIRD_PARTY is not blocked, using techniques similar to the techniques described in http://tools.ietf.org/html/draft-ietf-pcp-dslite-00#section-4 -- which requires the CPE to block such PCP messages -- and THIRD_PARTY is supported by the upstream ISP, then THIRD_PARTY introduces new risks because THIRD_PARTY would not require the attacker to spoof their source IP address.

> 
>> 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?
> 
> [Med] The use of THIRD_PARTY assumes the network in which it is used is trusted. This is a generic concern discussed in rfc6887.

I don't understand what is meant by 'network trust' in your sentence.  You mean, that no device will send a bogus PCP message, accidentally (misconfigured) or maliciously?


> 
>  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.
> 
> [Med] Your scenario involves NAT... which is not the case we are discussing here. For this particular case, there is no need to insert a THIRD_PARTY by the PCP Proxy because the internal IP address set by the proxy is also the address used by the proxy to relay the request.

Sorry.  Allow me to restate:

"Imagine a situation, all too common, where there are two 
non-NAT CPE 
devices 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."


Those non-NAT CPE devices could be 100% IPv6-only Homenet devices, doing IPv6 filtering as suggested in Simple Security (RFC6092) and running PCP and PCP proxy as the way to poke pinholes through their firewalls (as suggested in http://tools.ietf.org/html/rfc6092#section-3.4 where it references ALD, UPnP IGD, MIDCOM, and NSIS).

-d



> 
> 
>> 
>> -d
>> 
>> 
>> 
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : [e-mail] [mailto:[e-mail]] De la part de
>> Dan
>>>> Wing
>>>> Envoyé : mercredi 24 juillet 2013 03:41
>>>> À : [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pcp
>