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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
