Cisco Cisco Firepower 4120 Security Appliance

TCP Reset

Radware recommends enabling the TCP-Reset option in symmetric and ingress-only environments that include

HTTP, HTTPS, and SMTP traffic.

Caution:

When DefensePro implements the TCP-Reset mechanism, according to the relevant RFCs (for HTTP,

HTTPS, and SMTP), a new connection must be initiated automatically when the original connection is reset (in this

case, by the TCP-Reset mechanism). For browsers that fully comply with this aspect of the RFCs, the connection

will be re-initiated automatically, and the user will experience a delay of approximately three seconds with no

additional latency expected during the authentication period. (The authentication period is determined by the TCP
Authentication Table Aging

parameter, which, by default, is 20 minutes.) For browsers that do not fully comply

with this aspect of the RFCs, legitimate users will receive a notification that the connection is reset and will need to

manually retry the connection. After the retry, the users will be able to browse with no additional latency expected

during the authentication period.
When the Use TCP Reset for Supported Protocols checkbox is selected, DefensePro uses the TCP-Reset

authentication method for HTTP, HTTPS, SMTP, and custom-protocol traffic instead of the authentication method,

which, for Radware DefensePro DDoS Mitigation version 8.10, is Safe- Reset).
Custom-protocol

refers to traffic that you define for the TCP-Reset method to handle. To enable you to do this,

DefensePro exposes two, system-defined Application Port Groups: TCPReset-ACK and TCPReset-Data. These

Application Port Groups are dummy groups, which are defined with Layer 4 port 0 (zero). (For the procedure to

To define custom-protocol traffic for the TCP-Reset method, page

143

When DefensePro implements the TCP-Reset method, DefensePro tries to match packets to a relevant

Application Port Group according to the following order:
1.

HTTP

HTTPS

SMTP

TCPReset-Data

TCPReset-ACK

DefensePro handles packets in a session according to the first packet that matched one of the relevant

Application Port Groups.
When the TCP-Reset option is enabled, DefensePro does the following:
1.

When it receives a SYN packet, DefensePro replies with a SYN-ACK packet with a cookie in the Sequence

Number field using the original destination IP address and MAC, without any additional authentication

parameters (cookies).

If the response is an ACK with the cookie:

—

In HTTP or HTTPS traffic or custom-protocol traffic with the TCPReset-Data Application Port Group,

DefensePro waits for the first data packet from the client. (If DefensePro receives an ACK with no data

before the first data packet, DefensePro drops the packet.) When the DefensePro device receives data, it

replies with a RST packet, and saves the source IP address in the TCP Authentication table.

—

For SMTP or custom-protocol traffic with the TCPReset-ACK Application Port Group,

DefensePro replies with a RST packet, and saves the source IP address in the TCP

Authentication table.

Note:

HTTP, HTTPS, and SMTP sources respond automatically to a RST packet by re-sending a SYN—that

is, the source automatically retries to open the connection with the protected server. Legitimate clients are

expected to retry and open a new connection towards the protected server.

Page 144 of 281