Traffic Flow Confidentiality (TFC)
to hide/masquerade the traffic pattern to prevent statistical traffic analysis attacks.
RFC 4303 - IP Encapsulating Security Payload (ESP)
2.7. Traffic Flow Confidentiality (TFC) Padding
As noted above, the Padding field is limited to 255 bytes in length. This generally will not be adequate to hide traffic characteristics relative to traffic flow confidentiality requirements. An optional field, within the payload data, is provided specifically to address the TFC requirement.
An IPsec implementation SHOULD be capable of padding traffic by adding bytes after the end of the Payload Data, prior to the beginning of the Padding field. However, this padding (hereafter referred to as TFC padding) can be added only if the Payload Data field contains a specification of the length of the IP datagram. This is always true in tunnel mode, and may be true in transport mode depending on whether the next layer protocol (e.g., IP, UDP, ICMP) contains explicit length information. This length information will enable the receiver to discard the TFC padding, because the true length of the Payload Data will be known. (ESP trailer fields are located by counting back from the end of the ESP packet.) Accordingly, if TFC padding is added, the field containing the specification of the length of the IP datagram MUST NOT be modified to reflect this padding. No requirements for the value of this padding are established by this standard.
In principle, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in Section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC.
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls for the feature.
Re: ESP's use of dummy packets?
TfcProject – Discreet
pfkeyv2.h in tfcproject/trunk/ipsec-tools-0.6.6/src/include-glibc/net – Discreet
Traffic masking in IPsec: architecture and implementation
basic TFC mechanisms can be categorized as follows:
− Packet forming (padding, fragmentation, etc.);
− Packet timing (queuing and de-queuing);
− Dummy packet management (generation and discarding).
TFC Control Algorithms
the simplest and most straightforward algorithm consists in embedding the SA’s traffic in a CBR traffic pattern (with packets of constant size and a constant packet inter-arrival time). Such algorithm is ideal in the level of protection, it has a low complexity, but it also introduces serious performance drawbacks both in limiting the throughput and in filling the network with padding and dummy packets.
It is worth noting here that besides CBR, any traffic pattern that is independent of the original traffic flowing in the SA has the same properties. Algorithms can also generate traffic independent patterns using stochastic processes (modifying packet size, timing, or both). Other control algorithms are the adaptive ones, where the output pattern depends on properties of the original flow. Some examples are random size padding, random introduced delay, or a rate adaptive CBR.
Traffic Flow Confidentiality in IPsec: Protocol and Implementation
It can combine the TFC basic mechanisms arbitrarily:batching,
CBR (Continuous Bit rate),
random delay algorithms
Queue congestion Reactive algorithm (still experimental)
A User Space application allows to configure TFC SA parametersDelay Algorithm
ESP Traffic Flow Confidentiality
traffic-flow confidentiality (TFC)