Stephen Farrell writes: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I'll be a yes ballot but I'd like to chat briefly if that's ok, just > to check the level of consensus behind the algorithm choices > documented here. For example, is A.3.2 recommending that only > AES_CBC and AES-CCM_8 ought be implemented?
No. This document does not give any recommendations for the algorithms. The normal IPsec way is that we do not list mandatory to implement algorithms in protocol documents. We have separate documents for them, i.e. RFC4307 for IKEv2 (or most likely the RFC4307bis version which is now work in progress in the IPsecME WG) and RFC7321 for ESP and AH. The algorithms in the appendex A is just subset of the algorithms which are most likely to be useful for the person implementing minimal IKEv2. The actual algorithms that will be used are most likely be something that depends on the environment. I.e. if this is used in the 802.15.4 environment, where the hardware already has everything needed for the AES-CCM, then IKEv2 SA and ESP SA are most likely using AES-CCM too. > And would we still recommend 1536 D-H and wouldn't 2048 by itself be > sufficient? The RFC4307bis in the IPsecME WG will most likely say that 2048 bit MODP group is mandatory to implement, but I would expect that constrained devices might want to use ECP or smaller MODP groups instead. > Shouldn't you be clear about that kind of stuff? (I mean > what algs you're telling folks to implement in appendix A.) Did the > WG discuss all those kinds of decision? (Or are they just what you > implemented?) What will be used and what will be implemented will quite often be same in the constrained use cases. I.e. they first decide what they will use, and will only implement that. This will most likely make those implementations non-conforming to the IKEv2, as they might not implement all mandatory to implement algorithms. On the other hand RFC4307bis etc tries to keep algorithms for constrained devices as a SHOULD, so minimal IKEv2 implementations using suitable algorithms for them will be able to talk to the full IKEv2 implementations as they implement those algorithms too. On the other hand, in the constrained environment the "server" and "client" end of the connections are usually tied together, i.e. they follow same profile which will then specify the algoritms which will be used. All of that is outside the scope of this document. This document do assume that we follow normal mandatory to implement algorithms as specified by the already existing separate RFCs. In the IPsecME WG, there was discussion whether we should have two profiles in the RFC4307, one for the constrained devices, and another for normal devices. I.e. whether the mandatory to implement algorithms for constrained devices should be different than what is required for full implementations. This is still ongoing discussion on the IPsecME WG, and this document will assume implementors follow whatever the final bis document will say. > The reason this is a discuss is just so that we're clear about the > algorithm stuff - I suspect a bunch of folks will just do what this > document says (or have already) so ensuring these choices are good > ones that the WG actually thought about now is I think worthwhile. As I said earlier, this document does not try to propose any specific set of algorithms, it mostly just removed those algorithms which was seen unneeded for minimal implementations. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Would it be worth waiting on 25519 for this? There is no implementations implementing that yet, so I think it is too early to put that in. Also those implementations we had for this minimal ikev2, did not support anything else than MODP Diffie-Hellman, so we could not claim that we have implementation experience about those groups. > Would the code-size and CPU improvements be better than publishing > now? As this document does not restrict or give any guidance for selection of the algorithms (except it says that in the constrained environment there will most likely be exactly one configured algorithm set), there is no problem of someone picking that curve in the future for their environment when that curve has been standardized for IPsec. > I guess it could be that the CPU improvement mightn't be as > good on smaller CPUs (not sure), but I just figured it'd be good to > ask since work on 25519 for IPsec is under way and it should have > some benefits. (I'm fine though if the answer here is "no, not yet" > in which case, there's no need to even respond to me:-) I think we would need to get some implementation experience on the constrained devices before we can say how well the curve25519 will work on those devices. In theory it should work ok, but theory does not always agree with the actual implementations :-) -- [email protected] _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
