Re: ESPv3 TFC padding

[Stephen Kent <kent@bbn.com>]

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

I am not aware of an explicit provision for IKE v1 negotiation of this feature.

>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.


As you noted, dummy packets could be inserted at random intervals to 
mask the absence of actual traffic. One can get fancier and "shape" 
the actual traffic to match some distribution to which dummy traffic 
is added as dictated by the distribution parameters.  (another 
obvious candidate for local management controls).

As with the packet length padding facility for TFS, the most secure 
approach would be to generate dummy packets at whatever rate is 
needed to maintain a constant rate on an SA.  If packets are all the 
same size, then the SA presents the appearance of a constant bit rate 
data stream, analogous to what a link crypto would offer at layer 
1/2.  However, this is unlikely to be practical in many contexts, 
e.g., when there are multiple SAs active, because it would imply 
reducing the allowed bandwidth for a site, based on the number of 
SAs, and that really undermines the benefits of packet switching.

It is certainly easier to receive and discard dummy packets than to 
generate them, but nobody complained during the during WG period on 
this document, so I assume that nobody had a problem with this 
requirement. So, yes, it is a MUST and it is universally applicable.

Steve