Hi Michael Richardson,
In Case of ESP
Sai2 = SA + Proposal + 3 transforms (1. Encryption 2. Integrity 3.Extended
Sequence Number )
Minimum Size of SA payload is 40 Bytes = (SA) 4 + (Proposal + SPI )12 + (3
transforms [3*8]) 24, SA payload size for ENCR_AES is 44 bytes
REKEY_SA(12) + SA (40) + 48 (2x TSx 24 * 2) + Ni 20 bytes = 120 bytes (IPv4).
REKEY_SA(12) + SAi2 (40bytes) + 96 (2x TSx 48 * 2 )+ Ni 20 bytes = 168
bytes (IPv6).
REKEY_SA(12)+ SA_TS_UNCHANGED (12) + Ni 20 bytes = 44 bytes (IPv4).
REKEY_SA(12)+ SA_TS_UNCHANGED (12) + Ni 20 bytes = 44 bytes (IPv6).
KEx = 8 + 32 bytes (256-bit ECDSA) = 40 bytes.
all ts-opt %Saved all-ke ts-opt-ke %Saved
IPv4: 120 44 63% 160 84 47 %
IPv6: 168 44 70% 208 84 59%
If we send more number of cryptographic suits the percentage of saving will
increase
Most if deployment scenario what I observed is initiator is sending at least 5
cryptographic suits, in some deployment scenarios they are sending 120
cryptographic suites
If more cryptographic suites are configured the saving with will increase
exponential.
Regards,
Sandeep.k
>> It might be worth putting the nonce into the SA_TS_UNCHANGED payload, as
>> that saves another 4 bytes. --> this also good suggestion we
-----Original Message-----
From: Michael Richardson [mailto:[email protected]]
Sent: 03 July 2019 23:08
To: Sandeep Kampati <[email protected]>; [email protected]
Cc: Meduri S S Bharath (A) <[email protected]>
Subject: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01
Sandeep, I read the document this past week.
I found the claim that the TS and SA details were worth optimizing to be
surprising.
So I counted the size of the CHILDSA proposal.
This means the SAi2, TSi and TSr in the initiator, With the responder providing
SAr2, TSi and TSr.
HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
TSi, TSr} -->
TSx = 8 (header) + 8 + 8 = 24 (IPv4)
8 + 8 + 32 = 48 (IPv6)
SAi2= 8+4(SPI) + transforms
transforms = 8+ 4(cipher)+ 4(integ) = 16 bytes
total = 28 bytes.
Ni = 4 + nonce-size (16+ bytes)
N(REKEY_SA) = 8 bytes.
total: SAi2 (28bytes) plus 2x TSx 24 * 2 + Ni 20 bytes + N 8= 104 bytes (IPv4).
SAi2 (28bytes) plus 2x TSx 48 * 2 + Ni 20 bytes + N 8= 152 bytes (IPv6).
I have not included KEi, as you did in your section 3.2.1, because I assume
that if computation and netweork resources are at premium, that doing
additional exponentiation is inappropriate. Maybe a new DH every N rekeys.
KEx = 8 + 32 bytes (256-bit ECDSA) = 40 bytes.
potentially there are some notifications, at 8 bytes each, potentially longer.
Replacing this with a single 16-byte Notify would be a win on total bytes, but
as it does not reduce the number of packets at all, I'm still having difficulty
believing it really matters.
It might be worth putting the nonce into the SA_TS_UNCHANGED payload, as that
saves another 4 bytes.
A new Ni/Nr is needed each time as the child SA key derivation needs that
freshness. So, the math is:
all ts-opt all-ke ts-opt-ke
IPv4: 104 36 144 74
IPv6: 152 36 202 74
{There are some assumptions that I have made in this calculation.
Probably some mistakes, so if an important argument point, I'll post a Google
Calc page with my assumptions.
The cost of KE size with DH groups would be bigger than with ECDH groups. }
--
Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6
IoT consulting =-
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
