Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

Tarko Tikan <tarko@lanparty.ee> Tue, 12 November 2013 17:46 UTC

Return-Path: <tarko@lanparty.ee>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78DF21E8141 for <v6ops@ietfa.amsl.com>; Tue, 12 Nov 2013 09:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOhQcq4UFm61 for <v6ops@ietfa.amsl.com>; Tue, 12 Nov 2013 09:46:17 -0800 (PST)
Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) by ietfa.amsl.com (Postfix) with ESMTP id C625521E80C4 for <v6ops@ietf.org>; Tue, 12 Nov 2013 09:44:27 -0800 (PST)
Received: from tuli.elion.ee ([194.126.117.170] helo=[192.168.28.102]) by valgus.lanparty.ee with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <tarko@lanparty.ee>) id 1VgI0m-0007e4-HK for v6ops@ietf.org; Tue, 12 Nov 2013 19:44:25 +0200
Message-ID: <528268F3.8090501@lanparty.ee>
Date: Tue, 12 Nov 2013 19:44:19 +0200
From: Tarko Tikan <tarko@lanparty.ee>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com>
In-Reply-To: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 194.126.117.170
X-SA-Exim-Mail-From: tarko@lanparty.ee
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee)
Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 17:46:25 -0000

hey,

> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.

+1 from me (as an operator) for the concept. This is similar to what I 
plan to deploy but with one exception - we will not do this in the CPE, 
we will do it in the edge routers via subscriber management instead.

This way we can configure it centrally and very easily push new policy 
for certain subscriber when one wants to have "permit any" inbound. For 
us this also follows IPv4 operating model (which might not always be the 
best case but feels like a best case for us).

I'm _not_ saying doing this in the CPE is wrong, this is very typical 
for the cable operators for example - configure everything via modem 
config files delivered on boot. Or for operators who have no subscriber 
awareness in the edge routers. YMMV.

-- 
tarko,
elion.ee