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

Kristian McColm <kristianmccolm@hotmail.com> Fri, 22 February 2019 03:31 UTC

Return-Path: <kristianmccolm@hotmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0956130E11; Thu, 21 Feb 2019 19:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.125
X-Spam-Level:
X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=hotmail.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 2fpF7l_u4SVH; Thu, 21 Feb 2019 19:31:24 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002088.outbound.protection.outlook.com [40.92.2.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6DB128B33; Thu, 21 Feb 2019 19:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zFzr+egheE1OI3b0QJOy3fcP6DSHMGYxEWWpkLVUZ4M=; b=p+3pDgzMQCaS0RNHFGV39DpOcKYzjz+v7FfWHUHem/nIIkoURmPjBA+3D4c9ldxnaSEB9y3b54k0wM5RqRlXCY01YEcBebMvQcDyvhqr0gkhreqUMI2JzN1qZmXqJL1fBr3h8p2jjpUyiZoFjb8G3VL2WIBDb1eh1Wp0U+7s1Diixjfxr96WUuev2OV37tyfALPxsJNXv4CBC9xsFQhpnxH6K9VfNUlsRWGUuDDWe4OBRAezTEUQ56rVHVCpeLP5YIEPpLJtuKn0/OhmY45D1XLENWxu8KOjRr4KI9hNVEVBGvbIoW016F3c7JpylMCJz7RbF+A/Qa1d2tLuYRVPTA==
Received: from SN1NAM01FT044.eop-nam01.prod.protection.outlook.com (10.152.64.60) by SN1NAM01HT167.eop-nam01.prod.protection.outlook.com (10.152.65.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Fri, 22 Feb 2019 03:31:23 +0000
Received: from DM6PR04MB4009.namprd04.prod.outlook.com (10.152.64.54) by SN1NAM01FT044.mail.protection.outlook.com (10.152.65.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11 via Frontend Transport; Fri, 22 Feb 2019 03:31:23 +0000
Received: from DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968]) by DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968%5]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 03:31:23 +0000
From: Kristian McColm <kristianmccolm@hotmail.com>
To: Tom Herbert <tom@herbertland.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>
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
Thread-Topic: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
Thread-Index: AQHUylQ7xClo1pMmD0qbB4iWLKyk0aXrFpQAgAAAlH2AAAfcAIAACn2D
Date: Fri, 22 Feb 2019 03:31:23 +0000
Message-ID: <DM6PR04MB40096241EB14D0526F7131CDDD7F0@DM6PR04MB4009.namprd04.prod.outlook.com>
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>
In-Reply-To: <CALx6S36_aOy3273zGM+26z+04xF2q4_iBfj6LkFjX3qvuJZERw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:5E372F61856D06B4BC176C745AE1596DE00C80E2D35AEF44ADCFED59870030C3; UpperCasedChecksum:7AF867D7BC31208C3CA78B2923DE9B85B6D0B38C4781AB1EF94802FA60E81DB7; SizeAsReceived:8020; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [4Ar1q2mnjL9MiW7ETtB7w2sSdLT7BvCg]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031324274)(2017031323274)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM01HT167;
x-ms-traffictypediagnostic: SN1NAM01HT167:
x-microsoft-antispam-message-info: MTjV4jAHOxG7DVJZ7YDEl/sQvHgv2NyvCz9/OaANAdHIZGFt7SduThDkmQi12Krr
Content-Type: multipart/alternative; boundary="_000_DM6PR04MB40096241EB14D0526F7131CDDD7F0DM6PR04MB4009namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c6d992c-c519-4912-ac44-08d69876381e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 03:31:23.3450 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT167
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SRxOIJo2nuGexMd49paAN4A7qag>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 03:31:27 -0000

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