Re: [Netrqmts] IETF 105 Minutes

Alessandro Amirante <alex@meetecho.com> Wed, 31 July 2019 13:22 UTC

Return-Path: <alex@meetecho.com>
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 B312A120020 for <netrqmts@ietfa.amsl.com>; Wed, 31 Jul 2019 06:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
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 HOAYcrpWFJyr for <netrqmts@ietfa.amsl.com>; Wed, 31 Jul 2019 06:22:11 -0700 (PDT)
Received: from smtpcmd04131.aruba.it (smtpcmd04131.aruba.it [62.149.158.131]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC8120018 for <netrqmts@ietf.org>; Wed, 31 Jul 2019 06:22:11 -0700 (PDT)
Received: from [192.168.1.230] ([93.44.57.15]) by smtpcmd04.ad.aruba.it with bizsmtp id jRN82002K0KiRsV01RN8Lf; Wed, 31 Jul 2019 15:22:10 +0200
To: Toerless Eckert <tte@cs.fau.de>
Cc: netrqmts@ietf.org
References: <DF3803B7-C05B-4A31-B873-73A86B1416CE@vigilsec.com> <19915.1564514403@localhost> <20190730202439.zl6gjvzasxofvej2@faui48f.informatik.uni-erlangen.de> <27837.1564524525@localhost> <20190730222340.x6g232kpp7eadanp@faui48f.informatik.uni-erlangen.de> <2712.1564526544@localhost> <20190730225843.hznqmck3lkgfpwz4@faui48f.informatik.uni-erlangen.de>
From: Alessandro Amirante <alex@meetecho.com>
Message-ID: <3d76dc0e-ca2e-1a9c-6038-081c3fea895a@meetecho.com>
Date: Wed, 31 Jul 2019 15:22:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190730225843.hznqmck3lkgfpwz4@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1564579330; bh=KJG3lPfS/66ziOCZev6o/OmKRlHZNT4FMvEj/IOheJo=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=Wpg7DMQnuYEK7DGyTHeftFWfUb3ftK1+2N9ALjcvAFQmJftUmITFcsCqOqLjZKQqp ZT3VOyO6OYCgTlnbyiZcA9caA/qikZXAHdOxHw1mtUzZCb7KUTsXztANawG9z1OsMv LCCesZK6Sykqfr7tT6CmSFw3qrEaZybu89LXo7watmpLodcbRvts502WOSrInbgSs4 2LgCBYw3Q5KqpVAN/HDwyjbtSxtmhyVeg8YzoM/Wh3GUmwVSovuPw4kcHD21r7iqdz JwZYXqoqyKisb1B6qUc7urp0JRmHeyQt9S+0/E9nbduS8bvdiFK/i1pTeEM9zM7LjV 9F7vFAVos19wg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/Xz940sVZXPaMLtybeCSPxqo2KoE>
Subject: Re: [Netrqmts] IETF 105 Minutes
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: Wed, 31 Jul 2019 13:22:15 -0000

Il 31/07/19 00:58, Toerless Eckert ha scritto:
> On Tue, Jul 30, 2019 at 06:42:24PM -0400, Michael Richardson wrote:
>>
>> Toerless Eckert <tte@cs.fau.de> wrote:
>>      >> A $22 home router fixes that problem.
>>
>>      > Sure, but why would i have to bring my own WiFi<->WiFi home router to
>>      > the IETF to give me that function for the company notebook.
>>
>> Laptops are regularly attacked at the Coffee Shop from BEHIND the NAT44
>> "firewall".  No firewall the IETF provides will solve that.
> 
> That IMHO today an untypical and recgonizeable bad hotspot setup.
> 
>> As your company IT guy why they gave you an insecure laptop for travel.
>> So seriously, go ask them.  NOT AN IETF PROBLEM.
> 
> Providing access that is less secured than what users can normally
> expect at work/hotspots/home is an explicit IETF choice, and i am
> questioning why people would think its a good idea to only provide that
> choice.
> 
>> Better yet, bring your company IT guy to IETF, so that they learn what's it
>> like to be connected to the actual Internet. As you say, most have never been online.
> 
> Nobody connects endpoint to the actual Internet without firewalls in between.

This can be true for IPv4. It isn't for IPv6. I've had a NAT-ted v4 
address and a public v6 address for quite some time, both at home and at 
the office.

A.

> Yes, a good travel notebook should have that firewall built-in. Many may
> be good. Windows probably a lot better than Linux. But its a kind of
> strange policy to provide such an uncommon type of access without
> communicating it clearly to the whole community and understanding their
> preferences.
> 
>>      > I guess the best thing i could think of would be to have a BCP RFC for
>>      > how hotels should build out their network infrastructure to be best
>>      > prepared for conferences/workshops etc. This could easily proliferate
>>
>> It's a great idea, and I sure wish it would occur.
>>
>> To be effective, they hotel chains would need to solicit this document, and
>> pay a significant figure for the consulting.  Otherwise, they will ignore it.
> 
> If a lot of conferences would refer to it, the hotels would not ignore
> it. Otherwise we might worst case support the business model of useless
> consultants reading our doc, and recommending its points for a lot of
> money to hotels.
> 
> But yes, its work, so the question is whether there is enough critical
> mass to write it.
> 
>> capport WG has been struggling for attention of the same types.
> 
> I think thats a fundamentally different problem space.
> 
> To automate the captive portal problem, you need to be able to tie every
> IoT devices authenticatication to some poor human, who forcefully has to absorb the
> advertisement of the portal and bear legal responsiblity requested by
> the portal. So pretty much you need a mobile phone app and cloud broker
> where iot device manufacturer can hire middle school kids that will then
> continuously watch advertisement clips from those portal operators and
> whose parents will pay the bail when the kid has to go to jail for
> something the IoT device did do wrong.
> 
> Or else the business model of the captive portal has to change.
> 
> Cheers
>      toerless
>>
>> -- 
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>>
> 
> 
> 
>> -- 
>> Netrqmts mailing list
>> Netrqmts@ietf.org
>> https://www.ietf.org/mailman/listinfo/netrqmts
> 
> 

-- 
Ing. Alessandro Amirante, Ph.D.

Meetecho S.r.l.
www.meetecho.com

Via Riviera di Chiaia 124
80122 Napoli, Italy

Mobile: +39 329 6178743
E-mail: alex@meetecho.com