Re: [v6ops] Thoughts about wider operational input

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 04 April 2022 10:15 UTC

Return-Path: <prvs=1093b5d1d9=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC16B3A1B51 for <v6ops@ietfa.amsl.com>; Mon, 4 Apr 2022 03:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 TqdwRqjQsQVK for <v6ops@ietfa.amsl.com>; Mon, 4 Apr 2022 03:15:24 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id B2CCE3A1B4C for <v6ops@ietf.org>; Mon, 4 Apr 2022 03:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1649067320; x=1649672120; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=/QIF7AVe mlNAPSX7j++4FytxwxKOWGNP2IMDzS6bByE=; b=q86rkz5Ab/9Qe5jNANXwlov9 xfWALmm3BFFb/hn+GI8psb/p4AUFfxW5SgfL/hpN8osG3YIxkF2e9k5eSrFffniH QBEOuRm+R7AEzk0ZXX/jbBAI/hWlf9CHEumzzxaKPdznbGlLhbzwiShEvHx574re OU1NWXOZGio1uraT32M=
X-Spam-Processed: mail.consulintel.es, Mon, 04 Apr 2022 12:15:17 +0200
Received: from [10.10.10.145] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000836848.msg for <v6ops@ietf.org>; Mon, 04 Apr 2022 12:15:17 +0200
X-MDRemoteIP: 2001:470:1f09:495:618d:c93c:1b85:8ebe
X-MDHelo: [10.10.10.145]
X-MDArrival-Date: Mon, 04 Apr 2022 12:15:17 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1093b5d1d9=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/16.60.22022702
Date: Mon, 04 Apr 2022 12:15:15 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops list <v6ops@ietf.org>
Message-ID: <9889B39E-8632-4A2D-9226-E59857F7C89A@consulintel.es>
Thread-Topic: [v6ops] Thoughts about wider operational input
References: <52661a3d-75dc-111a-3f23-09b10d7cb8d4@gmail.com> <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com> <YjmJQMNgnJoSInUw@Space.Net> <D75EF08F-6A41-41B2-AFB2-649CBCC1D83E@consulintel.es> <CAPt1N1nRnYUFA=yyJHx6t52yqWbmcd2Tf1H8gQuCZBd3Q3VqJw@mail.gmail.com> <7F4AEB43-4B24-4A21-AE9D-3EB512B98C46@consulintel.es> <8fac4314b8244ba6b33eea68694296d0@huawei.com> <9A13E47B-75D0-443F-9EE9-D2917ACB2D0F@consulintel.es> <CAO42Z2xUG+BXj+VQpajed9aGjH+q-HR7RX7C-T4DsTbouz7xWQ@mail.gmail.com> <F6A90BBF-7F44-403E-960A-8F756353B562@chinatelecom.cn> <B49417F7-3EFB-4A4D-9D1A-0D21574EA4F2@consulintel.es> <44B01ACA-3D5C-4618-B608-3B3479D29875@consulintel.es> <62447DCB.1010206@jmaimon.com> <7228D9A7-54A8-4BAE-9299-204C049F600B@consulintel.es> <6244BA91.3060306@jmaimon.com>
In-Reply-To: <6244BA91.3060306@jmaimon.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ykP2tBeHL8lGjw_ftIvSrIEjThU>
Subject: Re: [v6ops] Thoughts about wider operational input
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Apr 2022 10:15:36 -0000

What I'm saying is that if you don't have a NAT you will need to ensure that the CPE has a firewall and it is enabled by default. It is not only in the interest of the subscriber, but also the ISP, to avoid calls to the help desk, or abuse cases, etc., etc.

Regads,
Jordi
@jordipalet
 
 

El 30/3/22, 22:17, "Joe Maimon" <jmaimon@jmaimon.com> escribió:



    JORDI PALET MARTINEZ wrote:
    > Because if you don't have NAT, you are forced to properly configure a firewall.

    That is backwards.

    NAT requires state management to operate. What exactly is forcing the 
    existence of a firewall, let alone its proper configuration?

    NAT is an operational requirement. You have it because without it 
    something does not work the way you want it to.

    Firewalls are a security requirement. You implement them because without 
    it something you do not want to work might or even probably will.

    Take car insurance as an example. Even where not legally mandated 
    (anywhere?) its an obvious practical necessity. Yet, uninsured drivers 
    and cars abound on the road. Because lack of insurance doesnt interfere 
    with the ability to operate the vehicle. Its not an operational requirement.

    Operational requirements meet my definition of "force". Security 
    requirements, decidedly less so as has been painfully and universally 
    obvious for decades. Or should be.

    As far as the proper configuration of one? Proving your NAT is 
    sufficiently properly configured. Easy. The firewall? Impractical to 
    impossible, its a negative theorum.

    Restated correctly: Without NAT, you must choose to implement a firewall 
    for it to exist. Perhaps properly. Likely not. Fixed that for you.

    Or:

    Because if you don't have NAT, unless you choose to properly configure a 
    firewall, you will not have one either, properly configured or otherwise.

    >
    > With a NAT, many don't even have a firewall or is not sufficiently well configured.

    Please explain how removing the near universal existence of NAT improves 
    this situation. Do you somehow believe that there will be the equivalent 
    or even greater number of deployments and users who actively choose to 
    deploy firewalling as a result of the global routability of their 
    addressing and the lack of NAT, and that now having made that choice it 
    will as matter of course be followed by the choice to do so in the 
    utmost correct, stringent and sufficient fashion? Farcical.

    At least with the existence of NAT there also exists some level of state 
    management and unsolicited incoming traffic constraints from reaching 
    the internal network nodes. By default, by dint of them being 
    operationally on the internet.

    Joe


    >
    > Regards,
    > Jordi
    > @jordipalet
    >   
    >   
    >
    > El 30/3/22, 17:58, "v6ops en nombre de Joe Maimon" <v6ops-bounces@ietf.org en nombre de jmaimon@jmaimon.com> escribió:
    >
    >
    >
    >      JORDI PALET MARTINEZ wrote:
    >      >
    >      > To demonstrate how NAT is not security, you just need to enable Teredo
    >      > or any other UDP tunneling traversing the NAT, so the security guys
    >      > can see that without any special config in the NAT, you can dig a
    >      > whole on it (Teredo Navalis = Shipworm).
    >      >
    >      > Regards,
    >      >
    >      > Jordi
    >      >
    >      > @jordipalet
    >      >
    >
    >      And then you need to demonstrate how the equivalent would not happen on
    >      IPv6.
    >
    >      Joe
    >
    >      _______________________________________________
    >      v6ops mailing list
    >      v6ops@ietf.org
    >      https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    >
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
    >
    >




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.