[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IBM VPN Bakeoff Issues
>>>>> "Stephen" == Stephen Waters <Stephen.Waters@digital.com> writes:
>> 12. Does ESP-NULL require padding (the ESP doc says 4-byte
>> alignment, ESP-NULL doc says 1-byte alignment). The consensus was
>> that ESP is 4-byte aligned.
> There is no ambiguity. ESP in general requires 4 byte padding or a multiple
> of 4. ESP-NULL has a block length of 1. Since the padding used for a
> particular combination of ESP and an encryption algorithm is the lowest
> common multiple of 4 (from ESP) and the block length of the cipher, the
> result is that ESP with the NULL cipher uses a padding of 4 (or 8, or 12,
> ...)
> [[SW]] There may not be any ambiguity, but there is contradiction and
> confusion :) We're not talking about 'ESP in general' though, right, this is
> NULL-ESP, and I don't understand why NULL-ESP should have any padding, let
> alone 4 bytes. NULL-ESP actually means ESP-Authentication, and the mandatory
> authentication algorithms don't need padding. One problem is where folk
> want to pad for other reasons - then your left with the dilemma of not
> knowing if it was applied or not. With PPP ECP, if there is no need to pad,
> but the last octet of data could be taken for a pad length, then explicit
> padding is added. Since the pad length can be 0-255, I guess that means a
> pad length is mandatory, but why can't I just add a single byte with value 0
> if I'm not interested in padding?
The ESP spec is, as far I can see, perfectly clear on this. I see no
contradiction in it.
It describes three reasons for padding:
1. encryption transform requires blocks of size n > 1.
2. authentication data should start on 4-byte aligned boundary.
3. sender may want to obfuscate the packet size.
It seems pretty clear that (2) is required independent of (1) and
(3). As Tim said, the net result is that you must pad to an
LCM(blocksize,4) multiple. For DES and the like, that means 8; for
RC4 and Null, it means 4.
paul
References: