Subject: [IPsec] Closing some more issues for IKEv2bis

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Jan 2010 11:43:48 +0200

Hi all. Time for another set of issues.

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.

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.

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.

Regarding issue #140, we're still waiting for an explanation about how the whole transport mode through NAT issue is relevant to RFC 5555.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Jan 2010 13:42:49 +0200

Yoav Nir writes:
> 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 :-) 
> 
> 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.
----------------------------------------------------------------------

> 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. ]] 
> 
> 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.

> 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? 
> 

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.
-- 
[email-masked]