ESP TFC PADDING NOT SUPPORTED

ESP TFC PADDING NOT SUPPORTED

5612
Created On 02/16/23 22:21 PM - Last Modified 04/17/26 01:19 AM


Symptom


  • Ikemgr logs report "received notify type ESP_TFC_PADDING_NOT_SUPPORTED"
  • VPN tunnel is working without issues.
00:26:38.108 -0600  [PWRN]: {    3:     }: x.y.z.34[500] - a.b.c.13[500]:0x555555a5a060 vendor id payload ignored
00:26:38.108 -0600  [PWRN]: {    3:     }: x.y.z.34[500] - a.b.c.13[500]]:0x555555a5a060 received notify type ESP_TFC_PADDING_NOT_SUPPORTED
00:26:38.108 -0600  [PWRN]: {    3:     }: x.y.z.34[500] - a.b.c.13[500]:0x555555a5a060 received notify type NON_FIRST_FRAGMENTS_ALSO
00:26:38.108 -0600  [INFO]: {    3:     }: x.y.z.34[500] - a.b.c.13[500]:0x7fffd00625c0 authentication result: success


Environment


  • Palo Alto Firewall.
  • Supported PAN-OS.
  • IPSec VPN.


Cause


PAN-OS does not support Traffic Flow Confidentiality (TFC) in ESP.



Resolution


Log Message Explanation:

The log message "Received notify type ESP_TFC_PADDING_NOT_SUPPORTED" indicates that the Palo Alto Networks firewall has received a notification from the IPsec VPN peer stating that ESP Traffic Flow Confidentiality (TFC) padding is not supported.


Background & Fix in PAN-OS 8.1.6:

  1. Initially, the firewall did not support ESP TFC padding but failed to notify peers, causing some to continue sending TFC-padded packets, which were then dropped.
  2. This issue was fixed in PAN-OS 8.1.6, where the firewall was updated to always send the ESP_TFC_PADDING_NOT_SUPPORTED notification to peers, regardless of whether it was the initiator or responder.
  3. If the peer follows RFC standards, it should stop sending TFC-padded packets upon receiving this notification.
  4. Since the firewall does not support ESP TFC padding, receiving this notification from a peer has no operational impact.


Context & Implications:

  1. TFC padding is an optional IPsec feature that adds random padding to ESP packets to obscure traffic patterns.
  2. PA firewalls will always send the ESP_TFC_PADDING_NOT_SUPPORTED notification to peers. This will not trigger any log messages.
  3. Peer firewalls may also send the notification to Palo Alto Networks firewall, which will trigger a log message, just like any other received notify payload. 
  4. If both sides send the notification, the expectation is that no ESP packets will be transmitted with TFC padding from either side. 
  5. PA firewalls still do not support TFC padding as of version 12.1, so there will be no change in behavior on the PA device.
  6. To reiterate, this is an expected and benign log message, not an error. It simply indicates that both firewalls will not be sending ESP TFC padded packets, which is perfectly normal.
  7. The message seen in the log, is not an error and is unrelated to any tunnel failure symptoms they may be observing.


Additional Information


 Definitions from https://datatracker.ietf.org/doc/html/rfc5996:

  • The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the sending endpoint will not accept packets that contain Traffic Flow Confidentiality (TFC) padding over the Child SA being negotiated.
  • If neither endpoint accepts TFC padding, this notification is included in both the request and the response.
  • If this notification is included in only one of the messages, TFC padding can still be sent in the other direction

Note:

  • The design of TFC is such that some devices will not have problems processing the packets even though they do not support it.
  • However, PAN-OS being a security OS has additional built-in checks on the size of packets.
  • One of such checks expectedly fails to result in packets getting dropped. 
  • NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1 simply as "Used for fragmentation control. See [RFC4301] for an explanation.
  • [RFC4301] says "Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
  • The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA."


Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000kH06CAE&lang=en_US&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail