[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP Pad byte changes
>>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
Scott> Jackie Wilson wrote: <snip...>
>> if it is not important from a security standpoint to have it,
>> then why is it in the draft?
Scott> One argument for using this mechanism is that filling the pad
Scott> bytes with a predictable value prevents filling them with
Scott> other things, i.e. leaking information. I'm not personally
Scott> arguing for or against, just making an observation.
That's an excellent argument for requiring the sending of some
specified value. But I sure am puzzled about why there's a
requirement (or even a suggestion) that it be checked on receive.
Unless I'm missing something, the only thing that's necessary for
packet parsing is that you have to be able to tell the length of the
pad. The only additional property needed for security is that the pad
must not be someone else's data.
The current pad pattern certainly does both of these. Lots of other
pad count plus pad data rules would work just as well -- e.g., pad
data = constant byte N (any N), or random, or pseudorandom. But since
the current pattern works, I wouldn't want to argue for changing it.
On the other hand, I would like to know why the rule is that you MUST
(rather than MAY) check the pad on receive.
paul
References: