Subject: [BEHAVE] scoping CGN Requirements document

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Mar 2011 12:15:53 -0700

Requirements documents are notoriously difficult, across the industry and
across life in general ("the new bicycle MUST have 24 gears").  There
appears to be considerable scope creep with the CGN Requirements document,
for which I am partially guilty.  My desire is to get this document
published, and I had thought we were close to finishing the document until
Simon's update caused a flurry of new CGN requirements to be considered.

The general theme for the document is that the CGN should be "fair".  That
was the reason for the initial CGN-specific requirement which is that a
subscriber be limited to a certain number of IPv4 ports -- to prevent one
user from denying service to other legitimate users.

Dave and I have discussed the organization of the document in the past, and
the following two tenets seem pretty valuable in scoping the document:

  * if a requirement is specific to a Carrier Grade NAT, it should be a 
    new requirement in the document.  For example, restricting a user
    to a certain number of ports.

  * if a requirement is not specific to a Carrier Grade NAT, it
    should not be a _new_ requirement in the document.  Instead, the
    document should reference an existing requirement.  For example,
    the TCP behavior of a CGN can be described by BEHAVE's existing
    TCP behavior document, RFC5382.  For example, hold-down timers
    is not specific to a CGN (because existing NAPT would have 
    similar or identical requirements), and TCP/25 filtering is not 
    specific to a CGN (as evidenced by ISPs filtering TCP/25 without 
    deploying a CGN).  For example, new logging requirements caused 
    by IPv4 address sharing is well-described by other IETF documents 
    which can be cited.

In addition to the follow-ups on the mailing list from this email, I added
10 minutes to BEHAVE's agenda in Prague to discuss scoping the CGN
Requirements document.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 22 Mar 2011 14:21:46 -0400

I think there are certain nuances that are not clear. It would be good to
discuss in the meeting.

By the very nature of 'Carrier' Grade NAT it means it is not a regular NAT.
Therefore should all previous behave RFCs apply blindly? Or as part of this
process should some be updated to reflect this new type of NAT device?

If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT becomes
a CGN?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Mar 2011 14:27:59 -0400

>From the Terminology section:

   Carrier-Grade NAT (CGN):  NAT device placed between a subscriber and
      the Internet in an ISP's network.  A CGN translates IP addresses
      and transport-protocol port numbers in the packets that it
      forwards across the border between the internal and external
      realms.

This makes it clear that a CPE is not a CGN.

Thanks,
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: "Dan Wing" <[email-masked]>
Date: Tue, 22 Mar 2011 11:41:35 -0700

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Tuesday, March 22, 2011 11:22 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]; draft-ietf-behave-lsn-
> [email-masked]
> Subject: Re: [BEHAVE] scoping CGN Requirements document
> 
> By the very nature of 'Carrier' Grade NAT it means it is not a regular
> NAT.  Therefore should all previous behave RFCs apply blindly? 

No.  We should carefully evaluate which of the requirements apply, and
re-apply them.  Right now, the document effectively says "the requirements
of BEHAVE's UDP, TCP, and ICMP documents SHOULD be followed".  If there
is something more specific (or less specific) for a CGN, it should be 
in the CGN document.

> Or as part of this

Exactly.

> If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT
> becomes a CGN?

A related question, which is why I suggested and really liked the
name "Large Scale NAT", is "does a really large enterprise want or
need the features ascribed to a Carrier-Grade NAT?".  Afterall,
an enterprise with 20,000-30,000 users actively hitting the NAT
is larger than many ISPs.

To your question, the threshold is crossed when there are users
behind the NAT which are separately responsible for their own
Internet activity.  At home, anyone who calls the fire department
from my phone will make me (as the owner of the phone line) 
responsible for the fine for the false phone call.  Once that
changes, it gets into CGN territory.  At least, that's my 
definition for whatever that's worth.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 22 Mar 2011 14:43:39 -0400

Thanks Simon,

Please clarify

A Layer-3 CPE fits this descriptions since it is placed between devices in a
subscriber home and the ISP. Or do you mean a device place between the CPE
and the Internet network?

In the case of managed CPEs or Enterprise NAT, are these CGNs?

If you have a NAT as a cloud service, does that make it a CGN?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Mar 2011 15:45:38 -0400

On 2011-03-22 14:43, Reinaldo Penno wrote:
> subscriber home and the ISP.

...but it's not "in an ISP's network".

See also Figure 1:

                                  .
                                  :
                                  |       Internet
                  ............... | ...................
                                  |       ISP network
                                  |
                                  |
                              ++------++  External realm
                  ........... |  CGN   |...............
                              ++------++  Internal realm
                                |    |
                                |    |
                                |    |    ISP network
                  ............. | .. | ................
                                |    |  Customer premises
                        ++------++  ++------++
                        |  CPE1  |  |  CPE2  |  etc.
                        ++------++  ++------++

                      Figure 1: CGN network topology

If there is a clarification to be made, please let me know so I can fix
the draft.

> In the case of managed CPEs or Enterprise NAT, are these CGNs?

No, because they are not "in the ISP's network".

> If you have a NAT as a cloud service, does that make it a CGN?

Yes it is, according to the draft's definition.

Again, this draft needs to get the definition right. Let me know if it
needs to be changed.

Thanks,
Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 22 Mar 2011 17:23:54 -0400

If the administrative authority extends to the CPE (whether small or large)
it is questionable if it is in the ISP's network or not. Also, the 'CPE' can
be is some co-location connected through a metro Ethernet. It is in the
ISP's network but customer has full control over it.

I think we should avoid topology related definitions of CGN.

One thing seems common across all 'regular' NATs; they  have a single
subscriber behind it. I think a NAT becomes a CGN when it aggregates more
than one subscriber and therefore you have address sharing across
subscribers.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Mar 2011 18:17:16 -0400

> I think we should avoid topology related definitions of CGN.

Sure, as long as we have a better alternative.

> than one subscriber and therefore you have address sharing across

I think I would agree with that, especially if we add some notion of 
"control" that subscribers do or do not have over the NAT.

On terminology issues it is important to be precise. So I ask you to 
please send a concrete proposal (the actual text that would go in the 
draft) that we may discuss further.

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Mar 2011 15:17:20 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Reinaldo Penno
> Sent: Tuesday, March 22, 2011 2:24 PM
> To: Simon Perreault
> Cc: [email-masked]
> If the administrative authority extends to the CPE (whether small or
> large) it is questionable if it is in the ISP's network or not.
> Also, the 'CPE' can be is some co-location connected through a 
> metro Ethernet. It is in the ISP's network but customer has full 
> control over it.
>
> 

Exactly.

Differentiating between who pays for the electricity or who has
administrative privileges isn't what's important.  Rather, it
is if there is more than one entity, with their own bill, 
Terms of Service agreement, installation address, etc.

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 23:22:41 +0100

In your previous mail you wrote:

=> +1   
   
Regards

[email-masked]

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 08:05:21 +0100

Hi Dan, all,

(*) I fully agree a scoping is needed if we want this document to progress but since this is a CARRIER GRADE NAT and not a "normal" NAT in a CPE, some of the requirements as worded in existing behave RFCs should be re-examined: in particular the configuration of the timers is a "MAY" in existing RFCs while in the CGN case this should be at least defined as "SHOULD", etc. 

(*) The current version of I-D is talking about "Carrier-Grade NAT (CGN) devices" which IMO should be avoided. We are not defining the requirement for a device but a "Function" or a "Functional Element".

(*) Basically, a CGN can be defined as "a NAT-based Functional Element operated by an administrative entity (e.g., operator) to share the same address among several subscribers.". 

(*) Because the CGN is operated by an operator, several dimensions may be taken into account as listed below (but the WG may decide to focus only on a subset):

* "Basic" NAT behaviour itself
* Customized NAT: all the configuration specific to the operator: timers, address sharing, shared address pool, exclude some ports from the shared port pool, dedicate address pool for ICMP, port quotas (implicit/explicit), behaviour when the port limit is reached, support of port set, etc.
* "Basic" per-subscriber functions: blacklist a subscriber, differentiated customer profiles, etc.
* Data retention and Legal Intercept requirements: this set of requirements can be elaborated in this I-D but instead a clear statement in the I-D to say this is out of scope can be added.
* Provider-oriented functions: QoS transparency (e.g., DSCP re-marking, prioritization), emergency, resource fair usage, 
* Filtering functions: NAT filtering, inbound (from subscriber-facing) address filtering, inbound port filtering, etc. 
* Requirements to avoid application brokenness: (dynamic) port forwarding, insert host_id, etc. 
* Ensure service availability and reliability during reboot or outage: a CGN is a stateful function. This is provider-specific.
* Operational considerations: graceful restart, graceful shutdown for planned maintenance operations, stable storage, etc.
* Resource optimisation: when several CGN are deployed, an operator need to load balance the traffic among deployed CGNs
* Management functions: behaviour when a subscriber quota is fired, behaviour when a port usage threshold is reached, MIB/YANG modules to be supported 

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : lundi 21 mars 2011 20:16
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : [BEHAVE] scoping CGN Requirements document

-d

---

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

Dear Simon,

I would suggest to update this definition and avoid using the "device" term. CGN is a function and not a device: it can be embedded in existing routers or be deployed in standalone device. 

What about the following proposal:

"Carrier-Grade NAT (CGN): NAT-based [RFC2663] Functional Element operated by an administrative entity (e.g., operator) to share the same address among several subscribers.".

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mardi 22 mars 2011 19:28
À : [email-masked]
Objet : Re: [BEHAVE] scoping CGN Requirements document

Thanks,
Simon

---

From: Dong Zhang <[email-masked]>
Date: Wed, 23 Mar 2011 16:06:31 +0800

>"control" that subscribers do or do not have over the NAT.

+1. The subscriber cann't operate or configure the CGN easily like its HGW or CPE.

What about this based on Med's proposal:

"Carrier-Grade NAT (CGN): NAT-based [RFC2663] Functional Element operated by an administrative entity (e.g., operator) to share the same address among several subscribers. CGN is managed by the administrative entity, not the subscribers".

Thanks.

2011-03-23 

Dong Zhang

---

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

[email-masked] wrote, on 03/23/2011 03:05 AM:
> (*) The current version of I-D is talking about "Carrier-Grade NAT (CGN)
> devices" which IMO should be avoided. We are not defining the requirement for
> a device but a "Function" or a "Functional Element".

Agreed. The next revision will avoid this.

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

---

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

Dong Zhang wrote, on 03/23/2011 04:06 AM:
> "Carrier-Grade NAT (CGN): NAT-based [RFC2663] Functional Element operated by an
> administrative entity (e.g., operator) to share the same address among several
> subscribers. CGN is managed by the administrative entity, not the subscribers".

Unless the WG disagrees, the next revision will include this definition.

Thanks,
Simon