cancel
Showing results for 
Search instead for 
Did you mean: 

K36155089 in the wild?

ChristianH
Nimbostratus
Nimbostratus

Does anyone have experience identifying K36155089 and / or know the impacts of this bug? We're supposedly affected and I'd like to see if anyone has experience with it and also if they know they performance impacts that the workaround causes?

1 ACCEPTED SOLUTION

Hello ChristianH.

If your fastL4 is configured as:

  • PVA Acceleration: Full.
  • Offload State: SYN

Then you should be affected by the mentioned bug. That means that all the embryonic sessions (TCP-Half Open) will be removed from the connections table using the "Idle Timeout" counter instead of the "TCP Handshake Timeout" (which is more restrictive than the "Idle Timeout" counter).

  • Idle Timeout: 300 sec
  • TCP Handshake Timeout: 5 sec

Then, those connections (TCP Half-Open) will be remaining in the connection table for more time than expected.

The workaround KB states to change the Offload State from SYN to EST. That means using PVA after the connection is established.

|-----------> SYN >-----------| >> HW Offloading using SYN
|---------< SYN-ACK <---------|
|-----------> ACK >-----------|
|---> REST OF THE TRAFFIC >---| >> HW Offloading using EST

 That means that the TCP Handshake will be done using CPU instead of HW (a bit of CPU higher than using HW).

You could think about this set could be vulnerable to DoS attacks. But thanks to the SYN Cookie protection (by default), your system should be protected.
REFhttps://support.f5.com/csp/article/K74451051

 

Regards,
Dario.

View solution in original post

3 REPLIES 3

Hello ChristianH.

If your fastL4 is configured as:

  • PVA Acceleration: Full.
  • Offload State: SYN

Then you should be affected by the mentioned bug. That means that all the embryonic sessions (TCP-Half Open) will be removed from the connections table using the "Idle Timeout" counter instead of the "TCP Handshake Timeout" (which is more restrictive than the "Idle Timeout" counter).

  • Idle Timeout: 300 sec
  • TCP Handshake Timeout: 5 sec

Then, those connections (TCP Half-Open) will be remaining in the connection table for more time than expected.

The workaround KB states to change the Offload State from SYN to EST. That means using PVA after the connection is established.

|-----------> SYN >-----------| >> HW Offloading using SYN
|---------< SYN-ACK <---------|
|-----------> ACK >-----------|
|---> REST OF THE TRAFFIC >---| >> HW Offloading using EST

 That means that the TCP Handshake will be done using CPU instead of HW (a bit of CPU higher than using HW).

You could think about this set could be vulnerable to DoS attacks. But thanks to the SYN Cookie protection (by default), your system should be protected.
REFhttps://support.f5.com/csp/article/K74451051

 

Regards,
Dario.

Beautifully explained, thank you!

Hello Smith845,

There is no solution beyond the workaround.

 

Regards,
Dario.