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

From: Dan Wing <[email-masked]>
Date: Tue, 23 Jul 2013 18:40:54 -0700

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

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 08:08:45 +0200

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. 

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

Cheers,
Med  

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

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 15:56:16 -0700

> * 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 exter…

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…

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

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 10:05:39 +0200

Hi Dan,

Please see inline.

Cheers,
Med

>De : Dan Wing [mailto:[email-masked]]
>Envoyé : vendredi 26 juillet 2013 00:56
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] draft-ietf-pcp-proxy and draft-cheshire-recursive-pcp
>
>
>> * 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.  

>
>
>> * 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 

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

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

  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.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Jul 2013 10:20:38 +0200

> [Med] The plain mode is what is implemented in most platforms I'm aware of, and it is the mode adopted by the WG.

Why did the WG adopt this method in the first place? Why did those 
platforms do it that way? There must be a reason...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 11:28:32 +0200

Hi Simon,

You can find some justification in the DS-Lite draft (see the appendix).

I recall there were discussions in the list and some interim meeting but I failed where the decision was formally made. BTW, it is hard to find pcp meeting minutes :-(

Cheers,
Med   

>De : [email-masked] [mailto:[email-masked]] De la part de Simon
>Perreault
>Envoyé : vendredi 26 juillet 2013 10:21
>À : [email-masked]
>Objet : [pcp] DS-Lite "plain mode" (Was: Re: draft-ietf-pcp-proxy and
>draft-cheshire-recursive-pcp)
>
>> [Med] The plain mode is what is implemented in most platforms I'm aware
>of, and it is the mode adopted by the WG.
>

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Jul 2013 10:22:36 -0700

> [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 N…

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

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

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

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

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

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