Subject: [pcp] GET and GETNEXT OpCodes

From: <[email-masked]>
Date: Wed, 9 Mar 2011 20:10:35 +0800

Hi Med,

Since these two options are supposed to be designed for PCP relay, if
the relay could always recover from losing state by issuing GETNEXT to
retrieve 

the whole port mapping table, I wonder what's the use case for GET?

BR,

Xiaohong

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Mar 2011 14:05:54 +0100

In your previous mail you wrote:

   Since these two options are supposed to be designed for PCP relay, if
   the relay could always recover from losing state by issuing GETNEXT to
   retrieve the whole port mapping table, 
   
=> the two opcodes (BTW the last proposal not yet edited uses one opcode)
are for from server to client synchronization, not only for IWF/Proxy
even it can use it.

   I wonder what's the use case for GET?

=> for instance to get the remaining lifetime, or to check if an
explicit dynamic mapping was really installed by the server, etc.
(BTW note PEER provides the same function of implicit dynamic
mappings).

Thanks

[email-masked]
(replacing Mohammed who is not yet back from Lunch)

PS: nice properties of the GET operation are;
 - it doesn't change the server state
 - it should get a SUCCESS response with the external
  address and a 'fresh' Epoch value.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Mar 2011 11:34:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Wednesday, March 09, 2011 5:06 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [pcp] GET and GETNEXT OpCodes
> 
> 

No, PEER does not provide the same function for implicit dynamic
mappings.  PEER requires the client know the entire 5-tuple.  
For the client to know that, it cannot have forgotten the
5-tuple (forgotten = "lost state").

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Mar 2011 23:16:42 +0100

=> by 'pure GET' I mean something which should return one result
so it is a terminology issue (it should become clearer with
the last GET/GETNEXT specs).

Thanks

---

From: <[email-masked]>
Date: Thu, 10 Mar 2011 11:55:34 +0800

|=> the two opcodes (BTW the last proposal not yet edited uses 
|one opcode) are for from server to client synchronization, not 
|only for IWF/Proxy even it can use it.

>From interim meeting notes:
Stuart: On reboot, client makes mapping requests, which look like
renewals to the server.
Alain: This is the case where the PCP relay crashes.

I want to make a comment :
usually UPnP IGD Control Point issues "AddPortMapping" after rebooting. 
I supopse PCP Client will do similarly, which means PCP client would 
also make mapping requests on reboot,which look like renewals to the 
server like Stuart stated.That's why I don't see a use case of
GET/GETNEXT 
for 'pure' PCP Clients.

|   I wonder what's the use case for GET?
|
|=> for instance to get the remaining lifetime, or to check if 
|an explicit dynamic mapping was really installed by the server, etc.

In case of a PCP Client, when does it want to know if the explicit
dynamic 
mapping was really installed by the server? In case of a PCP proxy,
it maintains a mapping table.

|(BTW note PEER provides the same function of implicit dynamic 
|mappings).

|Thanks
|
[email-masked]
|(replacing Mohammed who is not yet back from Lunch)
|
|PS: nice properties of the GET operation are;
| - it doesn't change the server state
| - it should get a SUCCESS response with the external
|  address and a 'fresh' Epoch value.
|

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Mar 2011 15:38:25 +0100

=> yes, the failure model (which is IMHO *not* adapted to ISP CGNs)
of UPnP IGD was explicited in the version 2 and is to reinstall
mappings as the server (IWF in our case) is not required to use
stable storage.

   I suppose PCP Client will do similarly, which means PCP client would
   also make mapping requests on reboot, which look like renewals to the
   server like Stuart stated.

=> you assume implicitely two important things:
 - a failure model where it is enough for the client to reinstall
  its explicit dynamic mappings. This has two problems: it can take
  time to detect a failure on the PCP server side (NAT-PMP uses multicast
  to solve this point) and this opens the door of explicit dynamic
  mapping thefts when the PCP server controls an ISP CGN (something
  which is out of scope for UPnP IGD and NAT-PMP)

 - this doesn't solve the problem of 'stale' explicit dynamic
  mappings, i.e., mappings which are installed on the PCP server but
  the PCP client for any reason didn't delete.

  That's why I don't see a use case of GET/GETNEXT for 'pure' PCP Clients.
   
=> GETNEXT is the not-disruptive way to synchronize a PCP client and
server pair (the disruptive way is to send first a 'delete all' so
the PCP server 'starts' in a 'virgin' state).

   In case of a PCP Client, when does it want to know if the explicit
   dynamic mapping was really installed by the server? In case of a
   PCP proxy, it maintains a mapping table.
   
=> as a co-author of the PCP Proxy I-D I can say it doesn't maintain
a mapping table. It is *not* an option for a simple PCP Proxy
and it is a by default NOT RECOMMENDED option for a smart PCP Proxy
(of course to discuss further you need the whole text of the I-D,
I expect it will be posted for the dead line, next Monday).

Thanks

PS: BTW UPnP IGD has equivalents of GET/GETNEXT so the 'stale' mapping
issue comes from a partial application of the UPnP IGD model to PCP,
i.e., the first part of your argument is not sound.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 10:06:06 -0800

> Sent: Thursday, March 10, 2011 6:38 AM

Oh!  That must be the security problem you refer us back to, but have not
re-explained to us.

So, the scenario is:

  1. PCP client does a MAP
  2. PCP server (or the CGN) crashes and loses state
  3. PCP client is, of course, unaware of that state loss until
     much later (whatever its refresh interval is)
  4. In that interval, another PCP client (or implicit dynamic
     mapping) could grab that port.

The same problem exists without PCP, of course, with an
implicit mapping (e.g., created with a TCP SYN).  And the
resolution is described in Section 6, "Cold Standby Mode" 
of draft-xu-behave-stateful-nat-standby-06:  that the 
CGN needs to use a different public IPv4 address pool 
when it crashes and loses state.   IMO, that advice 
belongs in BEHAVE's CGN Requirements document, as it 
does not solely affect PCP.  Simon Perreault, CC'd, 
is the editor of the CGN Requirements document.

In the PCP document, adding something along the lines of seems a reasonable
addition for the Epoch section:

   In the time between a PCP server loses state and the PCP client
   notices the lower-than-expected Epoch value, it is possible that the
   PCP client's mapping will be acquired by another host (via an
   explicit dynamic mapping or implicit dynamic mapping).  This means
   incoming traffic will be sent to a different host.  A mechanism to
   immediately inform the PCP client of state loss would reduce this
   interval, but would not eliminate this threat.  The PCP client can
   reduce this interval by using a relatively short lifetime; however,
   increases the amount of PCP chatter.  Connection authentication 
   (e.g., TLS) does eliminate this threat.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Mar 2011 01:56:48 +0100

Oh!  That must be the security problem you refer us back to, but
   have not re-explained to us.
   
=> yes, I am tired to explain it again and again.

   So, the scenario is:
   
     1. PCP client does a MAP
   
   The same problem exists without PCP, of course, with an
   implicit mapping (e.g., created with a TCP SYN).

=> yes, it exists for implicit dynamic mappings, explicit
dynamic mappings and static mappings, and its severity increases
for each kind of mappings.
IMHO it is unbearable for static mappings (i.e., if one of my ISPs
fails to protect a static mapping of mine I'll sue it),
critical for explicit dynamic mappings and perhaps to expensive
to solve for implicit dynamic mappings (i.e., if one of my ISPs
fails to protect an implicit dynamic mapping I'll just say it
is the way of life, @#$* NATs!). Of course this is based on
relative lifetimes and what is expected from each kind.

   And the
   resolution is described in Section 6, "Cold Standby Mode" 
   of draft-xu-behave-stateful-nat-standby-06:  that the 
   CGN needs to use a different public IPv4 address pool 
   when it crashes and loses state.

=> yes, it is a way a solve the problem but it is in fact
the sacrifice of the operation in order to save the security,
i.e., IMHO not the best solution. BTW its scalability is
questionable too. I put a (*) to this solution as I'll refer
to it below.

   IMO, that advice 
   
=> I'd *really* like to get something in the security
considerations.
   
   In the PCP document, adding something along the lines of seems a
   reasonable addition for the Epoch section:
   
      increases the amount of PCP chatter.
   
=> two remarks: what subscribers want is to eliminate the threat and
at the exception of the cited solution (*) and similar ones the way to do
that is to REQUIRE that PCP Servers controlling NATs which serve
multiple subscribers and can reassign mappings to save the explicit
dynamic mapping state in stable/persistent storage.
(BTW it is well known such NATs have to use stable/persistent storage
for many other reasons so it is not a problem).
 And this belongs to security so should be in the security considerations
(at least the security requirements must be).

      Connection authentication (e.g., TLS) does eliminate this threat.   
   
=> unfortunately it is not the case: a perfectly authenticated
subscriber can acquire an explicit dynamic mapping of another
subscriber if the PCP Server lost the fact it was the explicit dynamic
mapping of another subscriber.

Thanks

PS: BTW to explain to subscribers (victims?) of ISP CGNs they should
use IPsec (network layer), TLS (transport layer) and/or application
security for all communications is not very kind as they are likely in
countries where these security solutions are very far to be allowed.

---

From: <[email-masked]>
Date: Fri, 11 Mar 2011 18:02:57 +0800

|   I suppose PCP Client will do similarly, which means PCP client would
|   also make mapping requests on reboot, which look like 
|renewals to the
|   server like Stuart stated.
|
|=> you assume implicitely two important things:
| - a failure model where it is enough for the client to reinstall
|  its explicit dynamic mappings. This has two problems: it can take
|  time to detect a failure on the PCP server side (NAT-PMP 

xiaohong: agreed, but how to heal quickly? sending GET/GETNEXT Periodiclly ?

|uses multicast
|  to solve this point) and this opens the door of explicit dynamic
|  mapping thefts when the PCP server controls an ISP CGN (something
|  which is out of scope for UPnP IGD and NAT-PMP)
|
| - this doesn't solve the problem of 'stale' explicit dynamic
|  mappings, i.e., mappings which are installed on the PCP server but
|  the PCP client for any reason didn't delete.
|
|
|  That's why I don't see a use case of GET/GETNEXT for 'pure' 
|PCP Clients.
|   
|=> GETNEXT is the not-disruptive way to synchronize a PCP 
|client and server pair (the disruptive way is to send first a 
|'delete all' so the PCP server 'starts' in a 'virgin' state).
|
|   In case of a PCP Client, when does it want to know if the explicit
|   dynamic mapping was really installed by the server? In case of a
|   PCP proxy, it maintains a mapping table.
|   
|=> as a co-author of the PCP Proxy I-D I can say it doesn't 
|maintain a mapping table. It is *not* an option for a simple 

xiaohong: I meant PCP proxy maintains a mapping table in memory and once reboot it issues 
GETNEXT to re-construct mapping table.
 
|PCP Proxy and it is a by default NOT RECOMMENDED option for a 
|smart PCP Proxy (of course to discuss further you need the 
|whole text of the I-D, I expect it will be posted for the dead 
|line, next Monday).
|Thanks
|
[email-masked]
|
|PS: BTW UPnP IGD has equivalents of GET/GETNEXT so the 'stale' 
|mapping issue comes from a partial application of the UPnP IGD 
|model to PCP, i.e., the first part of your argument is not sound.

Xiaohong: UPnP IGD Control Point implementation usually issues GetSpecificPortMappingEntry 
before AddPortMapping to know if the external port has been occupied by other clients, but PCP 
client doesn't have to know it  because PCP client accept any external port returned from PCP server
|

---

From: <[email-masked]>
Date: Fri, 11 Mar 2011 18:15:41 +0800

|Oh!  That must be the security problem you refer us back to, 
|but have not re-explained to us.
|
|So, the scenario is:
|
|  1. PCP client does a MAP
|  2. PCP server (or the CGN) crashes and loses state
|  3. PCP client is, of course, unaware of that state loss until
|     much later (whatever its refresh interval is)
|  4. In that interval, another PCP client (or implicit dynamic
|     mapping) could grab that port.
|
|The same problem exists without PCP, of course, with an 
|implicit mapping (e.g., created with a TCP SYN).  And the 
|resolution is described in Section 6, "Cold Standby Mode" 
|of draft-xu-behave-stateful-nat-standby-06:  that the CGN 
|needs to use a different public IPv4 address pool 
|when it crashes and loses state.   IMO, that advice 
|belongs in BEHAVE's CGN Requirements document, as it does not 
|solely affect PCP.  Simon Perreault, CC'd, is the editor of 
|the CGN Requirements document.
|
|
|In the PCP document, adding something along the lines of seems 
|a reasonable addition for the Epoch section:
|
|   In the time between a PCP server loses state and the PCP client
|   notices the lower-than-expected Epoch value, it is possible that the
|   PCP client's mapping will be acquired by another host (via an
|   explicit dynamic mapping or implicit dynamic mapping).  This means
|   incoming traffic will be sent to a different host.  A mechanism to
|   immediately inform the PCP client of state loss would reduce this
|   interval, but would not eliminate this threat.  The PCP client can
|   reduce this interval by using a relatively short lifetime; however,

xiaohong: that could help, but how long would be the perfect lifetime
that niether too long
for healing nor too short to limit the amount of PCP chatter?

|   increases the amount of PCP chatter.  Connection authentication 
|
BR,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Mar 2011 14:41:48 +0100

xiaohong: agreed, but how to heal quickly? sending GET/GETNEXT
   Periodiclly ?
   
=> no even it is not a bad idea. The best is to make PCP server/NAT
transparent for explicit dynamic bindings.

   |=> as a co-author of the PCP Proxy I-D I can say it doesn't=20
   |maintain a mapping table. It is *not* an option for a simple=20
   
   xiaohong: I meant PCP proxy maintains a mapping table in memory

=> this is what I understood.

   Xiaohong: UPnP IGD Control Point implementation usually issues
   GetSpecificPortMappingEntry before AddPortMapping to know if the
   external port has been occupied by other clients,

=> I gave up trying to understand a common behavior of UPnP clients (:-)

   but PCP client doesn't have to know it because PCP client accept
   any external port returned from PCP server

=> a PCP client still expects its view of its explicit dynamic mappings
is shared by the PCP server: this is a synchronization problem and
the two solutions are to delete all mappings (but a bit disrupive,
isn't it) and a GET/NEXT operation (as described in the fealure I-D).

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 09:41:33 -0800

> From: [email-masked] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Friday, March 11, 2011 2:16 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE:[pcp] GET and GETNEXT OpCodes
> 
> 

There isn't any ideal value.

The exact same problem occurs with DHCP, today -- the DHCP server
can crash and lose state (forgetting which clients had leased
which addresses), and a different host can acquire that address.

Even if there was a way to inform a host, immediately, that the
PCP server lost state (e.g., using a multicast message, as done
by NAT-PMP), one host could beat another host.  The window of
opportunity would be shorter, but something as simple as being
connected to wired Ethernet (rather than wireless) or a faster
Ethernet driver or faster CPU would allow someone to win.

I don't see a solution.

As my proposed text suggests, if this is a concern, use TLS
on the connection itself.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 10:02:11 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 10, 2011 4:57 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 'Simon Perreault'

Is there such a requirement, today, for ISP-provided dynamic
IPv4 addresses (e.g., assigned via PPPoE or DHCP) -- in IETF 
specifications, service level agreements, or similar?

I do not believe there is.  But if there is, let's copy that 
wording from the DHCP RFC.

If there isn't, I do not see why PCP needs to go above and
beyond current industry practice and current behavior for
dynamic IPv4 address assignment.

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 00:00:41 +0100

=> DHCP servers I know try to use stable/persistent storage
to avoid this. Exactly they use a 'lease file' which is
committed at a reasonable rate so if the file is written on a disk
to lose a lease is very unlikely. Some offer a static lease
facility which is the exact equivalent of the static mapping
(dynamic leases being the equivalent of explicit dynamic mappings).

   Even if there was a way to inform a host, immediately, that the
   PCP server lost state (e.g., using a multicast message, as done
   by NAT-PMP), one host could beat another host.

=> yes, it is a race so you can expect the bad guy to cheat and win.

   The window of
   
=> in the case of PCP to win the race you have only to poll at
a high rate the PCP server...

   I don't see a solution.
   
=> use stable/persistent storage at the PCP server side so the
problem no longer can happen.

=> oops, I believe I misinterpreted this suggestion: I believed
it meant to use TLS to protect PCP messages when it means to use
TLS to protect connections using explicit dynamic mappings.

Seems we'll need a shared addressing issue document but from
the saag and not from the intarea...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 00:32:35 +0100

=> there is one for DNS dynamic update (RFC 2136):
 - 3.4.2.1 mentions explicitely 'persistent storage'
 - 3.5 - Stability (quoted below)

   "When a zone is modified by an UPDATE operation, the server must
   commit the change to nonvolatile storage before sending a response to
   the requestor or answering any queries or transfers for the modified
   zone.  It is reasonable for a server to store only the update records
   as long as a system reboot or power failure will cause these update
   records to be incorporated into the zone the next time the server is
   started.  It is also reasonable for the server to copy the entire
   modified zone to nonvolatile storage after each update operation,
   though this would have suboptimal performance for large zones."

=> RFC 3315 (DHCPv6) has a requirement about stable storage for
DUID-LLT (BTW it doesn't make sense to protect assignments without
a reliable and stable identity).
BTW protest against this argument: dynamic IPv4 address assignment
(aka a particular use of DHCPv4) is not universal so you can't use
a total lack of security of DHCPv4 to say security is useless.

=> can you explain exactly what you mean by 'dynamic' here?
My ISP uses DHCP but dynamic assigns the same fixed address each time
the CPE reboots or renews. So IMHO you mean a new address each day,
a behavior which is not based on technical considerations (nor
commercial ones when some competitors propose a fixed address :-).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 15:54:39 -0800

> Sent: Friday, March 11, 2011 3:33 PM
> To: Dan Wing

Thanks.  I adjusted the final sentence in the text below, which
echoes similar wording from RFC2136:

<t>In the time between a PCP server loses state and the PCP client
  notices the lower-than-expected Epoch value, it is possible that the
  PCP client's mapping will be acquired by another host (via an
  explicit dynamic mapping or implicit dynamic mapping).  This means
  incoming traffic will be sent to a different host.  A mechanism to
  immediately inform the PCP client of state loss would reduce this
  interval, but would not eliminate this threat.  The PCP client can
  reduce this interval by using a relatively short lifetime; however,
  this increases the amount of PCP chatter.  The use of connection
  authentication between peers (e.g., TLS), or persistent storage of
  mappings in the PCP server c) eliminates 
  this threat.
</t>

> commercial ones when some competitors propose a fixed address :-).

My ISP does the same.

Nevertheless, there is no contract, SLA, or any agreement whatsoever
that my ISP continues to give me the same IPv4 address tomorrow.

Which is why I use a dynamic DNS service and my NAT watches for
changes to its WAN address.  And between the time my NAT notices
the WAN change and when I can register a new address in DNS
and my DNS TTL expires -- connections from the Internet will 
go to my 'previous' address.  There is nothing I can do about
that, but to run very tight timers (e.g., TTL timer) -- which
is why I wrote text for PCP encouraging tight timers.  Yes,
they increase the chattiness.

The same is true of PCP, which is doing the same sort of thing
as DHCP.

And, no amount of state storage in the PCP server, or a DHCP
server, will fix the problem.  Redundant systems do fail,
including redundant disks.  

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 15:10:19 +0100

=> purely editorial:

     authentication between peers (e.g., TLS), or persistent storage of
     explicit dynamic mappings in the PCP server eliminates 
     this threat.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 15:25:38 +0100

=> in France you can get VoIP from your ISP so it is in contracts
even for some personal use/millions of subscribers ISPs
(and mine using 6rd I have a fixed /64 IPv6 prefix too).

=> for an ISP DHCP server to lose the year history of leases can
lead to a nearly unbound fine (1500 euros per subscriber) with
one of the last French laws so I am sure ISPs have a solution...
   
Regards