[shara] draft-thaler-port-restricted-ip-issues: Host Implementation Issues

<mohamed.boucadair@orange-ftgroup.com> Mon, 01 March 2010 10:35 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA193A7622 for <shara@core3.amsl.com>; Mon, 1 Mar 2010 02:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[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 Inrl+X5FruJ3 for <shara@core3.amsl.com>; Mon, 1 Mar 2010 02:35:57 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 101E03A8544 for <shara@ietf.org>; Mon, 1 Mar 2010 02:35:57 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8EB871346A5; Mon, 1 Mar 2010 11:35:56 +0100 (CET)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7508535C06B; Mon, 1 Mar 2010 11:35:56 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 1 Mar 2010 11:35:56 +0100
From: mohamed.boucadair@orange-ftgroup.com
To: "dthaler@microsoft.com" <dthaler@microsoft.com>
Date: Mon, 01 Mar 2010 11:35:55 +0100
Thread-Topic: draft-thaler-port-restricted-ip-issues: Host Implementation Issues
Thread-Index: Acq5Kvj2gX0kmXnPSxGusAebQamD+g==
Message-ID: <4233_1267439756_4B8B988C_4233_6698_1_94C682931C08B048B7A8645303FDC9F30EFAFF530F@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.1.101228
Cc: "shara@ietf.org" <shara@ietf.org>
Subject: [shara] draft-thaler-port-restricted-ip-issues: Host Implementation Issues
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2010 10:35:58 -0000

Dear Dave,

In your draft, you wrote: "To actually apply a port restriction, host stack implementations
   would need to change.  Without such a change, a host may naturally
   attempt to use the IP address with arbitrary protocols and ports,
   which would be akin to address spoofing in a port-restricted IP
   address model."

For fixed networks, several scenarios for the deployment of port restriction may be considered. Host-based model is one flavour among others.
 
For the CPE-based model, port-restriction features are not required to be supported by the hosts behind the CPE since port-restriction are to be enforced in the CPE: No changes are required for the hosts in such scenario.

For the host-based model (e.g., mobile networks), I agree that port-restriction feature is required to be supported by the host. Some modifications are needed (FYI, port-restriction feature may be activated by entering two IPTABLES lines in Linux-based Oses.). These modifications are to be positioned against expected gains such as:

- Battery consumption for mobile devices because keepalive messages to maintain NAT entries are avoided (in NAT-based solutions, "Always-on" services would impact severely the battery consumption. Not to mention several layers of keepalive messages: e.g., IPsec, SIP )
- No need to embed ALG in intermediary nodes. 
- No need to embed NAT traversal technique in the host
- No latency due to retrieving the perceived IPv4 public address (to be assigned by the NAT)
- Session tracking issues: It is not required to maintain per-session tracking information (legal requirement)
- Etc.  

Cheers,
Med

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************