[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 18:29 -0400 9/25/03, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>>>>>>  "Karen" == Karen Seo <kseo@bbn.com> 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.
>
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