-
Notifications
You must be signed in to change notification settings - Fork 1
Home
#NetAssay
NetAssay is a system to allow the use of higher level primitives for filtering flows. Currently, the only ways of filtering is based on network headers, like IP addresses, MACs, protocols, and ports. This is well and good, but doesn't allow for easy dynamic changes based on something higher level. Being able to filter based on, say, a domain name such as example.com, or a network application type such as video traffic, or based on a network path such as traffic from AS 64496, can be invaluable for network operators.
We define Network Principals as what something is, what something is called, and what something does. Web traffic is what something is, example.com is a domain's name, and a user that visits example.com is a user of example.com. Now, NetAssay allows you have filters based on these high level principals.
Unfortunately, there aren't any switches that will recognize "example.com" and be able to filter based on that. This means that we need to find a mapping from high-level principal down to something that switches can understand, such as what is in network headers.
The good news is that there are many systems out there that already do this! DNS provides us a mapping from domains to IP addresses. BGP provides us a mapping from Autonomous System to IP address prefixes. ARP maps IPs to MACs, 802.1X maps users to MACs...
NetAssay uses these mappings to to create equivalent rule sets. For example, say example.com has two servers at IPs 98.41.100.2 and 98.41.100.3, and we wanted to filter on traffic going in both directions. We could say that the equivalent rule set is:
match(srcip='98.41.100.2) + match(dstip='98.41.100.2) + match(srcip='98.41.100.3) + match(dstip='98.41.100.3)
To perform this mapping from network principal to equivalent rule sets, we've come up with an abstraction called a Metadata Engine (ME). A ME takes an outside data source (say a lookup table matching ports to network protocols or a connection to a BGP server that passes in BGP updates), the network principal that the user wants to use (such as 'SQL' or 'AS 64496') and creates the equivalent rule set (such as port 118 or 128.66.88.0/24).
There is one inherent piece that is missing however. These mapping change all the time. The network principal does This needs to be handled carefully and quickly. Using BGP as an example, BGP routes change frequently. The mapping of example.com may change from 128.66.88.0/24 to 128.66.88.0/24 and 128.66.130.0/24. This means that the equivalent ruleset needs to change, update the overall set of rules, and push these to the switches.
The main control module is less fancy than one would think - it's more of an interface from Pyretic to the MEs than anything else.
There are examples of the various function in this directory.
This is based on the Pyretic project out of Princeton University.
Sean Donovan is the only current author for the NetAssay project, but is happy to have further contributors.