Detection and Reporting of IP Flow Direction

1 Design
- 1.1 OVSDB Settings Requirements from the Controller
- 1.2 Flow Direction Reporting
- 1.3 Direction Determination
  - 1.3.1 Initial Implementation Details
  - 1.3.2 Direction & Originator Determination
    - 1.3.2.1 TCP
    - 1.3.2.2 UDP
- 1.4 Testing Instructions
2 Published Content

Design

OpenSync has the ability to detect and report the direction of an IP flow. Relevant policies (outbound, inbound, intra-LAN) can be applied according to the detected direction.

The accumulator structure is augmented using two fields indicating the overall flow direction. A flow is represented by two accumulators, each capturing stats for one of the directions (LAN-to-WAN or WAN-to-LAN). Next to the accumulator, a second field indicates which leg of the flow each field represents (the originator).

On creation of the accumulator, the direction field is marked as no direction set. The fsm_net_parser_to_acc() checks the direction field of the accumulator. If set to outbound or inbound, no more work is needed.

Otherwise:

fsm_net_parser_to_acc() looks up the reverse flow accumulator.
If the reverse flow accumulator has its direction set, then the original accumulator inherits the reverse flow accumulator direction.

Otherwise:

The original flow is processed to determine its direction, and the reverse flow accumulator inherits it.

OVSDB Settings Requirements from the Controller

The core_dpi_dispatch 'other_config' table needs a new (key, value) pair ("all_clients", <tag referring to all clients of the location>"). The following tag and Flow Service Manager (FSM) settings have been used during development:

$ ovsh -j s Openflow_Tag_Group -w name==all_clients name tags
[
    {
        "name": "all_clients",
        "tags": [
            "set",
            [
                "cportal-0",
                "eth_devices",
                "home--1"
            ]
        ]
    }
]

$ ovsh -j s Flow_Service_Manager_Config -w handler==core_dpi_dispatch
[
    {
        "if_name": "br-home.dpi",
        "_version": [
            "uuid",
            "8b48b16c-3467-4391-a623-db296340f99e"
        ],
        "other_config": [
            "map",
            [
                [
                    "included_devices",
                    "$[all_clients]"
                ]
            ]
        ],
        "type": "dpi_dispatcher",
        "plugin": "",
        "_uuid": [
            "uuid",
            "a1137e80-2326-4d02-9437-bd9d646e77c9"
        ],
        "pkt_capt_filter": "",
        "handler": "core_dpi_dispatch"
    }
]

Flow Direction Reporting

The IP flow protobuf is augmented to carry the IP flow information.
FSM will report the direction of flows it marked to FCM.
Following the current framework, FCM ultimately reports the flows to the controller.

Report example:

{
    "observationPoint": {
        "locationId": "59efd33d2c93832025330a3e",
        "nodeId": "4C718002B3"
    },
    "observationWindow": [
        {
            "endedAt": "1604964952",
            "flowStats": [
                {                    
                   "flowCount": {
                        "bytesCount": "30000",
                        "packetsCount": "100"
                    },
                    "flowKey": {
                        "direction": "FLOW_DIRECTION_OUTBOUND",
                        "dstIp": "32.33.34.35",
                        "dstMac": "dd:ee:ff:cc:bb:aa",
                        "flowState": {
                            "firstObservedAt": "1604964952",
                            "lastObservedAt": "1604964952"
                        },
                        "ipProtocol": 17,
                        "originator": "FLOW_ORIGINATOR_SRC",
                        "srcIp": "192.168.40.1",
                        "srcMac": "11:22:33:44:55:66",
                        "tptDstPort": 53,
                        "tptSrcPort": 12345
                    }
                }
            ],
            "startedAt": "1604964952"
        }
    ],
    "reportedAt": "1604964952"
}

Direction Determination

The direction determination targets first and foremost the TCP and unicast UDP flows.
Packet drops can happen before hitting the core DPI dispatcher. The detection should be resilient to such drops.

TCP case:
The detection of the SYN flag or SYN/ACK flag in the TCP header provides necessary and sufficient information. If none of these flags are detected, the determination uses the tranport port numbers as described below.
TCP/UDP cases:
If the source or destination port is a reserved port, it hints at the direction of the flow.

Initial Implementation Details

FSM internally represents a bidirectional flow as a pair of network_metadata flow accumulators. The accumulator definition is augmented with two fields - direction and originator. The direction represents the flow original direction, and is set using the following values:

NET_MD_ACC_UNSET_DIR
NET_MD_ACC_OUTBOUND_DIR
NET_MD_ACC_INBOUND_DIR
NET_MD_ACC_LAN2LAN_DIR

OUTBOUND : The flow originated from the location device to an internet entity outside of the location.
INBOUND : The flow originated from an internet entity outside of the location to the location device.
LAN2LAN : A flow between devices of the location

FSM manages two accumulators for a bidirectional flow (flow originator -> flow destination and flow destination -> flow originator). The originator field indicates the originator for each accumulator (the 5/7 tuple source or destination).

Direction & Originator Determination

TCP

The detection of the SYN or SYN/ACK flag in the TCP header provides the necessary (and sufficient) information.

SYN flag detected:

The originator is set to NET_MD_ACC_ORIGINATOR_SRC

i) If the source MAC is a location client and the destination MAC is not a location client:

The direction is set to NET_MD_ACC_OUTBOUND_DIR

ii) If the source MAC is not a location client and destination MAC is a location client:

The direction is set to NET_MD_ACC_INBOUND_DIR

iii) If both MAC’s are clients of the location:

The direction is set to NET_MD_ACC_LAN2LAN_DIR

SYN -ACK flags detected:

The originator is set to NET_MD_ACC_ORIGINATOR_DST

i) If the source MAC is a location client and the destination MAC is not a location client.

The direction is set to NET_MD_ACC_INBOUND_DIR

ii) If the source MAC is not a location client and the destination MAC is a location client.

The direction is set to NET_MD_ACC_OUTBOUND_DIR

iii) If both MAC’s are clients of the location:

The direction is set to NET_MD_ACC_LAN2LAN_DIR

No SYN nor SYN-ACK flags detected (already established connections):

i) If both source and dst macs are clients of the location:

The direction is set to NET_MD_ACC_LAN2LAN_DIR

The originator is set to NET_MD_ACC_UNKNOWN_ORIGINATOR

ii) The source port is a well-known port (Reserved port i.e., <1024)

If the destination mac is a location client:
The direction is set to NET_MD_ACC_INBOUND_DIR

The originator is set to NET_MD_ACC_ORIGINATOR_DST

else

The direction is set to NET_MD_ACC_OUTBOUND_DIR

The originator is set to NET_MD_ACC_ORIGINATOR_SRC

iii) If source port is not reserved port i.e. >=1024

If the source mac is a location client

The direction is set to NET_MD_ACC_OUTBOUND_DIR

The originator is set to NET_MD_ACC_ORIGINATOR_SRC

else

The direction is set to NET_MD_ACC_INBOUND_DIR

The originator is set to NET_MD_ACC_ORIGINATOR_DST

iv) If both source and destination ports are > 1024 or macs are not found.

The direction is set to NET_MD_ACC_UNSET_DIR

The originator is set to NET_MD_ACC_UNKNOWN_ORIGINATOR

UDP

Traffic direction is decided based on source/dest ports. It follows the same procedure as TCP direction on Ports.

Testing Instructions

Add the all_clients key in the core DPI dispatcher setting:

$ ovsh u Flow_Service_Manager_Config -w handler==core_dpi_dispatch other_config:ins:'["map",[["included_devices","$[all_clients]"]]]'

Trigger outbound and inbound traffic in both bridge and router mode. Validate that the reports direction and originator fields are set within the expected values.

Published Content

https://www.opensync.io/s/EDE-021-030-501_FSM_Plugins.pdf

https://www.opensync.io/s/ERE-021-061-701_FSM_Plugin_Requirements.pdf