Re: [arch-d] possible new IAB programme on Internet resilience

Simon Leinen <simon.leinen@switch.ch> Fri, 20 December 2019 16:46 UTC

Return-Path: <simon.leinen@switch.ch>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B79F120856 for <architecture-discuss@ietfa.amsl.com>; Fri, 20 Dec 2019 08:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 IEc3JenIjrSP for <architecture-discuss@ietfa.amsl.com>; Fri, 20 Dec 2019 08:46:12 -0800 (PST)
Received: from mailg110.ethz.ch (mailg110.ethz.ch [IPv6:2001:67c:10ec:5605::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6645312084D for <architecture-discuss@iab.org>; Fri, 20 Dec 2019 08:46:11 -0800 (PST)
Received: from mailm212.d.ethz.ch (2001:67c:10ec:5603::26) by mailg110.ethz.ch (2001:67c:10ec:5605::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 20 Dec 2019 17:46:03 +0100
Received: from macsl (130.59.196.135) by mailm212.d.ethz.ch (2001:67c:10ec:5603::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 20 Dec 2019 17:46:08 +0100
From: Simon Leinen <simon.leinen@switch.ch>
To: Marc Blanchet <marc.blanchet@viagenie.ca>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, architecture-discuss@iab.org
In-Reply-To: <EAF951A6-71A3-4B83-8881-7D96DE67E1F1@viagenie.ca> (Marc Blanchet's message of "Fri, 20 Dec 2019 09:06:34 -0500")
References: <f13e1588-35e0-2493-93d2-add3480bb207@cs.tcd.ie> <EAF951A6-71A3-4B83-8881-7D96DE67E1F1@viagenie.ca>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin)
Date: Fri, 20 Dec 2019 17:46:20 +0100
Message-ID: <aa7e2reyhv.fsf@switch.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [130.59.196.135]
X-ClientProxiedBy: mailm117.d.ethz.ch (2001:67c:10ec:5602::29) To mailm212.d.ethz.ch (2001:67c:10ec:5603::26)
X-TM-SNTS-SMTP: 7554958F4792E9F984740D736C748AB17CEBD168E29457E2E3722B5C761CE3E92000:8
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/BJagRN8nwI0RB2s3Avoe-Qosb4s>
Subject: Re: [arch-d] possible new IAB programme on Internet resilience
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2019 16:46:15 -0000

Marc Blanchet writes:
> good proto charter. I would complement that, while diversity is key,
> it is not the only facet that needs to be looked at for resilience. I
> could think of others, such as decreasing DDOS capabilities by:
> « don’t advertise/forward what’s wrong »: for example: BGP lack of
> basic filtering, BCP38, …  Maybe this is out of the scope you had in
> mind.

While it's generally a good idea to not advertise or forward what's
wrong, I think this is a general security consideration that I wouldn't
associate with resilience (maybe more with "resistance" to
attack/damage).

In fact, one could argue that in the presence of restrictive definitions
of "right", what you suggest will actually make the system less
resilient (though more secure, at least from the perspective of those
holding narrow definitions of "right").
-- 
Simon.