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

[Ottawa bakeoff feedback] problem with ESP Padding

Here at the Ottawa ANX workshop we have found a problem with the definition
of Padding in the ESP document.  We found this problem:

The text in sections 2.4 and 2.5 of draft-ietf-ipsec-esp-v2-00.txt
discusses Padding and Pad Length.  We found that people (including myself)
interpreted this like this:

Given a block that ends in 'xx xx', to form the tail end of the ESP
message, you would get

   xx xx [Padding=1 2 3 4] [PadLth=4] [NxtProt=4]

Note this has the padding stuff being 1..2..3..4..4.  That last 4 is the
Pad Length.  It is the length of the "Padding field", the field BEFORE the
Pad Length.  The "1.2.3.4" is the Pad (value).  It is sort of
self-describing.  (The NxtProt is the Next Protocol, e.g. a 4 for IP.)

This is wrong.  It doesn't work for hardware vendors.  It does not meet the
requirement for self-describing padding, as hardware vendors requested and
in the style of PPP.

Here is what we should do:

Given a block that ends in 'xx xx', the tail of the ESP message would be
  xx xx [Padding=1 2 3 4]+[PadLth=5] [NxtProt=4]
This changes the Pad Length field to mean "the length of the padding field,
counting the length byte itself".  Note that since the Pad Length is
mandatory, the minimum value for this is a 1.  This has the padding stuff
being 1..2..3..4..5.

I propose the draft text change.  I propose that section 2.5 now on page 7
change to this:

"2.5 Pad Length

The Pad Length field indicates the number of pad bytes in the message,
including itself.  The
range of valid values is 1..255, where a value of one means that no Padding
bytes are present, other
than the Pad Length itself.  Zero is not a valid Pad Length field.  The Pad
Length field is mandatory."

This will of course break all the ESP implementations that support the
current draft.  Note that you can build in backwards compatability by
implementing this:

  if pad length > 1
    then
      if pad length byte is the same as the previous byte
      then
        implement previous pad algorithm i.e. pad_length++;
Follow-Ups: