Subject: [IPsec] My notes about IKEv2bis

From: <[email-masked]>
Date: Wed, 3 Sep 2008 09:01:44 +0300

A while ago, I promised to send my list of "things that need to be 
looked at" about IKEv2bis to the mailing list.

These are a mix of things that IMHO might be wrong, might benefit from
some editorial changes/clarifications, things that just need some
thinking to check if they're actually correct, and other random notes.

--------

Abstract: needs rephrasing, include at least "IKE is a component of
IPsec used for performing mutual authentication and establishing and
maintaining security associations (SAs)" from RFC 4306 abstract.

1.5: Needs rephrasing, maybe merge with 2.21.

2.4: "receiving parties need to deal with it in other requests" Is
this right, and how it's dealt with? And only requests, not responses?

2.5: Needs to clarify what exactly the message containing the
INVALID_MAJOR_VERSION notification looks like (Fukumoto Atsushi's
email 2007-06-12)

2.6 (near Clarif-2.1) and 2.6.1: needs rephrasing/more explanation
(especially "MUST NOT fail" is unclear).

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")

2.7 and 3.3.6: text about INVALID_KE_PAYLOAD might need clarification:
if none of the proposed groups is acceptable, NO_PROPOSA_CHOSEN is the
correct notification (thread "Is this a good use of the
INVALID_KE_PAYLOAD notification", May 2007)

2.8: might be wrong place for Clarif-5.9.

2.8: maybe clarify that when rekeying, the new SA might have
different traffic selectors and algorithms than the old one?

2.8: probably should clarify what you do when you receive
NO_PROPOSAL_CHOSEN during IKE_SA rekeying

2.9.1: might not fully consistent with RFC 4301 regarding decorrelated
policy etc. (emails 2008-11-28 and 2008-11-30).

2.19: text about FAILED_CP_REQUIRED needs editing, and it's in wrong
place (breaks flow of other text)

2.19 and 2.19.1: needs editing/rephrasing, perhaps merging these
two sections to improve flow.

2.19 and 3.15: text about configuration payloads is still in
two places; either merge or more clearly separate what goes where.

2.23: lots of bullets here, could be formatted in more readable way?

5: "implementation using EAP MUST also use strong authentication",
change from RFC 4306, and "strong" is ambiguous (e.g. is "group secret"
strong?)

8.2: RFCs 2251, 2486, and 3513, and FIPS 180-1, have been obsoleted by
newer documents.

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

The document probably should talk about PAD in the context of 
IKE_SA authentication, and traffic selector authorization.

INVALID_IKE_SPI needs some clarification (emails from 2007-10-17 to
2007-10-19)

There should be text about how a protected INVALID_SPI notification
is processed.

Mapping of incoming IKE packets to IKE_SA needs clarification
(maybe in 2.1, 2.6 or 3.1): it's done using the recipient SPI only,
not e.g. using the source IP address.

The text about transport mode NAT-T isn't right: it really needs to
discuss how the SPD and TS payloads work, and it seems incremental
checksum fixup can't work as described (I have longer notes about this
topic based on discussions with Tero in December 2007).

ADDITIONAL_TS_POSSIBLE probably needs clarification: it seems the
recipient can't really use this for anything else than
logging/debugging, if even that (thread August 2008)

Do traffic selectors containing port numbers make sense if the 
protocol is 0? (thread August 2008)

Would it be useful to have a separate section describing "CHILD_SA
attributes" like ESN, ESP_TFC_PADDING_NOT_SUPPORTED, IPCOMP_SUPPORTED,
NON_FIRST_FRAGMENTS_ALSO, etc.?

Do we need text about simultaneous reauthentication and/or
simultaneous initiation of IKE_SAs? (email 2007-08-21, thread June
2008)

Should we support OPAQUE protocol selectors for IPv6 (thread May/June
2007)

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

The document will eventually need a "changes to RFC 4306" (or at 
least "changes that implementors of RFC 4306 should look at") 
section.

Tero's email on 2008-07-29 had bunch of things.

Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Sep 2008 13:42:35 +0300

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

> 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

What are such features?
-- 
[email-masked]