Hi Yoav.

> I agree that term "authenticated" is a bit misleading here.
> The better term would be "integrity protected".
> In our proposal receiver can be absolutely sure that
> each fragment comes from the very peer he/she exchanged
> DH exponents and calculated shared secret with.
>
> All fragments which ICV cannot be verified are discarded
> and don't prevent communication with real peer in any way.

So in order to get the responder to spend memory resources on storing the fragment, the initiator needs to expand CPU resources on completing the D-H calculation, and calculating integrity protection on the fragment. Makes sense.

Sorry, did you read the draft?

There is no DH calculating per fragment. DH is calculated once in IKE_SA_INIT as in ordinary IKE SA establishment (note, that unprotected messages, including IKE_SA_INIT
and IKE_SA_RESUME cannot be fragmented).

And you spent absolutetly the same amount of CPU power to calculate/verify ICV on
fragments as you would spend it on non-fragmented message
(probably a little bit more, as total length of all fragments of one message could be a bit more than the length of original message due to padding, IKE header and so on,
but the usual difference is few percents).

Let me emphasize again.
1. In our proposal sender and receiver spend roughly the same amount of CPU power
   as they would spend on protecting/verifying non-fragmented message.
2. In our proposal sender and receiver spend roughly the same amount of CPU power as they would spend on protecting/verifying fragmented message in Cisco/MS solution. 3. In our proposal sender needs to encrypt/protect one message twice only once per SA establishments and only if he/she tries first to send unfragmented
   message and after some retransmits decides to resend it fragmented.
   This is avoidable if sender always sends large messages fragmented.
4. Comparing to Cisco/MS solution our proposal allows receiver to
   verify integrity of individual fragment, so forged fragments will not
   consume receiver's memory and could not prevent receiver
   from getting valid fragments.

What do you get when you put together the fragments? a decrypted IKE message? Just the list of payloads?

After you decrypt and verify content of Encrypted Fragment Payload of all fragments, get rid of now unnecessary headers and put all together, you get a decrypted IKE message.

Yoav=

Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to