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

Tom Herbert <tom@herbertland.com> Fri, 22 February 2019 02:54 UTC

Return-Path: <tom@herbertland.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 2B12012F295 for <v6ops@ietfa.amsl.com>; Thu, 21 Feb 2019 18:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 thuwxgfPO8OL for <v6ops@ietfa.amsl.com>; Thu, 21 Feb 2019 18:54:03 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 DB0581288BD for <v6ops@ietf.org>; Thu, 21 Feb 2019 18:54:02 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id j36so974823qta.7 for <v6ops@ietf.org>; Thu, 21 Feb 2019 18:54:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aiBJv+9bXiIlG7COd5yckx+fFOmZJc2QFNXBII13a5U=; b=a8KVruEix3jVyEnZqw045oH5FECRTunoiitFFV/TLbUPjKpR7p8lrDKY5YorqxeLam 8Vgk9otX2Yk+GZg3FxLH3FRM5VYUjdA1ytxFprfhqYgYRJG9f9IljDaDwRRajIgux8V4 OWxlFQh7TfjE8KeqM1BxGMCYJetL+5FMyBrUJJkjg+Iwaii2BuSCrqKCSam/4qqMPaGH S9arU7VTr/fHV2PjRmPx07yhBPZPDvfJicBob6rqssLB1/bCh+hmPxqeSmonRKs1TEkO Kt7lUEsF+dcGwI35xf2ch26lnId2YslT8wlHFj8ryUsw9Jx3lJn5y8Uc7UDKVRInJ88f lw8A==
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; bh=aiBJv+9bXiIlG7COd5yckx+fFOmZJc2QFNXBII13a5U=; b=sIBSCclb8eZ3MigDn7i+qHz+9STfWohvrGdzBvdbrAoIJ7NP9tnzNx5PuKmp/Vh6/9 FdMB2TXDYaf/NYhtqPt3Z8aRJ3gSANKwjEq7BUMcnUcqUe+qZNZ2q8GmqNjj86txM+uo 93ow7mqTqiQcaDeydAyMzy9LjnphNHsUGTqKLgnAPPL++pfRG9y+KwMgoh5Q2PrzYVto Scaq5pnzSUqybTxt8NB90ffF1r+9Au4BmS3H59bSr4GbFzIQfttaXmy8dMcv5JiyDolX hajsyyEtYotwq2oOmceZBbFb9swbGg4FrDzbsMosTZXTDQuMhENvTaBbzvEah5SeX7Qi sGxg==
X-Gm-Message-State: AHQUAuaAt8rfj5/BPJ8TQmDuh70QaUcwaGXqagEilEQFK3hypcbNGb8J gnavz/xDDAr45gxSJiM97atSpatf7xF2WkhH7Umi/Q==
X-Google-Smtp-Source: AHgI3IbvLv3Ts7LPpFUMsFAaxxhBeFVUn1FHOa61SbR52zHfTOUcBn6lERWO7NwBWSAEw4e1400HNMXZlUFqclfZy64=
X-Received: by 2002:a0c:8dc2:: with SMTP id u2mr1439652qvb.168.1550804041656; Thu, 21 Feb 2019 18:54:01 -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>
In-Reply-To: <DM6PR04MB4009E6096E8CF525931D46A5DD7F0@DM6PR04MB4009.namprd04.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 21 Feb 2019 18:53:50 -0800
Message-ID: <CALx6S36_aOy3273zGM+26z+04xF2q4_iBfj6LkFjX3qvuJZERw@mail.gmail.com>
To: Kristian McColm <kristianmccolm@hotmail.com>
Cc: 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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XqtE6fBcikYlHlMMfPkwEOUTQgg>
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 02:54:05 -0000

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