[IPsec] My notes about IKEv2bis

[<Pasi.Eronen at nokia.com>]

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
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec