Subject: [pcp] draft-wing-pcp-proposed-packet-format-00

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Oct 2010 12:55:22 -0700

FYI, I just posted:
  http://tools.ietf.org/html/draft-wing-pcp-proposed-packet-format-00

Abstract:
  A proposed packet format for PCP.

  This document is for discussion purposes.  It is not intended to be
  published as an RFC.
                                                                                  
-d

---

From: <[email-masked]>
Date: Thu, 7 Oct 2010 07:33:45 +0200

Dear Dan, all,

Thank you for putting this together. 

I know we discussed this privately, but I send this to the list so that we can hear other opinions. Below the open issues I still have with the proposed format:

* A length field may be required
* The proto field is too small IMHO if we want PCP to be used to open pinholes in a firewall (other protocol codes than UDP and TCP can be indicated). 
* A request-id (also called transaction-id) is needed for the following reasons:

(a) Avoid to use several source port numbers when issuing PCP requests. I agree this can be avoided by matching the internal port and the internal IP address. But this is not the case when PCP is used to open pinholes in firewalls for instance for portless protocols (e.g., rsvp, icmp, some modes of ipsec, etc.). 
 
(b) Avoid poisoned answered received from malicious servers: with a request-id of 32 and a randomized source port; an attacker has to guess a 48-bits value; which is hard enough to protect the PCP Client. 

* The Epoch field is not required for reliable NATs; I thought the main use case we have for PCP was Carrier Grade NAT. Those devices are likely to recover PCP-instructed mappings upon reboot or failure. Why should we cover non-reliable NAT in the base PCP protocol? An alternative would be to define an Epoch IE and let have it as a configurable option in the PCP Server. Not returning the Epoch simplifies the PCP Server.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mercredi 6 octobre 2010 21:55
À : [email-masked]
Objet : [pcp] draft-wing-pcp-proposed-packet-format-00

FYI, I just posted:

Abstract:

-d

_______________________________________________
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, 07 Oct 2010 15:57:16 +0200

In your previous mail you wrote:

=> in fact it is not required because UDP provides the message length.

   * The proto field is too small IMHO if we want PCP to be used to
     open pinholes in a firewall (other protocol codes than UDP and
     TCP can be indicated).
   
=> we need 4 values (i.e., 2 bits, we have 3 today): all, UDP, TCP,
protocols in an IE.

   * A request-id (also called transaction-id) is needed

=> I agree but I prefer an opaque IE which is just reflected by the server.
It is a generalization of a TID (as you can put a TID in it), it can
handle state (so it is possible (even pretty easy) to write a stateless
proxy), nonce, etc.

     for the following reasons:
   
   (a) Avoid to use several source port numbers when issuing PCP requests.

=> this is the TID for the poor (:-). Obviously we don't want this.

   I agree this can be avoided by matching the internal port
   and the internal IP address. But this is not the case when PCP is
   used to open pinholes in firewalls for instance for portless
   protocols (e.g., rsvp, icmp, some modes of ipsec, etc.).
   
=> even in the DS-lite context it is very painful for a proxy to
match a response with a request without the help of a TID or similar.
   
   (b) Avoid poisoned answered received from malicious servers: with a
   request-id of 32 and a randomized source port; an attacker has to
   guess a 48-bits value; which is hard enough to protect the PCP
   Client.
   
=> what you want is a nonce so you should buy by opaque IE idea.
   
   * The Epoch field is not required for reliable NATs;

=> I fully agree: the epoch should be moved to an IE for the benefit
of NAT-PMP IWF or in local environments where it is not reasonnable
to require the NAT to be statefull.

   I thought the main usecase we have for PCP was Carrier Grade
   NAT. Those devices are likely to recover PCP-instructed mappings
   upon reboot or failure. Why should we cover non-reliable NAT in the
   base PCP protocol? An alternative would be to define an Epoch IE
   and let have it as a configurable option in the PCP Server. Not
   returning the Epoch simplifies the PCP Server.
   
=> +1

[email-masked]

---

From: <[email-masked]>
Date: Thu, 7 Oct 2010 16:58:27 +0200

Dear Françis,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 7 octobre 2010 15:57
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] draft-wing-pcp-proposed-packet-format-00 

Med: Yes, you are right. Implementers need to take into account I and E fields to locate the start of the IEs if any.

Med: I don't have any preference, whether it is encoded in a fixed field or an IE. 

   

   
=> +1

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 7 Oct 2010 12:14:52 -0400

Hello,

I disagree with such statements at this point since I still need to see data
to back them up. 

For example,

1 - First and foremost, please define CGN.
2 - Then we please define a reliable NAT - such that state is never ever
lost. Please see (4)
3 - The BEHAVE RFCs do not mention the necessity of keeping NAT binding
state across reboots/power off, why keeping PF dynamic state is needed?
4 - CLI to clear mapping state will be implemented for sure due to security
reasons. How should we deal with that?

Therefore, I'm fine with removing the Epoch, but clients will need to deal
with the PCP Server loosing all state during certain types of events - such
event could be a admin clearing all mappings due to a security concern.

Thanks,

Reinaldo

On 10/6/10 10:33 PM, "[email-masked]"
<[email-masked]> wrote:

> * The Epoch field is not required for reliable NATs; I thought the main use
> case we have for PCP was Carrier Grade NAT. Those devices are likely to
> recover PCP-instructed mappings upon reboot or failure. Why should we cover
> non-reliable NAT in the base PCP protocol? An alternative would be to define
> an Epoch IE and let have it as a configurable option in the PCP Server. Not

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2010 18:51:16 +0200

Med: Yes, you are right. Implementers need to take into account I
   and E fields to locate the start of the IEs if any.
   
=> oops, it was not clear in your message but you meant a header length
field, didn't you?

Regards

PS: I am afraid if you have to support mixed v4/v6 PCP a header length
won't remove a significant part of the complexity.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2010 19:17:56 +0200

For example,

=> a NAT which is so big and noisy I don't want one at home.
Seriously I have a convenient definition for this particular discussion:
a NAT where clients (guys at the internal side, the other/external is
the or to the Internet) may not trust together. As an immediate
consequence to forward a packet from the Internet to the wrong client
is a major security issue.

=> reliable for the port forwarding entries. Note this is done even with
not CGN NAT (the NAT in front of me is not a CGN and its (port forwarding)
config is very reliable (save in a flash memory and downloaded at each
reboot)).

=> PF is *not* equivalent in the security point of view to a dynamic
NAT binding (*) so BEHAVE RFCs are right but don't apply.

=> yes, when my PCP server crashes (or when I kill it) all the PF entries
it has installed are flushed, and this is done by the AFTR code as fast
as possible. There are many reasons for this and security is one of
them as lifetimes are managed by the PCP server, and when the PCP server
restarts its first action is to reinstall the PFs it keeps in stable
storage (a BSD DB which is my approximation from the top of stable storage).
BTW a missing PF is bad but is not a security issue.

=> the Epoch doesn't help you because it doesn't provide an usable
proactive way to warn clients about such events.

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 7 Oct 2010 14:15:16 -0400

Comments inline...

> is a major security issue.

I have difficulty parsing this definition. Hosts outside the security zone
are not trusted in general. But the definition seems to apply to broadband
subscribers when your IP address change and you get somebody else's (a
problem that has always been there). Seems to apply to enterprises NATs.

> config is very reliable (save in a flash memory and downloaded at each

CLI driven configuration is okay. Dynamic state driven by protocols is
another.

> NAT binding (*) so BEHAVE RFCs are right but don't apply.

Actually with EIM I see very little difference except that there is a
shorter lifetime. But the CGN can also enforce a very small lifetime.

> BTW a missing PF is bad but is not a security issue.

When they are clear they are gone - really. The whole purpose of clearing is
to not reuse them.

> proactive way to warn clients about such events.

Agree. But developing a protocol where its correctness relies on devices
having persistent storage for dynamic state does not sound correct.

Offline I asked examples of other IETF protocols that have dynamic state and
rely on persistent storage to operate correctly - and whether they are
implemented on 'CGN' boxes.

---

From: Dayong Guo <[email-masked]>
Date: Fri, 08 Oct 2010 09:28:20 +0800

> => oops, it was not clear in your message but you meant a 
> header length field, didn't you?
> 

A length field is valuable when TWO pcp messages are carried in one UDP
packet.

---

From: <[email-masked]>
Date: Fri, 8 Oct 2010 07:40:35 +0200

Dear all, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 7 octobre 2010 19:18
À : Reinaldo Penno
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Dan Wing; [email-masked]
Objet : Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-packet-format-00 

   
   For example,

Med: Agree. I'm mainly concerned with a basic requirement which is the following excerpt from http://tools.ietf.org/html/draft-xu-behave-nat-state-sync-02:

"The NAT states mentioned in this document only mean those NAT states
   which are created dynamically, rather than those static NAT states
   which are configured manually on NAT devices. For those static NAT
   states, they are essentially part of the configuration data. The
   replication of configuration data among a group of devices is
   absolutely outside the scope of this document."

"Static entries" mentioned above apply also for PCP-instructed ones.

BTW, I think we need to have a clear definition somewhere to agree on the terminology. Note that several levels of reliability in the NAT can be envisaged as described in http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-04.  

   

Regards

---

From: <[email-masked]>
Date: Fri, 8 Oct 2010 07:50:45 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]] 
Envoyé : jeudi 7 octobre 2010 20:15
À : Francis Dupont
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Dan Wing; [email-masked]
Objet : Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-packet-format-00

Comments inline...

Med: Does that mean that if you have configured ACL in a router using an automatic means such as COPS or NETCONF, when your router reboots you will loose those ACLs? IMHO, we need to distinguish between dynamic mappings which are created by outbound packets and those which are configured using manual configuration, xml-based config, via a web portal or by PCP. Those mappings should treated as for static configuration data. Recovery of this PF during failure or reboot is a requirement from a service provider perspective. 

>    reasons. How should we deal with that?

Med: Your point Reinalod is valid. BTW, the reasons I see to have such CLI command are more about troubleshooting or to "clean" stale mappings, but the "security" reasons I don't have a concrete example. 

Med: Persistent storage for "port forwarding" entries not for the all the mappings instantiated by outgoing packets.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 8 Oct 2010 01:51:27 -0400

On 10/7/10 10:40 PM, "[email-masked]"
<[email-masked]> wrote:

> Med: Agree. I'm mainly concerned with a basic requirement which is the
> following excerpt from
> http://tools.ietf.org/html/draft-xu-behave-nat-state-sync-02:
> 

I disagree according to
http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework/

"State:  "State" refers to dynamic information that is stored in a
      network element.  For example, if two systems are communicating
      using a TCP connection, each stores information about the
      connection, which is called "connection state".  In this context,
      the term refers to dynamic correlations between IP addresses on
      either side of a translator, or {IP address, transport protocol,
      transport port number} tuples on either side of the translator.
      Of stateful algorithms, there are at least two major flavors
      depending on the kind of state they maintain:"

PCP entries are clearly dynamic state created by protocol exchange and have
a lifetime. 

> 
> BTW, I think we need to have a clear definition somewhere to agree on the
> terminology. Note that several levels of reliability in the NAT can be
> envisaged as described in
> http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-04.
>

---

From: <[email-masked]>
Date: Fri, 8 Oct 2010 08:11:23 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]] 
Envoyé : vendredi 8 octobre 2010 07:51
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-packet-format-00

I disagree according to

Med: PCP-unstructured entries or using any other tools to configure port forwarding on the CGN are not in the same level as dynamic mappings created by outgoing packets. Unlike other mappings which have system-wise timers (system-wise timers are configured for all UDP and TCP packets), these entries have their per-entry timers (a.k.a., lifetime). What we are saying here is that a basic reliability requirement for the CGN is to protect any static or automatic (e.g., PCP) port forwarding against failure. This requirement is not about imposing hot-standby or the recovery of all dynamic states instantiated by outgoing packets. We had this requirement about port forwarding in our CGN RFP and I don't remember I seen an objection from the vendors on having this requirement.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 8 Oct 2010 02:22:21 -0400

Med,

More comments inline....Trying to steer away from semantics discussion.

On 10/7/10 11:11 PM, "[email-masked]"
<[email-masked]> wrote:

> Med: PCP-unstructured entries or using any other tools to configure port
> forwarding on the CGN are not in the same level as dynamic mappings created by
> outgoing packets. Unlike other mappings which have system-wise timers
> (system-wise timers are configured for all UDP and TCP packets), these entries
> have their per-entry timers (a.k.a., lifetime). What we are saying here is
> that a basic reliability requirement for the CGN is to protect any static or
> automatic (e.g., PCP) port forwarding against failure. This requirement is not
> about imposing hot-standby or the recovery of all dynamic states instantiated
> by outgoing packets. We had this requirement about port forwarding in our CGN
> RFP and I don't remember I seen an objection from the vendors on having this
> requirement.

Well, in summary some service providers care and others do not. Just like
Stateful NAT synch, some providers care and others do not. And therefore the
protocol can not work only if you keep state. Keeping state should be seen
as a bonus in some recovery situations.

On a more practical note, applications can not really rely on port
forwarding state being foolproof to work. IMHO trying to offset application
limitations on the network is the wrong thing to do - it is ALGs all over
again. 

That is why 'new' applications leverage EIM/EIF, AP, connection symmetry,
etc. 

I prefer dealing with failure and recovery in the protocol, specially since
there are other situations:

* CPE changing of IP address,
* Use of anycast address for AFTR/BR/CGN (do we create PCP entries in all
devices under the same anycast? How?)
* others.

I propose we go back and revisit the protocol to make sure clients/servers
can deal with failure within the protocol. Maybe a combination of Epoch and
PING/PONG would take care of most of the failures, maybe not, but let's take
to a logical conclusion before throwing the towel and saying all state need
to be kept.

Thanks,

Reinaldo

>> This message and any attachments (the "message") are confidential and
>> intended
>> solely for the addressees.

---

From: <[email-masked]>
Date: Fri, 8 Oct 2010 08:37:25 +0200

Re-,

Agree. 

Let's do this. 

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]] 
Envoyé : vendredi 8 octobre 2010 08:22
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-packet-format-00

Med,

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Oct 2010 14:44:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dayong Guo
> Sent: Thursday, October 07, 2010 6:28 PM
> To: 'Francis Dupont'
> Cc: [email-masked]
> Subject: Re: [pcp] draft-wing-pcp-proposed-packet-format-00
> 
> 

Unsupported.
 
-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Oct 2010 00:08:09 +0200

PF is *not* equivalent in the security point of view to a dynamic
   NAT binding (*)
   
=> oops, I missed to explain this. With the traditional view of
a NAT from the client to the Internet, a NAT entry is a 7-tuple:
 - protocol
 - original/internal source address
 - original/internal source port
 - mapped/external source address
 - mapped/external source port
 - destination address
 - destination port
In the port forwarding entry destination address and port are wildcards.

---

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

=> it clearly doesn't apply to home NATs (where you can get NAT-PMP and/or
UPnP-IGD) and it depends for enterprise NATs (often the enterprise NAT
is embedded inside the firewall and the whole inside is considered as
one security domain. But this is not the right place for this discussion,
the important thing is we want to use PCP with CGNs following the
security constraint I described).

=> I agree dynamic PFs are less critical in an operational point of view
but they aren't different from the security point of view as soon as
their visible lifetimes can be long.
   
   > NAT binding (*) so BEHAVE RFCs are right but don't apply.
   
=> note I failed to explain that (just repaired before this message).

   
=> correctness -> security (but I agree we want *both*)

Note this is only for CGNs with my 'security' definition and for
port forwarding entries.

   Offline I asked examples of other IETF protocols that have dynamic state 
   and rely on persistent storage to operate correctly - and whether they are
   implemented on 'CGN' boxes.
   
=> dynamic DNS requires persistent storage (I can give you the pointer
if you need). BTW there is no requirement to put the PCP service (which
is in the control plane) in the same box than the NAT/CGN (which is
in the forwarding plane) so you can't infer security requires the CGN
has persistent storage, only that the entity which controls the CGN
has one.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Oct 2010 00:31:44 +0200

=> I can guess this is not something we want to add in the protocol (:-).

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Oct 2010 00:43:55 +0200

> "Static entries" mentioned above apply also for PCP-instructed ones.
   
=> I agree with Mohamed, here the term static is the strict opposite
of the dynamic one, and port forwarding entries are 'static' even they
can get a lifetime.

   I disagree according to

   PCP entries are clearly dynamic state created by protocol exchange

=> but not 'dynamic state' in the behave meaning where everything not
in the forwarding plane is qualified as 'static'.

Regards

PS: I like the security point of view because it makes very clear
port forwarding entries and behave dynamic states are two very different
things.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Oct 2010 00:55:53 +0200

Well, in summary some service providers care and others do not.

=> it is a security concern so IMHO they should care.

   Just like Stateful NAT synch, some providers care and others do not.

=> no, this is different. A CGN reboot is just inconvenience,
a CGN controller which can lose its port forwarding state is a major
security issue.

   On a more practical note, applications can not really rely on port
   forwarding state being foolproof to work.

=> application security does rely on it.
If an attacker can crash such a CGN controller can steal the traffic to
any server behind the CGN.
   
   saying all state need to be kept.
   
=> the hold down (make expired and deleted PF entries unavailable for
others than the previous holder) requirement implies the PF state
SHOULD be kept.

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 8 Oct 2010 19:02:29 -0400

Hello,

> => no, this is different. A CGN reboot is just inconvenience,

Certain providers have different views on this.

> a CGN controller which can lose its port forwarding state is a major

What is a CGN controller?

Anyway, PF mappings across reboots are wiped and no packets will get
through. It is as secure as it started.

> any server behind the CGN.

Please elaborate on an actual use case.

> others than the previous holder) requirement implies the PF state

Much like TCP FIN and RST in a CGN. But not necessarily across reboots.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 8 Oct 2010 19:06:20 -0400

Can you elaborate how different a PF is from an EIM/EIF mapping given both
have the same inactivity lifetime? I think this would be a good exercise on
the security model that could be incorporated on the draft.

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Oct 2010 17:01:14 -0700

Forwarding subscriber A's PCP-allocated port to subscriber B is similar --
if not identical -- to today's situation where subscriber C's IP address is
assigned to subscriber D.  In both cases, a subscriber starts receiving
traffic that was intended for a different subscriber.  I appreciate this is
a security issue.  

I don't see that PCP can do better than "server MUST honor the Lifetime it
provides in the PCP response".  Failure of the server (e.g., crash, disk
failure, ...) will cause the server to violate that MUST.  Failures always
override a MUST, otherwise we would start every RFC with "the device and
software MUST never fail".

-d

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 08, 2010 3:56 PM
> To: Reinaldo Penno
> Cc: [email-masked]; Dan Wing; [email-masked]
> Subject: Re: [pcp] PCP Failure Scenarios - Re: draft-wing-pcp-proposed-
> packet-format-00
> 
>

---

From: Dong Zhang <[email-masked]>
Date: Sat, 09 Oct 2010 10:29:56 +0800

Hi,

mohamed.boucadair 2010-10-08 Wrote:
>Med: PCP-unstructured entries or using any other tools to configure port forwarding on the CGN are not in the same level as >dynamic mappings created by outgoing packets. 
I agree this point. We could treat the PCP entries as a kind of dynamic-configured data and the CLI is a kind of manual-configured data. In my understanding, both are configuration.

>Unlike other mappings which have system-wise timers (system-wise timers are configured for all UDP and TCP packets), these entries >have their per-entry timers (a.k.a., lifetime). What we are saying here is that a basic reliability requirement for the CGN is to >protect any static or automatic (e.g., PCP) port forwarding against failure. This requirement is not about imposing hot-standby or >the recovery of all dynamic states instantiated by outgoing packets. We had this requirement about port forwarding in our CGN RFP >and I don't remember I seen an objection from the vendors on having this requirement.
But I have a question here. Redundancy or hot-standy can be the solution for NAT failure, reboot and power off. Either the configuration or the dynamic data can be recovered. Is the requirement here to rely on static memory to provid PF entries safety? maybe I don't catch the disucssion.

Thanks.

------------------				 
Dong Zhang
2010-10-09

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Oct 2010 12:30:44 +0200

=> what I mean is this has only an operational impact.

   
=> the entity where is the control plane of the CGN.

=> this argument applies to the forwarding plane and I agree there is
no security issue at this place.

   
=> imagine I use telnet to remotely connect to a box which is behind
the NAT embedded in my home gateway (PS: in fact I use ssh which is
protected against this but I don't believe I am a standard user :-).
Of course this needs a port forwarding entry, if the attacker can reboot
the CGN controller and override this port forwarding entry, the next
time I'll try to connect from the outside to my box I'll give my login
and password believing I'll send it to my box.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Oct 2010 12:44:23 +0200

=> I agree.

=> there are two parts:
 - the port forwarding entry stays active/installed during the lifetime,
  this is for the fordarding plane and I agree if it crashes it won't
  be honored.
 - the port forwarding entry may not be overwritten by a different client
  (PS: note we need a good definition of client here) during the lifetime
  and an extra small delay (typically 2*MSL for packets in transit).
  This is for the control plane and IMHO it MUST be enforced when there
  is more than one client. This implies to commit the port forwarding
  state to a stable storage.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Oct 2010 08:42:41 -0700

> Sent: Monday, October 11, 2010 3:31 AM
> To: Reinaldo Penno

Thanks for explaining.  I now understand how that scenario and
requirement is similar to DHCP.

-d