On Tue, Jul 04, 2017 at 07:17:05PM +1000, Marc Boschma wrote: > My circumstance is that I have an environment of a very large enterprise > inter-network with a large number of intranets (many with overlapping address > space) that need to be proxied through a series of proxies to a shared / > inter-network service.Being able to track / log flows across the series of > proxies and or knowing the origin of a request is very useful from an > operations perspective. > > There is also a security requirement to track the client source IP address > and origin network - thus the interest in the namespace TLV which in our > circumstance would represent the origin network.
Actually this makes a lot of sense, and I didn't consider the case where you have multiple networks with the same addresses (which is a common problem for large enterprise networks and partner VPNs). It's true that a proxy (or a series of proxies) sometimes make it possible to interconnect overlapping networks. And a single address has a different meaning for different nodes, so being able to transmit sort of a node ID or network ID to be used as a namespace makes quite some sense. Now one of the issues is what to do with such information once relayed between proxies. Ideally only the first one filling the entry should set this element and other ones should simply pass it unmodified. This could be seen as some extension to the existing namespace system (including internally in the connections) to be able to deal with an element set on the bind lines for example. For example if we had a "netid" parameter on the bind line, we could imagine logging it and passing it in headers along with the source address. Maybe adding a 32-bit field into struct connection to store such an element would be a good start. I was thinking about abusing the existing ns_entry for this until I realized that containers might overlap between machines and furthermore require having their own netid as well. So in the end I tend to like your idea :-) Willy
