Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

Owen DeLong <owen@delong.com> Fri, 09 August 2013 19:27 UTC

Return-Path: <owen@delong.com>
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 8377D11E817C for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2013 12:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 RxKHgfnAyuJe for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2013 12:27:50 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FC11E8175 for <v6ops@ietf.org>; Fri, 9 Aug 2013 12:21:35 -0700 (PDT)
Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r79JHLdg019217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 12:17:21 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r79JHLdg019217
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376075841; bh=PHNtEaFFh40X/jlD1JpSKfEyqdE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=3iZtIK2LZlqhuDoyuyTxMSb0LHoXrfgMtGxOYXlUyxdrson3RBb6PViYD8DtRzXDj WO93V86mMqEIlxfNTSpsmKdcp//GHANl/+EVMm3+swXWuM9CYkxPZ5VDGz21tjrklc MNQbW7x/AmLQd8PLP62PzUDdmqyuqJYVutmhChSk=
Content-Type: multipart/alternative; boundary="Apple-Mail=_B99E2586-CD61-405F-8596-0ED2DF59D622"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CA6D42D0F8A41948AEB3864480C554F104AE7A3F@xmb-rcd-x10.cisco.com>
Date: Fri, 9 Aug 2013 12:17:23 -0700
Message-Id: <C00B4018-6FEE-441C-B807-B1126101CE6D@delong.com>
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <CAKD1Yr13GK_cuvkt2LpJ1qJo2NR8eUnY-xfwMF_zWfe0P1mm9g@mail.gmail.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <CAKD1Yr2_d=4uD1W4WcQ82rupjVJ4UmmQAQmtSY+aQgTXmscNUw@mail.gmail.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> <CA6D42D0F8A41948AEB3864480C554F104AE7A3F@xmb-rcd-x10.cisco.com>
To: Arie Vayner (avayner) <avayner@cisco.com>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 09 Aug 2013 12:17:21 -0700 (PDT)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 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: Fri, 09 Aug 2013 19:27:55 -0000

On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) <avayner@cisco.com> wrote:

> Another loosely related point that I think could make sense in such a document would be the ways to accomplish multi-homing and how it is different than today’s IPv4 implementations.
>  
> Many enterprises rely on NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4.
>  
> If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers.
> Traffic leaving from an Internet gateway site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)

Or stateful firewalls have to get better about sharing state. There are two things that can help with this...

1.	Put your firewalls as close to the end systems they protect as possible. Make your security zones relatively small and place the firewalls closer together at those narrower borders.
	This will often require more firewall units, but it helps in a number of ways:
	A.	Firewall policy tends to be much simpler (and as a result less error prone and more reliable)
	B.	The hardware demands on the firewall tend to be lower so you can buy cheaper units.
	C.	The simpler rulesets can be more easily tailored to meet business requirements as they evolve.

2.	Improve firewalls. Give the firewalls that all protect the same boundary a way to mesh-peer with each other and exchange information about the state tables such that triangle routing is no longer problematic.

> Syncing upstream and downstream routing policies is not always an easy task (but could be relevant in some cases).
> Linking the Internet gateway layer across sites (before hitting the stateful security layer) could be another solution.

If we make the changes above to the firewalls, this could be  a lot less relevant in most cases.

> Do you think a short discussion to raise awareness for this potential issue could be relevant in such a document?

It's certainly worth documenting. I'm not sure whether it belongs in this document or not.

Owen