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

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




While looking over the remaining issues still open on RFC 2401bis,
Barbara and I were looking at issue #76, to make sure it was fully
addressed.  Per the discussion on the mailing list, this issue was
transferred to the ESP v3 document.  So when I went to double check to
make sure the text was properly reflected 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.

3) We modify ESPv3 to indicate that the mere use of IKEv2 implies that
   the receiver can accept ESP packets that contain RFC padding.

What do folks think?

						- Ted