[IPsec] My notes about IKEv2bis

[Tero Kivinen <kivinen at iki.fi>]

Pasi.Eronen at nokia.com writes:
> 2.7 and 3.3.6, possible contradiction about INVALID_KE_PAYLOAD ("MUST
> again propose its full set of." vs. "SHOULD, however, continue
> to propose its full supported set")

The 2.7 talks about the IKE_SA_INIT, and there it is MUST to propose
the full set. The 3.3.6 talks about the attribute negotiation in
general, and for example in the CREATE CHILD SA case the exchange is
already authenticated, thus there cannot be man in the middle even if
the initiator decides to retry CREATE CHILD SA with only the select
Diffie-Hellman group, i.e. does not include full supported set.

>From the responders point of view this does not matter, thus there is
no interoperability problem here, even if initiator only uses smaller
set. I think should in the 3.3.6 is still ok for the general case and
the 2.7 needs to keep the MUST as that is required for the security in
the IKE_SA_INIT case. 

> Text doesn't cover all the exchange collisions from RFC 4718 Section
> 5.11 yet (but I doubt implementors will get many of those right anyway...).

Most of those does not really matter as long as the implementations do
not crash on such cases. For example in 5.11.1 even if other end sends
duplicate delete for some SPI, that most likely will not cause any
problems. In 5.11.2 if either end fails to close SA properly, they
will close it after the DPD fails in the future. In the 5.11.3 the
failure might cause some extra IPsec SAs to be created, but that
should not cause problems.

The only really important case is the 5.11.4, as if during the IKE SA
rekeying the wrong IKE SA inherits the child SAs of the original IKE
SA that will cause the state to be messed up between the hosts, and
only way to recover will be to delete IKE SAs and start over. 

> Should we move features with no known implementations from the main
> text to an appendix?

What are such features?
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec