[Netrqmts] netrqmts - on the issue of firewalls
Toerless Eckert <tte@cs.fau.de> Tue, 23 July 2019 22:26 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: netrqmts@ietfa.amsl.com
Delivered-To: netrqmts@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7551202E2 for <netrqmts@ietfa.amsl.com>; Tue, 23 Jul 2019 15:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.844
X-Spam-Level:
X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_MED=-2.3, 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 krkQgEWShNHp for <netrqmts@ietfa.amsl.com>; Tue, 23 Jul 2019 15:26:56 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30050120352 for <netrqmts@ietf.org>; Tue, 23 Jul 2019 15:26:56 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AF454548014 for <netrqmts@ietf.org>; Wed, 24 Jul 2019 00:26:51 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9DB6E440041; Wed, 24 Jul 2019 00:26:51 +0200 (CEST)
Date: Wed, 24 Jul 2019 00:26:51 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: netrqmts@ietf.org
Message-ID: <20190723222651.4os2mgtvwrhabx4i@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/yEdFUo1MuLlea-roK00CEipJJy4>
Subject: [Netrqmts] netrqmts - on the issue of firewalls
X-BeenThere: netrqmts@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <netrqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netrqmts/>
List-Post: <mailto:netrqmts@ietf.org>
List-Help: <mailto:netrqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 22:26:58 -0000
Hi folks Wrt IETF network and firewalls: Let me start: There is nothing wrong with a draft saying There MUST be network options that do not prohibit end-to-end and external connectivity for any traffic (no limiting firewalls or NATs). Its a different thing to say what the current draft says: The network MUST NOT prohibit end-to-end and external connectivity for any traffic (no limiting firewalls or NATs). which implies i think "for all VLANS/SSID" (e.g. IETF and IETF-hotel). The notion of unrestricted Internet access is cool for all those people who managed to figure out this mailing list exists, but i am sure the mayority of IETF attendes does not know it exists, does not really know what the policies are, and would even start wondering if they match what does keep their notebooks safe. Yes. 10 years ago the number of IETF participants bothering about this was larger, but we are moving more into "application" space, where some form of "normal" == "protected" Internet access is a i think more likely than with traditional IETF folks coming from routing and wanting to smell the unlimited freedom at least for a week. So, the best solution would be to hand out a welcome sheet during registration: Welcome to the IETF network. Let your notebook for the first time in its life experience what otherwise is a privilege of your home/hotel/hotspot gateway/access-point: The pure evil of the Internet and its attacks. Experience how a flat broadcast domain of hundreds of users with link-layer multicast and broadcast allows to fully explore this evilness much faster. Especially with likely 20% or more infected computers with some form of virus and 10% users thinking attacks can be a great hobby. Enjoy! The second best option of course would be to have some form of SSID with a firewall (just simple no outside to inside initiated flows) and no inside<->inside traffic. Which i know is heresy against tradition, but somehow part of how today >99.999% of users equipment of this network technolgy we all live off are connected. Or: Why is it a good tradition to ONLY establish a form of access that represent <0.000% of how end systems are attached ? OF course we MUST have the unrestricted option for experimentation, but when folks experiment with RTCweb/ICE/STUN/etc they probably would have been happy to have firewall options too given how they must work with them in the real world, so don't tell me there is no value of firewall for experiments. It just depends on what experiment you want. As a simple way i woud suggest to make ietf-hotel protected, and leave the other SSIDs as they are. Of course its clear this might be diffult depending on how IETF integrates with existing hotel network, but given how seemingly hotel APs can be reconfigured with ietf-hotel SSID, i am sure L2 properties can also be reconfigured. Cheers Toerless Disclaimer: All number in this research papers have been pulled out of thin air within a matter of seconds, but it should be hard enough to prove them wrong that no funding for longer research could be allocated.
- [Netrqmts] netrqmts - on the issue of firewalls Toerless Eckert