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

[Kristian McColm <[e-mail]>]

What you describe is, unless I missed something, network segmentation. I absolutely agree that network segmentation, either physical or virtual, is an important concept in network security. Separating customer facing interfaces from management interfaces is one example that comes to mind.

But I believe in the context of this discussion we are taking about layer 3 and up, deep packet inspection, flow analysis, and packet filtering, etc.

Even still, one could argue layer 1 and 2 segmentation is still done at the host level. The host has different physical or virtual interfaces that can have different policy in terms of routing/switching. The switches provide the different segments but the host ultimately decides which interface to put an ethernet frame onto, and if one arrives, how it should be processed. Likewise, the owner of the host requests a port that will put the interface into an appropriate network segment.

In other words, the host still decides what resources it needs and how it uses them.

An important concept to understand is that networks do not create data, they are merely the conduit that hosts use to communicate with each other. So then, in my view, the creators and consumers of the data flowing across a given network should be the ultimate point of access control and auditing, not the conduit itself.


From: Raymond Burkholder <[e-mail]>
Sent: Friday, February 22, 2019 4:53:54 AM
To: Kristian McColm; Tom Herbert
Cc: Fernando Gont; IPv6 Operations; [e-mail]; JORDI PALET MARTINEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

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?