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
- [v6ops] Hmm. Interesting article... Fred Baker (fred)
- Re: [v6ops] Hmm. Interesting article... Warren Kumari
- Re: [v6ops] Hmm. Interesting article... Fred Baker (fred)
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... joel jaeggli
- Re: [v6ops] Hmm. Interesting article... Fred Baker (fred)
- Re: [v6ops] Hmm. Interesting article... Ted Lemon
- Re: [v6ops] Hmm. Interesting article... joel jaeggli
- Re: [v6ops] Hmm. Interesting article... Ca By
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Mark Smith
- Re: [v6ops] Hmm. Interesting article... Ray Hunter (v6ops)
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Ray Hunter (v6ops)
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fred Baker (fred)
- Re: [v6ops] Hmm. Interesting article... Fred Baker (fred)
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Enno Rey
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Howard, Lee
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Ca By
- Re: [v6ops] Hmm. Interesting article... Ca By
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Tim Chown
- Re: [v6ops] Hmm. Interesting article... Fred Baker (fred)
- Re: [v6ops] Hmm. Interesting article... Mark Smith
- Re: [v6ops] Hmm. Interesting article... Mark Smith
- Re: [v6ops] Hmm. Interesting article... Enno Rey
- Re: [v6ops] Hmm. Interesting article... Mark Smith
- Re: [v6ops] Hmm. Interesting article... Joe Touch
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Joe Touch
- Re: [v6ops] Hmm. Interesting article... 🔓Dan Wing
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Mark Smith
- Re: [v6ops] Hmm. Interesting article... Joe Touch
- Re: [v6ops] Hmm. Interesting article... Tom Herbert
- Re: [v6ops] Hmm. Interesting article... Ca By
- Re: [v6ops] Hmm. Interesting article... Nick Hilliard
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Mark Smith
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Joe Touch
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Fernando Gont
- Re: [v6ops] Hmm. Interesting article... Tim Chown
- Re: [v6ops] Hmm. Interesting article... Owen DeLong
- Re: [v6ops] Hmm. Interesting article... Fernando Gont