)]}' { "commit": "9dd7f8907c3705dc7a7a375d1c6e30b06e6daffc", "tree": "9330b1d7ffe29ec0f1c06bf8ff73c5c7d1c258ce", "parents": [ "09aa98ad496d6b11a698b258bc64d7f64c55d682" ], "author": { "name": "Jarno Rajahalme", "email": "jarno@ovn.org", "time": "Thu Feb 09 11:21:59 2017 -0800" }, "committer": { "name": "David S. Miller", "email": "davem@davemloft.net", "time": "Thu Feb 09 22:59:34 2017 -0500" }, "message": "openvswitch: Add original direction conntrack tuple to sw_flow_key.\n\nAdd the fields of the conntrack original direction 5-tuple to struct\nsw_flow_key. The new fields are initially marked as non-existent, and\nare populated whenever a conntrack action is executed and either finds\nor generates a conntrack entry. This means that these fields exist\nfor all packets that were not rejected by conntrack as untrackable.\n\nThe original tuple fields in the sw_flow_key are filled from the\noriginal direction tuple of the conntrack entry relating to the\ncurrent packet, or from the original direction tuple of the master\nconntrack entry, if the current conntrack entry has a master.\nGenerally, expected connections of connections having an assigned\nhelper (e.g., FTP), have a master conntrack entry.\n\nThe main purpose of the new conntrack original tuple fields is to\nallow matching on them for policy decision purposes, with the premise\nthat the admissibility of tracked connections reply packets (as well\nas original direction packets), and both direction packets of any\nrelated connections may be based on ACL rules applying to the master\nconnection\u0027s original direction 5-tuple. This also makes it easier to\nmake policy decisions when the actual packet headers might have been\ntransformed by NAT, as the original direction 5-tuple represents the\npacket headers before any such transformation.\n\nWhen using the original direction 5-tuple the admissibility of return\nand/or related packets need not be based on the mere existence of a\nconntrack entry, allowing separation of admission policy from the\nestablished conntrack state. While existence of a conntrack entry is\nrequired for admission of the return or related packets, policy\nchanges can render connections that were initially admitted to be\nrejected or dropped afterwards. If the admission of the return and\nrelated packets was based on mere conntrack state (e.g., connection\nbeing in an established state), a policy change that would make the\nconnection rejected or dropped would need to find and delete all\nconntrack entries affected by such a change. When using the original\ndirection 5-tuple matching the affected conntrack entries can be\nallowed to time out instead, as the established state of the\nconnection would not need to be the basis for packet admission any\nmore.\n\nIt should be noted that the directionality of related connections may\nbe the same or different than that of the master connection, and\nneither the original direction 5-tuple nor the conntrack state bits\ncarry this information. If needed, the directionality of the master\nconnection can be stored in master\u0027s conntrack mark or labels, which\nare automatically inherited by the expected related connections.\n\nThe fact that neither ARP nor ND packets are trackable by conntrack\nallows mutual exclusion between ARP/ND and the new conntrack original\ntuple fields. Hence, the IP addresses are overlaid in union with ARP\nand ND fields. This allows the sw_flow_key to not grow much due to\nthis patch, but it also means that we must be careful to never use the\nnew key fields with ARP or ND packets. ARP is easy to distinguish and\nkeep mutually exclusive based on the ethernet type, but ND being an\nICMPv6 protocol requires a bit more attention.\n\nSigned-off-by: Jarno Rajahalme \u003cjarno@ovn.org\u003e\nAcked-by: Joe Stringer \u003cjoe@ovn.org\u003e\nAcked-by: Pravin B Shelar \u003cpshelar@ovn.org\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "96aee34ef55f5ab5328bd8f2a211aa769bcb0dc1", "old_mode": 33188, "old_path": "include/uapi/linux/openvswitch.h", "new_id": "90af8b8e10f8f0ef358ff989309cdca7fa52b552", "new_mode": 33188, "new_path": "include/uapi/linux/openvswitch.h" }, { "type": "modify", "old_id": "efa9a8858cc6a474022f7f210250f0743ac6cf8c", "old_mode": 33188, "old_path": "net/openvswitch/actions.c", "new_id": "b1beb2b94ec76c6a8e415019439d09e47d11a7df", "new_mode": 33188, "new_path": "net/openvswitch/actions.c" }, { "type": "modify", "old_id": "f989ccf38eab49428b7d4fa273eabf4bb02bb6f2", "old_mode": 33188, "old_path": "net/openvswitch/conntrack.c", "new_id": "bfd7606c8be1fe01cd2542d36564ee6f7339defb", "new_mode": 33188, "new_path": "net/openvswitch/conntrack.c" }, { "type": "modify", "old_id": "8f6230bd618333561b2c4636a3f8f52356a6bd6c", "old_mode": 33188, "old_path": "net/openvswitch/conntrack.h", "new_id": "9e92445dc0924172a5b3c46bda00c0750905f148", "new_mode": 33188, "new_path": "net/openvswitch/conntrack.h" }, { "type": "modify", "old_id": "2c0a00f7f1b7d195b98f70e6ec0235b650a63311", "old_mode": 33188, "old_path": "net/openvswitch/flow.c", "new_id": "9d4bb8eb63f25c2e9e9e5f4190e6c943a32be547", "new_mode": 33188, "new_path": "net/openvswitch/flow.c" }, { "type": "modify", "old_id": "f61cae7f9030df68c3001e5e63dc2c903b3d1d3f", "old_mode": 33188, "old_path": "net/openvswitch/flow.h", "new_id": "76e05b25f03039f5e58bcf9338d540ac0f0408a9", "new_mode": 33188, "new_path": "net/openvswitch/flow.h" }, { "type": "modify", "old_id": "c87d359b9b37a07711c65e61a1cb882148f76ee0", "old_mode": 33188, "old_path": "net/openvswitch/flow_netlink.c", "new_id": "989f38f120bb41fe0d8810ed8760d259debe1d1d", "new_mode": 33188, "new_path": "net/openvswitch/flow_netlink.c" }, { "type": "modify", "old_id": "45f9769e5aaccdc46f60eaff5672034b48622ebd", "old_mode": 33188, "old_path": "net/openvswitch/flow_netlink.h", "new_id": "929c665ac3aa99c8eb9635ea72a45c50743d60af", "new_mode": 33188, "new_path": "net/openvswitch/flow_netlink.h" } ] }