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

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2019 13:38:22 -0400

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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Sandeep Kampati <[email-masked]>
Date: Tue, 16 Jul 2019 10:02:07 +0000

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).

       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-masked]] 
Sent: 03 July 2019 23:08
To: Sandeep Kampati <[email-masked]>; [email-masked]
Cc: Meduri S S Bharath (A) <[email-masked]>
Subject: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01

This means the SAi2, TSi and TSr in the initiator, With the responder providing SAr2, TSi and TSr.

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.

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:

{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-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 14:23:50 -0400

I wasn't sure from your reply if you agreed with my numbers, or wanted to
revise them.  I think some numbers should go into the document, do you?

Sandeep Kampati <[email-masked]> wrote:
    > 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

5 suites makes sense.
120 does not sense to me, do you know what the combinatorics involved are?
Since the gateway picks one and replies, the situation where the gateway
wants to continue with the same one, there doesn't seem to be that much savings.

    > If more cryptographic suites are configured the saving with will

I don't think it's *exponential*, I think it's linear per connection :-)
If you want to count savings per gateway, then it's O(n*m) where n=number of
clients, m=number of suites.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Jul 2019 17:39:16 -0400

> On Jul 16, 2019, at 06:02, Sandeep Kampati <[email-masked]> wrote:
> 
> 

But for a rekey, the initiator could just send the currently used negotiated transforms. It knows these are accepted / favoured. If for some reason the currently used transforms are no longer accepted, it could do a new initial exchange after the rekey failed, or another rekey attempt with more ciphers.
So the gain should not be measured against the 120 transforms.

> 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

Strongswan is known to send everything it got. Which is a giant amount. With debugging enabled, the entire code was so slow the exchange timed out. We had to rewrite proposal parser to be smarter.

But I only expect such a large set on the initial exchanges - not on rekeys.

Paul