Re: Issue #76: TFC padding in ESPv3 and requirments for IKEv2

[Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr>]

On Sat, Jan 31, 2004 at 11:58:56PM -0500, Theodore Ts'o wrote:
> 
> ... in ESPv3, I found the
> following text:
> 
>    TFC padding takes advantage of an intrinsic feature of IP, i.e.,
>    other data may be present in a buffer delivered to an IP interface,
>    beyond the packet length indicated by the IP total length field.
>    Thus, in tunnel mode, a compliant IP stack at a receiver should
>    ignore this padding. In this sense, existing IPsec implementations
>    could have made use of this capability previously, in a transparent
>    fashion. However, because receivers may not have been prepared to
>    deal with this padding, the SA management protocol MUST negotiate
>    this service prior to a transmitter employing it, to ensure backward
>    compatibility.  Combined with the convention described in section 2.6
>    above, about the use of protocol ID 59, an ESP implementation is
>    capable of generating dummy and real packets that exhibit much
>    greater length variability, in support of TFC.
> 
> There's only one minor problem.  IKEv2 doesn't currently have a way of
> negotiating this capability, and the ESPv3 specification states that the
> SA management protocol MUST negotiate this facility.  This leaves us
> with a couple of possibilities:
> 
> 1) We go ahead with the documents ESPv3 and IKEv2 as they currently
> stand, which would mean that TFC padding cannot be used until somoene
> writes a quick RFC which defines a new notification message:
> 
>         ESP_TFC_PADDING_SUPPORTED                   16394
> 
>             This notification asserts that the sending endpoint will
> 	    accept packets that contain Flow Confidetiality (TFC)
> 	    padding.
> 
> 2) We modify IKEv2 to include this new notification message now.

Either ways are correct, however I think 2) is the most reasonable
solution, given documents involved are still IDs. I'd rather see some
more lines in IKEv2 than an almost empty RFC.

> 
> 3) We modify ESPv3 to indicate that the mere use of IKEv2 implies that
>    the receiver can accept ESP packets that contain RFC padding.
                                                      ^- Nice lapsus :)
I don't see 3) as an alternative to specifying the notification message
somewhere; do you mean that the requirement for the SA-MP to negotiate
TFC should be eased for IKEv2 ? I think this should always be
negotiated, not only because of backward compatibility, but also because
of possible performance issues wrt link capacity and host memory: one
should be able to tell it's peer it can not live easily with padded or
dummy packets.

-- 
Jean-Jacques Puig

[homepage] http://www-lor.int-evry.fr/~puig/