On 8 February 2017 at 11:32, Jarno Rajahalme <ja...@ovn.org> wrote: > Add the fields of the conntrack original direction 5-tuple to struct > sw_flow_key. The new fields are initially marked as non-existent, and > are populated whenever a conntrack action is executed and either finds > or generates a conntrack entry. This means that these fields exist > for all packets that were not rejected by conntrack as untrackable. > > The original tuple fields in the sw_flow_key are filled from the > original direction tuple of the conntrack entry relating to the > current packet, or from the original direction tuple of the master > conntrack entry, if the current conntrack entry has a master. > Generally, expected connections of connections having an assigned > helper (e.g., FTP), have a master conntrack entry. > > The main purpose of the new conntrack original tuple fields is to > allow matching on them for policy decision purposes, with the premise > that the admissibility of tracked connections reply packets (as well > as original direction packets), and both direction packets of any > related connections may be based on ACL rules applying to the master > connection's original direction 5-tuple. This also makes it easier to > make policy decisions when the actual packet headers might have been > transformed by NAT, as the original direction 5-tuple represents the > packet headers before any such transformation. > > When using the original direction 5-tuple the admissibility of return > and/or related packets need not be based on the mere existence of a > conntrack entry, allowing separation of admission policy from the > established conntrack state. While existence of a conntrack entry is > required for admission of the return or related packets, policy > changes can render connections that were initially admitted to be > rejected or dropped afterwards. If the admission of the return and > related packets was based on mere conntrack state (e.g., connection > being in an established state), a policy change that would make the > connection rejected or dropped would need to find and delete all > conntrack entries affected by such a change. When using the original > direction 5-tuple matching the affected conntrack entries can be > allowed to time out instead, as the established state of the > connection would not need to be the basis for packet admission any > more. > > It should be noted that the directionality of related connections may > be the same or different than that of the master connection, and > neither the original direction 5-tuple nor the conntrack state bits > carry this information. If needed, the directionality of the master > connection can be stored in master's conntrack mark or labels, which > are automatically inherited by the expected related connections. > > The fact that neither ARP not ND packets are trackable by conntrack
* ARP nor ND > allows mutual exclusion between ARP/ND and the new conntrack original > tuple fields. Hence, the IP addresses are overlaid in union with ARP > and ND fields. This allows the sw_flow_key to not grow much due to > this patch, but it also means that we must be careful to never use the > new key fields with ARP or ND packets. ARP is easy to distinguish and > keep mutually exclusive based on the ethernet type, but ND being an > ICMPv6 protocol requires a bit more attention. > > Signed-off-by: Jarno Rajahalme <ja...@ovn.org> Acked-by: Joe Stringer <j...@ovn.org>
