Subject: [pcp] existing mapping and PREFER_FAILURE

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Oct 2011 23:46:26 +0200

In base 14 section 9.3 (Processing a MAP request):

   If a mapping already exists for the requested Internal Address and
   Port, the PCP server MUST refresh the lifetime of that already-
   existing mapping, and return the already-existing External Address
   and Port in its response, regardless of the Suggested External
   Address and Port
                   ^ missing . here

I believe this doesn't apply when the request has a PREFER_FAILURE
option, does it? So I'd like to get it in the text.

And BTW there is nothing when the already existing mapping is
not an explicit dynamic mapping:
 - the behavior when it is an implicit dynamic mapping is NAT dependent,
  i.e., the NAT should promote it to an explicit dynamic mapping or
  raise an error if it can't
 - the behavior when it is a static mapping is specified later but
  as it roughly follows the current text IMHO for this case we can keep it.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 15:26:07 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, October 13, 2011 2:46 PM
> To: [email-masked]
> Subject: [pcp] existing mapping and PREFER_FAILURE
> 
>   i.e., the NAT should promote it to an explicit dynamic mapping

Ok, new text:

        <t>If a mapping already exists for the requested Internal
        Address and Port and the PREFER_FAILURE Option is not present,
        the PCP server MUST refresh the lifetime of that
        already-existing mapping, and return the already-existing
        External Address and Port in its response, regardless of the
        Suggested External Address and Port in the request.  If a
        mapping already exists for the requested Internal Address and Port
        the request contains the PREFER_FAILURE Option, but the
        Suggested External Address and Port do not match the actual
        External Address and Port of the already existing mapping, the
        error CANNOT_PROVIDE_EXTERNAL_PORT is returned.  If an implicit
        mapping already exists for the requested Internal Address
        and Port, the mapping SHOULD be upgraded to an explicit mapping.</t>

I'm tempted to make it 'MUST upgrade', in fact, for reason I describe
below.

> or

If it can't, it's broken.  We don't want to encourage such implementations,
because they push the problem back to the PCP client to resolve -- and 
sometimes the PCP client _cannot_ resolve it (try getting FTP or ssh
to listen on a non-default port makes it hard for all of the local 
devices connecting to deal with the non-default port).

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 10:36:16 +0200

In your previous mail you wrote:

   Ok, new text:

   
=> I am for 'MUST upgrade or return an error'

=> I understand your reasons but here it is the PCP WG so we have to
live with any NAT implementations.

=> if there is an already existing implicit dynamic mapping it is
because a packet from the internal address and port was sent a short time
before. So these NATs push the problem back to which has caused it,
and BTW which has not followed the requirement to enforce the port
to not be used by another application.
   
Now we can perhaps reach an agreement if we define the word upgrade,
in my message I used the term "promote" because it suggests most of the
characterictics are kept, for instance the external address and port.
If we change it by "promote to or replace by" we cover all cases as
the explicit dynamic mapping has only to use the same internal address
and port (and to be the unique mapping to use them).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 08:59:09 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 14, 2011 1:36 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] existing mapping and PREFER_FAILURE
> 
> 
> and Port

But that is exactly what causes a problem.

> live with any NAT implementations.

The NAT has to handle MAP in a way that works well.  

Here is the example problem, which has been discussed on the
mailing list before, and discussed in f2f meetings before -- but
for everyone's benefit:

Let's say an application starts listening on port N (e.g.,
TCP/22, TCP/80, TCP/8080, UDP/5061, etc.).  Then, through
no fault of that application, the OS's stack decides to use
that same port for an outgoing connection to the Internet
(from a completely unrelated application).  The application
listening on port N also has some incoming connections to
that port N, from hosts within the home network (e.g., the
music streaming devices).  Now, I click the "allow 
connections from the Internet" button on my application,
which causes it to make a PCP MAP request.  If that gets
denied, that means my application needs to start listening
on another port ("M"), try again, repeat.  That's a significant
burden for the application, and now it is listening on two
ports (N, where it has already accepted connections from
hosts on the same network, and the eventual M port which
is for connections from the Internet).

> to not be used by another application.

Can this problem be entirely avoided by the application listening
on the port using INADDR_ANY or SO_EXCLUSIVEADDRUSE or something else?  
It has been my understanding that it's impossible for an application 
to prevent the OS from using its listening socket for the OS's outgoing
connections, from an explanation over a year ago from Simon.  

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 18:13:58 +0200

=> this is why I propose "promote to or replace by" which
puts the eventual damage on the already existing implicit
dynamic mapping which should have never existed.

   
=> but PCP explicitely can't change NAT behavior.

   
=> I know this but in fact it is not a good example: if the
application can't get the exclusive use of the port in the OS
it will be in trouble anyway.

=> it is OS dependent, I can answer (yes) for BSDs, I have never been convinced
by SO_REUSEADDR implementation on Linux, and SO_EXCLUSIVEADDRUSE is
supposed to be the (other) solution on recent versions of Windows...

   > and port (and to be the unique mapping to use them).
   
=> can you answer to this proposal?
   
Regards

---

From: Simon Perreault <[email-masked]>
Date: Fri, 14 Oct 2011 12:55:26 -0400

> supposed to be the (other) solution on recent versions of Windows...

I heard my name! ;)

The point is that we cannot require PCP clients to go through the very
tricky steps that are needed to ensure exclusive use of a port. PCP has
to work without PCP clients having exclusive use of a port.

The current text is OK in this regard.

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: "Dan Wing" <[email-masked]>
Date: Mon, 17 Oct 2011 15:41:59 -0700

> Sent: Friday, October 14, 2011 9:14 AM
> To: Dan Wing
> Cc: [email-masked]

The implicit mapping on the NAT might have been created by
a completely unrelated application running on the same host;
we can't encourage harming it.  It was completely legitimate
when the application created that mapping.

> => but PCP explicitely can't change NAT behavior.

We have been through this since Stuart's presentation at
IETF80, http://www.ietf.org/proceedings/80/slides/pcp-8.pdf,
slides 9-15, when this was called IMPLICIT_MAPPING_EXISTS.

> it will be in trouble anyway.

Then use Simon's example at
http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html

> => can you answer to this proposal?

What are the side effects of the proposal?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Oct 2011 11:29:50 +0200

=> there are two cases:
 - the colliding application got the port by accident: it is not
  legitimate at all as the service is supposed to have exclusive
  use of the port
 - the colliding application is the service itself and the implicit
  mapping was created for instance during a race after NAT reboot.
  In this case not only it is not a problem to delete the implicit
  mapping but it should be deleted.
In conclusion the "replace by" seems better than to raise an error.

   
=> two comments:
 - this presentation didn't propose a solution to collision
  on the internal address and port
 - the charter is still the same: NAT behavior is out of scope
  (and out of the action field of the IETF too :-)

   
=> the colliding implicit dynamic mapping is deleted and no
error is raised for collision reason.
   
Regards