Subject: Re: [IPsec] My notes about IKEv2bis

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Oct 2008 10:29:51 -0700

[[ The responses have the same format as before. ]]

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.

===Done.

1.5: Needs rephrasing, maybe merge with 2.21.

===Not done. They don't seem that tightly linked.

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?

===Not done, should be taken to the list.

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

===Not done, should be taken to the list.

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

===Not done, should be taken to the list.

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

===Not done, should be taken to the list.

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)

===Not done, should be taken to the list.

2.8: might be wrong place for Clarif-5.9.

===Done. Moved it to 2.2, where the term is first used.

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

===Done.

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

===Not done, should be taken to the list.

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

===Not done, should be taken to the list.

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

===Not done, should be taken to the list.

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

===Not done, deferred to next version so we can have the new section vetted by the WG to make sure we didn't lose anything.

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

===Not done, deferred to next version so we can have the new section vetted by the WG to make sure we didn't lose anything.

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

===Not done. This seems pretty readable as-is, and it makes it more clear what each requirement is.

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

===Already done.

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

===Done.

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

===Not done, should be taken to the list.

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

===Not done, should be taken to the list.

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

===Done.

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

===Not done, should be taken to the list.

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.

===Done.

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

===Not done, should be taken to the list.

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)

===Not done. Need specific wording, becuase the current wording certainly makes it sound like it is more useful than that.

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

===Done.

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

===Not done, pending proposed wording and discussion on the list.

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

===Not done, given that those threads went into a rathole.

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

===Not done, technical change to the spec.

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

===Not done, pending a list of such features and discussion on the
list.

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

===Done. Well, it's already there as Section 1.7.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec