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
