Yoav Nir writes: > 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.
That change is ok for me. > 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. This two bullet version is fine by me, I had missed the text in the RFC4301, so my proposed 3rd bullet is not need. > 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. I proposed new text for this: http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html > 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)" That bracketed part was added to solve this #141. > If anyone else has comments about this issue, please raise them NOW, > because we are going to close this in a few days. So I think this issue can already be closed, as the at least from my point of view the fix has already been added to the -07 version. > 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. As I pointed out in my email http://www.ietf.org/mail-archive/web/ipsec/current/msg05694.html I need more information what RFC5555 really needs before I can comment on this issue. I used about half an hour writing about 200 lines of more detailed analysis about the issue, but then ended up deleting it when I realized that it is no point for me to go and try to cover all possible cases, as everything depends what RFC5555 really needs. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
