Subject: [pcp] Resolving contentious issue #1: Epoch

From: Alain Durand <[email-masked]>
Date: Thu, 21 Oct 2010 08:58:57 -0700

The question is Do we need an Epoch in the PCP packet format?

The concept of Epoch is inherited from NAT-PMP, where it helps a local NAT to restore state.

I'd like the proponents and the opponents of Epoch to speak now and make their case.
This window of discussion is open for 2 days. (until 12pm EDT Friday). 

  - Alain.

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 18:38:21 +0200

Dear Alain, all

   The Epoch discussion should be positioned in its overall context:
   the reliability of the mappings information maintained in the
   PCP Server.

   I had an off-line discussion with Reinaldo and we agreed on the
   following requirements:

   Req 1:   Ability to detect if the port control server is alive;

   Req 2:   Ability for a client to (dynamically) select another
      available server in case the primary server fails to respond after
      a given number of solicitations and/or upon timer expiration.
      Additionally, a server that fails to respond to clients'
      solicitations can be backed up by another server.

   Req 3:   Ability for a client to audit its active mappings.  The
      server should also support a means to audit instantiated mappings.
      This mechanism is meant to facilitate the management of the
      mappings: avoid delivery of unwanted traffic, clean stale mapping
      entries, better ports usage, etc.

   We also (almost) agreed on the followings:

   1.  An indication of a PCP Server reboot (Epoch like approach) is not
       sufficient to indicate the states are lost but it can be used as
       a trigger for PCP Client to audit its PCP entries; States can be
       stored in a permanent storage or a full synchronisation;

   2.  In case of cold standby without any PF state synchronisation, the
       backup CGN can answer with an Epoch (!=0) which does not help the
       client to guess that states are lost; the Epoch should be
       redefined so that it can be used as a hint for the PCP Client to
       audit its mappings;

   3.  When CLI clear command is supported, not all the PF entries may
       be lost, some PFs may be alive some not.  In order to be
       exploited by the PCP Client to audit its mappings, the Epoch
       should be set to 0;

   4.  When an anycast address is used, Epoch does not help to indicate
       to the PCP Client it should audit its mappings; we need further
       triggers to cover this case.

   My own conclusions are:

   o  Epoch can be used as a simple system-wise hint to indicate to the
      PCP it needs to audit its mappings;

   o  Epoch should be re-defined to cover the case of cold standby and
      CLI clear commands;

   o  Epoch is not sufficient since it does not cover the anycast
      scenario;

   IMHO, we should propose a framework to meet the requirements above;
   Epoch being one of tools we have on the table.

   Of course, still the question about the encoding:

   o  Define the Epoch as an IE or as a fixed field.

   Cheers,

   Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : jeudi 21 octobre 2010 17:59
À : [email-masked]
Objet : [pcp] Resolving contentious issue #1: Epoch

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Oct 2010 21:53:17 +0200

First I'd like to justify a term I'll use. From base-00:

                                  +-----------------+
                               +--+ NAT or firewall +---<Internet>
                              /   +-----------------+
     +------------+          /          ^
     | PCP Client +-<network>           | Interaction (e.g., using XML)
     +------------+          \          v
                              \   +------------+
                               +--+ PCP Server |
                                  +------------+

                  Figure 2: NAT with Separate PCP Server

In the NAT part on the right I name the top the forwarding plane
and the bottom (i.e., the PCP server) the control plane.

The question about the Epoch is in fact a question about where to put
the state. From a security point of view it is critical to make
impossible for a bad guy to overwrite a port forwarding entry (PF)
which was not removed and has not yet expired, i.e., which is owned
by someone else.

The only way to enforce this is to require the control plane
(i.e., the PCP server) to put its state in a stable storage.
As the PCP server is not allowed to lose its state the Epoch
mechanism doesn't make sense.

So IMHO the Epoch mechanism should be removed from the protocol.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Oct 2010 22:19:10 +0200

In your previous mail you wrote:

   
=> do you want to know if the PCP server is alive, if the NAT/firewall
(with your PFs installed) is alive or both? Note for the first the
inconvenience is to be no longer able to manage the PFs, for the
second it is a partial (PFs not installed) or complete (NAT/firewall
crashed) lost of service.

=> again this is about the PCP service or the NAT/firewall one?
BTW for the PCP service I don't understand how it can be made
independent, i.e., how to switch the PCP server only.

=> can you give a definition of audit? And whether/how is it related
to the PCP protocol.

=> either the PCP server is not allowed to lose its state or
this state lost raises a critical security issue (an attacker
can steal PFs).

=> which state (or where)?

      2.  In case of cold standby without any PF state synchronisation, the
          backup CGN can answer with an Epoch (!=0) which does not help the
          client to guess that states are lost;

=> i.e., the Epoch must be related to a particular CGN.

      3.  When CLI clear command is supported,

=> the clear command de-installs PFs but doesn't delete them, does it?

      4.  When an anycast address is used

=> is it the same case than 2?
   
      My own conclusions are:

=> there is a missing word, IMHO client, after 'PCP'.

=> but if we define a are-you-there?/I-am-here request/response then:
 - it is not useful to put an Epoch in all requests/responses
 - something like the number of PFs for the client is far more useful
  (it gives a clear indication of a bad synchronization, here likely
   from a state lost on the client side)

   
=> not a fixed field as it is not required.

Regards

PS: I am strongly oppose to a 'get-my-PF-list' request in PCP because
it is a lightweight protocol over UDP (i.e., don't copy the DHCP
leasequery).

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 07:52:24 +0200

Dear Françis,

Apologies if my wording was not so that "clear". 

By "audit mappings" I meant a PCP Client checks whether its PCP-instructed mappings are still alive in the PCP Server and that all the information characterising a PCP mapping entry is up to date. This can be seen as synchronizing the PCP mappings maintained in both the Client and Server sides. 

The PCP Server can also implement means to audit the mappings it maintains to identify for instance stale mappings and then remove them.

Please see inline. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 21 octobre 2010 22:19
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Alain Durand; [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch 

   

Med: In this context, I'm only concerned with the aliveness of the PCP Server.

   

Med: Please see above.

Med: Yes. But in my mind this still in the scope of "auditing the mappings".

Med: PCP-instructed ones.

Med: For the Epoch to be useful in the case of cold standby, the Epoch should be set to 0 by the backup CGN when it takes over.

Med: CLI Clear command may delete a PCP-instructed mapping.

Med: There is a subtlety there: when the closer CGN is down, (an)other "active" CGN(s) can take over clients impacted by that failure. I.e., this latter will handle its own 'nominal" customers and some that were serviced by the failed CGN. This operation is transparent for the PCP Client since the same IP address is used to reach both CGN; and in the Server Side, the Epoch is not set to 0.
   
      My own conclusions are:

Med: Yes.

Med: The second point is something we can consider IMHO.

   

Regards

Med: At this stage, PCP List method can be considered as a candidate to synchronise states. If there are drawback we need to identify them also.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Oct 2010 13:28:34 +0200

By "audit mappings" I meant a PCP Client checks whether its
   PCP-instructed mappings are still alive in the PCP Server

=> this is still ambiguous:
 - the PCP server still knows PFs
 - PFs are installed and applied by the NAT/firewall
It seems you are about the first but the second is more interesting
(and not directly related to PCP as a protocol).

   and that all the information characterising a PCP mapping entry is
   up to date. This can be seen as synchronizing the PCP mappings
   maintained in both the Client and Server sides.
   
=> there is still a synchronizing issue as the client can lose
its state but to solve this needs more than an "audit".

   The PCP Server can also implement means to audit the mappings it
   maintains to identify for instance stale mappings and then remove
   them.
   
=> the PCP server has no way to identify state mappings: it can only
to expire them when their lifetimes reach their end.

   Please see inline.

   
=> this raises a security issue as these deleted PFs are freed so
may be overwritten by a bad guy.

   
   
=> yes, the number of PFs is the most useful info in a few bytes (:-).

   Med: At this stage, PCP List method can be considered as a
   candidate to synchronize states. If there are drawback we need to
   identify them also.
   
=> some drawbacks are very clear: a list response doesn't fit in
a lightweight protocol using small datagrams. For an audit get
number and get entry are enough and IMHO doesn't leak potentially
dangerous infos, but they don't provide enough for a entry-by-entry
list which requires a get nth (as UPnP-IGD) or a get next (as SNMP,
IMHO get next is better but needs to standardize an order). Of
course any list operation can leak more info than we want (IMHO
this is a minor security concern but it can't be ignored).

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 09:23:37 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, October 21, 2010 12:53 PM
> To: Alain Durand
> Cc: [email-masked]
> Subject: Re: [pcp] Resolving contentious issue #1: Epoch
> 

Let's consider PCP being used with an consumer-grade NAT.  
Consumer-grade NATs have cheap non-volatile (NV) storage which can
only suffer through a few thousand writes.  To avoid destroying
that storage, they reduce writing to their NV storage very often.

It is desirable to use the same protocol for both consumer-grade
NATs and large-scale NATs.  In fact, this seems *highly* desirable
to me, for the same reasons we use TCP for local network access
(e.g., within a home network) and also over the Internet, and the
same with application protocols such as HTTP.

Consumer-grade NATs cannot store state permanently.  Thus, they
need Epoch (or something like Epoch; but nothing else has been
proposed).

Large-scale NATs are quite capable of incrementing an Epoch 
field; incrementing this value is trivial.

Thus for protocol consistency between NATs-which-retain-state
and NATs-which-lose-state, Epoch is necessary.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 09:30:05 -0700

> this state lost raises a critical security issue (an attacker

I meant to describe this situation in my previous message, but I'll do
it here.  Sorry.

There is another case, where a subscriber (e.g., using a web portal) or 
the network operations staff wants to clear port-forwarding entries for 
a specific user for whatever reason.  When this occurs, the PCP
server did not "lose state" and the NAT did not "lose state".  The
ports which were previously configured with PCP could be added to
a dead pool of ports (for the duration of their normal Lifetime,
as indicated in the earlier PCP messages), thus no attacker behind
the PCP server could steal them.

The PCP server can use a new (zero'd) Epoch *to that specific 
subscriber* to indicate the port mappings are all lost.  The
PCP client running on the subscriber's system(s) will notice
the lowered Epoch and attempt to do whatever it does (e.g.,
request the ports again [which would be given] and, if necessary,
re-register with dynamic DNS or the rendezvous service for the
protocol they're running).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 09:30:52 -0700

> [email-masked]
> Sent: Thursday, October 21, 2010 10:52 PM
> To: [email-masked]
> Cc: [email-masked]
> By "audit mappings" I meant a PCP Client checks whether its PCP-
> instructed mappings are still alive in the PCP Server and that all the
> information characterising a PCP mapping entry is up to date. This can
> be seen as synchronizing the PCP mappings maintained in both the Client
> and Server sides.

The PCP client can do that by refreshing its mappings.

-d

> maintains to identify for instance stale mappings and then remove them.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> 
> Med: For the Epoch to be useful in the case of cold standby, the Epoch
> should be set to 0 by the backup CGN when it takes over.
> 
> Med: There is a subtlety there: when the closer CGN is down, (an)other
> "active" CGN(s) can take over clients impacted by that failure. I.e.,
> this latter will handle its own 'nominal" customers and some that were
> serviced by the failed CGN. This operation is transparent for the PCP
> Client since the same IP address is used to reach both CGN; and in the
> Server Side, the Epoch is not set to 0.
> 
>       My own conclusions are:
> 
> Med: At this stage, PCP List method can be considered as a candidate to
> synchronise states. If there are drawback we need to identify them
> also.
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 09:33:56 -0700

> Sent: Friday, October 22, 2010 4:29 AM
> To: [email-masked]
> Cc: [email-masked]

Don't assume the ports are immediately released into the free pool.

The deleted ports can be added to the hold queue.  NATs have to 
implement a TIME_WAIT-like hold queue anyway (to prevent latent 
data from arriving for newly-created dynamic connections).  This would 
be the same queue, just a longer timeout than for a dynamicly-created 
(e.g., TCP SYN) connection.

>       from a state lost on the client side)

A "count of mapped ports" is only useful if there is *one* PCP client
instance in each subscriber's home.  Once there are two PCP clients
in the home (e.g., two computers with their own PCP client), it breaks
down.

-d

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 20:01:37 +0200

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 18:31
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

Med: The question is how to trigger this refresh ;-) Take the example of the use of an anycast address, how the PCP Client will detect it has to refresh its mappings? 

-d

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 20:05:10 +0200

Re,

For the count of the mappings, it is only a matter of definition. The PCP Server can return the count of mappings having the same internal IP address. 

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 18:34
À : 'Francis Dupont'; BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 11:16:33 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, October 22, 2010 11:02 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: RE: [pcp] Resolving contentious issue #1: Epoch
> 
> 
> Hi Dan,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> Med: The question is how to trigger this refresh ;-) Take the example
> of the use of an anycast address, how the PCP Client will detect it has
> to refresh its mappings?

That's a problem of "receiving asynchronous notification that mappings 
need to be refreshed".  NAT-PMP accomplished this with a multicast
message (from the NAT to all of the hosts on the LAN).  

I expect that, with a large-scale NAT that shouldn't lose its mind
as often as a consumer-grade NAT (kicking the power brick, crashing,
etc.), such asynchronous notification would not be used as often 
with a large-scale NAT.  

We can figure out how to solve the asynchronous notification problem
separately and in a scalable way (e.g., taking a page from how NTP is
often configured to avoid NTP across the access link from every
NTP-capable host on the LAN, we could maybe do multicast notification 
on the LAN (like NAT-PMP does today) combined with a UDP- or TCP-based
unicast notification with the PCP server).

-d

> > Med: In this context, I'm only concerned with the aliveness of the
> PCP
> > Server.
> >
> >       1.  An indication of a PCP Server reboot (Epoch like approach)
> is
> > not
> >           sufficient to indicate the states are lost but it can be
> used
> > as
> >
> >           a trigger for PCP Client to audit its PCP entries; States
> can
> > be
> >       2.  In case of cold standby without any PF state
> synchronisation,
> > the
> >           backup CGN can answer with an Epoch (!=0) which does not
> help
> > the
> >       o  Epoch can be used as a simple system-wise hint to indicate
> to
> > the
> > If you are not the intended addressee of this message, please cancel
> it
> > immediately and inform the sender.

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 20:17:58 +0200

Wanted just to precise my previous response:  

 The PCP Server can return the count of mappings having the same internal IP address and with the same subscriber identifier (e.g., IPv6 address, IPv6 prefix, etc.). 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 22 octobre 2010 20:05
À : Dan Wing; 'Francis Dupont'
Cc : [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch

Re,

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 18:34
À : 'Francis Dupont'; BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 11:22:04 -0700

> Sent: Friday, October 22, 2010 11:18 AM
> To: BOUCADAIR Mohamed NCPI/NAD/TIP; Dan Wing; 'Francis Dupont'
> Cc: [email-masked]
>  The PCP Server can return the count of mappings having the same
> internal IP address and with the same subscriber identifier (e.g., IPv6
> address, IPv6 prefix, etc.).

Doesn't work if PCP is implemented on the individual hosts and using
DS-Lite.  The subscriber-identifier would be the IPv6 prefix (of the 
B4).

And this also breaks if two applications are running on a host and 
implementing their own PCP client.  We could argue those applications
shouldn't do that, and should wait until the host OS (or a common 
framework) supports PCP.  But I don't see a reason to hobble the
protocol to require the OS (or a framework) for PCP to work 
correctly.

-d

> For the count of the mappings, it is only a matter of definition. The
> PCP Server can return the count of mappings having the same internal IP
> address.
> 
> Cheers,
> Med
> 
>

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 20:27:40 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 20:22
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Francis Dupont'
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

Med: don't get this. Sorry.

Med: What is meant with the count is to provide a hint for the PCP Client to audit it mappings (refresh); like the Epoch case, this does not mean that it is deterministic. If I follow you, Epoch should not be considered since there are cases it does not work (e.g., anycast case, cold standby) ;-)

-d

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 20:27:51 +0200

Re-,

I see we agree that Epoch alone is not sufficient to solve the problem we are handling here.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 20:17
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 11:41:18 -0700

> I see we agree that Epoch alone is not sufficient to solve the problem

However, that does not make Epoch useless.

Epoch provides the PCP client with the ability to know, whenever it 
receives a PCP response (that is, whenever it creates a new PCP 
mapping or refreshes an existing PCP mapping), that the Epoch
value has been reset and thus the PCP client's other mappings all
need to be refreshed/recreated.

-d

> > >          available server in case the primary server fails to
> respond
> > > after
> candidate
> > > This message and any attachments (the "message") are confidential
> and
> > > intended solely for the addressees.
> > > France Telecom Group shall not be liable for the message if
> altered,
> > > changed or falsified.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 11:43:08 -0700

> Sent: Friday, October 22, 2010 11:28 AM
> To: Dan Wing; 'Francis Dupont'
> Cc: [email-masked]
> Med: What is meant with the count is to provide a hint for the PCP
> Client to audit it mappings (refresh); like the Epoch case, this does
> not mean that it is deterministic. If I follow you, Epoch should not be
> considered since there are cases it does not work (e.g., anycast case,
> cold standby) ;-)

If there are two applications running, and one creates two PCP mappings
and the other application creates one PCP mapping -- they will both
be stuck in a continual loop validating their mappings because the
PCP server's mapping count is inaccurate (from the perspective of both
of those applications).

-d

> > >    => the clear command de-installs PFs but doesn't delete them,
> does
> > > it?
> > >
> > >          IMHO, we should propose a framework to meet the
> requirements
> > > above;
> > > => yes, the number of PFs is the most useful info in a few bytes
> (:-
> > ).
> > >

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 20:54:36 +0200

Re,

Please see inline.

Cheers
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 20:43
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Francis Dupont'
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

Med: You suppose that two instances of the PCP Client are active instead of using an API and only one PCP instance is active on a given host. Even in the case you described, the (loop) behaviour can be avoided if the condition to launch the refresh is to receive a count which is less than what is know to a given application. Why this shouldn't work?

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 01:09:29 +0200

=> I am not comfortable at all with this kind of arguments: this
kind of NAT has very different (than CGN) constraints and
there are already two different protocols (NAT-PMP and UPnP-IGD)
which manage PFs on them.
I am afraid we'll finish with a protocol which can be deployed in
a very insecure way just because it tries to cover too different
cases.
And BTW the hold down feature (11.2 of base-00) is incompatible
with a stateless NAT/Firewall.

   It is desirable to use the same protocol for both consumer-grade
   NATs and large-scale NATs.

=> desirable perhaps, reasonable? I need to be convinced.

=> you mean consumer-grade NATs on the local LAN: the Epoch
mechanism relies on the use of multicast to proactively signal
the lost of state.

=> as PCP is an extension of NAT-PMP you can force a fallback
from PCP to NAT-PMP where NAT-PMP should be used by simply
refusing a version > 0. This needs to change in current consumer-grade
NAT software...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 01:22:25 +0200

=> this is a delete all PF operation already supported (so described)
by PCP proposals.

   the network operations staff wants to clear port-forwarding entries for 
   a specific user for whatever reason.

=> I have a concern with this 'clean PF' operation because it is clear
Mohamed and you talk about a similar thing but with a critical
difference: delete vs de-install.

   When this occurs, the PCP
   
=> this is what I called a 'de-install' operation. It is safe,
a denial of service for the customer and of course it still needs
stable storage for the PCP server.

   The PCP server can use a new (zero'd) Epoch *to that specific 
   subscriber* to indicate the port mappings are all lost.

=> this is a reactive indication, i.e., a client will get the
knowledge about this only when it will send a request.
If you use a are-you-there/I-am-here request/response to poll
within a shorter interval the PCP server then there are better
solution than the Epoch.

=> first this doesn't match what I can see to be used today (perhaps
the real world is wrong but I am too old to want to change it :-),
second if PCP depends on such dynamic service discovery then IMHO
this should be explicitely in the charter.
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 01:27:48 +0200

=> no, refreshing/renewing only ensures all the PF known by the client
are known too by the server, not the opposite, i.e., the server can
have a PF which is not known (was lost) by the client.
To summary refreshing/renewing doesn't work for stale PF so is not
a proper solution to the synchronizing problem.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 01:35:37 +0200

=> this can be supported (as explained by Mohamed) exactly the same
way the delete all PF for a B4 / all PF for a client behind a B4
operations.
(this argument applies to the given example).
   
Regards

PS: this means the search key to describe PFs to delete or to
count PFs are the same. As far as I can see, the only difference
is for a get next operation we need to standardize an order.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 02:24:44 +0200

=> to make the notification and the resulting refresh by all clients
scalable is more than a challenge.
It seems Mohamed proposed to poll the server by clients. IMHO this
raises far less problems (and at least solvable problems).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 02:33:56 +0200

=> I'd like to reduce the count of PF problem to the delete all PF one.

For the DS-Lite case we have both delete all PFs for a B4 and delete
all PFs for a host (internal address set to 0.0.0.0 or the host address
in the delete request), so the reduction gives the solution.

The second case is more interesting but I disagree about the conclusion:
if two applications on the same host can independently manage a PF set
then an application should be allowed to delete its PFs and not all
the host PFs by side effect. I.e., the example shows there is a
possible need to refine again the delete operation, and the count
operation will be supported too.

Regards

PS: IMHO there is no reason to not support the two application case,
so we have to design another IE to handle this.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 02:51:44 +0200

=> I apologize for the bad charset (Mohamed mispelled Francis...)
   
   Med: You suppose that two instances of the PCP Client are active
   instead of using an API and only one PCP instance is active on a
   given host. Even in the case you described, the (loop) behaviour
   can be avoided if the condition to launch the refresh is to
   receive a count which is less than what is know to a given
   application. Why this shouldn't work?
   
=> this is only a proof a PF count is better than an Epoch
(a fact I was already convinced :-) but it doesn't explain how
the solve the synchronizing problem (i.e., client and server
keep the same state, here we can't detect states are different).

Regards

PS: my current conclusions:
 - a PCP server must keep state in stable storage so Epoch is useless
 - asynchronous notification is not scalable so Epoch is useless
 - for a client polling procedure, a PF count is better than Epoch
 - count PFs and delete all PFs are the same problem
 - in the discussion about count PFs we discovered a case where count PFs
  and delete all PFs need to be refined.

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 23 Oct 2010 10:32:30 -0700

> Sent: Friday, October 22, 2010 11:55 AM
> instead of using an API and only one PCP instance is active on a given
> host. Even in the case you described, the (loop) behaviour can be
> avoided if the condition to launch the refresh is to receive a count
> which is less than what is know to a given application. Why this
> shouldn't work?

So you're saying only one of the PCP instances would audit its mappings, 
whereas the other PCP instance would not audit its mappings?

-d

> > > De : [email-masked] [mailto:[email-masked]] De la part
> de
> > > PCP Server can return the count of mappings having the same
> internal
> > IP
> > > address.
> > >
> > > Cheers,
> > > Med
> > >
> > >
> > > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > > Francis Dupont
> > > >    and that all the information characterising a PCP mapping
> entry
> > is
> > > >    => but if we define a are-you-there?/I-am-here
> request/response
> > > > then:

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 23 Oct 2010 11:10:14 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 22, 2010 4:09 PM
> To: Dan Wing
> Cc: 'Alain Durand'; [email-masked]

NAT-PMP is a non-standard protocol.  PCP would be a standard protocol,
hopefully creating an incentive for products to adopt the standard.

> a very insecure way just because it tries to cover too different

Presence or absence of Epoch cannot prevent a PCP server (or NAT)
from losing its state.

> mechanism relies on the use of multicast to proactively signal

Multicast is used in NAT-PMP for asynchronous notification of
a NAT failure.  

Asynchronous notification is a separate feature from NAT-PMP/PCP 
including Epoch in normal (unicast) responses.

> refusing a version > 0. This needs to change in current consumer-grade

We are hopefully going to a world of IPv6, including IPv6
firewalls in consumer-grade equipment, possibly including
consumer-grade NAT64 or NAT46 -- who knows what the future will
bring.  In that future, an IPv4-only protocol such as NAT-PMP
will have less and less value.  Instead, something else needs
to be used on those consumer-grade NATs.  I suggest that should
be PCP.

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 22:54:51 +0200

> which manage PFs on them.
   
   NAT-PMP is a non-standard protocol.

=> it is a de facto standard protocol: it should not be hard to
make it a de jure standard. BTW to add IPv6 support & co should
be more complex from a procedure view.

   PCP would be a standard protocol,
   hopefully creating an incentive for products to adopt the standard.
   
=> what I mean is we have no solution today for creating PFs on CGNs
and if we have the choice between a too complex and potentially
insecure PCP proposal which solves everything and a simple secure
PCP proposal restricted to CGNs I prefer the second. Now we have
no security model for PCP so perhaps (:-) we don't put things in
the right order.

   > a very insecure way just because it tries to cover too different
   
   Presence or absence of Epoch

=> my argument was about the support of both consumer-grade NATs and CGNs.

   cannot prevent a PCP server (or NAT) from losing its state.
   
=> a PCP server or a NAT are not the same for this issue (cf
my control vs forwarding plane intro).

Regards

---

From: <[email-masked]>
Date: Sun, 24 Oct 2010 17:32:06 +0200

Hi Dan,

Please see inline.
Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : samedi 23 octobre 2010 19:33
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Francis Dupont'
Cc : [email-masked]
Objet : RE: [pcp] Resolving contentious issue #1: Epoch

Med: Both clients can audit their mappings if they receive a count from the server less than what is known to a given PCP Client. Of course, this would work if all the states are lost and not only a subset of them. 

BTW, in both cases (Epoch and Count), there is a critical issue raised by the scenario you described: if several instances of PCP Clients are active in the same host, how to ensure that none of them will delete the mappings of other instances? 

If each PCP Client is identified by its unique Client-ID (http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html), this issue can be mitigated.

Furthermore if the Client-ID is used, the count can be used as an efficient trigger for a PCP Client to audit its mappings.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 24 Oct 2010 08:45:01 -0700

> Sent: Friday, October 22, 2010 5:34 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]

For the DS-Lite case, there has also been some expressed desire
for 'delete all mappings to this subscriber' function, which would 
suffer the same problem -- namely, there may be other devices in the 
same home which don't want their mappings deleted.  I don't see a way 
to provide that function and also protect against accidental/malicious
deletion of mappings.

> so we have to design another IE to handle this.

So PCP should only work if there is a common library on the host,
which all applications use?  This is okay -- I mean, DHCP works
that way (DHCP responses come back to a fixed port on the
host), TCP works that way.  But some other protocols don't work
that way (HTTP, FTP).

-d

---

From: <[email-masked]>
Date: Sun, 24 Oct 2010 17:54:04 +0200

Hi Francis, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : samedi 23 octobre 2010 02:52
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch 

Med: Sorry about that. 

Med: The sync procedure will be the same whatever the hint used to launch a mapping audit. As for the sync procedure at least two solutions can be envisaged: (1) retrieve the list of states as maintained by the server, compare them with the ones known to the PCP client and refresh the mappings accordingly. (2) delete all mappings of a given PCP Client in the PCP Server and then re-create new ones in the PCP Server. The second alternative may not be optimal of the PCP Server put the "deleted" ports in a "Wait" pools. 

Regards

Med: if Client-ID is supported, the issue in your last bullet can be mitigated.

---

From: <[email-masked]>
Date: Sun, 24 Oct 2010 18:42:55 +0200

Hi Francis,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : vendredi 22 octobre 2010 13:29
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Alain Durand; [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch 

Med: I'm talking about both.

Med: Yes, you are right. But, to launch the sync procedure you need events triggering it: e.g., reboot of the CPE, change of the IP address, change of the PCP Server, etc. 

Med: this depends on the deployment model. In some scenarios subscriber-id can be used for that purpose; 

   Please see inline.

   

Med: This why I proposed the Client-ID idea. Only the PCP Client which creates a mapping can modify/delete it.

Med: There other use cases where this list mappings operation would be required: a subscriber need to know all the mappings its devices (PCP Client in PC1, PCP Clients in laptops, PCP Client in STB, PCP Client webcam, PCP Client in the CPE, etc.) has created in the PCP Server.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 19:43:24 +0200

Furthermore if the Client-ID is used, the count can be used as an
   efficient trigger for a PCP Client to audit its mappings.
   
=> I agree but it is more an application ID than a client ID
(even the term client is not defined so can cover what you want :-).

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Sun, 24 Oct 2010 13:52:52 -0400

It seems to me if we want multiple PCP Clients in the same host or home we
need some sort of ID in order to enable demux in general.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 22:24:05 +0200

For the DS-Lite case, there has also been some expressed desire
   for 'delete all mappings to this subscriber' function,

=> I am in this some.

   which would suffer the same problem

=> I can't see a problem here.

   -- namely, there may be other devices in the 
   same home which don't want their mappings deleted.

=> a device doesn't want something. The manager of the home/B4 does.

   I don't see a way to provide that function and also protect
   against accidental/malicious deletion of mappings.
   
=> you mean a host trying to delete all B4 PFs? As the request
must be relayed by the B4 I can't see a hard problem here.

   
=> I believe your question is about to require a source port so
it is not possible to have two requestors running on the same host.
I don't think we have to add this constraint. Now we are very far
from a standard PCP client API.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 22:30:13 +0200

Med: The sync procedure will be the same whatever the hint used to
   launch a mapping audit. As for the sync procedure at least two
   solutions can be envisaged: (1) retrieve the list of states as
   maintained by the server, compare them with the ones known to the
   PCP client and refresh the mappings accordingly. (2) delete all
   mappings of a given PCP Client in the PCP Server and then re-create
   new ones in the PCP Server. The second alternative may not be
   optimal of the PCP Server put the "deleted" ports in a "Wait"

=> I use 'hold down' for your 'Wait' state.

   pools.

=> note these don't do the same: the first copied the server state to
the client, the second clears the server state and sends the client
state to the server. Perhaps we need both?
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 22:38:19 +0200

Med: This why I proposed the Client-ID idea. Only the PCP Client
   which creates a mapping can modify/delete it.

=> this is secure only against an out-of-path attacker so IMHO has a
limited usage and doesn't provide an usable solution.

   Med: There other use cases where this list mappings operation would
   be required: a subscriber need to know all the mappings its devices
   (PCP Client in PC1, PCP Clients in laptops, PCP Client in STB, PCP
   Client webcam, PCP Client in the CPE, etc.) has created in the PCP
   Server.
   
=> so you argue we have to add a 'list PF' item in the TBD design list.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 22:41:10 +0200

=> for home we already have the internal address, the problem is for host
and it seems we agree (but not on the name of the ID :-).

Regards

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 07:38:42 +0200

Hi Francis,

Client-ID is an identifier if an instance of "PCP Client". This notion is to be distinguished from "customer identifier" or "subscriber identifier"; see what we elaborated in http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol-02#section-8.3.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : dimanche 24 octobre 2010 19:43
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch 

   

Regards

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 07:46:01 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : dimanche 24 octobre 2010 22:38
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Alain Durand; [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch 

   

Med: It provides also an assurance that no other internal PCP Client(s) can modify or delete its instructed mapping unless.  

Med: Yes. Mainly for service usability purposes.

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 08:04:13 +0200

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : dimanche 24 octobre 2010 22:30
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch 

Med: Yes. BTW, having the Client-ID would allow to mitigate the port optimisation issue in some scenarios (e.g., refreshing the mappings in the PCP Server when the internal IP address changes): only one request including the Client-ID and the new Internal IP address would suffice to update the mappings without changing the external port, etc. In such case, there is no need to put the ports in the "hold down" pool. 

   pools.

Med: They can do the same if the states reference is the PCP Client states.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 25 Oct 2010 09:24:49 +0200

Med: Yes. BTW, having the Client-ID would allow to mitigate the
   port optimisation issue in some scenarios (e.g., refreshing the
   mappings in the PCP Server when the internal IP address changes):
   only one request including the Client-ID and the new Internal IP
   address would suffice to update the mappings without changing the
   external port, etc. In such case, there is no need to put the ports
   in the "hold down" pool.
   
=> convenient but highly insecure...

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2010 09:25:09 -0700

> Sent: Sunday, October 24, 2010 1:24 PM
> To: Dan Wing

So, you are proposing that 'delete all mappings' be a PCP
message that the B4 element blocks/permits based on some
configured policy within the B4 element.

Same could be done by a PCP-aware NAT in the NAT444 scenario,
or a PCP-aware router in the CGN scenario.  Probably possible
in other PCP deployment scenarios, as well.

> it is not possible to have two requestors running on the same host.

I really want to allow two PCP clients (two requestors) running 
on the same host.

> I don't think we have to add this constraint.

Ok.

> Now we are very far from a standard PCP client API.

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 25 Oct 2010 20:34:48 +0200

=> yes, it is the idea. Note it is not very secure or new
(miniupnpd proposes a similar secure option even it doesn't
yet implement it).

=> as soon as there is a control point where messages must go through.

   
=> I agree but this needs work (a requestor ID).

Regards

PS: for at least deletes we go to all B4/CPE PFs, all host PFs and all
requestor PFs, i.e., 3 levels of granularity. (at least because the
same will be needed for list operation for instance).

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2010 17:14:10 -0700

> Sent: Monday, October 25, 2010 11:35 AM
> To: Dan Wing
> Subject: Re: deleting mappings [was RE: [pcp] Resolving contentious
> issue #1: Epoch]
> 
> 

Enforcing this at the customer premise router does seem best.  I'll
think about this some more.

> => I agree but this needs work (a requestor ID).

It seems possible without a requestor ID:

The two PCP clients, implemented inside of separate applications 
running on the same host (e.g., a webcam application and a 
web server application), will send their PCP request messages 
from different ephemeral UDP ports.

-d

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 07:27:21 +0200

Hi Dan,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 02:14
À : [email-masked]
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: deleting mappings [was RE: [pcp] Resolving contentious issue #1: Epoch] 

Med: The cleaner solution IMHO is to have a stable ID (PCP Client-ID will just work fine for this purpose); otherwise if the port to which the service is bound has changed (crash of the application, reboot, etc.), stale mapping entries will be present in the PCP Server (and therefore consuming the subscriber's quota).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 08:43:01 +0200

=> this raises two problems:
 - if there is a relay/proxy the UDP port will be lost
 - there is no way in the current protocol to know if the intended
  action of a delete all PFs is to delete all host PFs or all
  requestor PFs.
To summarize I believe we have to add a requestor ID in the protocol.

Regards

PS: of course if we want an easy unique ID the port + date is a good one
(it is my favorite default if there is no other requirement than to be
unique per host).

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 07:58:20 -0700

> Med: The cleaner solution IMHO is to have a stable ID (PCP Client-ID
> will just work fine for this purpose); otherwise if the port to which
> the service is bound has changed (crash of the application, reboot,
> etc.), stale mapping entries will be present in the PCP Server (and
> therefore consuming the subscriber's quota).

Crash (or disconnection) of the host can happen without PCP, 
causing dynamically-created connections (e.g., TCP SYN) to consume 
the subscriber's quota.

A requestor ID only helps for the quota problem if the requestor 
comes back online and deletes their old mapping.  That won't happen
with a hard crash (e.g., reset to factory defaults) nor if the
requestor has traveled 100km away.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 08:01:58 -0700

> Sent: Monday, October 25, 2010 11:43 PM
> To: Dan Wing

The PCP proxy, if present, would take responsibility for proxying
correctly.  Not a problem.

>   action of a delete all PFs is to delete all host PFs or all

IIRC, there are two different messages for 'delete all my mappings'
for IP address X (port=0, internal-ip-address=X) versus
'delete all mappings for all devices (port=0, 
internal-ip-address=0).

Those will have the same effect in NAT444 (from the PCP server
in the ISP's network's view), and those will have different
effects in DS-Lite (from the PCP server in the ISP's network
view).

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 00:21:15 +0200

=> do you argue the PCP proxy which an application must preserve
the UDP port which BTW is not an element of the protocol?

   
=> in fact we are going to 4 different meanings for all because
we have the all application/requestor PFs too (which is not
the all host PFs or the all subscriber PFs you are refering to)
and the all protocols which an independent degree of freedom
(the 3 others are embedded).

=> I agree but those are not what I am talking about.
   
   > To summarize I believe we have to add a requestor ID in the protocol.

=> I maintain.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 19:44:00 -0700

> Sent: Tuesday, October 26, 2010 3:21 PM
> To: Dan Wing

No, nothing can preserve the ephemeral source port.

>    'delete all mappings for all devices (port=0,

My bad, I misspoke.  There are two deletes in draft-wing-pcp-base-01 
described in Section 8.2:

  1. inside-port=<any port other than "0">, lifetime="0", IP=1.2.3.4
  2. inside-port="0", lifetime="0", IP=1.2.3.4

(1) deletes that particular mapping for internal IP 1.2.3.4
(2) deletes all the mappings for internal IP 1.2.3.4

We could add a third, which is "delete all mappings for all 
hosts owned by this subscriber".

> (the 3 others are embedded).

I don't understand the 'all application/requestor PF'.

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 07:16:11 +0200

Hi Dan,

Aside the quota issue, the client id helps also to prevent a PCP Client to delete the mappings of other PCP Clients. 

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 16:58
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: deleting mappings [was RE: [pcp] Resolving contentious issue #1: Epoch] 

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 08:39:00 +0200

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 04:44
À : [email-masked]
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: deleting mappings [was RE: [pcp] Resolving contentious issue #1: Epoch] 

Med: You have already this in pcp-base 

"To delete all pinholes for all hosts associated with this subscriber,
   an all-zero internal IP address is used." 

IMHO, this needs to be carefully considered: security issues in particular

FWIW, we have listed in http://tools.ietf.org/html/draft-bpw-softwire-pcp-flow-examples-00#section-4 various cases for delete operation. Note, the structure of the messages is not aligned with what is currently described in draft pcp-base.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 09:33:06 +0200

=> I propose to introduce a new term for the case where two applications
on the same host participate to the PCP protocol, the term could be
'requesting application' (not client because in base-01 'client' is
defined to be which talks to the server).
So we get this hierarchy:
 - requesting applications (without a standardized way to recognize them)
 - host (identify by its internal address)
 - subscriber (for DS-Lite/NAT444/etc)

and at the other end the server.
Hosts are in the home network/zone (we should pick one, IMHO the
word 'network' is the best but it could be ambiguous, i.e.,
be interpreted as one LAN), there is a box (home gateway (IMHO
the best), CP, CPE) per subscriber between the home network
and the ISP infrastructure (here I propose 'infrastructure')
which itself connects subscribers to a CGN.

BTW I use PF for dynamic port forwarding entries (i.e., the port
forwarding managed (created/deleted) by PCP) in place of mappings.
This is not perfect (it doesn't match the firewall case) but it
is already better than mappings. If someone can propose a good
name for the objects which are managed (i.e., created and deleted)
by PCP...

   
=> so it can't be used to identify a requesting application.

   
=> I'd like to add another which is "delete all PFs for this
particular requesting application". Without this a requesting
application could delete all PFs for this host by a not wanted
side effect so to have more than one requesting application
per host becomes bad, and we already agree if I remember the
two (or more) requesting application case should be supported.

   
=> this is why I am trying to fix the terms.
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 00:43:50 -0700

> Sent: Wednesday, October 27, 2010 12:33 AM
> To: Dan Wing

(wow, the way your mail user agent quotes email messages is complicated)

> defined to be which talks to the server).

I don't see the problem with 'PCP client'.  "Client" is used for
other protocols such as TCP and for HTTP and a lot of other 
client/server protocols, even when there is one client (e.g., DHCP) 
or multiple clients (e.g., HTTP -- think wget and firefox running
at the same time) on a single host.

> => so it can't be used to identify a requesting application.

The ephemeral source port distinguishes the two PCP clients.  I
agree the ephemeral source port does not """identify""" the
requesting application.  But I don't know what is meant to 
'identify' the requesting application.  

> two (or more) requesting application case should be supported.

This gets complicated.  What if there are multiple instances
of the same application running (on a VM, for example)?  The 
protection intended by such a feature starts to break down.  How
should the application identify itself, using its pid?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 00:47:11 -0700

> Aside the quota issue, the client id helps also to prevent a PCP Client
> to delete the mappings of other PCP Clients.

Is that a problem within a subscriber's network (within a home), that 
devices are deleting PCP mappings for other devices?

If so, that might be a problem useful solving.

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 10:01:33 +0200

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 09:47
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: deleting mappings [was RE: [pcp] Resolving contentious issue #1: Epoch] 

Med: Yes. 

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 01:11:53 -0700

>    an all-zero internal IP address is used."

I couldn't find it when I replied.  Thanks for pointing it out.

> IMHO, this needs to be carefully considered: security issues in

Hosts shouldn't be added to your home network if they're
going to be destructive?  I tell my dinner guests that all the
time!  :-)

> FWIW, we have listed in http://tools.ietf.org/html/draft-bpw-softwire-
> pcp-flow-examples-00#section-4 various cases for delete operation.
> Note, the structure of the messages is not aligned with what is
> currently described in draft pcp-base.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 01:31:57 -0700

> devices are deleting PCP mappings for other devices?

I would say "let's remove the function", but I don't understand
the problem.  If it's malicious users in the home (who invited
them to dinner?), they will just issue PCP Delete messages for
all of the home's IP addresses -- effecting the same thing as
"Delete All Mappings For This Subscriber".  Is it malicious 
users?  What else are those malicious users doing?

NAT-PMP didn't allow creating mappings for other hosts, because
that changes the security model from how dynamic connections
are created.  In PCP, this capability was added for two 
reasons:
  - allow a PCP client to open pinholes on behalf of 
    another host that doesn't run PCP (e.g., webcam).
  - interwork UPnP IGD to PCP.

But neither of those require a 'Delete All Mappings for This 
Subscriber' function.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 09:13:51 +0200

=> yes it is a problem, in particular when it is not the intended action.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 15:59:32 +0200

=> there is no other problem than the base-01 terminology chose one
of the possible meanings of the word (IMHO it is a good thing!).

   > => so it can't be used to identify a requesting application.
   
   The ephemeral source port distinguishes the two PCP clients.

=> yes!

   I agree the ephemeral source port does not """identify""" the
   requesting application.  But I don't know what is meant to 
   'identify' the requesting application.  
   
=> Google returns:
1. Establish or indicate who or what (someone or something) is: "the
judge ordered that the girl not be identified".
2. Recognize or distinguish (esp. something considered worthy of
attention): "ensure that their needs are identified"

In this case this is more the second so the fact the ephemeral source
port can't be used to distinguish between different requesting
applications running on the same host is the critical point
(and I believe we agree about this fact).

   What if there are multiple instances
   of the same application running (on a VM, for example)?

=> this application offers a service so usually this case can't
happen (the unicast service port can't be shared).

   How should the application identify itself, using its pid?

=> its port? Requesting applications share at least a resource,
the host, so the problem to identify applications is already
solved in some way.
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 11:41:57 -0700

> Sent: Thursday, October 28, 2010 12:14 AM
> To: Dan Wing

Can we solve it?  Or should we just remove the functionality from
PCP?

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 22:01:09 +0200

> => yes it is a problem, in particular when it is not the intended
   
   Can we solve it?

=> yes, we have just to add an ID for distinguish/identify requesting
applications.

   Or should we just remove the functionality from PCP?
   
=> there are two dependent issues if we remove 'all XXX PFs' deletes:
 - these deletes are more efficient than to delete PFs one by one
 - one by one means you have the list of PFs, and I showed to get
  a partial list length, i.e., the number of all XXX PFs, is the
  same problem than the equivalent partial delete.
Note this is bound to security: the 'partial' comes from the fact
we don't want PFs for the entity X be visible or deletable by a
sibling (i.e., at the same level) entity Y, at least by default.

So to remove the functionality is a good example of to throw out
the baby with the bath water...

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 14:24:39 -0700

> Sent: Thursday, October 28, 2010 1:01 PM
> To: Dan Wing

That is one way to solve it.  Another way is to allow the same host
(same IP address) that created the mapping to delete it, accomplishing
a similar effect.  The problem with adding an Application ID is
that a new host cannot clear mappings for itself, because it doesn't
know the Application ID used by the previous host (with that same
IP address) that created the mappings.  Or were you considering an
Application ID just to allow deleting someone else's mappings?

>  - these deletes are more efficient than to delete PFs one by one

Not very compelling; I don't forsee a lot of ports being created
on behalf of another host, and fewer that need to be deleted before
their natural expiration.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 Oct 2010 00:09:14 +0200

a similar effect.

=> the host is allowed to delete all PFs for itself (I propose to
add a level, not to replace one).

   The problem with adding an Application ID is
   that a new host cannot clear mappings for itself

=> why? I never asked this.

   because it doesn't know the Application ID used by the previous
   host (with that same IP address) that created the mappings.

=> I can't parse this. The only interpretation is a
requesting application can delete all PFs for another requesting
application (and only them) on the same host only when it knows
the application ID. Where is the problem?

   Or were you considering an Application ID just to allow deleting
   someone else's mappings?
   
=> no but if a requesting application has to do this it must first
get the application ID, for instance by listing all the PFs for
the (shared) host. BTW from the security point of view IMHO
there is no need to hard protect requesting applications on
the same host between themselves in PCP.

   >  - these deletes are more efficient than to delete PFs one by one
   
=> it is 1 vs 2*n

=> so your argument is that n is small. But IMHO the item is
more interesting (and it shows the 'all PFs' delete support comes
for free).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 15:53:33 -0700

> Sent: Thursday, October 28, 2010 3:09 PM
> To: Dan Wing
> Subject: Re: deleting mappings
> 
> 
>    > => yes, we have just to add an ID for distinguish/identify
>    > requesting applications.
> 
>    (same IP address) that created the mapping to delete it,
>    accomplishing a similar effect.
> 

Sorry, I thought we were talking about 3rd party deletion 
earlier in this thread,
http://www.ietf.org/mail-archive/web/pcp/current/msg00267.html

where I wrote:

 #  Is that a problem within a subscriber's network (within a home),
 #  that devices are deleting PCP mappings for other devices?
 #
 #  If so, that might be a problem useful solving.

and you responded:

 # => yes it is a problem, in particular when it is not the 
 #    intended action.

> => why? I never asked this.

In http://www.ietf.org/mail-archive/web/pcp/current/msg00270.html
you wrote:

  "=> yes, we have just to add an ID for distinguish/identify 
   requesting applications."

I call that an "application id".

> the same host between themselves in PCP.

I agree.

I believe the concern, earlier in this thread, was a host
deleting mappings for another host.

-d