Subject: [pcp] PEER creates implicit dynamic mapping - ticket #46

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Apr 2011 12:37:43 -0700

In -07, the PEER OpCode can cause the error NONEXIST_PEER to be returned, if
there is not already an implicit dynamic mapping (e.g., created with a TCP
SYN) in the NAT or firewall.  There is a worry that the application's
response to this error would be poorly handled because the error would
seldom (if ever) occur in a lab environment, but could occur in the field
(packet loss combined with non-blocking TCP client connection could cause
it, for example).  

The proposal is to:

  * modify PEER so that it creates a mapping, which functions exactly like 
    an implicit dynamic mapping.  That is, exactly as if a TCP SYN were 
    seen by the NAT or firewall.
  * eliminate the NONEXIST_PEER error code

http://trac.tools.ietf.org/wg/pcp/trac/ticket/46

Please discuss.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Apr 2011 16:36:03 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 3:34 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] PEER creates implicit dynamic mapping - ticket #46
> 
> I vote to keep the 07 behavior (PEER doesn't create mapping
> and NONEXIST_PEER can be returned), mainly because the propose
> change defines two different ways to do the same thing
> (to create an implicit dynamic mapping) which is both
> for formal and security considerations a bad thing.
> 
> BTW I am not convinced a common programmer knows how to
> open a socket with a priori addresses and ports, so (s)he has
> no use of this proposed capability to PEER then connect(),
> and to get an error when one tries to poll or extend the
> lifetime of a not existing mapping is IMHO far better than
> to hide the problem.

It's not for such a programmer the concern was raised.  Rather,
it's for the case of a program which does a non-blocking TCP
connection and the TCP SYN is dropped, and does a non-blocking
PCP PEER request.  On many a lab configuration, there isn't
packet loss and the programmer may never include support for
NONEXIST_PEER at all, or (if present) that code may never be
exercised.

As for the value / benefit of returning an error when a mapping
doesn't exist -- we should only have that problem if the PCP
message goes to the wrong PCP server, on a network with multiple
PCP servers and/or multiple NATs and/or multiple firewalls.  But
multiple PCP servers are out of scope, except for our support
of discovering one to talk with on each interface (e.g., one
PCP server on IPv4, another PCP server on IPv6) -- there has 
not been any discussion on the mailing list nor in the I-D how 
to handle multiple simultaneously-active PCP servers and 
choosing which to use.

-d