Feature request
Description
This is a follow-up to #375, which was auto-closed as stale rather than resolved.
I would like IVPN to consider anti-traffic-analysis protections beyond the current obfuscation options.
The reason for opening this as a new feature request is that obfuscation and anti-traffic-analysis do not address the same problem.
In the previous discussion, IVPN pointed to existing obfuscation options such as:
- V2Ray
- Obfsproxy (for OpenVPN)
Those are useful features, but they appear to target protocol masking / censorship resistance rather than traffic-analysis resistance.
The original issue referenced Mullvad’s DAITA work:
The concern is still relevant because even when VPN payloads are encrypted, metadata such as packet sizes, timing, direction, flow duration, and overall traffic patterns can still reveal information to a capable observer.
This is why I think the distinction matters:
- obfuscation mainly helps make VPN traffic harder to detect or block
- anti-traffic-analysis defenses aim to make traffic patterns themselves less useful for fingerprinting, classification, or correlation
According to Mullvad’s public description, DAITA is designed around measures such as:
- Constant packet sizes
- Random background / dummy traffic
- Data pattern distortion through cover traffic between client and VPN server
So this request is not simply “please add another obfuscation mode.”
It is a request for IVPN to consider a dedicated anti-traffic-analysis defense layer, or at least to clarify whether that area is on the roadmap, technically feasible, or intentionally out of scope.
I believe this is important because privacy-focused VPNs are increasingly evaluated not only on encryption and no-logs claims, but also on how much metadata remains observable to powerful passive adversaries.
Describe the solution you'd like
I would like IVPN to evaluate and potentially implement an optional anti-traffic-analysis mode, separate from the existing obfuscation features.
That could include one or more of the following:
- packet size normalization
- dummy / background traffic
- traffic pattern distortion
- other mechanisms intended to reduce traffic-analysis and fingerprinting risks
I am not necessarily asking for a 1:1 implementation of Mullvad DAITA.
I am asking IVPN to consider this feature category directly, instead of treating it as equivalent to existing obfuscation.
Useful references already shared in #375:
Describe alternatives you've considered
The main alternatives considered so far are IVPN’s existing obfuscation features, such as V2Ray and Obfsproxy.
However, those do not seem to address the same threat model. They are valuable for making VPN traffic harder to detect or block, especially in restrictive networks, but they do not appear to provide the same type of protection against traffic-pattern analysis that DAITA-like approaches aim for.
Another alternative would be to use different anonymity systems or more advanced network architectures, but those are often not practical for normal day-to-day VPN use.
That is why an optional anti-traffic-analysis feature inside IVPN would be valuable.
Feature request
Description
This is a follow-up to #375, which was auto-closed as stale rather than resolved.
I would like IVPN to consider anti-traffic-analysis protections beyond the current obfuscation options.
The reason for opening this as a new feature request is that obfuscation and anti-traffic-analysis do not address the same problem.
In the previous discussion, IVPN pointed to existing obfuscation options such as:
Those are useful features, but they appear to target protocol masking / censorship resistance rather than traffic-analysis resistance.
The original issue referenced Mullvad’s DAITA work:
The concern is still relevant because even when VPN payloads are encrypted, metadata such as packet sizes, timing, direction, flow duration, and overall traffic patterns can still reveal information to a capable observer.
This is why I think the distinction matters:
According to Mullvad’s public description, DAITA is designed around measures such as:
So this request is not simply “please add another obfuscation mode.”
It is a request for IVPN to consider a dedicated anti-traffic-analysis defense layer, or at least to clarify whether that area is on the roadmap, technically feasible, or intentionally out of scope.
I believe this is important because privacy-focused VPNs are increasingly evaluated not only on encryption and no-logs claims, but also on how much metadata remains observable to powerful passive adversaries.
Describe the solution you'd like
I would like IVPN to evaluate and potentially implement an optional anti-traffic-analysis mode, separate from the existing obfuscation features.
That could include one or more of the following:
I am not necessarily asking for a 1:1 implementation of Mullvad DAITA.
I am asking IVPN to consider this feature category directly, instead of treating it as equivalent to existing obfuscation.
Useful references already shared in #375:
DAITA announcement:
https://mullvad.net/en/blog/introducing-defense-against-ai-guided-traffic-analysis-daita
Maybenot paper / academic publication:
https://dl.acm.org/doi/abs/10.1145/3603216.3624953
https://dl.acm.org/doi/pdf/10.1145/3603216.3624953
Maybenot framework and simulator:
https://crates.io/crates/maybenot
https://crates.io/crates/maybenot-simulator
Maybenot defenses implementation:
https://github.com/ewitwer/maybenot-defenses
Describe alternatives you've considered
The main alternatives considered so far are IVPN’s existing obfuscation features, such as V2Ray and Obfsproxy.
However, those do not seem to address the same threat model. They are valuable for making VPN traffic harder to detect or block, especially in restrictive networks, but they do not appear to provide the same type of protection against traffic-pattern analysis that DAITA-like approaches aim for.
Another alternative would be to use different anonymity systems or more advanced network architectures, but those are often not practical for normal day-to-day VPN use.
That is why an optional anti-traffic-analysis feature inside IVPN would be valuable.