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