Subject: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification)

From: <[email-masked]>
Date: Wed, 16 Mar 2011 10:28:23 +0100

Dear authors,

The requirement I-D needs to specify the behaviour of the CGN when there are no available ports or when the per-subscriber quota is reached. 

The requirement can elaborate on the behaviour of the CGN such as the following (only as example):

If a (transport) protocol-specific state limit is configured or when there is no available free port, no binding for in-excess traffic must be instantiated in the CGN; in addition: 

* appropriate log events should be recorded
* ICMP message should be sent back to the requesting client (e.g., ICMP messages type 3 code 13)
* a notification (e.g., SNMP trap) towards a management system is be issued
* etc.

Cheers,
Med

---

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

> * ICMP message should be sent back to the requesting client (e.g., ICMP messages type 3 code 13)

Not sure about code 13. How about 0 instead?

> * a notification (e.g., SNMP trap) towards a management system is be issued

Unless the WG disagrees, I will add this.

I would also specify that the CGN MUST NOT terminate existing mappings
in order to "make room".

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: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 16 Mar 2011 16:11:21 +0200

On Wednesday 16 March 2011 11:28:23 ext [email-masked], 
you wrote:
> Dear authors,
> 
> The requirement I-D needs to specify the behaviour of the CGN when there
> are no available ports or when the per-subscriber quota is reached.
> 
> If a (transport) protocol-specific state limit is configured or when there
> is no available free port, no binding for in-excess traffic must be
> instantiated in the CGN; in addition:
> 

There's two situations where a user can run out of port. Either (s)he is evil 
and trying to mount a denial of service, or it legitimately requires a lot of 
concurrent flows toward the same remote IP address.

If the user is evil, I would rather not send an ICMP message at all.

If the user is not evil, I would rather drop the packet and cross my fingers 
that one port will be freed soon enough that upper-layer (transport or app) 
retransmits will succeed in getting a port allocated. I believe applications 
will cope better with that, than with ICMP errors

Think of the stereotypical case of a we browser establishing a LOT of HTTP 
connections to a server while viewing several pages with lots of images and 
AJAX and what not. Waiting for retransmit will slow down the browser. Sending 
ICMP errors (or TCP resets) will cause user-visible failures on the other 
hand.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

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

Dear Rémi,

When port quota are configured, there is no much value to differentiate the customers (evil or not); it is more simple to have a system-wise configuration. 

Applications may evolve in the future to use the returned ICMP message and to adapt their behaviours accordingly. 

BTW, I'm fine with having the ability to enable/disable this ICMP function.

Cheers,
Med 

-----Message d'origine-----
De : Rémi Denis-Courmont [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 15:11
À : [email-masked]
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification)

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 10:32:52 -0400

> will cope better with that, than with ICMP errors

Agreed.

This is very similar to what happens when a normal router exceeds its
capacity: it drops the packet. This is congestion. TCP is built on the
assumption that packet loss equals congestion. We should not interfere
with that.

I think that argument would be strong enough to warrant the contrary: a
CGN MUST NOT send an ICMP message when it has no ports left.

Simon

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 16 Mar 2011 16:39:21 +0200

On Wednesday 16 March 2011 16:26:54 ext [email-masked], 
you wrote:
> Dear Rémi,
> 
> When port quota are configured, there is no much value to differentiate the
> customers (evil or not); it is more simple to have a system-wise
> configuration.

Yeah? So what?

I wrote that, regardless of the evilness or not of the user, it was best to 
not send ICMP errors (albeit for different reasons).

> to adapt their behaviours accordingly.

That's a silly assumption. Evolved applications will learn (if they have not 
already done so) to not make excessive connections to the same peer, and they 
will learn to do IPv6.

So this is all about existing contemporary applications. And I claim that not 
sending ICMP errors works better in that case.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

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

In your previous mail you wrote:

   in addition: 
   
   * ICMP message should be sent back to the requesting client (e.g.,
  ICMP messages type 3 code 13)

=> not so clear: usually it is never a good idea to send an ICMP and
in this case 3/13 was designed for a permanent condition.
So IMHO a SHOULD is not the right thing, I prefer a MAY or
alternatively I suggest to implement the MAY switch of RFC 1812
to disable 3/13 sending and to make it 'disable' by default...

Regards

[email-masked]

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rémi Denis-Courmont
> Sent: Wednesday, March 16, 2011 7:11 AM
> To: [email-masked]
> Cc: ext [email-masked]; draft-ietf-behave-lsn-
> [email-masked]
> Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is
> reached (ICMP notification)
> 
> ICMP errors (or TCP resets) will cause user-visible failures on the
> other hand.

So you are saying you disagree with

  http://tools.ietf.org/html/rfc5508#section-6

-d

> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

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

Agreed. I understand per Dan's email that there is some history on this (
http://tools.ietf.org/html/rfc5508#section-6), but I always wondered in the
original RFC people took into account 'evil' users, applications coping with
that, flooding users that have quotas with ICMP messages, etc.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 18:37:52 -0700

> Behalf Of Reinaldo Penno
> Sent: Wednesday, March 16, 2011 3:36 PM
> To: Simon Perreault; [email-masked]
> original RFC people took into account 'evil' users, applications coping
> with that, flooding users that have quotas with ICMP messages, etc.

ICMP code 13 is supposed to be a soft error, which has no effect on TCP,
  http://tools.ietf.org/html/rfc5461#section-2.2
However, at the moment I cannot find where code 13 was defined as a soft
error.

-d

---

From: ssenthil <[email-masked]>
Date: Thu, 17 Mar 2011 02:11:09 -0400

> in this case 3/13 was designed for a permanent condition.

Can you point me to some documentation on code 13 being a permanent
condition (hard error)? In the past there were a lot of discussions
surrounding code 13 (related to rfc5508) and I don't believe that code 13
was spelled out as a hard error.

---

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

=> +1
I disagree too: ICMP 3/13 should be sent only for administrative
restrictions, and not for resource constraints.
BTW as I said you MAY have a switch to disable ICMP 3/13 so
you can use this to lower the SHOULD, and as we are talking about
NATs this should do exactly what I want (:-).

Regards

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 16:15:53 +0100

Francis,

Please see inline.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : jeudi 17 mars 2011 16:07
À : Dan Wing
Cc : [email-masked]; [email-masked]; BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification)

   
   
=> +1

Med: Which is the case when the port quota/limit is reached, no?

---

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

condition (hard error)?

=> I don't say permanent condition == hard error (in fact 3/13 was
designed before the texts about soft vs hard errors).
IMHO it is just what the description means: "administratively" is not
likely used for a something very transient.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Mar 2011 17:23:42 +0100

=> no, administrative restrictions mean firewall-like rules
(3/13 was clearly designed for firewalls BTW).

Regards

PS: what matters is what a user would believe when the connection
fails because of 3/13.  I don't think there is a doubt about the
'Communication Administratively Prohibited' message but in fact I
haven't checked what usual OSs return (I am afraid it would be
some kind of 'network unreachable').

---

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

>   http://tools.ietf.org/html/rfc5508#section-6

Well, that settles it. RFC5508 specifies exactly what any NAT (including CGNs)
should do when a port quota is reached: send an ICMP unreachable with code 13.

Disagreement with this rule need to go into an RFC5508-bis. This is now out of
scope for CGN requirements.

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

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 26 Mar 2011 22:56:07 -0400

> Well, that settles it. RFC5508 specifies exactly what any NAT (including CGNs)

'Any' NAT at that time did not include CGN (address sharing). Regular NATs
do not need to deal with address sharing (which is the basis of CGN
definition). It seems clear throughout all examples in previous BEHAVE RFCs
that this was not in the radar.

> scope for CGN requirements.

I believe we should strive to reuse previous RFCs recommendations but
because of the very nature of CGN we can not just get them all.

---

From: Simon Perreault <[email-masked]>
Date: Sun, 27 Mar 2011 11:27:15 +0200

> that this was not in the radar.

Of course, since those RFCs predate the draft we are now discussing.

> because of the very nature of CGN we can not just get them all.

Are you suggesting that we should "pick and choose" requirements from RFC 5008?

I suppose we could do that, but only if there is CGN-specific justification. So
far all I've heard about this issue applied to all NATs.

Thanks,
Simon