Yaron Sheffer writes:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
> be helpful.
>
> Here's a first shot (we'll need to add some descriptive text):
>
> SA Payload
> |
> ---------------............-
> | | |
> Proposal #1 Proposal #2 Proposal #n
> ESP ESP
> SPIx SPIy
> | |
> --------------------- --------------------
> | | | |
> Transform A Tranform B Transform C Transform D
> ENCR AUTH ENCR ESN
> AES HMAC-SHA-256 AES-CCM ESN=1
> |
> -----------------
> | | |
> Attr Ax Attr Ay Attr Az
> 128 192 256
Remove the Proposal #n part, as there is no need for that. It is bad
idea to include more than 2 proposals, as it just makes the payloads
bigger, and causes all kind of problems (for example in IKEv1 this
only way to do this, and vendors had very small upper limit for
number of proposals (2, 4 or 8 or so)).
As in IKEv2 multiple proposals is really needed only for normal
ciphers + authentication vs combined mode ciphers, so the example
should also show two, and this is something we should try to get
vendors to implement.
I have noticed that some vendors have taken their IKEv1 SA payload
processing and are making lots of proposals each having one algorithm
suite and in some cases they still have combination suite including
all alrogithms. This is just stupid and makes packets bigger and can
cause for example fragmentation for the packets, which would be much
smaller if the normal IKEv2 SA payload would be used.
This might be better example:
----------------------------------------------------------------------
SA Payload
|
+------------------+---------------------------+
| |
| |
Proposal #1 Proposal #2
Proto ID = ESP (3) Proto ID = ESP (3)
SPI size = 4 SPI size = 4
5 transforms 2 transforms
SPI = 0x95903423 SPI = 0x12345678
| |
+---+-----+---------+---------+---------+ +---------+
| | | | | | |
Transform Transform Transform Transform Transform Transform Transform
ENCR INTEG INTEG ESN ESN ENCR ESN
ENCR AUTH_HMAC AUTH_AES ESN=0 ESN=1 AES-GCM ESN=1
_AES_CBC _SHA1_96 _XCBC_96 w/8 octet
| ICV
| |
+-+---------+-----------+ +-----------+--+--------+
| | | | | |
Attribute Attribute Attribute Attribute Attribute Attribute
Key Length Key Length Key Length Key Length Key Length Key Length
128 192 256 128 192 256
----------------------------------------------------------------------
And that proposes 3 (ciphers) * 2 (integrity algorithms) * 2 (esn or
no esn) + 3 (combined mode with 3 key lengths) = 15 combinations:
ENCR_AES_CBC 128 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 128 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 128 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 128 bit key, AUTH_HMAC_XCBC_96, ESN=1
ENCR_AES_CBC 192 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 192 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 192 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 192 bit key, AUTH_HMAC_XCBC_96, ESN=1
ENCR_AES_CBC 256 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 256 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 256 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 256 bit key, AUTH_HMAC_XCBC_96, ESN=1
AES-GCM with 8 octet ICV 128 bit key, ESN=1
AES-GCM with 8 octet ICV 192 bit key, ESN=1
AES-GCM with 8 octet ICV 256 bit key, ESN=1
and the full SA payload takes 108 bytes.
BTW, If expanded to IKEv1 style the same SA payload would contain 15
proposals and would be 576 bytes...
If someone wanted to also allow PFS with for example 2 different
groups (plus none) it would add 48 bytes to the IKEv2 style payload,
but would multiply be IKEv1 style payload with 3 plus some raising it
to 2088 bytes...
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
