Enforcing HTTP/2 Application Security Within OpenFlow

With the increasing adoption of Software Defined Network (SDN) and OpenFlow by organizations to replace traditional Layer 3 routing and switching hardware, you may have wondered about applying advanced Layer 4 – 7 application awareness and network security services.

This Just ADC Insight offers details surrounding how to deploy a TCP proxy to challenge the ADC, network or research communities, including vendors such as F5, to develop and test an OpenFlow-based ADC product.  A TCP proxy is the foundation of building an ADC — without it, the OpenFlow system will not be able to access the payload for offloading and chaining intelligent application-layer features.

An OpenFlow based ADC will allow NetOps and DevOps teams to see the network as application flows, not just series of packets, providing a framework for programming application services within any OpenFlow network. Traditional Software Defined Networking offers programmability at the network layer, but offers users no application layer visibility for programming intelligent application layer logic into their networks.

Below you’ll find the details of the initial flow table setup, a description of the message exchange between the Controller and OpenFlow switch, and an overview of the north-bound API(s) to support a TCP proxy.  The TLS/SSL requirements for OpenFlow are discussed lightly and will be discussed in detail in a subsequent Insight. Additionally, no testing or implementation has yet been performed with this design — this is simply a thought experiment to illicit further discussion around its implementation.

Typical Openflow switches and SDN controllers make decisions of where to route and switch traffic at Layers 1-4. However, with an OpenFlow based ADC vendors can now setup a framework for the purpose of deploying Layers 4 through 7  services, including but not limited to:

• Old-School Server Load balancing – including basic services like source IP persistence.
• Intelligent ADC web-based application load balancing  – including HTTP URI load balancing, HTTP cookie based persistence.
• DDoS prevention – protect resources from DDoS attacks by leveraging TCP SYN cookies.
• Web-Application firewalling (WAF)– include SQL injection, Cross site scripting vulnerabilities, etc.

Optimizations with HTTP/2.0

To help minimize the number of TCP connections for a single user session, the HTTP/1.0 specification included a keep-alive header, which allowed multiple requests to be made over a single TCP connection. However, each request needed a response prior to sending the next request. To address this limitation, The HTTP/1.1 specification included HTTP pipelining, whereby the user could send multiple concurrent requests without requiring to receive a response between requests. Unfortunately, this feature never full became realized by browser vendors. Instead, browser vendors optimized application flow by opening many concurrent TCP connections per user session and distributing application requests across these connections.

To eliminate the need for maintaining many connections in this manner, Google developed a protocol called SPDY. This protocol addresses concurrency by sending requests over a single TCP connection. Google SPDY lead to the creation of the HTTP/2.0 specification.

You can certainly implement these Openflow features in HTTP/1, but are optimized in environments where you utilize HTTP/2.0, where the interaction between OpenFlow switch and Controller is minimized.

Existing OpenFlow Security Solutions

From some research on the web, you can find a number of interesting papers that make great progress on offering counter-measures of DDoS attacks, but none that provide details on implementing a complete TCP proxy.

• Network Anti-Spoofing with SDN Data plane
• IEEE DDoS TCP Flooding Protection

Please submit a comment if you have seen any other papers on this subject, or if you are interested in testing out these theories in a Mininet test environment.

How to Design a TCP Proxy in OpenFlow

The figure below provides a high-level schematic of a TCP proxy feature.

OpenFlow TCP Proxy Overview

 

The ADC traffic flow can be divided into three steps:

In Step 1, the client sends a TCP SYN packet to the ingress port to establish a TCP connection to a server that’s reachable from the Egress port, bearing in mind that the Ingress and Egress port may be the same port. The controller’s involvement in the TCP protocol is restricted to establishing and terminating TCP connections on behalf of the client and server. Once established, only connection termination packets will be forwarded to the controller, in either direction by the OpenFlow switch. Any data packets or TCP congestion detection and avoidance features, such as TCP window resizing, fast-retransmit, Nagle, etc. are handled between the client and server using the FastPath noted in the figure. The Openflow switch will pass packets produced by end-points containing data or these TCP features transparently between end-points, without Controller involvement.

The Controller must generate a random TCP sequence number for the TCP-SYN ACK packets. The OpenFlow application developer may also program the Controller to monitor the rate of incoming connection attempts via Northbound API for the purpose of enabling DDoS protection. In this case, the Controller inserts a SYN cookie in the response and delays the creation of any TCP state until the TCP ACK packet is received from the client. 

In Step 2, the controller establishes a new connection to the server. In this case, the Controller re-uses the sequence number presented by the client for its initial sequence number for the flow, thereby limiting the sequence number re-mapping requirement of the OpenFlow switch to the return packets of the flow.

During Steps 1 and 2, the Controller creates the necessary flow entries for the Openflow switch to re-map the non-TCP termination packets between the client and server directly, and switch the TCP termination packets back to the Controller. Additionally the controller may be programmed via Northbound API to forward packets using the Offload table in Step 3, to an intermediary system for processing prior to forwarding in either direction.

The controller maintains a ruleset that is programmed via the Northbound API for the OpenFlow application. The application may support rulesets based on the technologies listed above.

Connection Establishment

Client-side Connection Establishment:

Upon reception of a SYN packet with unique TCP source and destination ports, the controller completes the following tasks:

• Spoofs the server-side random sequence number, or in the case of DDoS Mitigation, generates a SYN Cookie.
• If there is no DDoS Mitigation, the Controller creates a flow entry in its local flow table, including the client’s TCP sequence number.
• The Controller generates a SYN-ACK Packet-Out message with the Outport equal to the Ingress port. The OpenFlow switch does not process the packet using the pipeline processing, instead forwards the packet directly out the Outport.
• The Controller awaits the associated ACK response from the client. If the ACK number contains a SYN cookie in the case of DDoS Mitigation, the controller creates the client flow in its local flow table.

Upon reception of the ACK packet from the client, the Controller completes the following tasks:

• The controller matches the ACK number against its randomly generated or SYN cookie-based sequence number.
• If the packet matches an existing flow, the Controller determines the server-side IP, TCP port, output port from the Northbound API ruleset. The Controller may need to generate an ARP Packet-Out message request to discover the Outport of the server.
• Using the client’s stored sequence number, the Controller sends the SYN Packet-out to the Server, thereby initiating the server-side TCP connection.

Server-side Connection Establishment:

Upon reception of the SYN-ACK packet from the server, the Controller creates the necessary flows in the OF switch, as outlined in the table design in the figure and described below, and sends an ACK Packet-Out message back to the server.

Connection Establishment

Connection Termination

Initiator-side Connection Termination:

Either the server or the client may elect to terminate the connection; therefore, in this section the terms initiator and recipient are used instead of client and server. In the case of Initiator-side termination, the Controller will always choose to use a TCP full close method.

Upon reception of a FIN packet from the initiator, the OpenFlow switch will match against one of its Termination flows, as outlined in the Table design figure.

 

Connection Termination (Full Close)

 

Prior to continuing with the initiator-side connection termination, the Controller will initiate the termination of the receiver-side first (as described in the next section), because the receiver may elect to use the TCP half close method which may include additional data packets and will need the initiator-side flows to remain open. To do this the controller generates a FIN packet and sends the Packet-Out message to the receiver by way of the OpenFlow switch. The Controller will place existing flows of the receiver in a terminating state, by setting the ‘terminating’ flag of the OpenFlow Extensible Matches (OXM) Type-Length-Value (TLV) tuple variable storage located in Action 0 of the flow. The controller then updates the Outport of the existing receiver flows to the Controller, so that the Openflow switch will forward the expected ACK packet back to the Controller, in response to the FIN packet from the Controller. Similar to the TCP connection establishment, there will be no pipeline processing for the termination.

 

Connection Termination (Half Close)

Once the receiver TCP termination is completed, the Controller generates the FIN packet and ACK packet Packet-Out message responses back to the initiator to continue with the Initiator-side termination, thereby leveraging a TCP full close method.

Upon reception of the ACK packet from the Initiator, the Controller removes the initiator flows from the OpenFlow switches tables.

Receiver-side Connection Termination:

Upon reception of the ACK packet from the receiver, in response to the FIN packet the Controller initiated during the Initiator-side Connection Termination as outlined above, the Controller leaves all flows in place for any further data that the receiver requires to send to the Initiator. The Controller takes no action upon reception of the TCP ACK packet.

Only when the Controller receives the FIN packet from the receiver, will the Controller remove the receiver flows from the OpenFlow switch tables. In response to the FIN packet the Controller sends an ACK packet to the receiver, thereby completing the connection termination towards the receiver.

OpenFlow Table Design

The figure below outlines the Table design for supporting a TCP proxy. The following sections describe each table and the required flow entries to support a TCP proxy.

 

Table 0 – Pre-mapped Table

Pre-mapped Table (Table 0)– This table is referred to as the Pre-mapped table, since this is where the flows are matched as they arrive into the OpenFlow switch, in their original state, prior to re-mapping sequence numbers, TCP ports, and server IPs.

Each TCP connection in the Pre-mapped table is conveyed with four flow entries in the Pre-mapped table.

• Client-side Forward flow (CS Forward) — This flow is for packets in the East-West direction, from client to server. The match fields are the client Inport, source port, destination port and destination IP. The actions of this flow can be either to forward directly to the Post-Mapped table, or out the Offload port, in which case the OpenFlow switch must translate the MAC address to that of the intermediary device, prior to forwarding out of the Offload Port. The offload port may also be an internal port, if the offload service is imbedded within the OpenFlow switch. When the offload intermediary service is completed it’s processing of the packet, the offload device sends the packet back into the Offload port, where the flow matches against the table-miss flow and is forwarded to the Offload table.

If there is no offload table, the Actions in this table include the Flow variable OXM TLV Storage Actions, as described in Table OXM TLV Variable Storage Actions, which the Openflow switch uses for re-mapping prior to forwarding to the Post-mapped table.

Variable Name	Description
CS.initialSeqNumber	Used to store the Client-side initial Sequence number, either from a random value or a DDoS SYN Cookie.
SS.initialSeqNumber	Used to store the Server-side initial Sequence number, either from a random value or a DDoS SYN Cookie.
terminatingFlag	Indicates that the flow is in the process of being terminated.
SS.currentSeqNumber	This is the sequence number of the current packet of the session from the Server-side context. This starts as SS.initialSeqNumber and is incremented by the packet size each time a packet arrives at the flow. This is required for the purpose of the Controller initiating the FIN packet in the direction of the recipient of the termination.
CS.currentSeqNumber	This is the sequence number of the current packet of the session from the Client-side context. This starts as CS.initialSeqNumber and is incremented each time a packet arrives at the flow.

OXM TLV Variable Storage

 

Note: The concept of using Actions for holding variables for use within other Actions by the OpenFlow switch is novel and unique and requires further development.

These Actions do not require any action by the Openflow switch, but rather are used by the Openflow switch as the location for the variables used to perform the Header Re-calculation Actions, as described in table — Header Re-calculation Actions.

Additionally, if there is no offload service, the Header Re-calc Actions are added to the flow in the Pre-mapped table.

 

Variable Name	Description	Value
TCP.ackNum	This is the new acknowledgement number that the OF calculates based on the SS.initialSeqNumber and CS.initialSeqNumber as well as the current acknowledgement number in the packet.	SS.initialSeqNumber + TCP.ackNum – CS.initialSeqNumber
TCP.srcPort	The OF switch may translate the source port based on the Northbound API ruleset for the application.	Northbound.rule.srcPort
IP.srcIP	The OF switch may translate the source IP based on the Northbound API ruleset for the application.	Northbound.rule.srcIP
TCP.dstPort	The OF switch may translate the destination IP based on the Northbound API ruleset for the application.	Northbound.rule.dstPort
IP.dstIP	The OF switch may translate the destination IP based on the Northbound API ruleset for the application.	Northbound.rule.dstIP

                    Header Re-calculation Actions.

 

• Server-Side Return flow (SS Return) — This flow is for the West-East return packets from the server back into the OF switch. The match fields are the server Inport, source port, destination port and destination IP. The actions of this flow can be either to forward directly to the Post-Mapped table, or out the Offload port. When the offload intermediary service is completed its processing of the packet, the offload service sends the packet untouched back into the Offload port, where the flow matches against the table-miss flow and is forwarded to the Offload table.
• CS Termination flow – This flow is for matching FIN packets initiated from the client. This flow entry forwards the FIN packet to the Controller for initiating the Connection termination process, as outlined later.
• SS Termination flow – This flow is for matching FIN packets initiated from the server. This flow entry forwards the FIN packet to the Controller for initiating the Connection termination process, as outlined later.

The Pre-mapped table must also contain a TCP connection initiation entry, that matches only on packets with SYN flag set, and table-miss entry where flows that do not match any flows are forwarded either to the Offload table if present, or to the Controller, or dropped if no flows are present.

Offload Table (Table 1) – This table is referred to as the Offload table and is optional. If the application does not require any intermediary processing, the application is reduced to a TCP connection proxy.

 

Table 1 – Offload table (optional)

Each TCP connection in the Offload table is conveyed with two flows as follows:

• CS-Forward – This entry matches the East-West client to server flow.
• SS-Return– This entry matches the West-East server to client flow.

 

Post-mapped Table (Table 2) – This table is referred to as the Pre-mapped table, since this is where the flows are matched as they leave the OF switch, prior to forwarding out the Egress port.

 Table 2 – Post-mapped Table

Each TCP connection in the Post-mapped table is conveyed with two flows as follows:

• SS-Forward—This flow is for matching packets that where originally matched in the CS-Forward entry in the Pre-mapped table. Here only the sequence number must be updated to reflect the sequence number that was spoofed by the Controller in the initial TCP handshake with the client.
• CS-Return—This flow is for matching packets that where originally matched in the SS-Return entry in the Pre-mapped table. Here the complete Header Recalculations must be completed to ensure the client recognizes the sequence and acknowledgement numbers from the server.

The figure below outlines how the OpenFlow switch can chain flows to intermediary application security services, prior to completing the pipeline stages of the OpenFlow tables outlined previously. The Offload ports may be an internal ports on the OpenFlow switch that points to software or hardware modules within the Openflow switch itself, or external services or virtualized applications for performing customized actions, such as SSL cryptography, DDoS Traffic cleansing, BGP blackholing, Web application firewalling, Intrusion Detection, etc.

 

 Security Services Offloading / Chaining

 

About the Author

Silvano Da Ros is an F5 ASM and APM certified Architect for JustADC, with over 15 years experience with various ADC vendors. When he’s not designing and troubleshooting F5 environments, you can find him on the tennis court or spending time with family.

 

Please comment or ask any questions about this article.

Additionally, feel free to contact us to learn more about JustADC’s Managed WAF services to address your application security needs.