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

[Michael Richardson <[e-mail]>]

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 =-