Subject: [pcp] THIRD-PARTY Option Issues

From: Margaret Wasserman <[email-masked]>
Date: Fri, 1 Apr 2011 09:44:02 +0200

The THIRD-PARTY option indicates that it will be discarded if it  
contains the same address as the address in the packet.  What are the  
implications of this choice for nodes that are behind more than one  
NAT?  Could you be in a situation where the node _sent_ a valid THIRD- 
PARTY request, but that the IP addresses in the header were translated  
en route, such that the addresses are the same?

In general, it is better _not_ to make behavior of an application  
depend on the addresses in the IP packet, for these reasons, unless  
those addresses are securely bound to the application protocol in some  
way.

Margaret

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 02 Apr 2011 00:31:25 -0700

On 1 Apr 2011, at 0:44, Margaret Wasserman wrote:

> The THIRD-PARTY option indicates that it will be discarded if it contains the same address as the address in the packet.  What are the implications of this choice for nodes that are behind more than one NAT?  Could you be in a situation where the node _sent_ a valid THIRD-PARTY request, but that the IP addresses in the header were translated en route, such that the addresses are the same?
> 
> In general, it is better _not_ to make behavior of an application depend on the addresses in the IP packet, for these reasons, unless those addresses are securely bound to the application protocol in some way.

While this is generally good advice for most protocols, I think in this case we can say simply that PCP is a protocol that simply doesn't work though (uncooperative) NATs. If there's an uncooperative NAT between you and the PCP-enabled NAT you're talking to, then there's nothing we can do about that, but we can detect it and report the error so the user knows what to do about it (replace your uncooperative NAT with a PCP-enabled NAT).

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Apr 2011 17:10:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Margaret Wasserman
> Sent: Friday, April 01, 2011 12:44 AM
> To: [email-masked]
> Subject: [pcp] THIRD-PARTY Option Issues
> 
> 
> contains the same address as the address in the packet. 

Section 10 in pcp-base-07 says:

   A THIRD_PARTY Option MUST NOT contain the same address as the source
   address of the packet.  A PCP server receiving a THIRD_PARTY Option
   specifying the same address as the source address of the packet MUST
   return a MALFORMED_REQUEST result code.  This is because many PCP
   servers may not implement the THIRD_PARTY Option at all, and a client
   using the THIRD_PARTY Option to specify the same address as the
   source address of the packet will cause mapping requests to fail
   where they would otherwise have succeeded.

> What are the
> NAT? 

The purpose of THIRD_PARTY is to convey a different address for
the mapping.  But there is never a different address for the mapping
when a nested NAPT is involved, such as what you're describing:

  [PCP client]---[NAPT1]--[NAPT2]-----[CGN]

In the above diagram, the PCP client would need to somehow obtain
a mapping from NAPT1 (using perhaps UPnP IGD), and somehow obtain
a mapping from NAPT2 (using perhaps PCP, because UPnP IGD won't
work), and another mapping from the CGN.  From each of those
NAT's perspectives, there is one and only one IP address 'behind'
it.  That is, the CGN only sees one IP address (that of NAPT2),
and NAPT2 only sees one IP address (that of NAPT1).  The PCP
request to NAPT2 and the PCP request to CGN would no need the
THIRD_PARTY option.  And if they included it, any value in the
THIRD_PARTY option that differs from the IP address of the PCP
request would fail the authorization checks described in Section
14.3.

> Could you be in a situation where the node _sent_ a valid THIRD-

Sure.  But when that happens, it is functionally the same as not
sending the THIRD_PARTY option at all.

I think what you're suggesting is that we have no reason for the MUST
NOT in the following paragraph:

   A THIRD_PARTY Option MUST NOT contain the same address as the source
   address of the packet.  A PCP server receiving a THIRD_PARTY Option
   specifying the same address as the source address of the packet MUST
   return a MALFORMED_REQUEST result code.  This is because many PCP
   servers may not implement the THIRD_PARTY Option at all, and a client
   using the THIRD_PARTY Option to specify the same address as the
   source address of the packet will cause mapping requests to fail
   where they would otherwise have succeeded.

> those addresses are securely bound to the application protocol in some

-d