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

Raymond Burkholder <ray@oneunified.net> Fri, 22 February 2019 04:54 UTC

Return-Path: <ray@oneunified.net>
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 EA2BA130EA2; Thu, 21 Feb 2019 20:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 qy9-iJ_k4HHW; Thu, 21 Feb 2019 20:54:10 -0800 (PST)
Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D593B130E90; Thu, 21 Feb 2019 20:54:09 -0800 (PST)
X-One-Unified-MailScanner-Watermark: 1551416040.18827@tw0HXBLUDGuPm2mms1UG2g
X-One-Unified-MailScanner-From: ray@oneunified.net
X-One-Unified-MailScanner: Not scanned: postmaster@oneunified.net
X-One-Unified-MailScanner-ID: x1M4rs61005474
X-OneUnified-MailScanner-Information: Please contact the ISP for more information
Received: from [10.55.40.131] (h96-45-2-121-eidnet.org.2.45.96.in-addr.arpa [96.45.2.121] (may be forged)) (authenticated bits=0) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id x1M4rs61005474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2019 04:53:56 GMT
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
To: Kristian McColm <kristianmccolm@hotmail.com>, 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>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@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>
From: Raymond Burkholder <ray@oneunified.net>
Organization: One Unified Net Limited
Message-ID: <e08695a1-6735-46c3-e85a-be349dde1811@oneunified.net>
Date: Thu, 21 Feb 2019 21:53:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <DM6PR04MB40096241EB14D0526F7131CDDD7F0@DM6PR04MB4009.namprd04.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------E01D869EA1E47D918FE031AE"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/C1oJAUmBftHdSpC5UHmPDj0FgvQ>
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 04:54:11 -0000

On 2019-02-21 8:31 p.m., Kristian McColm 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.

There is a grey area here, from my experience.  With virtualization and 
containers, hosts are becoming routers, with the host thus being an 
intermediary device.  And there is tooling available which allows the 
host to apply protection policies as well as segregation policies to the 
virtualized functions it hosts.

In other configurations, in a traditional vein, 'switches' connect hosts 
of various sorts, and in that same traditional vein, are intermediary 
devices and just forward packets.

But there are security flavours out 'there' where the switch is no 
longer just a switch.  For those end-points which are unable or are 
unwilling to handle their own security, there is a form of network 
topology where  the 'switch' becomes more intelligent and can perform 
security functions on ingress/egress at the port level. This provides a 
form of distributed nonSPOF style protection mechanisms.

In combining the concepts of the virtualization host I mentioned 
initially, and this edge 'protection switch', they are both sharing the 
concept of distributed nonSPOF security functionality (which I suppose 
is part of what Network Function Virtualization does).  As one specific 
example, I'll mention Cillium, which is highly IPv6 aware, and excels at 
providing this distributed routing/security/forwarding function in a 
distributed fashion.

So I think there is a happy medium: some end points devices just can't 
do their own security, and for paranoid network operators, you can't 
trust that they can, as well as from an endpoint developer perspective 
(think microservices), you don't want them to. Providing those services 
at the connecting port level is the next best thing for the consistent, 
distributed and reliable application of protection rules?