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

Rick Casarez <rick.casarez@gmail.com> Sun, 18 October 2015 12:35 UTC

Return-Path: <rick.casarez@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274CC1A1EF1; Sun, 18 Oct 2015 05:35:56 -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 rVAglF89nYob; Sun, 18 Oct 2015 05:35:53 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 3D45B1A1BF5; Sun, 18 Oct 2015 05:35:53 -0700 (PDT)
Received: by wikq8 with SMTP id q8so17132669wik.1; Sun, 18 Oct 2015 05:35:51 -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=LoDuQ1J6h2LokW6XxnptwZ6YAbq6HrznNEjVoH4it14=; b=C9dSsn0ZJN+SQlK+EdYw17yq7zz1B3XM2hT/KAu/VgibBpP7PeDNnwQHaHVCA+BuIa oE42xVtdOJnOcMB6Cdt7oG5NxzMVj7l4+CDNL5w2TRW1mY9/Jq2Yub3bfAyIWzZSmYam Zo+FO4JKMCNbOS56p2MQbfUA0HagjTAAFMUSDbXSPUSSHVamKPwSV0Q3MBnFjyCkNmO1 CuI4DYd37kYyYBupvCuPS6alOSjqNicgSJ5xASZYDCG7DrbfQ8jOl2nqNlCkl8k8U08y 5V3voeV7eAS3gCx+Id9veUcdH/nzlsnT2ky6xdtZ6SwWh37M/KnFhTa9599RtALN+adI U/tg==
MIME-Version: 1.0
X-Received: by 10.180.211.8 with SMTP id my8mr14347969wic.21.1445171751683; Sun, 18 Oct 2015 05:35:51 -0700 (PDT)
Received: by 10.27.108.76 with HTTP; Sun, 18 Oct 2015 05:35:51 -0700 (PDT)
In-Reply-To: <562155BC.6030701@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>
Date: Sun, 18 Oct 2015 08:35:51 -0400
Message-ID: <CAGWMUT686GhqGQ+H4McBXy7mmDChPQJH2kDzU_SNQAceFCucUA@mail.gmail.com>
From: Rick Casarez <rick.casarez@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="001a11c38e0ee60cfd05226044ae"
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/_lq1ytwp7B8NLMiVbq53DHXjnWU>
X-Mailman-Approved-At: Wed, 21 Oct 2015 20:15:00 -0700
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, Internet Area <int-area@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [Int-area] [v6ops] Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-01.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Oct 2015 12:35:56 -0000

Just trying to help. Answers in line.

-------------------
Cheers, Rick

Experiences not things.

On Fri, Oct 16, 2015 at 3:53 PM, Fernando Gont <fgont@si6networks.com>
wrote:

> Hi, Rick,
>
> Thanks so much for your feedback! Please find my responses in-line...
>
> On 10/16/2015 09:19 AM, Rick Casarez wrote:
> > While I get amused reading such things are we sure we need lines like
> > this in the document?
> >
> > "...and attempts to end the bickering on the topic, which is, for the
> > most part, of little value in illuminating the discussion."
> >
> > A few parts of the introduction I think can be re-worded to express the
> > issues professionally without getting people defensive by making the
> > statements you are making. Rise above it.
>
> I'll re-check the text -- The Intro was going to be re-worked, anyway.
>
> [Rick] Sounds good. Thanks.

>
>
> > 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.

>
> > 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.

>
>
> > Defense-in-depth - I think you should define this term in this section
> > since you go on to use it in following sections.
>
> Will do.
>
>
>
> > Section 3.3:
> >
> > The sentence:
> >
> > "By that line of reasoning, a firewall primarily protects
> > infrastructure, by preventing traffic that would attack it from it."
> >
> > I think flows better as:
> >
> > "By that line of reasoning, a firewall primarily protects
> > infrastructure, by preventing traffic that would attack it."
> >
> > or
> >
> > "A firewall primarily protects against infrastructure attacks."
>
> This seond option my work. (Your first option changes the meaning of the
> sentence).
>
>
>
> > 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.
The only cases I can think of is if the company has fired all engineers
after initial deployment. This would make it a business problem, not a
technical one since appropriate staffing is a business item.

Placement of the firewall is moot since if staffing is done correctly the
scenario I describe above should happen. If not staffed properly the
business has issues not related to creating new applications. In other
words it is not really the firewalls fault but the business for not having
anyone to maintain a piece of gear they deployed.

>
>
> > 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.

>
>
> > 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.

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