Subject: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets

From: Karen Seo <[email-masked]>
Date: Thu, 25 Sep 2003 17:17:42 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	76

Title:		More explanation re: ESPv3 TFC padding & dummy packets

Description:
============
Questions have been raised re: how much padding one should add and 
re: generation and discarding of dummy packets.  Should we add text 
explaining more about these topics?

Proposed approach:
==================
2401bis will be modified with text along the lines of:

"ESPv3 provides a facility to allow an arbitrary amount of padding to 
be appended to a packet, for traffic flow confidentiality, as well as 
a facility for efficient generation and discarding of "dummy" 
packets. Implementations SHOULD provide local management controls to 
enable the use of these capabilities on a per SA basis. The controls 
should specify which (if any) TFC features are to be employed, and 
provide parametric controls for the features.  For example, the 
controls might allow an administrator to generate random or fixed 
length dummy packets and to pad real packets to random or fixed 
lengths."

Thank you,
Karen

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Sep 2003 18:29:11 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Karen" == Karen Seo <[email-masked]> writes:
    Karen> "ESPv3 provides a facility to allow an arbitrary amount of padding
    Karen> to be appended to a packet, for traffic flow confidentiality, as
    Karen> well as a facility for efficient generation and discarding of
    Karen> "dummy" packets. Implementations SHOULD provide local management
    Karen> controls to enable the use of these capabilities on a per SA

  Unfortunately, they do not provide the required facilities to make onion
routing feasible with IPsec. (ZeroKnowledge experienced this problem and 
did a proprietary system as a result)

  In onion routing, when you decapsulate a packet, finding another encrypted
packet inside (not addressed to you), you then need a way to append padding
to the resulting packet so that it stays the same size as what was received.
  Essentially, one needs to do this on the *outside* of the packet. 

  If ESP had a length at the beginning of the ciphertext instead of at the
end, then it would be trivial, but this isn't so. This is clearly a wire
format change, so it is no longer the ESP that we know.

  I don't expected ESPv3 to solve this, but it might be good to note that
it doesn't solve this problem.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Stephen Kent <[email-masked]>
Date: Fri, 26 Sep 2003 09:45:24 -0400

>it doesn't solve this problem.
Michael,

Your observation is correct re a specific way to effect TFC, but its 
not the only way.  An intermediate system could decapsulate and then 
pad the new, outbound packet to some fixed size, or some arbitrary 
size, rather than trying to preserve the (padded) size of the inbound 
packet.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Sep 2003 13:33:38 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
    >> Unfortunately, they do not provide the required facilities to make
    >> onion routing feasible with IPsec. (ZeroKnowledge experienced this
    >> problem and did a proprietary system as a result)
    >> 
    >> In onion routing, when you decapsulate a packet, finding another
    >> encrypted packet inside (not addressed to you), you then need a way to
    >> append padding to the resulting packet so that it stays the same size
    >> as what was received.  Essentially, one needs to do this on the
    >> *outside* of the packet.
    >> 
    >> If ESP had a length at the beginning of the ciphertext instead of at
    >> the end, then it would be trivial, but this isn't so. This is clearly
    >> a wire format change, so it is no longer the ESP that we know.
    >> 
    >> I don't expected ESPv3 to solve this, but it might be good to note
    >> that it doesn't solve this problem.

    Stephen> Your observation is correct re a specific way to effect TFC, but
    Stephen> its not the only way.  An intermediate system could decapsulate
    Stephen> and then pad the new, outbound packet to some fixed size, or
    Stephen> some arbitrary size, rather than trying to preserve the (padded)
    Stephen> size of the inbound packet.

  How does it do this, unless it is encrypted again?  

  Not all designs assume that there are tunnels between adjacent systems.
There are performance vs accounting tradeoffs for each scenario. 

  You may have them *as well*, but that's not the point.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 26 Sep 2003 14:02:39 -0400

Michael,

Sorry, I misunderstood your example. But, I stand by my assertion 
that it is actually a questionable idea, from a TFC perspective, to 
try to make the outbound packet the same size as the inbound packet, 
in general. If different inbound packets arrive with different sizes, 
this just makes it easy for an observer to match inbound and outbound 
traffic through a router.

Steve

---

From: Tylor Allison <[email-masked]>
Date: Mon, 29 Sep 2003 07:24:30 -0500 (CDT)

> Title:		More explanation re: ESPv3 TFC padding & dummy packets

What about how often these dummy packets get sent, and the latency between
dummy packets.  Should this be a random stream or a fixed bandwidth stream?
Should the dummy data rate be configurable by the administrator?

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

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

[email-masked]
--------------------------------------------------------------------------------

---

From: Karen Seo <[email-masked]>
Date: Tue, 30 Sep 2003 12:58:53 -0400

Tylor,

Quoting some earlier text from Steve K....

"Dummy packets can be inserted at random intervals to mask the 
absence of actual traffic. One can also "shape" the actual traffic to 
match some distribution to which dummy traffic is added as dictated 
by the distribution parameters. 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 would undermine the 
benefits of packet switching.  How dummy packet insertion is handled 
SHOULD not be an implementation decision, however, but rather a 
parameter under control of the local administration."

We could amend the last sentence of the proposed text as follows

"For example, the controls might allow an administrator to generate 
random or fixed length dummy packets, or to pad real packets to 
random or fixed lengths, or to control the insertion timing of the 
dummy packets."

Would that address your concerns?

Thank you,
Karen