Re: [IPsec] draft-mglt-ipsecme-diet-esp-iv-generation

[Daniel Migault <[e-mail]>]

Hi Valery and thank you for your feed backs.

Instead of negotiating the IV compression in a separate way, Valery
suggests to have a specific mode like AES-CBC_WITH_IV_COMPRESSION for
example.

To me its sounds better than what is being described in the draft.

Please let us know what you think about this alternative, and which
function would you use to generate the pseudo random IVs in each packets.

See inline for more comments.

BR,
Daniel


On Tue, Jul 15, 2014 at 9:23 AM, Valery Smyslov <[e-mail]> wrote:

> Hi,
>
> I have some comments regarding the draft.
>
> First, it is not absolutely clear from the draft how the IV is generated
> for each packet. I presume
> that the IVs are taken sequentially for every new
> ESP packet to send from the bit string generated
> by prf+. But then it is not clear for me how the receiver
> would regenerate the same IV in case of packets loss
> and reordering. Sending LSB of IV would help here a bit, but then receiver
> would do quite a lot of work to guess
> the right IV, the overall process is not deterministic
> and opens a possibility for simple DoS attack.
>

This is true, and we should have added more text on that. The initial idea
is to rely on the Sequence Number, and their should be a deterministic way
to bind SN and IV for bot peers. However you are right, to avoid simple
DoS, there should also be a deterministic way to decompress the SN.


> The receiver would also look at the sequence number to deal with packets
> loss and reordering, but as far as I understnad the SN is optional in
> Diet-ESP.
>

It depends what optional means. Diet-ESP packets MUST have a complete
Sequence Number to enable anti-replay and to compute the ICV. On the other
hand, Diet-ESP provides the option to send only the LSB of the SN on the
wire. In order to avoid simple DoS attacks, the decompression of the SN
should be "almost" deterministic.


> Then, I'm not a crypto expert, but using the same
> key for both encryption and IV generation looks
> like a bit unsound.
>

This sounds bad to me too. Actually this is my main concern.


> Finally, I would prefer defining new transorms
> (for example AES-CBC with implicit IV) instead of negotiating IV
> compression separately.
>

That is maybe the way to do. Thanks for your feed back.

>
> Regards,
> Valery Smyslov.
>
>
>


-- 
Daniel Migault
Orange Labs -- Security
[phone]