Re: ESPv3 TFC padding

[Tylor Allison <allison@securecomputing.com>]

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

On Tue, 12 Aug 2003, Stephen Kent wrote:

> At 8:29 -0500 8/12/03, Tylor Allison wrote:
> >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,
>
> 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