Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03

Rémi Després <remi.despres@free.fr> Wed, 27 August 2008 11:53 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2DA3A6C26 for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 27 Aug 2008 04:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.205
X-Spam-Level:
X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 uQZRM0g4-aNk for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 27 Aug 2008 04:53:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B50E33A6C12 for <v6ops-archive@lists.ietf.org>; Wed, 27 Aug 2008 04:53:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KYJWo-000Imy-77 for v6ops-data@psg.com; Wed, 27 Aug 2008 11:49:34 +0000
Received: from [212.27.42.65] (helo=smtp8-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <remi.despres@free.fr>) id 1KYJWk-000ImI-Ib for v6ops@ops.ietf.org; Wed, 27 Aug 2008 11:49:32 +0000
Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id B9FD532A7E3; Wed, 27 Aug 2008 13:49:29 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id 2CA1D32A8A7; Wed, 27 Aug 2008 13:49:28 +0200 (CEST)
Message-ID: <48B53F07.2090807@free.fr>
Date: Wed, 27 Aug 2008 13:48:23 +0200
From: Rémi Després <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: teemu.savolainen@nokia.com
CC: rdenis@simphalempin.com, v6ops@ops.ietf.org
Subject: Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03
References: <20080824204553.08131c65.ipng@69706e6720323030352d30312d31340a.nosense.org> <48B1CCE8.1070305@gmail.com> <01af01c9065b$b4602440$c2f0200a@cisco.com> <48B23391.1090503@gmail.com> <01cd01c90672$a57c8790$c2f0200a@cisco.com> <48B31DA3.6080001@gmail.com> <07d201c906f7$50a85e30$c2f0200a@cisco.com> <48B32B43.5010103@gmail.com> <084c01c906fe$f9bf1840$c2f0200a@cisco.com> <48B33430.40704@gmail.com> <08b901c90710$4064aa60$c2f0200a@cisco.com> <48B354FA.7040601@gmail.com> <48B50B10.9090005@free.fr> <f0913a34d402b6a4d25787bab3eea17b@chewa.net> <DC237AE116C10E4C9AD162D6C2EE62FE0106AF6D@vaebe102.NOE.Nokia.com>
In-Reply-To: <DC237AE116C10E4C9AD162D6C2EE62FE0106AF6D@vaebe102.NOE.Nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

teemu.savolainen@nokia.com   (m/j/a) 8/27/08 12:46 PM:
>>> I also support that remote control of packet filtering should be
>>> standardized.
>>> IMO, its scope should cover both:
>>> - CPE control by hosts
>>> - control of ISP provided filtering devices by customer sites.
>> I have to disagree. An ISP is not supposed to do filtering in the first
>> place.
>>
>> Also, in real life, filtering by ISP is typically one of:
>>
>> - NAT contingency, in which case it cannot be controlled directly,
>> - not meant to be controlled by the user
>>  (e.g. blocking SMTP, NetBIOS, or other protocols, spoof 
>> protection...)
> 
> In cellular environments filtering of the downlink carbage to increase battery lifetime of handhelds is an important function.
> 
> However, if the firewall is there to save batteries and not to enforce any special policies, it might be more willing to be controlled?

I support this last point.

Indeed, if a cell phone would open just a few (address,port) couples, 
possibly none, for incoming connections, and would have this enforced by 
its service provider, it would be much better protected against battery 
exhaustion due to malevolent (address,port) scanning.

A protocol that at least achieves this level of protection is IMO needed.

Regards,

RD