Hi all We would like to begin closing IKEv2bis issue at a faster rate than we are opening new ones. Paul has sent the list a several issues. Some we have discussed, others - not so much. Here's a summary of three issues, which I think are ready for closure.
Issue #138 - Calculations involving Ni/Nr ========================================= Section 2.14: "only the first 64 bits of Ni and the first 64 bits of Nr are used in the calculation". This section has two calculations involving Ni/Nr, but this sentence should only apply to the former. Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED (but all bits are used when calculating SK_*)" There was just one response (from me), and I suggested the following text: only the first 64 bits of Ni and the first 64 bits of Nr are used in calculating SKEYSEED, but all the bits are used for input to the prf+ function. If anyone else has comments about this issue, please raise them NOW, because we are going to close this in a few days. Issue #139 - Keying material taken in the order for RoHC ======================================================== One of the differences between RFC 4306 and the IKEv2bis draft is in Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the IKEv2bis draft indicates the following: In Section 2.17, removed "If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet" because multiple IPsec protocols cannot be negotiated at one time. Is it possible to leave the quoted text in the spec? I agree that multiple IPsec protocols cannot be negotiated at one time; however, the text is useful for ROHCoIPsec implementers, where multiple keys may need to be generated for a ROHC-enabled Child SA. For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec encryption/authentication keying material will be taken, then an additional key will be taken for the algorithm used to verify the proper decompression of packet headers. I said I preferred to leave the text as it is, and let RoHC specify their modifications (which they did). Valery, Tero, and David chimed in, correctly pointing out that if multiple extensions are negotiated (RoHC + GCM + some future extension) it is up to the base document to specify the order between them. I'm convinced. Paul also suggested some text (below) for a bulleted list of two points. Tero suggested a third (encryption before authentication), but Valery pointed out that this is already in 4301. If the Child SA negotiation includes some future IPsec protocol(s) in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then (1) all keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction, and (2) keying material for the IPsec protocols are taken in the order in which the protocol headers will appear in the encapsulated packet. If anyone else has comments about this issue, please raise them NOW, because we are going to close this in a few days. Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND ====================================================================== Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA": Is this really necessary? I think this notification should only occur in cases where DELETE payload for this Child SA pair has already been sent, and probably has been processed already by the time the CHILD_SA_NOT_FOUND notification is received. No responses were received for this. My opinion is that CHILD_SA_NOT_FOUND will usually not occur at all. Even if lifetime is the same on both peers, rekeying is always done earlier than deleting (for example, if your SAs last 1 hour, you might rekey at 58 minutes, but only delete after 60 minmutes), so collisions of rekey and delete will be rare. Because of this, I believe that the CHILD_SA_NOT_FOUND will stem from some mismatch in the SAD between the two peers. Yes, this probably indicates a bug somewhere, but these things do happen. I believe the text should stay, as it clarifies that the peer does not need to create a new INFORMATIONAL exchange with a DELETE payload to discard. In fact the text already has in brackets "(if it still exists)" If anyone else has comments about this issue, please raise them NOW, because we are going to close this in a few days. I would also like to take this opportunity to ask people to look into issue #140 (No SPD entry for transport mode), as I think this one needs some serious discussion before closing. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
