Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

Fernando Gont <fgont@si6networks.com> Mon, 01 April 2013 17:59 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD161F0D26; Mon, 1 Apr 2013 10:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.474
X-Spam-Level:
X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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 dxYYQn2uIUui; Mon, 1 Apr 2013 10:59:50 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7216C1F0D22; Mon, 1 Apr 2013 10:59:50 -0700 (PDT)
Received: from [186.134.3.135] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <fgont@si6networks.com>) id 1UMj1H-0003a4-4e; Mon, 01 Apr 2013 19:59:48 +0200
Message-ID: <515985E1.1000404@si6networks.com>
Date: Mon, 01 Apr 2013 10:04:33 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com> <51559943.1010703@gmail.com>
In-Reply-To: <51559943.1010703@gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: opsec@ietf.org, ietf@ietf.org
Subject: Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 17:59:51 -0000

Brian,

On 03/29/2013 10:38 AM, Brian E Carpenter wrote:
> 
> My minimal request for this draft is for my name to be removed from
> the Acknowledgements, as I do not think that my comments have been
> acted on.

That has been my intent, and I sent a note before publishing one of the
latest revs to double-check that (not sure if I missed your respond, or
you didn't respond).


> In fact, I think that in its current state, this document is harmful
> to IPv6 deployment. It in effect encourage sites to fence themselves
> into an IPv4-only world. Particularly, it explicitly suggests a
> default/deny approach to IPv6-in-IPv4 tunnels, which would prevent
> the typical "baby steps" first approach to IPv6 deployment.

Sites that implement any kind of security policy employ a "default deny
policy" (for the simple reason that it's safer to open holes than
explicitly close them). The bottom-line is that if your site enforces
any kind of security policy, you should make an explicit decision
regarding what you do with v6, rather than being unaware that it's there
in your network.



> I would like to see the document convey a positive message, suggesting
> that an IPv4 site first decides which IPv6 deployment mechanism it
> will use, and then configures security appropriately (to allow that
> mechanism and block all others).

There's an operational gap here: in many cases, operators have no tools
to enforce security policies on such tunneled traffic.

Besides, when thinking about v6, enterprise networks and the like should
be doing native IPv6 (in which case v6 security controls would be
enforced throughout the network), rather than having each node go their
own way.


> A specific aspect of this is that if a site provides one well-managed
> 6in4 tunnel mechanism, all tunneled IPv6 packets will pass through
> well-defined points where security mechanisms may be applied.

In which case you'd be "enforcing IPv6 security controls", which is
entirely in-line ith what this document is saying.


> We shouldn't imply that not having an IPv6 plan and blocking all IPv6
> by default is a sound strategy.

It's not, and I don't think we're implying that. However, I'd note that
some people are in the position of blocking traffic, or not doing
anything about it. Check for IPv6 support in different security
products, and you might get depressed.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492