[Swan-dev] ESP_XXX and esp= problem (and ike= problem too)

[Paul Wouters]

The ESP_* entries for IKEv1 and IKEv2 no longer match :(

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-registry-9

Note the IKEv2 table has an "ESP" and an "IKEv2" column for encryption numbers. For the IKEv1
encryption algorithms, see (the confusingly named 'ipsec' not 'ike' page):

https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xml#ipsec-registry-4

In IKEv1, 21 is SEED, 22 CAMELLIA, 23 is NULL_AUTH_AES-GMAC.

In IKEv2, 21 is NULL_AUTH_AES_GMAC, 22 is reserved, 23 is CAMELLIA (CBC)
and 24 is CAMELLIA_CTR.

for our esp= line, we match our defined ESP_XXX enum names, so this is
now a problem. I noticed camellia had a weird number entry in IKEv1,
fixed it and found out I broke it for IKEv2, and reverted it.

So, now what does our "registration" for ESP even mean? And I guess this
breaks the PFKEY API? The kernel sure as hell cannot identify an
algorithm by a number anymore. What's the meaning of "22" now ?

We currently have:

000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256

The versions match up until id=9. id=10 was ESP_RC4 in IKEv1, and is
reserved in IKEv2. Not too bad, we do neither. It then matches up
to id=16. 17 is unassigned in both. 18-20 matches as well.

And 21-23 clashes. IKEv2 is the only one to have 24-27 right now.

So the question is what do we do for our esp= line, that in our code is
not depending on the IKE version at all? Should we make yet another
similar looking table with our own numbers? Should we postpone
converting the ike= and esp= strings until we know what version of
IKE we are talking?

Another solution would to be to declare IKEv1 only up to 20. So
esp=camellia would mean you have esp="" when initiating IKEv1, but you
would have esp=camellia when initiating/responding to IKEv2. Then we
use our ESP_XXX enum names based on the IKEv2 entries

Now on top of that, we have an IKE issue too. Camellia for IKEv2 is 23,
but for IKEv1 it is 8. AES (CBC) in IKEv2 is 12, in IKEv1 it is 7. Of
course, AES (CBC) works now for both IKE versions and ESP.

For instance, when you say ike=aes, you see:

000 "conname":   IKE algorithms wanted: AES_CBC(7)_000-SHA1(2)_000-MODP2048(14), [....]

So we are using the IKEv1 numbers there. But obviously we are not
sending 7 over the wire but 12 when using IKEv2.

We currently do not support ike=aesctr (though we have to add support
for that), and the string fails. But for esp=aesctr we do support it,
using the v2 numbering:

000 "conname":   ESP algorithms wanted: AES_CTR(13)_000-MD5(1)_000, [...]


I'm also beginning to feel we should really abandon all "registrations".
The Linux pfkey API is already not giving us all kernel supported algo's,
so we end up lying and working around missing entries and we need IKE
entries for ESP entries because it is used for things like keysize
lookups. And registering "IKE" items seems silly. We should know what
we support already and our code works partially via the registration
and partially outside of it.

Paul