Valery Smyslov writes: > > It matters when you use things like 802.15.9. IEEE 802.15.9 provides a > > method to transport IKEv2 messages over IEE Std 802.15.4. In typical > > PHY of the 802.15.4 the max frame size is 127 bytes, which leaves > > about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2 > > packet will require about 3-4 fragments sent in 3-4 frames. Each of > > those frames will be acknowledged, and there might be timing > > constrains how often they can be sent (for example in TSCH network > > this might be once per second at max, when using 10ms slot time, and > > slotframe size of 100). > > > > If we raise the MAC size from 8 to 16, that will cause 8% probability > > that we need one more frame to send that last part... > > That's a good reason. Shouldn't this (or similar) explanation be > added to the draft?
Perhaps. How much of current information we want to put in the document. The things are changing all the time, and it might be true now for IoT, but might not be true in few years. Isn't enough to just say that currently this algorithm might be used for IoT. > > Also the speeds are low (around 200 kBit/s), and every single byte > > transmitted consumes power... > > That's also a valid reason. Again, shouldn't it be mentioned? Same as above. > > Because for example 802.15.4 devices use AES_CCM already, thus they do > > have hardware to do AES_CCM, but they DO NOT have hardware to to AES > > CBC (there is no AES decryption at all in the hardware). Implementing > > AEAD is easier as it is just software for IKEv2, than adding AES > > decryption to hardware. > > I understand that most IoT devices implement AEAD (AEC-CCM). > And in this case there is no need for them to use Integrity Transform at all. > But since the draft explicitely lists an Integrity Transform for use > in IoT world (AUTH_AES_XCBC_96), then some plain (non-AEAD) > Encryption Transform for IoT must also be specified, > so that they can be used together. AUTH_AES_XCBC_96 was there for before because it was replacement for SHA-1 for general use, not only for IoT. When it was not taken in to the use, it could also be removed or downgraded lower. On the other there might be IoT devices which do not implement AES-CCM on hardware, so AES-CBC + AUTH_AES_XCBC_96 might be suitable combination for them. AES-CBC is already mandatory so there is no point of marking it as IoT only. > >> If an attacker can > >> retrieve the private numbers (for example a, b) (and? or?) the public > >> values (for example g**a, g**b), then the attacker can compute the > >> secret and the keys used and decrypt the exchange. > >> > >> What is (and? or?)? Is it some leftover? Shouldn't it be just "and"? > > > > Actual "or" is right. I.e., if attacker can get either one of the > > private numbers, he can compute the secret. > > I read this "or" as "if attacker can retrieve private numbers or > public values". The attacker can always retrieve public values, - it > is not the threat. If the phrase is changed as you suggest - "if > attacker can retrieve either one of private numbers" then the phrase > makes sense. True, public values is know always, so there is no point of "retrieving" them, I assumed it was supposed to be "(for example a, or b)". In that case we could have also "and as attacker usually knows pulic values"... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
