Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt

From: [email-masked]
Date: Thu, 18 Aug 2011 07:04:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Common requirements for Carrier Grade NAT (CGN)
	Author(s)       : Simon Perreault
                          Ikuhei Yamagata
                          Shin Miyakawa
                          Akira Nakagawa
                          Hiroyuki Ashida
	Filename        : draft-ietf-behave-lsn-requirements-03.txt
	Pages           : 18
	Date            : 2011-08-18

   This document defines common requirements for Carrier-Grade NAT
   (CGN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03.txt

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Aug 2011 10:08:58 -0400

This revision incorporates the changes discussed during the Quebec
meeting as well as shortly afterwards on the mailing list. Here's the
change log:

   o  Added exceptions for which it is not necessary to wait 120 seconds
      before reusing a port.

   o  Renamed "random port set" to "scattered port set", which is more
      accurate.

   o  Log "subscriber identifier" instead of internal address+port to
      allow for overlapping internal address ranges (DS-Lite).

   o  Adjusted logging text and added reference to I-D.boucadair-pppext-
      portrange-option.

   o  Adjusted destination logging text for bulk port allocation
      schemes.

   o  Removed requirement for I-D.ietf-intarea-ipv4-id-update.

   o  Made PCP support a SHOULD-level requirement.

   o  Lowered the level of requirement for not dropping existing
      mappings in order to "make room" to SHOULD level, and added
      rationale.

We think this is now ready for WGLC.

Simon

On 2011-08-18 10:04, [email-masked] wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
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: Fri, 19 Aug 2011 15:58:37 +0200

Dear Simon,

This version is much better than the -01; I didn't had a chance to read -02.

Some quick comments:

* Port randomization should be supported by default. The current text only discusses it for the port set case.
* Some discussion on the external IP address pool is imho needed; in particular to mention the external IP address pool is not necessary contiguous. BTW, external address pool should be defined.
* Add a reference to RFC4963 (e.g., in the security considerations section)

Thanks,
Cheers
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : jeudi 18 août 2011 16:09
À : [email-masked]
Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Aug 2011 10:21:06 -0400

> only discusses it for the port set case.

I agree, but this is not specific to CGNs. Any NAT should do proper port
randomization. What's different with CGNs is that you have multiple
subscribers competing for the same resources, and so you have to ensure
fairness. The security aspect of port randomization is the same.

So I suggest that we add this to
draft-penno-behave-rfc4787-5382-5508-bis instead.

Some further notes on this: port randomization on a NAT isn't as easy
(to specify) as on a host. There are a number of features that a NAT may
or should implement. See RFC 4787 sections 4.2. So we'll have to think
about it some more.

> * Some discussion on the external IP address pool is imho needed; in
> particular to mention the external IP address pool is not necessary
> contiguous. BTW, external address pool should be defined.

Can you please suggest some text? I'm not sure what needs to be said.

> * Add a reference to RFC4963 (e.g., in the security considerations

Will do.

Thanks,
Simon

---

From: <[email-masked]>
Date: Mon, 22 Aug 2011 10:55:31 +0200

Dear Simon,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : vendredi 19 août 2011 16:21
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt

Med: This makes sense but do you suggest to add a ref to draft-penno-behave-rfc4787-5382-5508-bis?

Med: Below a text proposal:

   The CGN function is required to be configured with a set of IPv4
   addresses, denoted as external IPv4 address pool.  The CGN function
   SHOULD NOT have any pre-requisite on the size neither the contiguity
   of the external IP address pool.  In particular, the CGN function
   SHOULD be able to be configured with contiguous and non-contiguous external IPv4
   addresses. The pool of external IP addresses MUST be routable.

Will do.

Med: Thanks.

---

From: <[email-masked]>
Date: Mon, 22 Aug 2011 11:01:28 +0200

Re- 

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : vendredi 19 août 2011 16:21
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-03.txt

Med2: Instead of adding a pointer to draft-penno-*, the following text:

   "This document builds upon previous works describing requirements for
   generic NATs [RFC4787][RFC5382][RFC5508].  These documents still
   apply in this context.  What follows are additional requirements, to
   be satisfied on top of previous ones."

can be updated to something like the following:

"  This document builds upon previous works describing requirements for
   generic NATs [RFC4787][RFC5382][RFC5508].  These documents, and their updates if any, still
   apply in this context.  What follows are additional requirements, to
   be satisfied on top of previous ones."

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Aug 2011 06:41:36 -0400

> Med: This makes sense but do you suggest to add a ref to draft-penno-behave-rfc4787-5382-5508-bis?

No. The suggestion in your other mail makes perfect sense to me.

>    addresses. The pool of external IP addresses MUST be routable.

Thanks. Unless the working group disagrees, this will be in the next revision.
(But I will wait after WGLC to produce this new revision.)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Aug 2011 06:42:30 -0400

>    be satisfied on top of previous ones."

Makes perfect sense.

Thanks,
Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 25 Aug 2011 16:51:51 -0400

Hello, 

Some comments on this draft.

1 -

"   REQ-3:  A CGN SHOULD limit the number of external ports (or,
           equivalently, "identifiers" for ICMP) that are assigned per
           subscriber.

--- snip ----

           C.  Additionally, it is RECOMMENDED that the CGN include
               administrator-adjustable thresholds to prevent a single
               subscriber from consuming excessive CPU resources from
               the CGN (e.g. rate limit the subscriber's creation of new
               mappings).
"

I do not agree that CPU consumption is related to number of external ports.
As the last sentence clarifies, the number of sessions per second is what is
important and not absolute number. Therefore I suggest changing the wording
on REQ-3 to read

...limit the number or rate of...

2 - 

   REQ-4:  A CGN SHOULD limit the amount of state memory allocated per
           mapping and per subscriber.  This may include limiting the
           number of TCP sessions, the number of filters, etc.,
           depending on the NAT implementation.

This seems a superset of REQ-3

But more to the point, I'm not sure this belongs in the draft because there
are cases it is not needed:

- Some other device in the network performs this function - without any NAT
associated with it

- No SLA exists or should be expected by subscribers. Therefore this
function is not needed.

3 -

  REQ-6:  It is RECOMMENDED that a CGN have an "Endpoint-Independent
           Filtering" behavior.

   Justification:  This is a stronger form of REQ-8 from [RFC4787].  An
      "Address-Dependent Filtering" behavior is NOT RECOMMENDED.  This
      is based on the observation that some games and peer-to-peer
      applications require EIF for the NAT traversal to work.  In the
      context of a CGN it is important to minimise application breakage.

I suggest we reword to say that EIF is recommend for those applications and
not a blanket statement saying it is always recommended. Otherwise there is
no problem with Address-Dependent Filtering.

The security considerations discussed in 4787 are important. EIF opens a
security hole and therefore that text needed to be copied here or referenced
since there are CGN deployments where security is the more important
consideration.

4 - 

  REQ-12:  When a CGN is unable to create a mapping due to resource
            constraints or administrative restrictions (i.e. quotas)...
..

            D.  and it SHOULD NOT delete existing mappings in order to
                "make room" for the new one.

Unless the quota per subscriber was, say, 400, but the configuration changed
to 200. But a user has 300 ports. Those extra 100 ports can be reclaimed to
make room. Or not?

Thanks,

Reinaldo

On 8/18/11 7:04 AM, "[email-masked]" <[email-masked]>
wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Behavior Engineering for
> Hindrance Avoidance Working Group of the IETF.
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 31 Aug 2011 10:16:42 -0400

> ...limit the number or rate of...

I don't understand your point.
- The finite resource being protected by REQ-3 is external ports.
- The finite resource being protected by REQ-3-C is CPU cycles.
REQ-3-C is worded very generally so that any CPU-consuming operation needs to be
limited, and the rate of mapping creation is given as an example. So this all
seems to agree with what you said.

> This seems a superset of REQ-3

- The finite resource being protected by REQ-3 is external ports.
- The finite resource being protected by REQ-4 is memory.
These are very different requirements.

> - No SLA exists or should be expected by subscribers. Therefore this

I don't understand. NATs create state, which uses memory, a finite resource.
CGNs are NATs that are shared my multiple subscribers that might be competing
for the same finite resource. Therefore this operator needs a way to ensure
fairness. This principle, fairness, is the cornerstone of this document, and has
been agreed upon by the WG from the start. It is in the interest of the Internet
that subscribers are allowed a fair share of resources.

> no problem with Address-Dependent Filtering.

I agree that we need to add text to identify the exceptions to the
recommendation. In light of the RFC2119 discussion on [email-masked], we need to
adopt the SHOULD...UNLESS... pattern. How about something like:

It is RECOMMENDED that a CGN have an "Endpoint-Independent Filtering" behavior
UNLESS it is known that "Address-Dependent Filtering" does not cause the
application layer protocol to break.

And I would remove the "An "Address-Dependent Filtering" behavior is NOT
RECOMMENDED." part because it is redundant.

How about that?

> since there are CGN deployments where security is the more important

Agreed, will do.

> to 200. But a user has 300 ports. Those extra 100 ports can be reclaimed to

I suppose they can. This requirement applies to implicitly-created mappings
(e.g. with a TCP SYN), not to operator intervention. I'll make that clear in the
next revision.

Thanks,
Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 31 Aug 2011 14:22:19 -0400

First of all let me clarify that I'm not against this requirement per se but
I think we should give room for the market to play out instead making
'policy' - as in 'market regulation'.

IMO ports is just like bandwidth, a shared resource. Both are very
important. There are ISPs that provide some minimum bandwidth guarantees on
their network for each sub. Some say you will get 'up to X-Mbps', which
theoretically could be zero.

Therefore my suggestion is that "...a CGN box SHOULD _support_ the ability
to provide a fair share of ports across subscriber..." but it is up to the
ISP to turn it on and how much.

Maybe there is an ISP that leverage the statistical multiplexing of ports
coming and going and charges $5 per month.

Another ISP guarantees at least 100 ports and charges $15.

The subscriber is free to choose whatever it prefers.