Salvatore,
The 80% distinction came from a discussion I had at summit, representing that
the majority of features described by the current security groups could be
implemented today with OVS without connection tracking. It’s not based on any
mathematical calculation… more of a
Paul,
Beyond explicit configuration for the cloud operator, documentation and API
validation for the end user, is there anything specific you would like to see
as a “warning label”? Does iptables do TCP sequence number validation? Where we
can, we should strive to match iptables behavior.
Carl,
You are correct in both distinctions. Like I mentioned to Paul, beyond explicit
configuration for the cloud operator, documentation and API validation for the
end user, is there anything specific you would like to see as a “warning label”?
Amir
On Jun 3, 2014, at 9:01 AM, Carl Baldwin
I would like to understand how did we get to this 80%/20% distinction.
In other terms, it seems conntrack's RELATED features won't be supported
for non-tcp traffic. What about the ESTABLISHED feature? The blueprint
specs refers to tcp_flags=ack.
Or will that be supported through the source port
Amir Sadoughi wrote:
Specifically, OVS lacks connection tracking so it won't have a RELATED feature
or stateful rules
for non-TCP flows. (OVS connection tracking is currently under development, to
be released by 2015
It definitely needs a big obvious warning label on this. A stateless
How does ovs handle tcp flows? Does it include stateful tracking of tcp --
as your wording below implies -- or does it do stateless inspection of
returning tcp packets? It appears it is the latter. This isn't the same
as providing a stateful ESTABLISHED feature. Many users may not fully
