Salomon, Jesse

Seipp, Kyle

English

Technical Disclosure Common

Technical Disclosure Commons Defensive Publications Series May 2020 Mechanism for Identifying Export Rules for a Given Subnet from an Export Rule String Kyle Seipp Pure Storage, Inc. Jesse Salomon Pure Storage, Inc. Follow this and additional works at: https://www.tdcommons.org/dpubs_series Recommended Citation Seipp, Kyle and Salomon, Jesse, "Mechanism for Identifying Export Rules for a Given Subnet from an Export Rule String", Technical Disclosure Commons, (May 02, 2020) https://www.tdcommons.org/dpubs_series/3210 This work is licensed under a Creative Commons Attribution 4.0 License. This Article is brought to you for free and open access by Technical Disclosure Commons. It has been accepted for inclusion in Defensive Publications Series by an authorized administrator of Technical Disclosure Commons.      PURE STORAGE DEFENSIVE PUBLICATION Mechanism for Identifying Export Rules for a Given Subnet from an Export Rule String  Kyle Seipp Jesse Salomon2Seipp and Salomon: Mechanism for Identifying Export Rules for a Given Subnet from anPublished by Technical Disclosure Commons, 2020Mehanism for Identifying Export Rules for aGiven Subnet from an Export Rule StringApril 20, 20201 BakgroundCustomers want to know whih IP addresses on whih systems have mison-gurations. However, it is diult for them to determine whih addresses andsubnets have this issue beause the export rules explain what the urrent rulesare, but not how they apply to a given IP or subnet. We have developed analgorithm to help determine the rules for their hosen IPs and subnets.For example, the ustomer would give us some input rule subjet like 1.2.3.4or 1.2.3.0/28 as well as a Export Rule String like 1.2.3.4 foo 1.2.3.5 bar1.2.3.4/30 bat. And we want to be able to output what the export rules are forthe inputed NetObj and where they ome from. In the rst example we wouldwant to output 1.2.3.4 has rule foo. In the seond example we would wantto outputInput NetObjet String Breakdown Inherited From Rules1.2.3.0/28 1.2.3.0/30 - Deny1.2.3.4 1.2.3.4 foo1.2.3.5 1.2.3.5 bar1.2.3.6/31 1.2.3.4/30 bat1.2.3.8/29 - Deny1.1 Key Denitions• A NetworkObjet or NetObj is an IP address or subnet. It an be ipv4 oripv6 based• A rule subjet is a NetObj in an export rule string that has some rulesassoiated with it.2 Brief Summary of NFS Export RulesAn NFS export rule is a list of settings for a given Filesystem and whih IPsand/or subnets these settings should apply to. In general, an export rule is13Defensive Publications Series, Art. 3210 [2020]https://www.tdcommons.org/dpubs_series/3210made up of alternating a rule subjet, and then some set of rules that apply toit. These rules take preedene in the order of spei IPs from left to right,then subnets from left to right, and then any global wildard rules. However,if any rule subjet is repeated, use its rightmost instane. This format is well-known, publi and doumented as part of the NFS spe. An example rule stringis desribed in the bakground setion above.Typially one parses these rules into a strut of a 3-tuple made up of 2 listsand a string. The rst list represents the IP rule strings. It is a potentiallyempty list of 2-tuples that are the IP and the rules assoiated with that IP. Theseond list is the same, but for subnets. The string is the list of rules for thewildard subnet. This string is potentially empty if there are no wildard rules.An example of this data struture would look something like thisstrut ExportRuleDataStrut {list<tuple<str, str>> ip_rule_list;list<tuple<str, str>> subnet_rule_list;str rule_string_for_wildards;}( [ ( " ip1 " ," ru l e s t r i n g f o r ip1 " ) , ( " ip2 " ," ru l e s t r i n g f o r ip2 " ) ℄ ,[ ( " subnet1 " ," subnet1 r u l e s " ) , ( " subnet2 " ," subnet2 r u l e s " ) ℄ ," r u l e s t r i n g f o r wi ldard subnet ")Note that transforming the export rules into suh a data struture is wellknown and standard via the NFS spe. Thus, we will disuss operating on suh adata struture interhangeably with operating on an expliit export rule string.Further, note that as part of reating suh a data struture, we automatiallyollapse repeated subjets to their rightmost instane and preserve the order ofthe IPs and subnets from left to right.3 Naive ApproahSuppose one wished to solve the problem as disussed in the Bakground setionwithout using the algorithm that will be disussed below. They would have asinput a NetObj and an export rule string. They an trivially onvert that exportrule string into an export rule data struture as desribed above. If the inputrule subjet is an IP and expliitly listed in the data struture, it an be foundin O(number of rules) time by expliitly searhing through the data struture.If is a subnet, then it takes at least O(rules2). The reason for this is that wemust hek eah IP and subnet to the left to see if it is a subset. We must do thisreursively to ensure that any of *those* sub-subnets have no sub-subnets orIPs. If the input rule subjet is a strit subset of a subnet in the data struture,we an also nd it in O(number of rules) time. However, if the input subjet isa superset of subnets in the data struture, we must look for every subset. Wemust then join them together and hek that this makes up the entire breadthof the input subjet. This joining is not entirely trivial beause some subnets24Seipp and Salomon: Mechanism for Identifying Export Rules for a Given Subnet from anPublished by Technical Disclosure Commons, 2020might be fully overed by expliit IPs. It is the proess of joining quikly andeasily that is the main subjet of this patent. To naively hek that all IPs andsubnets that are part of the input subjet are represented, we must expliitlylook at every IP in the region. In the worst ase, this an be 232 IPv4 addresses,whih is prohibitively expensive and even worse for IPv6.4 Algorithm Desription4.1 Converting from Rule String to Data StrutureAs mentioned in Setion 2 above, we onsider this proess a given from the NFSSpe. If the struture is empty, we an short iruit the rest of the algorithm andrespond with a blanket deny. We an onvert all of the IPs in the struture intotrivial subnets. For example an ip 1.2.3.4 would be onverted into 1.2.3.4/32.We an also onvert any wildard rules into rules assoiated with the maximalsubnet  0.0.0.0/0. This means that the entire data struture is made up ofsubnets. Note that we will preserve ordering. Therefore, the leftmost elementswill be trivial subnets if there are any and the rightmost subnet will be 0.0.0.0/0if there is a wildard entry.4.2 Building a Network Tree4.2.1 Dening a Network TreeWe are going to build a data struture we all a Network Tree. This strutureis a binary tree made up of nodes. A node of the Network Tree is a strutmade up of ve parts, a subnet, a rule soure, and pointers to its parent andboth hildren. The subnet is the name of the node and represents what partof the NetObj spae the node represents. The rule soure represents whih setof export rules apply to this node. Note that None is a valid value for rulesoure. The pointers to parents and hildren represent how the nodes attah toone another. Note that a node is either a leaf node or it isn't. A leaf node hasno hildren. A non-leaf node must have both of its hildren. A Tree is denedby a root node, and its desendants. The parent of the root node is None.The subnets of nodes and the relationships between nodes is deterministiand depends entirely on the subnet. We will desribe how this works usingIPv4, but this will work in exatly the same manner with IPv6. A given nodehas a subnet property. For example, 1.2.3.4/30. This subnet an be partionedinto two halves  1.2.3.4/31 and 1.2.3.6/31. Thus, those two nodes are thetwo hildren of the 1.2.3.4/30 node. Sine 1.2.3.4/30 and 1.2.3.0/30 ompletelypartition 1.2.3.0/29, they are the hildren of 1.2.3.0/29. Thus, 1.2.3.0/29 is theparent of 1.2.3.4/30. Note that a parent will always have a netmask that is onesmaller and that a hild will always have a netmask that is one larger. Notethat some subnets are of size 1 and orrespond to exatly one IP address, like1.2.3.0/32. These nodes will never have hildren. Additionally 0.0.0.0/0 has noparent beause it ontains the entire NetObj spae.35Defensive Publications Series, Art. 3210 [2020]https://www.tdcommons.org/dpubs_series/3210Figure 1: Network Tree Node Example1.2.3.4/30"None"1.2.3.0/29Parent Node1.2.3.4/31Left Child1.2.3.6/31Right Child4.2.2 Adding NodesSuppose we have an existing Network Tree as in the example from Figure 1.Note that in the gure, only one node is shown beause the parent and hildrennodes don't have a rule soure. They are shown to explain what the parent andhild would be. How would we add a hild to the 1.2.3.4/30, say 1.2.3.4/31. Wesee that the urrent node has the new node as a diret hild. So, we reate anew node with subnet 1.2.3.4/31 and set the hild point from the parent and theparent pointer in the hild to point to one another. We an set its rule soure.We also must reate the other hild node of 1.2.3.6/31. Now we are done.What if we want to add a desendant that is not a diret hild? We reateboth hildren of the urrent node. Then we determine whih of those is ananestor of the target node. Then, we reate that nodes hildren. Continue inthis manner until we reate the hild that we intended as a leaf node. It is fullyonneted to the root node that we started with.What if we want to add an anestor? We reate the parent node of the rootnode of the Network Tree and set up the pointers. Then, we set the parent asthe root node of the tree. Then we set up the other diret hild of the parentnode. This is the node that is the sibling of the original root node. This keepsall nodes having either 0 or 2 hildren.What if we want to add a node that is not a desendant of the root node, andis not an anestor? This means that this node must be adjaent in some sense,though perhaps not a sibling. Create parent nodes (appropriately as desribedabove) until one of them is an anestor of the target node. Then, we an followthe rules for targets that are desendants of the root node as desribed above.46Seipp and Salomon: Mechanism for Identifying Export Rules for a Given Subnet from anPublished by Technical Disclosure Commons, 20204.2.3 Algorithm Steps1. We are going to build a NetworkTree from the elements of the ExportRule Data Strut. To do so, we are going to loop over the NetObjs in thestrut starting with the rst subnet.2. Create the node representing the element and set the rule soure to theelement. This is the root of the tree.3. Consider the next NetObj in the Data Strut. Call it the urrent element.4. Start from the root and add the urrent element to the tree. The newelement must be either a desendant of the root node, an anestor of theurrent node, adjaent to the urrent node, or must be the urrent node.In setion 4.2.2 above we have already desribed how to add nodes to thetree in all of these ases. If the urrent element is equal to the root nodeand the root node has None as its rule soure, set the rule soure to theurrent element. If the rule soure is already set, then we are done withthis element and we an return to step 3.5. If the urrent element is not equal to the root node, we want to reatethe new node (and the onneting nodes) as disussed above in setion4.2.2. The onneting nodes should have the rule soures left as None.The new target node should have its rule soure set to that of the urrentelement. As disussed above, we also must reate the hildren of the newtarget node if they have not already been reated. When you set the rulesoure for any node as not None, you then look to see if we've alreadydened hildren nodes. If we have, then hek those hildren - eah onewhih urrently has rule soure as None will set its rule soure reursively(thus itself also heking for existing hildren and suh). If we haven't,then stop and don't bother reating the hildren. Notably, if we nd ahild with a rule soure whih is already set, then we don't have to hekits desendants - any that exist will guaranteed have the orret not-Nonerule soures. We are now done with the urrent element and an returnto step 3 to get a new element.6. When we have ompleted every subnet in the Data Struture (inludingthe wild ard entry) we are done building the NetworkTree.Note that this means that all nodes have either 0 or 2 hildren and that allnodes with 0 hildren (leaves) have a non-empty rule soure.4.3 Using the Network TreeNow that we have built this Network Tree, we an use it along with the originalData Struture, and the input NetObj to build the table that the ustomerwants. There are a few ases.57Defensive Publications Series, Art. 3210 [2020]https://www.tdcommons.org/dpubs_series/32101. If the input NetObj is a spei IP address, treat it as if it were the trivialsubnet.2. Suppose the input NetObj is a subnet that is a desendant of the rootnode. We start at the top of the Network Tree and move from node tohild based on whih of the two hildren will ontain the input NetObj.If we enounter a leaf node or a node with the same subnet as the inputNetObj, onsider the entire subtree with this this node as the root. Lookthrough all this subtree for their rule soures and look up the rule souresof the leaf nodes and put those into the table.3. Suppose the input is an anestor of the root node. Keep trak of theurrent root node. Muh like step 3 in setion 4.2, we want to reateparent nodes (and the empty sibling nodes) to the Network Tree's rootuntil we reah the speied anestor. The result will look something likethis. Now, we an mark all of those sibling nodes to the table as havinga rule soure of -. When we put these into the table, they will outputDeny to represent the fat that the export rule string should deny theseIPs aess. Then we an traverse the urrent tree to get the existing rules.Note that we do not want to save these temprorary expansions to theNetwork Tree in order to save spae. They are trivial to onstrut, sothey are not valuable for performane. To revert to the original tree, wean simply use the original root node that we saved at the beginning ofthe step. The other nodes have nothing in memory pointing to them, sothey are disarded. This is impliit based on implementation details.4. Suppose the input is adjaent to the root node. This means that there areno rules in the export rule string that desribe it. Thus, the entire tableshould be Deny.5 Advantages Over the Naive ApproahThis approah trades a trivial amount of memory in order to make this problemmuh faster in the normal use-ases and tratable in the more expensive ases.Additionally, beause we an ahe the Network Tree, subsequent runs with thesame set of export rules an be made even more heaply. However, under worstase senarios, this approah will still not perform well.First, we will ompare worst ases for both approahes. The worst ase forthe naive approah is an input NetObj of 0.0.0.0/0 and the entire rule string ismade up of expliit IPs. This will take 232 heks of eah expliit IP that an bein the NetObj against a 4096 harater export string. How does this ase fairfor our improved approah? Eah individual rule in the string will take about10 haraters at the shortest, so it will result in about 400 leaf nodes in theNetwork Tree. If they are maximally spread out, this means we need to traversethe entire tree from root to leaf, 400 times with a depth of 32. This works outto 400 ∗ 32 = 225225 = 2752 < 21268Seipp and Salomon: Mechanism for Identifying Export Rules for a Given Subnet from anPublished by Technical Disclosure Commons, 2020The worst ase for our improved approah is when we have to build a largeNetwork Tree. This ours when we have a large number of expliit rules,espeially with spread out expliit IP addresses beause it means we have moreintermediate nodes. Additionally, the worst ase is the largest input NetObjbeause it requires either having a large tree or temporarily inreasing its sizeduring exeution. Note that this is exatly the same as the ase above.The best ase senarios for both algorithms is the ase where the ustomerprovides empty rule strings or trivial input NetObjs. In these ases both algo-rithms will behave similarly by short iruiting to the right answer.What happens in the most ommon medium ases? In the naive approah wehave some input NetObj that is not ompletely overed by expliit IP addressesin the export rule string and some of the subnets likely overlap with either eahother or the expliit IPs. I laim that this is ommon beause the use asefor this system is to diagnose poorly set up export rules. Thus, one we haveexhausted the expliit IPs, the rest must be done by exhaustive lookup. Thissales with O(n) where n is the size of the subnet. Note that the size of thesubnet is 2value of the subnet size. How does this work in the new approah?Well we build up a sparse NetworkTree and we are able to nd a spei leafnode in O(log(n)) time. The majority of the leaf nodes are not going to besize-1 subnets. If they are, then the whole proess will take O(n) time whih isno faster than the naive approah. But if some of the leaf nodes are aused byhaving non-trivial subnets as leaf nodes, then we an run signiantly faster.6 Mis Notes• This system works regardless of IP version beause IPs and subnets alwayshave the same subsystem properties. The only dierene would be theupper and lower bounds on the number of rules and their sizes.79Defensive Publications Series, Art. 3210 [2020]https://www.tdcommons.org/dpubs_series/3210© Pure Storage 2017   | 2                        Pure Storage, Inc. Twitter: @purestorage  www.purestorage.com  650 Castro Street, Suite #400  Mountain View, CA 94041  T: 800-379-7873  Sales: sales@purestorage.com Support: support@purestorage.com Media: pr@purestorage.com General: info@purestorage.com 10Seipp and Salomon: Mechanism for Identifying Export Rules for a Given Subnet from anPublished by Technical Disclosure Commons, 2020

Mechanism for Identifying Export Rules for a Given Subnet from an Export Rule String

https://www.tdcommons.org/cgi/viewcontent.cgi?article=4282&context=dpubs_series

Mechanism for Identifying Export Rules for a Given Subnet from an Export Rule String

Abstract

Similar works

Full text

Available Versions

Technical Disclosure Common