Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

Mark Smith <markzzzsmith@gmail.com> Fri, 22 February 2019 07:51 UTC

Return-Path: <markzzzsmith@gmail.com>
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 135CE130DC9; Thu, 21 Feb 2019 23:51:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sVoheF8Aw70y; Thu, 21 Feb 2019 23:51:16 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75E5126D00; Thu, 21 Feb 2019 23:51:15 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id q81so1049423oic.5; Thu, 21 Feb 2019 23:51:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qDuroK3z8BztG3jKm++r4AGzJVDpi822jZsEupQ6l+U=; b=OPwNsdFh7hSv2FQcNK+kmb5zJhF8E/3SY+DoUhRE8AzaWZN36c5+nRon68e/ACptEI Q7ukV9gHcLrUUbk45uGU/QN4jto1ITJMnTSBVMdoagA8nY5LAxy28b6IdOZiFrOwVwju 7u1scQlQQu4/G8PL1EIuokxXP6Ov2m2RlEHOhlJsOr7do8ysAfKgBLTBOw+oSLg9iNtb 7SF7oVAP3Jy5wRYfHvhpO1+GPDqvrmPXa66zXqi7MY42wabjKguqAsVjGfbPg1zya74U R6OaqinTlHsJTBTmiN4IBZUdA/BbtHmIJE6nKqlfuVj57wMuAqe8li2CEvDB5ulEh5Um XTGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qDuroK3z8BztG3jKm++r4AGzJVDpi822jZsEupQ6l+U=; b=noh+5G1Kk8Tp4JMSvmL+BP+G/rApgP9I0A9E1xhVuc5FbxcxReyFcIlgCS2vIUvBsa 5aMCOow1k/+Tqs3XyWUBIqD9mard8xS7d022WCguZYwpuZJk9nIF4oQMl3KN8Bm62b4a cvHL+jl7WVJT4JGq3EVMf7Ywvs1Ndl/vd3XT138OC89W3T5r0gZx3HrXM4er63+UTzCS oclVlMnqJ+1BVppWQ2yVE2cLUiBHA2eDiwrhg+wwsY/FST/WEs4+JV0uQcQRTmMS84XF izH0tXOw72Q9tLrEvnmvuyE+mYhjtqg3KgO1MrqPKxJZaARaq/JAiaITTAKt57ep5i2B O/hQ==
X-Gm-Message-State: AHQUAuYHR2lwonZWH/M9QAFalvp4KtVQ0+5jom3VJTM/3QtUEFTekbPc QLTQKHUVTkYb/9UZ1RsYc1DbNtIgiQJQTLJTsr0=
X-Google-Smtp-Source: AHgI3Ias0Yt3qXN/Yd/Zvb8PM6+UuwMbJz4bR5nSFU43VPwvRKVtd32PCMBX2XjLe6OZfE82XuaiDeI/vw9fbCAY6uE=
X-Received: by 2002:aca:5785:: with SMTP id l127mr1663617oib.14.1550821874680; Thu, 21 Feb 2019 23:51:14 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com> <CALx6S36K5v9gusorEvj_uJjW4YwgERGdoWZOABREMpnqhJWJPw@mail.gmail.com> <DM6PR04MB4009E6096E8CF525931D46A5DD7F0@DM6PR04MB4009.namprd04.prod.outlook.com> <CALx6S36_aOy3273zGM+26z+04xF2q4_iBfj6LkFjX3qvuJZERw@mail.gmail.com> <DM6PR04MB40096241EB14D0526F7131CDDD7F0@DM6PR04MB4009.namprd04.prod.outlook.com> <CAD6AjGRh1z9+N6K423e5kcPFceDXA8CcBX6EJ4uzv80SC_VW-g@mail.gmail.com>
In-Reply-To: <CAD6AjGRh1z9+N6K423e5kcPFceDXA8CcBX6EJ4uzv80SC_VW-g@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 22 Feb 2019 18:50:48 +1100
Message-ID: <CAO42Z2xiUvxeXZFy8KgiAQOdq+LX4k8gDzE9ePik3CycsaZEHw@mail.gmail.com>
To: Ca By <cb.list6@gmail.com>
Cc: Kristian McColm <kristianmccolm@hotmail.com>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/HaxEbkxNdTknzH9FjvgCe9wf-H8>
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
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: Fri, 22 Feb 2019 07:51:18 -0000

On Fri, 22 Feb 2019 at 15:08, Ca By <cb.list6@gmail.com> wrote:
>
>
>
> On Thu, Feb 21, 2019 at 8:31 PM Kristian McColm <kristianmccolm@hotmail.com> wrote:
>>
>> Then by that same token, can the end user devices, network services and network devices not provide their own packet filtering and other security mechanisms rather than forcing all network traffic to traverse centralized security devices?
>>
>> It won't be a popular opinion with network security folks and security appliance vendors, but I am a believer that the endpoint device is the right place to implement network security. Intermediary network devices should not, in my opinion be doing anything other than forwarding packets to their destination.
>
>
> +1, i have had a good experience removing stateful devices for the majority of flows from a large mobile network over the last 5 years as we transitioned for 464xlat.   No downsides.
>

+1

Encryption plus multipath transport layer protocols like MP-TCP is
really going to screw up a lot of things a lot of people are used to
doing in the network.

Multipathing doesn't just mean via two network interfaces, it may mean
different IPv6 addresses (say, one older, one newer, during
transition) temporary addresses on the same network interface.

Jump to the Impacts section on slide 63 if you want to cut to the chase.

"The Rapid Rise of the Mobile Multihomed Host, and what it might mean
to the network"
https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf

Regards,
Mark.


> And, with larger ipv6 space and random iid, discoverability risk is very low for 3rd parties / scans / botnets
>
> CB
>>
>> ________________________________
>> From: Tom Herbert <tom@herbertland.com>
>> Sent: Thursday, February 21, 2019 9:53:50 PM
>> To: Kristian McColm
>> Cc: Fernando Gont; IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
>>
>> Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
>>
>> On Thu, Feb 21, 2019 at 6:25 PM Kristian McColm
>> <kristianmccolm@hotmail.com> wrote:
>> >
>> > Amen to that. Make the end user devices responsible for their own security.
>> >
>> Kristian,
>>
>> Devices and applications are already responsible for their own
>> security. No serious application or OS would ever rely on the presence
>> of an external firewall for its security.
>>
>> However, there is still some benefit of stateful firewalls to protect
>> network resources from attack. So we want the functionality of a
>> stateful firewall in stateless solution without any of the annoying
>> limitations of stateful devices (like they only work with certain
>> protocols, force flows to traverse specific intermediate nodes, are
>> single points of failure, etc). FAST ( draft-herbert-fast-00) is one
>> proposal for this.
>>
>> Tom
>>
>> _______________________________
>> > From: v6ops <v6ops-bounces@ietf.org> on behalf of Tom Herbert <tom@herbertland.com>
>> > Sent: Thursday, February 21, 2019 9:23:38 PM
>> > To: Fernando Gont
>> > Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
>> > Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
>> >
>> > On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont <fgont@si6networks.com> wrote:
>> > >
>> > > On 21/2/19 22:58, JORDI PALET MARTINEZ wrote:
>> > > >
>> > > >     I agreee with that with one exception. I believe that NAT/IPv4 can
>> > > >     offer better privacy in addressing than IPv6 given current addess
>> > > >     allocation methods.
>> > > >
>> > > > I'm for as much privacy as possible, however, not at the cost of things such as:
>> > > > - Unnecessary complexity increase
>> > > > - Moving from peer-to-peer to client-server for everything
>> > > > - Single point of failure
>> > > > - Increasing the attacks chances by reducing the surface to the servers
>> > > > - Increase the complexity of app development
>> > > > - Complexity to host services in "clients"
>> > > > - Complexity to use "freely" and "efficient" DNS
>> > > > - etc
>> > >
>> > > There are two protocols associated with NATs:
>> > > 1) Apps that incorporate IP addresses and ports in the app protocol
>> > > require an ALG
>> > > 2) Because of of the "only allow outgoing connections" side-effect of
>> > > NATs, you need UPnP to open holes in the NAT, or some NAT traversal
>> > > technique.
>> > >
>> > >
>> > > "1)" goes away when you remove the NAT.
>> > >
>> > > "2)" does not if you replace the NAT with a stateful firewall that only
>> > > allows outgoing connections. -- the majority of the IPv6 deployments
>> > > I've seen use this policy/model. And, of course, this is also a single
>> > > point of failure, will also increase application complexity, etc., etc.,
>> > > etc.
>> >
>> > So we need to eliminate stateful firewalls as well as NAT...
>> >
>> > Tom
>> >
>> > >
>> > >
>> > >
>> > > --
>> > > Fernando Gont
>> > > SI6 Networks
>> > > e-mail: fgont@si6networks.com
>> > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> > >
>> > >
>> > >
>> > >
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------