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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
