Subject: Re: [IPsec] Re: ESP's use of dummy packets?

From: Csaba Kiraly <[email-masked]>
Date: Mon, 03 Dec 2007 13:40:19 +0100

Dear Stephan,

>> ...
>> I would also like to take the occasion to say that we have made some 
>> efforts to extend the Traffic Flow Confidentiality capabilities of 
>> IPsec. In our research we were trying to create a separate TFC 
>> security protocol, which goes beyond the limited TFC capabilities 
>> that were already included in ESPv3. We have included support for 
>> size modifications such as padding (with explicit payload size 
>> information), fragmentation and aggregation. It also supports packet 
>> re-timing, as well as dummy generation and discarding. Finally, the 
>> choice of the masking algorithm combining one or more of these basic 
>> tools is handled separately.
>
> Since 4303 already provides for arbitrary padding, and efficient dummy 
> packet generation and discarding, presumably the additional features 
> to which you refer are a management interface to control these extant 
> features, plus packet re-timing and the fragmentation and aggregation 
> features that help optimize channel bandwidth?
>
You have summarized it perfectly, but let me put some more detail behind 
some of these points.

In our experimental protocol, in order to to support padding, we have 
opted for having a header field containing explicitly the payload 
length. While  ESP do support arbitrary padding,  it does not support it 
in every situation. As it is discussed in your RFC, padding only works 
if the upper protocol layer knows what to do when it receives a larger 
PDU, i.e. the PDU should contain a length indicator, and processing 
should not throw an error when the received PDU is longer then expected. 
Padding still works in tunnel mode, for several other protocols, and for 
the remaining ones there is a workaround by forcing an extra internal IP 
header through tunnel mode operation. While this choice is absolutely 
reasonable if TFC is a small addition, in our case, where we were 
looking specifically at a complete TFC solution, our priority was to 
make the protocol as generic as possible, thus we have made the payload 
length field explicit. This is really just a small difference, nothing 
serious.

More interesting is fragmentation support, which seems to make a huge 
difference against a number of traffic analysis methods. It is not just 
bandwidth optimization, but much more. First of all, it can considerably 
change packet count, already fooling several of the analysis methods  in 
literature nowadays. This is achieved without adding much overhead, as 
it would happen if we use dummies with the same scope. More precisely, 
overhead in bytes in traded for increased latency and decreased 
reliability (due to the usual one fragment dropped -> whole packet lost 
problem). Second, fragmentation also gives us an unimpeded choice of 
masked traffic pattern. There is no necessity anymore to pad all packets 
to the MTU just to hide large ones as well.

Aggregation simply complements fragmentation, giving us bandwidth 
optimization and changes in packet count. It is also worth noting that 
aggregation is based on the payload length field, therefore it only 
requires a one bit flag in the header (the flag specifies whether 
padding or another payload follows).

Some attacks (e.g. website fingerprinting, device fingerprinting) show 
that timing could be needed in some cases as well. Of course, like with 
dummy, timing should only be used if the scenario requires it.

As far as management is concerned, we are experimenting with different 
masking algorithms. We are trying to figure out the protection 
performance trade-off of different algorithms, as well as the right way 
(the right set of parameters) to describe the algorithms in a SA. Since 
our project is on privacy, we are evaluating TFC in cases like 
protection against website fingerprinting attacks, against traffic 
classification, or the use of TFC in low-latency anonymization networks. 
It is absolutely not trivial how the description of different algorithms 
should go, at least it is hard to address it from a theoretical point of 
view. Many of the masking strategies can be decoupled into a timing 
strategy, a packet size strategy and a dummy strategy. Tools (padding, 
fragmentation, aggregation) can be turned on/off. Other strategies are 
more complex, and cannot be decoupled this way. We are still working on 
this, looking at deterministic and randomized strategies, at dependence 
between the masked and the original pattern in time and size domains, etc.
Of course any ideas are highly welcomed!

Csaba

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec