Subject: [pcp] PEER vs. explicit mappings

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Oct 2011 12:29:43 +0200

It seems the PEER opcode was changed to create explicit dynamic
mappings, i.e., no longer implicit dynamic mappings.
If it is the case why this was not announced and/or discussed
in the list before?

Regards

[email-masked]

PS: BTW this major change is *not* listed in the B.1
"Changes from draft-ietf-pcp-base-13 to -14"???

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 12:45:37 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Wednesday, October 12, 2011 3:30 AM
> To: [email-masked]
> Subject: [pcp] PEER vs. explicit mappings
> 

The ability to create a mapping was done in -09,
http://tools.ietf.org/html/draft-ietf-pcp-base-09#section-7.3
" For Restoring Lost Implicit TCP Dynamic Mapping State",
but at that time we neglected to describe PEER as creating
a mapping as being an "explicit" mapping.

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Oct 2011 22:34:34 +0200

=> I strongly disagree and IMHO it is far to be a matter of misunderstanding:
until the version 14 the PEER opcodes were about implicit dynamic mappings
when the MAP opcodes were about explicit dynamic mappings.
As there are some NAT implementations where implicit dynamic mappings
and explicit dynamic mappings are essentially different this is *not* a detail.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 14:03:34 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2011 1:35 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] PEER vs. explicit mappings
> 
> 

Can those NATs, when they get a PEER request for mapping that does
not already exist (that is, an explicit mapping), return an error?

If so, I'll add text to the document explaining such.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 12 Oct 2011 17:46:14 -0400

If the NAT gets a PEER message before any connection it can install a
session/flow. This is a useful property and I would like it to remain as is.
It is implementation dependent is those mappings are kept in a separate
table or whatnot.

Optionally the PCP Server can disallow that, sure.

---

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

=> these NATs always return a CANNOT_PROVIDE_EXTERNAL_PORT error when
the suggested external port is not zero if for instance associated
port pools are different.

Of course my prefered solution is to come back to the previous
behavior, i.e., PEER is about implicit dynamic mappings.

Regards

PS: as in the other case, PCP before, one can use MAP to get the
explicit mapping (s)he wants IMHO this makes PEER useless.

---

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

If the NAT gets a PEER message before any connection it can install
   a session/flow. This is a useful property and I would like it to
   remain as is.  It is implementation dependent is those mappings are
   kept in a separate table or whatnot.
   
=> this is not question: the PEER was about implicit dynamic mappings
and without announce, discussion or even mention in the changes now
it is about explicit dynamic mappings. This is exactly the kind of
things which makes me to believe to work on PCP is just a waste of
my time.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 17:23:57 -0700

> Sent: Wednesday, October 12, 2011 3:52 PM
> To: Reinaldo Penno
> Cc: Dan Wing; [email-masked]

I recall you objected to PEER being allowed to create mappings back 
when -09 was written, and objected to the use-case of PCP being 
allowed to re-create state in a crashed (home) NAT.

In PCP, we have long used the word "explicit" to mean "create a 
mapping", and as of -09, PEER can do that just like MAP can do 
that.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 17:28:16 -0700

> Sent: Wednesday, October 12, 2011 3:47 PM
> To: Dan Wing
> Cc: [email-masked]
>    > and explicit dynamic mappings are essentially different this is
> *not* a
>    > detail.
> 

PEER is still about implicit dynamic mappings.  Hopefully my upcoming
changes in -15 will soften this.

> explicit mapping (s)he wants IMHO this makes PEER useless.

They are certainly similar.  But they're not the same.

PEER's creation of an explicit mapping is supposed to work
exactly as if a TCP SYN were sent by the client.  Which on many 
NATs creates a different mapping and different filtering than 
if MAP or UPnP IGD or NAT-PMP or a web page is used to 
configure port forwarding.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Oct 2011 11:34:21 +0200

=> so we'll get what was in the draft 13 in sections 9.3 and 9.4 with
some "implicit dynamic mappings" in the text, shan't we?

   
   PEER's creation of an explicit mapping is supposed to work
   exactly as if a TCP SYN were sent by the client.

=> I can't parse this statement as a TCP SYN creates an
implicit dynamic mapping which is not the same than an explicit
dynamic mapping (here I use the PCP terminology, not the common
meaning of the word "explicit").

   Which (TCP SYN) on many NATs creates a different mapping and
   different filtering than if MAP or UPnP IGD or NAT-PMP or a web
   page is used to configure port forwarding.
   
=> so you agree on many NATs the implicit dynamic mapping from
a TCP SYN is different than an explicit dynamic mapping or
a static mapping? So I don't understand why PEER is no longer
specified to act on implicit dynamic mappings??

Regards   

PS: I strongly suggest to replace the word explicit by a
synonym in the PEER text so the fact the PEER action is
by definition explicit can no longer lead to confusion
with the PCP terminology.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 11:22:10 -0700

> Sent: Thursday, October 13, 2011 2:34 AM
> To: Dan Wing
> Cc: [email-masked]

Here is my current work-in-progress text regarding this point in -15,

   10.2.  Generating a PEER Request

   This section describes the operation of a client when generating a
   message with the PEER Opcode.

   The PEER Opcode MAY be sent before or after establishing bi-
   directional communication with the remote peer.

      If sent before, this is considered an "explicit dynamic mapping",
      and the PEER Opcode will create a new explicit mapping in the PCP-
      controlled device, which will be used for translating traffic to
      and from the remote peer; this mapping functions the same as if an
      implicit dynamic mapping were created (e.g., because of a TCP SYN
      from the client).  This is useful for restoring a mapping after a
      NAT has lost its implicit mapping state (e.g., due to a crash).
      Note that some PCP servers and some PCP-controlled devices are
      expected to not support this functionality and will respond with a
      PCP error.

      If sent after, this is considered an "implicit dynamic mapping".
      This allows the client to learn the IP address, port, and lifetime
      of the assigned External Address and Port for the implicit
      mapping, and to extend this lifetime (for the purpose described in
      Section 8.3).

Does this text help, or hurt?  

-d

---

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

=> why the quotes? implicit dynamic mapping and explicit dynamic
mapping are defined in the terminology.

         from the client).

=> so why not create an implicit dynamic mapping?

         This is useful for restoring a mapping after a
         NAT has lost its implicit mapping state (e.g., due to a crash).

=> it is easier to restore the mapping with a mapping of the same
kind (I don't say it will always work but it reduces the number of
cases where it is sure to never work).

=> I agree with this statement: NATs with strong port randomization
could return a CANNOT_PROVIDE_EXTERNAL_PORT error.

=> I have a real concern about a behavior depending on the NAT state
which is by definition unknown by the client, in particular after
NAt reboot. And I can't see any reason for such a complexity.

   
=> it is better but what I really want is the PEER command to act
in all cases on implicit dynamic mappings.
I have a proposal: just say for the first part the PCP server SHOULD
create an implicit dynamic mapping and if this operation is not supported
by the NAT it MAY create a mapping which cannot be distinguished from
an implicit dynamic mapping by the PCP client (for instance its lifetime
cannot be reduced, it is not deleted by MAP with lifetime=0, etc).

BTW this means we can get real implicit dynamic mappings and
similar to implicit dynamic mappings, or with other words the
definition of implicit dynamic mappings in PEER is behavioral.

Now you can explain what is the problem with 100% pure/real implicit
dynamic mappings because I can't see one.
   
Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 13 Oct 2011 17:25:22 -0400

I propose to drop 'implicit' vs. 'explicit' and just call 'PEER mappings'.

Whether a session was created by the PEER message or taken over by a PEER
message, the end result is the same. You have a peer map with the same
characteristic irrespective of how it got to be a peer map.

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 16:21:13 -0700

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, October 13, 2011 2:25 PM
> To: Francis Dupont; Dan Wing
> Cc: [email-masked]

Works for me.   I'll start making those changes.

-d

---

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

=> but we want something which is not static or explicit dynamic too,
according to the terminology it should be implicit dynamic, and if
we define a forth kind of mappings how to explain they should behave
as implicit dynamic? It is not like NATs are not able to create
implicit dynamic mappings...

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 14 Oct 2011 05:29:26 -0400

I could not follow what is the issue you are worried about. I propose these
mappings as far as PCP is concerned.

- MAP
- PEER

I think your 'implicit mappings' are called 'sessions' and are already
defined elsewhere. 

Thanks,

Reinaldo

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 17:49:42 +0200

- MAP
   - PEER
   
=> I want to use the PCP terminology, section 3 of base 14, which classifies
mappings into 3 types: static, explicit dynamic and implicit dynamic.

=> I don't want to use another terminology without agreed definitions.
According to the terminology and base drafts until the version 14,
MAP clearly acts on explicit dynamic mappings and PEER on implicit
dynamic mappings.
So why to change this?

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 14 Oct 2011 12:09:55 -0400

> MAP clearly acts on explicit dynamic mappings and PEER on implicit

This a construct we defined. I see no problem in collapsing and simplifying
the concepts. 'Sessions' are defined and used in NAT64 and other RFCs.

---

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

=> if the idea is to say 'sessions' is a shorter name for implicit dynamic
mappings and PEER acts on sessions I have no objection.

Regards

PS: as far as I can understand here and now the verb "act" means:
 - recreate with suggested external address and port,
  can fail the same way than for PREFER_FAILURE

 - create without suggested external port (or address)

 - eventually extend the lifetime if the implicit dynamic mapping
  (oops, the session) already exists (if it doesn't exist then
  we are in one of the two previous cases, this means in particular
  a PEER request without suggested address and port always succeed,
  which raises the two questions if the request matches an explicit
  dynamic mapping (return its remaining lifetime? it should not happen
  so is it useful to find a way to warn the client?) or a static
  mapping (obviously return UINT32_MAX lifetime))

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 14 Oct 2011 14:16:56 -0400

>   can fail the same way than for PREFER_FAILURE

Agreed but one nit. I'm not sure there is a 'recreate' per se in the PCP
Server but I understand it is useful for explaining the procedure.

As far as the PCP Server goes there are:

- New mappings
- Extension of lifetime

A 'recreate' is just a new mapping that might (or not) ask for a specific
external IP:port, with/out PREFER_FAILURE.

>  - create without suggested external port (or address)

Yep.

>   mapping (obviously return UINT32_MAX lifetime))

Yes.