Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.

2015-10-13 Thread Jarno Rajahalme

> On Oct 13, 2015, at 3:39 PM, Joe Stringer  wrote:
> 
> Thanks all, I made some minor fixups (mostly documentation) and pushed
> this series to master.
> 
> Next step: Datapath backport!

This is great!! Thanks Joe!

  Jarno

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev


Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.

2015-10-13 Thread Joe Stringer
On 2 October 2015 at 14:16, Joe Stringer  wrote:
> This series adds support for sending packets through a connection tracker,
> which allows OVS to perform stateful firewalling functions. The functionality
> added in this series works in conjunction with the interface proposed in the
> in the current upstream Linux kernel development release, expected to become
> Linux-4.3. The linux datapath backport is not included in the series at this
> time, but a work in progress version is made available in a branch (see 
> below).
>
> The functionality is manipulated through a new action "CT" and several new NXM
> fields: ct_state, ct_zone, ct_mark, ct_label. The CT action allows these 
> fields
> to be populated, and for connections that match the flow to be tracked. Later
> patches in the series also allow metadata to be attached to these connections.
>
> When a flow is sent through the connection tracker, there are two common
> functions to perform. Firstly, match packets from port 1 and do a lookup:
>
> ovs-ofctl add-flow br0 "in_port=1,actions=ct(table=1)"
>
> When the table is specified, the ct action forks pipeline processing in two.
> The original instance of the packet will continue processing the current
> actions list as an untracked packet. An additional instance of the packet will
> be sent to the connection tracker, which will be re-injected into the OpenFlow
> pipeline to resume processing in the specified table, with the ct_state and
> other ct match fields set.
>
> The connection state, as represented in the ct_state field, consists of a
> collection of flags, including:
> - Tracked (trk): Connection tracking has occurred.
> - Reply (rpl): The flow is in the reply direction.
> - Invalid (inv): The connection tracker couldn't identify the connection.
> - New (new): This is the beginning of a new connection.
> - Established (est): This is part of an already existing connection.
> - Related (rel): This connection is related to an existing connection.
>
> When the first packets for a new connection are sent through the connection
> tracker, the ct_state will have the "+trk+new" flags set. The OpenFlow
> controller may specify a policy to match new connections and allow or deny
> them.
>
> The second function of the ct action is to "commit" the connections. This
> signals to the connection tracker that this connection should be tracked on an
> ongoing basis, so that subsequent packets may be identified as belonging to
> this connection. For instance, to allow new connections from port 1->2:
>
> ovs-ofctl add-flow br0 \
> "in_port=1,ip,ct_state=+trk+new,action=ct(commit),2"
>
> Later packets in the connection will have the "+est" flag set, so existing
> connections may be allowed as so:
>
> ovs-ofctl add-flow br0 "in_port=1,ip,ct_state=+trk+est,action=2"
>
> In addition to the above, several other parameters may be provided to the ct
> action:
> - zone: A 16-bit value or NXM field to retrieve the zone from. Each zone is an
>   independent connection tracking context. Connections which are committed to
>   zone A will not be remembered in zone B, unless the connection is also
>   explicitly committed to zone B.
>
>   eg: actions=ct(zone=1),ct(zone=NXM_NX_REG0[0..15])
>
> - exec: Execute a nested set of actions. This allows additional functions to 
> be
>   performed as part of the connection tracking execution. In this series, the
>   set_field, reg_move and reg_load actions are supported with two connection
>   tracking metadata fields: ct_mark and ct_label. No other actions are
>   supported.
>
>   eg: actions=ct(commit,exec(set_field:1->ct_mark))
>
> - alg: Specify an ALG to assist connection tracking. Some protocols consist of
>   multiple traffic streams that are impossible to associate without additional
>   context. This parameter provides that context to the connection tracker to
>   make it possible to track, for instance, FTP data connections.
>
>   eg: actions=ct(commit,alg=ftp)
>
> Further examples are available in the commit messages for each patch, the
> ovs-ofctl(8) man pages, and the traffic testsuite in tests/system-traffic.at.

Thanks all, I made some minor fixups (mostly documentation) and pushed
this series to master.

Next step: Datapath backport!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev


Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.

2015-10-05 Thread Joe Stringer
On 5 October 2015 at 15:32, Ben Pfaff  wrote:
> On Fri, Oct 02, 2015 at 02:16:07PM -0700, Joe Stringer wrote:
>> This series adds support for sending packets through a connection tracker,
>> which allows OVS to perform stateful firewalling functions. The functionality
>> added in this series works in conjunction with the interface proposed in the
>> in the current upstream Linux kernel development release, expected to become
>> Linux-4.3. The linux datapath backport is not included in the series at this
>> time, but a work in progress version is made available in a branch (see 
>> below).
>
> I think I've acked every patch except 11 (I'll defer to Daniele on that
> one).

Thanks for the review. I already got review from Daniele on the last
round for patch 11.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev


Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.

2015-10-05 Thread Ben Pfaff
On Fri, Oct 02, 2015 at 02:16:07PM -0700, Joe Stringer wrote:
> This series adds support for sending packets through a connection tracker,
> which allows OVS to perform stateful firewalling functions. The functionality
> added in this series works in conjunction with the interface proposed in the
> in the current upstream Linux kernel development release, expected to become
> Linux-4.3. The linux datapath backport is not included in the series at this
> time, but a work in progress version is made available in a branch (see 
> below).

I think I've acked every patch except 11 (I'll defer to Daniele on that
one).
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev


[ovs-dev] [PATCHv4 00/11] Add support for connection tracking.

2015-10-02 Thread Joe Stringer
This series adds support for sending packets through a connection tracker,
which allows OVS to perform stateful firewalling functions. The functionality
added in this series works in conjunction with the interface proposed in the
in the current upstream Linux kernel development release, expected to become
Linux-4.3. The linux datapath backport is not included in the series at this
time, but a work in progress version is made available in a branch (see below).

The functionality is manipulated through a new action "CT" and several new NXM
fields: ct_state, ct_zone, ct_mark, ct_label. The CT action allows these fields
to be populated, and for connections that match the flow to be tracked. Later
patches in the series also allow metadata to be attached to these connections.

When a flow is sent through the connection tracker, there are two common
functions to perform. Firstly, match packets from port 1 and do a lookup:

ovs-ofctl add-flow br0 "in_port=1,actions=ct(table=1)"

When the table is specified, the ct action forks pipeline processing in two.
The original instance of the packet will continue processing the current
actions list as an untracked packet. An additional instance of the packet will
be sent to the connection tracker, which will be re-injected into the OpenFlow
pipeline to resume processing in the specified table, with the ct_state and
other ct match fields set.

The connection state, as represented in the ct_state field, consists of a
collection of flags, including:
- Tracked (trk): Connection tracking has occurred.
- Reply (rpl): The flow is in the reply direction.
- Invalid (inv): The connection tracker couldn't identify the connection.
- New (new): This is the beginning of a new connection.
- Established (est): This is part of an already existing connection.
- Related (rel): This connection is related to an existing connection.

When the first packets for a new connection are sent through the connection
tracker, the ct_state will have the "+trk+new" flags set. The OpenFlow
controller may specify a policy to match new connections and allow or deny
them.

The second function of the ct action is to "commit" the connections. This
signals to the connection tracker that this connection should be tracked on an
ongoing basis, so that subsequent packets may be identified as belonging to
this connection. For instance, to allow new connections from port 1->2:

ovs-ofctl add-flow br0 \
"in_port=1,ip,ct_state=+trk+new,action=ct(commit),2"

Later packets in the connection will have the "+est" flag set, so existing
connections may be allowed as so:

ovs-ofctl add-flow br0 "in_port=1,ip,ct_state=+trk+est,action=2"

In addition to the above, several other parameters may be provided to the ct
action:
- zone: A 16-bit value or NXM field to retrieve the zone from. Each zone is an
  independent connection tracking context. Connections which are committed to
  zone A will not be remembered in zone B, unless the connection is also
  explicitly committed to zone B.

  eg: actions=ct(zone=1),ct(zone=NXM_NX_REG0[0..15])

- exec: Execute a nested set of actions. This allows additional functions to be
  performed as part of the connection tracking execution. In this series, the
  set_field, reg_move and reg_load actions are supported with two connection
  tracking metadata fields: ct_mark and ct_label. No other actions are
  supported.

  eg: actions=ct(commit,exec(set_field:1->ct_mark))

- alg: Specify an ALG to assist connection tracking. Some protocols consist of
  multiple traffic streams that are impossible to associate without additional
  context. This parameter provides that context to the connection tracker to
  make it possible to track, for instance, FTP data connections.

  eg: actions=ct(commit,alg=ftp)

Further examples are available in the commit messages for each patch, the
ovs-ofctl(8) man pages, and the traffic testsuite in tests/system-traffic.at.

---
This series is also available here with WIP datapath support:
https://github.com/justinpettit/ovs conntrack

---
v4: Reduce duplicate code for parsing ct_labels
Simplify reg_load for 128-bit fields
More testing of commandline formatting for fields
ct_label byte ordering is now consistent with conntrack-tools
Update for latest proposed interface changes
Minor bugfixes
Add several acks
v3: Change label OpenFlow wire format to be128.
Extend ct_state to 32 bits on the wire (remains 16 bits in flow).
Expand on ovs-ofctl documentation for ct fields and action.
Add several new OpenFlow wire-format and formatting tests.
Handle nested actions parsing with the correct OpenFlow version.
Tighten corner case error handling.
Add some new system tests passing packets via the local stack.
v2: Applied patches 1-2.
Expand NXM_NX_CT_STATE to 16 bits (datapath remains 8 bits).
Extend interface documentation, particularly in meta-flow and ofp-actions.
Addressed feedback from v1.
v1: First non-