On 11/11/14 at 03:11pm, Andy Zhou wrote:
> >
> > I would like to keep the option to share the same zones because I
> > can see a lot of value to match on CTs which have been created by
> > netfilter or vice versa.
> Is it sufficient if both ip_defrag and conntrack actions uses the same
> zone as their
> parameters?
It should be. I haven't actually tried it.
> >> Technically this cleaner. OVS IP_DEFRAG can be applied to either IN or
> >> OUT direction,
> >> depending on OF rules, thus only one zone is needed. I did not add a
> >> new zone for this patch
> >> since I have not found a good way to add compat header for it.
> >> >
> >> > A typical example would be:
> >> >
> >> > in_port(2),actions=ip_defrag(),...
> >>
> >> Why is this typical?
I should have left the word typical out of that sentence ;-)
> > Should have been more precise. A typical example in which the match
> > associated with the flow running the defrag action may not match all
> > packets which end up being reassembled.
> >
> > This specific discussion was held a couple of years back in the context
> > of netfilter where packets could bypass the iptables rules by getting
> > reassembled/defraged into a packet which was already accepted. Such a
> > packet may contain L2 bits or metadata which would require it to get
> > dropped by rules.
> What would be a good solution? It seems having OVS_IP_DEFRAG would
> solve the problem by preventing non OVS frames from being
> defragmented.
> That still leaves us with iif, which I am not sure if it is a problem
> -- OF rules can put iifs into different zones is required.
Agreed.
Adding OVS_IP_DEFRAG plus OVS_IP_DEFRAG_END with a 1:1 mapping to
conntrack zones is probably a good default. It assumes that OVS will
see all fragments which is a fair assumption in general.
That leaves the issue of handling a single OF flow which results
in multiple datapath flows:
in_port(1), actions=ip_defrag()
in_port(2), actions=ip_defrag()
The datapath flow handling the last fragment will get the 0 return
value from ip_defrag() and thus process the packet which is somewhat
unexpected as one would most probably expect the flow which has seen
the first packet or the offset = 0 fragment to process the packet.
That's merely an accounting issue though.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
