Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt

Rick Casarez <rick.casarez@gmail.com> Tue, 20 October 2015 12:17 UTC

Return-Path: <rick.casarez@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF311B3394; Tue, 20 Oct 2015 05:17:27 -0700 (PDT)
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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLuXGdkCwHMx; Tue, 20 Oct 2015 05:17:24 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E0D1B33A3; Tue, 20 Oct 2015 05:17:24 -0700 (PDT)
Received: by wicfx6 with SMTP id fx6so42615602wic.1; Tue, 20 Oct 2015 05:17:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Mp4dMTWstIIjiRNPke2GkKSAKjrk+dV9yG9et6NeAQ=; b=P9bWEaSluWj6LwNoNZGu//96oPoLa1DsVMRD5SqO+gTk8eeGXymyf1+Bo52eVrDMUA IaIWcGJVkwqv/BUnBL859EBj3DH7JD49OmWQh2fdwy070a9N3CnNTFEuqEOSfS5N4Wyi z47nnIDfVFQZYPGdHz0glOXI8LkKs9g457z4Vf7Y/v1nekQWwxDsvLsjyoQm56ZYjTlz 7rCRNIAFKS27MgOn12FEluLZHCQOLq/XDtO/wh9Z+SQzwpwW03j302bvsZQ1LvbCFJG5 i6/3tEoPQ711Ayg6lPrMk4294a/Kl74cJdAdwIfFRkG4S2Fyri+fpneDdd5sz2nW7k9r oW/w==
MIME-Version: 1.0
X-Received: by 10.180.211.8 with SMTP id my8mr25676649wic.21.1445343442559; Tue, 20 Oct 2015 05:17:22 -0700 (PDT)
Received: by 10.27.108.76 with HTTP; Tue, 20 Oct 2015 05:17:22 -0700 (PDT)
In-Reply-To: <562590A5.90802@si6networks.com>
References: <20151013134530.1812.78498.idtracker@ietfa.amsl.com> <561D0CB7.3040606@si6networks.com> <CAGWMUT4A5Y=R6KN6oJdGzMOQJ=5aPUr8XJbEhZ3pBJ+hZD8_RA@mail.gmail.com> <562155BC.6030701@si6networks.com> <CAGWMUT686GhqGQ+H4McBXy7mmDChPQJH2kDzU_SNQAceFCucUA@mail.gmail.com> <562590A5.90802@si6networks.com>
Date: Tue, 20 Oct 2015 08:17:22 -0400
Message-ID: <CAGWMUT7ttM5DYZaDSrDdOaswvYmMBwfmMvLaa-dxY7pHWG31Qg@mail.gmail.com>
From: Rick Casarez <rick.casarez@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="001a11c38e0e78eea50522883ee9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/1dBv5wipg0RAJnrHbH-mEd_9uG4>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, Internet Area <int-area@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 20 Oct 2015 12:17:27 -0000

Hmm so maybe the problem is the scope of the draft. You seem to want to
cover home-based unmanaged CPE devices that have firewall functionality
built into them (Not dedicated firewalls as I recognize them). This is a
very specific definition of firewall and a specific type of deployment. If
you changed the introduction and scope to say you are only discussing this
specific type of hardware and deployment then a lot of the problems I have
with the text disappear.

If you however want this draft to cover firewalls in general then you have
to be aware of all the different ways they are deployed and maintained. You
also need to distinguish what separates a firewall from general L3/L4
access-control. I can tell you the industry does differentiate between the
two.

As for your statement that routers just route packets, that has not been
true for well over 18 years if not longer. ACLs/Filters on routing and
switching devices is not a new phenomenon.

Finally, to truly cover the subject you also have to at least mention the
things that have replaced dedicated firewalls for security at the Edge
(Load-balancers with built in Firewall functionality as an example) that
even PCI and SOC have accepted.
-------------------
Cheers, Rick

Experiences not things.

On Mon, Oct 19, 2015 at 8:53 PM, Fernando Gont <fgont@si6networks.com>
wrote:

> Hi, Rick,
>
> On 10/18/2015 09:35 AM, Rick Casarez wrote:
> > Just trying to help. Answers in line.
>
> Indeed -- and that's really appreciated!
>
>
>
> >     > In Section 2:
> >     >
> >     > Firewall - I am wondering if a better definition can be made. From
> >     what
> >     > you wrote I cannot distinguish between a Firewall and an ACL.
> >
> >     An ACL is a policy. A firewall is a device that enforces filtering
> >     policies.
> >
> > [Rick] Your definition would encompass routers and switches who have
> > ACL/Filters on interfaces/SVIs. I would not consider these firewalls.
>
> Well, that's a firewalling functionality. From a strict point of view, a
> router does not really drop offending packets, but just forwards them.
>
>
>
> >     > No mention
> >     > of state tracking for instance etc.
> >
> >     Ok, will try to add somethin in this respect.
> >
> > [Rick] Please do, as Ca mentions this is how the vast majority of the
> > world define it as. This even includes common compliance audits like
> > PCI/SOC etc.
>
> Question: WOuld you include this as part of the fw definition, or rather
> e.g. simply define "state-tracking"?
>
>
>
> >     > Section 5.1:
> >     >
> >     > "The drawback of this approach is that the security goal of "block
> >     > traffic unless it is explicitly allowed" prevents useful new
> >     applications."
> >     >
> >     > I am not sure I understand this line. It blocks new applications
> from
> >     > immediately traversing the firewall. I know from experience though
> >     that
> >     > when a discussion is had with the NetSec team the application can
> be
> >     > added to the allow list. So not sure a "default deny" means new
> stuff
> >     > never gets allowed as the text insinuates.
> >
> >     Well, that depends on where the firewall is being deployed, and if
> it is
> >     actively managed.
> >
> > [Rick] I am unaware of any firewall deployed that is no longer managed.
>
> I'm told that comcast does currently deploys this sort of boxes for
> their IPv6 residential customers.
>
> And I'd argue that anything that is deployed at the home mostly follows
> into this category...
>
>
>
> >     > Section 6:
> >     >
> >     > There are temporary IPv4 addresses too.
> >
> >     Not by definition I'd say. Or... would you mind elaborating a bit
> more
> >     in this respect?
> >
> >  [Rick] My apologies on this one got some wires crossed. This is good to
> go.
>
> Thanks for double-checking!
>
>
>
> >     > As for application being tunneled over well-known ports that
> >     sounds like
> >     > a breakdown of communication between the Service Owners and NetSec.
> >     > Simple communication *should* lead to the creation of a profile
> >     for that
> >     > new application and its individual port. By doing what you
> describe it
> >     > sounds like a Service Owner trying to get out of doing due
> diligence
> >     > with NetSec or not knowing what port their application needs for
> >     access
> >     > (More common than you might think).
> >
> >     Yes. Or, at times, a user/app trying to circumvent unmanaged
> firewalls.
> >     -- Ironically, at times these protocols are referred to as "firewall
> >     friendly".
> >
> >  [Rick] The scenario makes no sense other than a mismanaged company
> > frankly. You are essentially encouraging something against BCP. Even
> > beyond security you will make it difficult to troubleshoot if everything
> > is using the same port to traverse the firewall.
>
> We¿re not talking about companies, but about e.g. about firewalls
> deployed at homes, and applications meant to be employed by such users.
>
> Thanks!
>
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>