[BEHAVE] RE : CGN REQ: Port Set Assignment

<mohamed.boucadair@orange-ftgroup.com> Tue, 15 March 2011 19:01 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236983A6E61 for <behave@core3.amsl.com>; Tue, 15 Mar 2011 12:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.117
X-Spam-Level:
X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGK61S89RwO0 for <behave@core3.amsl.com>; Tue, 15 Mar 2011 12:01:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id E4BA43A6E77 for <behave@ietf.org>; Tue, 15 Mar 2011 12:00:58 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 017263243A5; Tue, 15 Mar 2011 20:02:24 +0100 (CET)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D4E7523804B; Tue, 15 Mar 2011 20:02:23 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 15 Mar 2011 20:02:24 +0100
From: mohamed.boucadair@orange-ftgroup.com
To: Dan Wing <dwing@cisco.com>, "draft-ietf-behave-lsn-requirements@tools.ietf.org" <draft-ietf-behave-lsn-requirements@tools.ietf.org>
Date: Tue, 15 Mar 2011 20:02:23 +0100
Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment
Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/
Message-ID: <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr>, <12f501cbe341$fe3310d0$fa993270$@com>
In-Reply-To: <12f501cbe341$fe3310d0$fa993270$@com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.165415
Cc: DENG Xiaohong ESP/PEK <xiaohong.deng@orange-ftgroup.com>, "behave@ietf.org" <behave@ietf.org>
Subject: [BEHAVE] RE : CGN REQ: Port Set Assignment
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2011 19:01:21 -0000

Re-

A "Port Set" does not mean necessarily "contiguous port range"!

Both pure randomized port set or Simple port randomization with port sets can be considered.

We have an implementation to assess the behavior of simple port randomization (only two lines of codes are needed to implement it: the algorithm uses the port mask and port value).

Another solution to generate random ports is available at: http://tools.ietf.org/html/draft-bajko-pripaddrassign-03#section-5.

Cheers,
Med


________________________________________
De : Dan Wing [dwing@cisco.com]
Date d'envoi : mardi 15 mars 2011 19:51
À : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@tools.ietf.org
Cc : behave@ietf.org
Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment

> -----Original Message-----
> From: mohamed.boucadair@orange-ftgroup.com
> [mailto:mohamed.boucadair@orange-ftgroup.com]
> Sent: Tuesday, March 15, 2011 11:19 AM
> To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org
> Cc: behave@ietf.org
> Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment
>
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
> ________________________________________
> De : Dan Wing [dwing@cisco.com]
> Date d'envoi : mardi 15 mars 2011 18:55
> À : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-
> requirements@tools.ietf.org
> Cc : behave@ietf.org
> Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment
>
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of mohamed.boucadair@orange-ftgroup.com
> > Sent: Tuesday, March 15, 2011 8:07 AM
> > To: draft-ietf-behave-lsn-requirements@tools.ietf.org
> > Cc: 'behave' <(behave@ietf.org)>
> > Subject: [BEHAVE] CGN REQ: Port Set Assignment
> >
> > Re-,
> >
> > Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn-
> > requirements-01#section-5 discusses various modes for the port
> > assignment but there is no explicit requirement.
> >
> > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?)
> > support the ability to assign port sets.
>
> Why?
>
> Med: We can ask the other question around: why only the dynamic NAT
> should be supported?

Because that's what NATs do today -- NATs in people's homes and
deployed by enterprises do that today.

> More seriously, the use of port set has several advantages in term of
> log reduction and in some implementation(s) has important  impact on
> performances (because of the per-entry write operations). Tests we have
> done for some implementations showed severe degradation. FWIW, some CGN
> implementations support only the port set allocation and the length of
> the port set is even no configurable!

Yes, well aware.

> IMO, the decision to activate the port set or use the dynamic mode
> should left to operators (enterprise, service providers, etc.).

Their incentive is to reduce costs.  But "port sets" (or "bulk port
allocations", or whatever term) increase the attack surface of
the subscribers, with no cost or security risk to the ISP.  The
incentives are in the wrong place.  It's obvious what an ISP
will do -- they will prefer to increase the attack surface of
their subscribers.

Speaking personally (not as chair), I do not support the
IETF making a recommendation that users be restricted to
a fixed set of port numbers.

-d



> -d
>
> > The selection of the dynamic
> > mode vs. port set is deployment-specific.
> >
> > Cheers,
> > Med