Subject: ESPv3 TFC padding

From: Tylor Allison <[email-masked]>
Date: Tue, 12 Aug 2003 08:29:39 -0500 (CDT)

Hi,

I have a few questions on what folks are doing for the Traffic-Flow
Confidentiality (TFC) padding for ESPv3.  Is there an algorithm being
deployed for determining how much padding to add, or is that implementation
specific?  Sorry, I couldn't find any documentation for this feature,
outside of the ESPv3 draft.

I'm trying to figure out if it is best to use a random amount of TFC padding,
or to pad out to a certain size (e.g. segment size) for all packets.
It would seem that random padding probably isn't sufficient, as if you're
trying to mask small packets, adding a random pad will just result in a
bigger packet on average, but will still be discernable from a VPN which is
just passing large packets.

If this is truly implentation specific, I'll just pick what I think is
best.  But if there has been some discussion on this, or this is a draft
out there somewhere, I'd like to try and do as others are doing.

Thanks!

Tylor

--------------------------------------------------------------------------------
Tylor Allison
Principal Engineer

Secure Computing®
Protecting the world's most important networks (TM)
www.securecomputing.com
NASDAQ: SCUR
--------------------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Aug 2003 10:00:33 -0400

>out there somewhere, I'd like to try and do as others are doing.

Tylor,

The safest bet is to add padding to packets to make them all the same 
size, e.g, on a per-SA basis,  but this may yield unacceptable 
performance in many contexts. So, we have no standard for how to 
choose the amount of padding to add to traffic. It ought not be an 
implementation decision, however, but rather a parameter under 
control of the local admin.

Steve

---

From: Tylor Allison <[email-masked]>
Date: Tue, 12 Aug 2003 11:30:38 -0500 (CDT)

Two more questions:

First, with TFC padding, the ESPv3 draft states that the SA management
protocol MUST negotiate the TFC service prior to employing the service.  Is
there any draft in the works for how this would be done in IKEv1?  I
suppose it could either be done via a Notify or in the QM SA attributes.

My second question is regarding "dummy" packet generation, and the intended
usage of this feature.  The current draft states that an implementation
MUST support this feature as both a transmitter and a receiver.  I'm
assuming that the purpose of this feature is to be able mask traffic
patterns of normal IPsec traffic, inserting dummy packets into the mix at
random intervals.  Is this assumption correct?  Also, is it really intended
that all IPsec implementations supporting ESPv3 MUST implement this
feature, as the current draft states?  I could see the case where all must
be able to receive such packets.

Thanks!

Tylor Allison

---

From: Henry Spencer <[email-masked]>
Date: Mon, 18 Aug 2003 23:52:41 -0400 (EDT)

> just passing large packets.

Barring grossly bandwidth-intensive measures like padding all packets out
to a constant size and regularly injecting dummy packets if no real ones
appear, all you can accomplish with such measures is to add noise to the
data obtained by traffic analysis.  If the underlying "signal" is strong
enough, it will eventually show through the noise.

But this doesn't make noise addition worthless.  The noise can *hamper*
traffic analysis even if entirely precluding it is impractical.  The
trickier the particular analysis is in the first place, e.g. trying to
figure out what's going on inside a multi-user SA carrying several kinds
of traffic simultaneously, the more it hurts to add a bit of extra noise
to the data. 

                                                          Henry Spencer
                                                       [email-masked]