Subject: [BEHAVE] CGN REQ: Hold-down pool

From: <[email-masked]>
Date: Tue, 15 Mar 2011 16:10:58 +0100

Re-,
 
An important missing requirement is the behaviour for the timeouted ports; I refer to this as hold down pool. These ports SHOULD NOT be assigned to new requesting users before the expiration of the hold down timer. The purpose is to prevent users from receiving unwanted traffic.

The hold-down timer and size of the pool should be configurable by the operator.

Cheers,
Med

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 10:56:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, March 15, 2011 8:11 AM
> To: [email-masked]
> Cc: 'behave' <([email-masked])>
> Subject: [BEHAVE] CGN REQ: Hold-down pool
> 
> Re-,
> 
> An important missing requirement is the behaviour for the timeouted
> ports; I refer to this as hold down pool. These ports SHOULD NOT be
> assigned to new requesting users before the expiration of the hold down
> timer. The purpose is to prevent users from receiving unwanted traffic.

Agreed, that should be a requirement.

> The hold-down timer and size of the pool should be configurable by the

Can we make recommendations on the hold down timers for UDP, TCP, 
and ICMP?

-d

> Cheers,
> Med
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 15 Mar 2011 14:32:40 -0500

On 3/15/11 9:10 AM, "[email-masked]"
<[email-masked]> wrote:
> An important missing requirement is the behaviour for the timeouted ports; I
> refer to this as hold down pool. These ports SHOULD NOT be assigned to new
> requesting users before the expiration of the hold down timer. The purpose is
> to prevent users from receiving unwanted traffic.
> 

I agree on this requirement.  It ought to be included in the
lsn-requirements draft as a SHOULD.

Cheers,
-Benson

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 09:56:20 +0100

Re-,

For the RECOMMENDED values, I must admit this is complex because it depends on the address sharing ratio, the actual port usage ratio, etc.

As an SP I would like to have these parameters configurable. We hope with the operational experience we tune these parameters to find a RECOMMENDED value.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 18:57
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] CGN REQ: Hold-down pool

-d

---

From: ssenthil <[email-masked]>
Date: Wed, 16 Mar 2011 05:20:14 -0400

There should be default values for these hold-down timers in the absence of
any configured values. We should not expect the operators to configure these
timeouts to make CGN operational. It may be as simple as no-holddown-timers.

One of the common performance metric that is used to measure a CGN is the
connection setup rate and with the holddown logic that metric will now
largely depend on the value of the hold-down timers.

Senthil

On 3/16/11 4:56 AM, "[email-masked]"
<[email-masked]> wrote:

> 
> Re-,
> 
> For the RECOMMENDED values, I must admit this is complex because it depends on
> the address sharing ratio, the actual port usage ratio, etc.
> 
> As an SP I would like to have these parameters configurable. We hope with the
> operational experience we tune these parameters to find a RECOMMENDED value.
> 
> Cheers,
> Med
> 
> 
> À : BOUCADAIR Mohamed OLNC/NAD/TIP;
> [email-masked]
> Cc : [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 09:49:04 -0400

On 2011-03-15 11:10, [email-masked] wrote:
> assigned to new requesting users before the expiration of the hold
> down timer. The purpose is to prevent users from receiving unwanted
> traffic.
> 

Ok it seems we have consensus to add this.

We need to figure out what the default values will be.

Proposal:
- TCP: 2*MSL
- UDP: 0 seconds
- ICMP: 0 seconds

For UDP and ICMP, there is no point in adding to the normal mapping
expiration lifetime. When the mapping expires it already means that
there was no traffic on it for the last X seconds.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 15:31:24 +0100

Re-,

For the UDP don't forget the case of incoming connections (e.g., SIP INVITE message is received just after a PCP-instructed mapping expired.). We need a safety timer for UDP also.

BTW, in addition to the timers, we need to consider also the pool size.

Cheers
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 16 mars 2011 14:49
À : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Hold-down pool

Proposal:
- TCP: 2*MSL
- UDP: 0 seconds
- ICMP: 0 seconds

Simon

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Mar 2011 16:37:03 +0200

> there was no traffic on it for the last X seconds.

I don't get the need for hold-down. If you assume that the binding timeout protects UDP and ICMP from late packets (i.e., it's > 2*MSL) why is this not also effective for TCP?

Or do you assume that the binding timeouts will be much shorter than 2*MSL? In that case, introducing a hold-down timer that needs tuple state doesn't seem to really save memory compared to simply using longer binding timeouts.

What am I missing?

Thanks,
Lars

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 11:27:51 -0400

On 2011-03-16 10:31, [email-masked] wrote:
> For the UDP don't forget the case of incoming connections (e.g., SIP
> INVITE message is received just after a PCP-instructed mapping
> expired.). We need a safety timer for UDP also.

Hmmm... I was assuming that the CGN had inbound mapping refresh (REQ-6a
in RFC4787).

I guess the same reasoning equally applies to ICMP.

What do you suggest instead of zero?

> BTW, in addition to the timers, we need to consider also the pool

I don't quite understand the "pool" concept. What happens when the
number of ports in hold-down is larger than the pool size?

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 08:39:20 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, March 16, 2011 1:56 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] CGN REQ: Hold-down pool
> 
> 
> Re-,
> 
> For the RECOMMENDED values, I must admit this is complex because it
> depends on the address sharing ratio, the actual port usage ratio, etc.

I don't think so.

There is a safe minimum that we can recommend, and justify why.

Otherwise, when IPv4 addresses get expensive and/or users need more
ports, ISPs will "fix" the problem by cranking down the hold timer
from NNN seconds to NN seconds to N seconds.

> As an SP I would like to have these parameters configurable. We hope
> with the operational experience we tune these parameters to find a
> RECOMMENDED value.

I don't think the SP is well-placed to actually gain that operational
experience.  I doubt anyone will call their ISP when their TCP
session is corrupted due to aggressive timers.  What is the ISP's 
ability to receive operational feedback from the harm caused to
users?

Take an extreme -- set the value to 0.  Even with such a short 
value, many, many TCP sessions will be fine because the seq/ack
numbers will not overlap (see Benson's post on that which 
pointed out).  A few will get corrupted.  How is the ISP going
to monitor/avoid that, or get told about it?

-d

> down
> > The hold-down timer and size of the pool should be configurable by
> the
> > operator.
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 16:47:39 +0100

In your previous mail you wrote:

   Proposal:
   - TCP: 2*MSL
   - UDP: 0 seconds
   - ICMP: 0 seconds

=> this suggests to make a different between protocols,
IMHO it is simpler to have one hold-down timing (of 120s).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 17:06:25 +0100

What am I missing?
   
=> logging: the hold-down protects lookups in the log against clock skew.

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 16 Mar 2011 13:55:18 -0400

If the hold-down for TCP is 120 seconds at a rate of, say, 250k ports per
second, you will have on average 250K*120 seconds = 30M ports unavailable
until the next 120 seconds window.

30M ports is roughly equivalent to 500 public addresses.

If the rate goes up to 1M ports per second...well you get the picture. For
ISPs trying to save address and stay in business it becomes quite a burden.

Then there is an added Req to not use a pool in certain situations - pool
hold time.

Now an ISP needs to have 3x the number of public addresses.

On 3/16/11 6:49 AM, "Simon Perreault" <[email-masked]> wrote:

>> the operator.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 12:59:25 -0700

> Behalf Of Reinaldo Penno
> Sent: Wednesday, March 16, 2011 10:55 AM
> To: Simon Perreault; [email-masked]
> Subject: Re: [BEHAVE] CGN REQ: Hold-down pool
> 

And then double that to meet the current text for the cold-standby 
requirement.

The incentives to do the wrong thing are in the wrong place; the ISP
will choose smaller values (to conserve IPv4 addresses) and harm
user sessions.  We need ways to align these goals, as much as
possible.

Same problem occurs with stateful NAT64, of course.

-d

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 07:35:29 +0100

Dear Simon

The rationale behind the pool is to prevent all/majority of your ports be unusable because tagged as hold-down port. We need a means to control the amount of port to be put in that pool; hence the need to configure a pool size.

As for the UDP timers, I agree with Francis to have one value for TCP/UDP. I have no magic value so far.

Cheers,
Med 

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 16:28
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Hold-down pool

Simon

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Mar 2011 15:40:43 +0100

=> I don't buy your argument because it proves 120 seconds are already
too large for the lifetime of established TCP connections, BTW:
 - 120 is really too short and will break applications (I have the
  proof of this)
 - RFC 5382 REQ-r says 2 hours 4 minutes: this is obviously too large
  and I found firewalls which have shorter lifetimes.

Nevertheless I propose to keep 120 seconds but as a default, the hold
down timer could be any value between 0 (i.e., hold-down disabled) and
a reasonable maximum (I've just looked at my code and I put 600).

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 17 Mar 2011 14:04:11 -0400

I think you are talking about idle timeout.

The Hold-down is the time the port can not be re-used for another session
after FINs have been received from both sides. It has nothing to do with
idle or session timeout

Thanks,

Reinaldo

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 17 Mar 2011 16:41:08 -0500

During normal operation, a flow reuse hold-down timer makes sense.  However,
there are cases where the CGN might benefit from reducing or ignoring the
timer.  And the potential for negative effects isn't bad enough to forbid
that behavior.  Thus, a hold-down timer cannot be a MUST requirement - it
ought to be a SHOULD requirement.

Further, if I recall correctly in your original note on the topic, you
applied this hold-down timer to "state loss" events such as reboots and
failures.  And I believe you conclude that a backup address pool is
required.  I disagree.  By making the hold-down timer a requirement, the CGN
is faced with either (a) reserving an address pool for use following
state-loss events, wasting those resources during normal operations, or (b)
forcing downtime for the hold-down period of time following a state loss
event.  We can avoid this situation entirely by just not making it a
requirement.

My input is to make hold-down timers a SHOULD requirement during normal
operations, with some text commenting about state loss events.  Perhaps,
include a MAY statement allowing for reserved address pools to cope with
these state loss events.  And leave the details up to each implementation.

Cheers,
-Benson

On 3/17/11 1:35 AM, "[email-masked]"
<[email-masked]> wrote:

> The rationale behind the pool is to prevent all/majority of your ports be
> unusable because tagged as hold-down port. We need a means to control the
> amount of port to be put in that pool; hence the need to configure a pool
> size.
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Mar 2011 20:12:00 -0400

> amount of port to be put in that pool; hence the need to configure a pool

Understood.

I have one further question: is this CGN-specific?

The hold-down functionality seems to me like it would apply to any NAT.

The hodl-down pool size limit seems to me like it would be CGN-specific, as a
DoS-prevention mechanism.

Am I right?

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org