Re: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01

[Sandeep Kampati <[e-mail]>]

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:[e-mail]] 
Sent: 03 July 2019 23:08
To: Sandeep Kampati <[e-mail]>; [e-mail]
Cc: Meduri S S Bharath (A) <[e-mail]>
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 <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-