Yoav Nir writes: > Issue #142 - Difference from RFC 4718 in rekeying IKE SA > ======================================================== > Section 2.25.2, "If a peer receives a request to delete a Child SA > when it is currently rekeying the IKE SA, it SHOULD reply as usual, > with a Delete payload." I noticed this is different from whatRFC > 4718 recommended, but this is probably OK, given the other text... > (but I still hope this was intentional change :-) > > The relevant text in RFC 4718 is in section 5.11.8: > It seems this situation is tricky to handle correctly. Our proposal > is as follows: if a host receives a request to rekey the IKE_SA when > it has CHILD_SAs in "half-open" state (currently being created or > rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host > receives a request to create or rekey a CHILD_SA after it has started > rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS. > > The case where CHILD_SAs are being closed is even worse. Our > recommendation is that if a host receives a request to rekey the > IKE_SA when it has CHILD_SAs in "half-closed" state (currently being > closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host > receives a request to close a CHILD_SA after it has started rekeying > the IKE_SA, it should reply with an empty Informational response. > This ensures that at least the other peer will eventually notice that > the CHILD_SA is still in "half-closed" state and will start a new > IKE_SA from scratch. > > This seems to be a change to bits on the wire, so we would like the > group's approval. AFAICT no discussion has taken place so far.
Me and Pasi exchanged few emails about this issue: http://www.ietf.org/mail-archive/web/ipsec/current/msg05695.html http://www.ietf.org/mail-archive/web/ipsec/current/msg05817.html and the final comment from Pasi was: ---------------------------------------------------------------------- > > - Section 2.25.2, "If a peer receives a request to delete a Child > > SA when it is currently rekeying the IKE SA, it SHOULD reply as > > usual, with a Delete payload." I noticed this is different from > > what RFC 4718 recommended, but this is probably OK, given the > > other text... (but I still hope this was intentional change :-) > > This was intentional change. <snip> OK; with this reply, I'm OK with closing issue #142. ---------------------------------------------------------------------- > Issue #145 - IKE_SA rekeying wording in 2.8 > =========================================== > Section 2.8, sentence: "Note that, when rekeying..." This is in > wrong place; the rest of this paragraph is about IKE_SA rekeying, so > it should be moved to the previous paragraph. > [[ Tero noted this as well, but Paul disagreed, saying that the > placement was correct. This needs to be resolved. ]] > > I don't really see how this is in the wrong place. The entire > paragraph reads as follows: > To rekey a Child SA within an existing IKE SA, create a new, > equivalent SA (see Section 2.17 below), and when the new one is > established, delete the old one. Note that, when rekeying, the new > Child SA SHOULD NOT have different traffic selectors and algorithms > than the old one. > > This is about Child SAs. It's only the next paragraph that talks > about IKE SAs. I think this should stay where it is. Again, no > discussion was spotted on the list. This was already fixed in the draft-ietf-ipsecme-ikev2bis-07.txt: http://www.ietf.org/mail-archive/web/ipsec/current/msg05710.html So this issue can be closed. This issue was originally brought up by Scott C Moonen (http://www.ietf.org/mail-archive/web/ipsec/current/msg05376.html) in December, and Paul fixed it already then in his internal draft copy (http://www.ietf.org/mail-archive/web/ipsec/current/msg05378.html), and then when both me and Pasi noticed this again in January, he probably didn't remember that he had already fixed this already and when he checked his internal draft he didn't find anything wrong with the text, as he had already fixed it earlier. > Issue #144 - Placement of INVALID_KE_PAYLOAD text > ================================================= > There are two places that have very similar text about > INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and > Section 2.7 (for IKE_SA_INIT exchange). Especially the latter seems > a bit strange, everything else in that section applies to > CREATE_CHILD_SA exchanges, too, but this paragraph explicitly > applies to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works > roughly the same way in CREATE_CHILD_SA, too). Perhaps the text in > 2.7 should be moved to 1.2? > > So the proposal is to move the contents of the penultimate paragraph > (below) in section 2.7 ("Cryptographic Algorithm Negotiation") to > section 1.2 ("Initial Exchanges"). What do you think? > > Since the initiator sends its Diffie-Hellman value in the > IKE_SA_INIT, it must guess the Diffie-Hellman group that the > responder will select from its list of supported groups. If the > initiator guesses wrong, the responder will respond with a Notify > payload of type INVALID_KE_PAYLOAD indicating the selected group. In > this case, the initiator MUST retry the IKE_SA_INIT with the > corrected Diffie-Hellman group. The initiator MUST again propose its > full set of acceptable cryptographic suites because the rejection > message was unauthenticated and otherwise an active attacker could > trick the endpoints into negotiating a weaker suite than a stronger > one that they both prefer. I think this section can be moved, and it might even be better in the section 1.2 than in the 2.7. This also means that the reference in the section 3.10.1 for INVALID_KE_PAYLOAD needs to be updated to point to section 1.2 after the change too. > Regarding issue #140, we're still waiting for an explanation about > how the whole transport mode through NAT issue is relevant to RFC > 5555. Yes. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
