Re: [v6ops] Hmm. Interesting article...

Fernando Gont <fgont@si6networks.com> Thu, 04 February 2016 11:17 UTC

Return-Path: <fgont@si6networks.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 98CA41ACEB2 for <v6ops@ietfa.amsl.com>; Thu, 4 Feb 2016 03:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 djWAOubp7rPz for <v6ops@ietfa.amsl.com>; Thu, 4 Feb 2016 03:17:51 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053C41ACEB7 for <v6ops@ietf.org>; Thu, 4 Feb 2016 03:17:51 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CE993206A44; Thu, 4 Feb 2016 12:17:47 +0100 (CET)
To: Enno Rey <erey@ernw.de>, v6ops@ietf.org
References: <165F7549-2A4C-44C3-9FBA-3AF69DE50110@cisco.com> <CAHw9_iLDjyZ6CKUjcyqUBe3-_EJxDekG7a1cPVLpF_U9tVvUgQ@mail.gmail.com> <56AFD626.1000802@bogus.com> <FBABBC18-CFFA-46C9-A63C-B86FE2CFFC94@cisco.com> <6EB29183-FA9A-4B94-BD68-115DB190FE65@delong.com> <56B06129.7090301@si6networks.com> <657448B4-4F56-445A-8862-8E0EB8D1A8B2@delong.com> <20160202133121.GH94027@ernw.de> <4B69E159-3EB4-47C7-8EE3-4075451F8D6A@delong.com> <56B10835.7070604@alvarezp.org> <20160202211331.GA95817@ernw.de>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56B33300.6060704@si6networks.com>
Date: Thu, 04 Feb 2016 08:16:16 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160202211331.GA95817@ernw.de>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/igtzfHB1nKjWZA2g1TGNeAxFhwY>
Subject: Re: [v6ops] Hmm. Interesting article...
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: Thu, 04 Feb 2016 11:17:56 -0000

On 02/02/2016 06:13 PM, Enno Rey wrote:
> Hi,
> 
>> On 02/02/2016 09:44 AM, Owen DeLong wrote:
>>>>> If you're running a host without any sort of filter, that's 
>>>>> really not a problem we should be solving at the network
>>>>> level. That's more of an educational problem.
>>>> 
>>>> that's a very interesting statement, taking the end-to-end 
>>>> principle into account, which IPv6 strives to realize/bring
>>>> back.
>>> 
>>> Why? There???s nothing about filters that interferes with the 
>>> end-to-end principle.
>>> 
>>> A Stateful inspection firewall that doesn???t mangle the packet
>>> header is perfectly acceptable in an end-to-end world. Whether
>>> it???s a network-level firewall, a host-level firewall, both,
>>> etc.
> 
> a network-level "stateful inspection" firewall keeps track of, well,
> state. doing so "in the network" is a - from my understanding -
> fundamental violation of the e2e principle, not least as it impedes
> "survivability in the face of failure".

FWIW, this is what we say in
<https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-01>
about this:

---- cut here ----
3.2.  The End-to-End Principle

   One common complaint about firewalls in general is that they violate
   the End-to-End Principle [Saltzer].  The End-to-End Principle is
   often incorrectly stated as requiring that "application specific
   functions ought to reside in the end nodes of a network rather than
   in intermediary nodes, provided they can be implemented 'completely
   and correctly' in the end nodes" or that "there should be no state in
   the network."  What it actually says is heavily nuanced, and is a
   line of reasoning applicable when considering any two communication
   layers.

      [Saltzer] "presents a design principle that helps guide placement
      of functions among the modules of a distributed computer system.
      The principle, called the end-to-end argument, suggests that
      functions placed at low levels of a system may be redundant or of
      little value when compared with the cost of providing them at that
      low level."

   In other words, the End-to-End Argument is not a prohibition against
   e.g. lower layer retries of transmissions, which can be important in
   certain LAN technologies, nor of the maintenance of state, nor of
   consistent policies imposed for security reasons.  It is, however, a
   plea for simplicity.  Any behavior of a lower communication layer,
   whether found in the same system as the higher layer (and especially
   application) functionality or in a different one, that from the
   perspective of a higher layer introduces inconsistency, complexity,
   or coupling extracts a cost.  That cost may be in user satisfaction,
   difficulty of management or fault diagnosis, difficulty of future
   innovation, reduced performance, or other forms.  Such costs need to
   be clearly and honestly weighed against the benefits expected, and
   used only if the benefit outweighs the cost.

   From that perspective, introduction of a policy that prevents
   communication under an understood set of circumstances, whether it is
   to prevent access to pornographic sites or prevents traffic that can
   be characterized as an attack, does not fail the End-to-End Argument;
   there are any number of possible sites on the network that are
   inaccessible at any given time, and the presence of such a policy is
   easily explained and understood.

   What does fail the End-to-End Argument is behavior that is
   intermittent, difficult to explain, or unpredictable.  If I can
   sometimes reach a site and not at other times, or reach it using this
   host or application but not another, I wonder why that is true, and
   may not even know where to look for the issue.
---- cut here ----

Thanks!

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