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

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Tue, 13 August 2013 04:54 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 7DC3921F9EC4 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 21:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=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 GTslqm-HDgiD for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 21:54:34 -0700 (PDT)
Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with ESMTP id F1E6821F9E33 for <v6ops@ietf.org>; Mon, 12 Aug 2013 21:54:33 -0700 (PDT)
Received: from [98.139.215.140] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 04:54:25 -0000
Received: from [98.139.212.248] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 04:54:25 -0000
Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 04:54:25 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 29385.2094.bm@omp1057.mail.bf1.yahoo.com
Received: (qmail 74506 invoked by uid 60001); 13 Aug 2013 04:54:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376369664; bh=FNX5vDsG72zH8E2Vf3wXhziEXLrf37GpRSjni5ySBRU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AyVGsUqLTFyhA9Mpu+GfLM/oYOGGRLFs1gbtQRuFC/gGPWPBNuYyh7iYBJXPs7/NyRkISpcih3tJUwSM2aht/8YQv4ckZISO4z4k+mCIs/oNzW645fGUtEBfOtClIrOfNVUAjRtj691weZb9FCICB/E9enN43hY3RcvQG3TYCQA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uB5pHZZ18kDUWOkUNPl+M51WpCdmikWoHBU3FLalfzESc2vmA36eVaH8bMK1YmSKO3d0CWEc4JkkwfqNs2tdPe5kdrrgzhqMIREcfdL/5C0h4hvPoab6fIirjyoEway47X99tNnqwqmofNeqwAiZgF1YGYqBFKSX/TDMAlzutf8=;
X-YMail-OSG: rf.ZYtwVM1k.ybyz_aSDWPyTqjx_.VKG0hXmqtes0VKkdro 6vrngQDJvpwJpPaCimUhtsRi2RpjGSX1I7mFZyCwT5W5_QxVj7XE4C9pTvV4 QSgm_OrYtmzniYKOzuqET7Wz.tmITUnwe5.acLBdwa53A_dVZMLFFFViadB_ rLw5HPyI4zIQV0bBNKHAMJm67n7SA.jhLQwktmo1EFJo2ZZu7XiZp9Ay73V. 0IkehdV5eQ540pkkARsPsE9t8OolPS4fdrYFfkHZOswTgVTXncuZ8ictX8cy gqpcaI0VQVrg0NTmZPQMK9BngYrHiFCx8jVImI4_4qWCWLOMWXc_WwWCJtaq gOaKONbCJdUgqZifet30jAdN7096TdE7bZzFQEm2YtqoWKRm1Ivk3YPhTUCF gVo5CUPri0eMLXCN4g8qMfNUaBnqU1uw.PRY_.wpKeBgnyY.pvC7Z9eAN3u9 DTiCor_GUhzMnKPer2tS7JEaIeuclnSerfRv3nLqtuudA_Hw_1zGJwXBqad6 vjo3SEX1kfNnOJMjNFdQBvSWRhLvn7OnnHvfV9_2kBS.U.gdNiFrRrZRALPG yi38dEj6ls0h.mScQ7IOdL_Mzt4qXwueet_crGElnFIM-
Received: from [118.208.74.180] by web142504.mail.bf1.yahoo.com via HTTP; Mon, 12 Aug 2013 21:54:24 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBBcmllIFZheW5lciAoYXZheW5lcikgPGF2YXluZXJAY2lzY28uY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUdWVzZGF5LCAxMyBBdWd1c3QgMjAxMyA2OjMwIEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1lbnRlcnByaXNlLWluY3JlbWVudGFsLWlwdjYgV0dMQwoBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.154.571
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> <C00B4018-6FEE-441C-B807-B1126101CE6D@delong.com> <CA6D42D0F8A41948AEB3864480C554F104AEAABE@xmb-rcd-x10.cisco.com> <520945FF.4000700@gmail.com>
Message-ID: <1376369664.37168.YahooMailNeo@web142504.mail.bf1.yahoo.com>
Date: Mon, 12 Aug 2013 21:54:24 -0700 (PDT)
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Arie Vayner \(avayner\)" <avayner@cisco.com>
In-Reply-To: <520945FF.4000700@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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, 13 Aug 2013 04:54:39 -0000




----- Original Message -----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> To: Arie Vayner (avayner) <avayner@cisco.com>
> Cc: "v6ops@ietf.org" <v6ops@ietf.org>
> Sent: Tuesday, 13 August 2013 6:30 AM
> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
> 
> On 12/08/2013 17:27, Arie Vayner (avayner) wrote:
>>  Owen,
>> 
>>  While the arguments about moving the firewalls closer to the users are 
> valid they are often are not practical (or at least the customers I worked with 
> would not implement this option).
>>  Imagine an enterprise network with 300 spoke sites, but only 2 or 3 
> Internet gateway locations (with some private WAN in between).
>>  Moving the firewalls to the spoke sites would increase the number of 
> firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... 
> This is a major CAPEX and OPEX impact...
> 
> Clearly DOS and scanning protection has to be done as close to the Internet
> border routers as possible, and there your logic applies.
> 
> However, as Steve Bellovin pointed out many years ago, the best number of
> firewalls for upper layer protection is one per host, which scales nicely
> and has less CAPEX and OPEX than middlebox firewalls will ever have.
> 

Host based firewalling by default has also pretty much been reality for most devices for the last 5+ years, if not much longer (Windows XP Service Pack 2 provided and enabled by default a host firewall in around 2004). I think the reality today is that vendors assume that if a device could be plugged directly into the Internet it probably will be, and therefore they provide and enable host based firewalls by default.

It seems common for the people who make the above argument to be the same people who are facilitating direct attachment of hosts to untrusted and uncontrolled networks by providing laptops instead of desktops, organising 3G/4G dongles for those laptops, and allowing rather than prohibiting people from taking those laptops home, to conferences, cafes and hotels. Fortunately their OS vendors have taken care of enabling host protection on their behalf.

> Not that I see any of this argument as relevant to the IP version number.
> 

Agree.

>    Brian
> 
>>  Arie
>> 
>>  From: Owen DeLong [mailto:owen@delong.com]
>>  Sent: Friday, August 9, 2013 12:17 PM
>>  To: Arie Vayner (avayner)
>>  Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); 
> v6ops@ietf.org
>>  Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
>> 
>> 
>>  On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) 
> <avayner@cisco.com<mailto: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
>> 
>> 
>> 
>> 
>> 
>>  ------------------------------------------------------------------------
>> 
>>  _______________________________________________
>>  v6ops mailing list
>>  v6ops@ietf.org
>>  https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>