[IPsec] AD review comments for draft-ietf-ipsecme-ikev2bis

[Sean Turner <[e-mail]>]

Here is my AD review for draft-ietf-ipsecme-ikev2bis-08.  I read this 
from the perspective of: I just picked this up how do I implement this. 
  I found nothing wrong with the protocol, but there were lots of things 
that could be done to make this a bit easier to read (at least from my 
perspective of not having been eating and sleeping IPsec for years).  As 
such, I consider all of my comments as editorial/nits.

Sec 1: "exchange" is introduced in the 4th paragraph but abandoned in 
the 6th and 7th: r/"request/response"/"exchange".

Sec 1.1: (IKE is deployed right) r/IKE is expected to be used to 
negotiate/IKE is used to negotiate

Sec 1.1.3: At the end of the last paragraph add: (see Section 2.23)

Sec 1.2: Should the 2nd and 3rd paragraph be swapped?  Could also remove 
one of the two references to Section 2.14 for derived keys and then add 
the reference in later when SKEYSEED is introduced.

Sec 1.2: Sometimes initiator and responder are split out in the 
notation/payload table and sometime they are not.  There's also some 
notations missing that are used later (e.g., "Derived" for SK_d, as well 
as SK_pi, SK_pr, SK_ai, SK_er, SK_ei, SK_er, g^ir).  Should the table be 
expanded to include these other notations?  Also, N and CP always uses 
() in the figures so should () be in the table?

Sec 1.2: r/DH/Diffie-Hellman or r/Diffie-Hellman exchange 
[DH]/Diffie-Hellman (DH) exchange [DH]

Sec 1.2/1.3/3.3.4/3.4/D.9: D-H group, DH group, DH Group?

Sec 1.2/2.6.1/2.13/2.15/3.4: (1.2) r/Diffie-Hellman group/Diffie-Hellman 
(DH) group.  (elsewhere) r/Diffie-Hellman group/DH group and 
Diffie-Hellman Group/DH group and DH Group/DH group

Sec 1.2: Should there be some discussion about traffic selectors after 
message #3 and #4?  All of the fields are discussed except the TSi and 
TSr fields.

Sec 1.2: 2nd paragraph after the 4th message refers to messages by 
number # (also occurs later in the document).  Should we add text that 
says "later we sometimes refer to this as message number 1, 2, 3, or 4"?

Sec 1.2: 3rd to last paragraph mentions responses that do not prevent an 
IKE_SA from being set up.  Should the list (or a pointer to a list) of 
messages that do prevent a set up be listed here?

Sec 1.2, 3rd to last para: r/The list of responses/The list of Notify 
Message Types

Sec 1.2, 2nd to last para: r/(for example, AUTHENTICATION_FAILED)/(for 
example, the AUTHENTICATION_FAILED Notify Message Type error is returned)

General: It would be really nice if the Notify Message Type (error vs 
status) was included every time a Notify Message Type is discussed.

Sec 1.2, 2nd to last para: r/notification has/notification message has

Sec 1.2, 2nd to last para: r/the error indication/the Notify Message 
Type indicating the error

Sec 1.2/1.3: The third paragraph in 1.2 is repeated as the second 
paragraph in 1.3.  Was this intentional?

Sec 1.3: The fourth paragraph says that an implementation MAY refuse all 
CREATE_CHILD_SA requests within an IKE SA.  Is there text somewhere that 
says doing so will result in x, y, z?

Sec 1.3: r/the INVALID_KE_PAYLOAD/the INVALID_KE_PAYLOAD Notify payload

Sec 1.3 (last para): r/This notify/This NOTIFY message

Sec 1.3.1 (3rd para after response): r/NOT/not

Sec 1.3.1: r/Failure of an attempt to create/A failed attempt to create

Sec 1.3.3: r/Notify type/Notify Message Type

Sec 1.4.1: r/delete payloads/Delete payloads X2

Sec 1.4.1: r/Informational exchange/INFORMATIONAL exchange

Sec 1.4.3: r/Note that this specification nowhere specifies time 
periods/Note that this specification does not specifies time periods

Sec 1.5: A reply is sent to "whence it came".  Is that a loop or should 
"it" be replace the "the request"?  Text as follows: The message is a 
response message, and thus it is sent to the IP address and port from 
whence it came with the same IKE SPIs and the Message ID and Exchange 
Type are copied from the request.

Sec 1.7: Figures and references are "bit more regular - are we giving 
them more fiber? :) Not sure what you mean by regular - maybe uniform?

Sec 1.7: What is GMAC.  I searched in the document and couldn't find it. 
Is it supposed to be HMAC?

Sec 1.7: r/All of Section 2.25 was added to/Added Section 2.25 to

Sec 2: r/oversize UDP messages/oversized UDP messages

Sec 2.3: r/This Notify/This Notify Message Type

Sec 2.3 (last pra): Should the optional be OPTIONAL?

Sec 2.4: r/unprotected notifications/unprotected Notify messages

Sec 2.4: r/This notification/This Notify Message Type

Sec 2.4: Should INFORMATIONAL message be informational message.  The 
earlier section differentiated between "INFORMATIONAL exchange" and 
"informational message."

Sec 2.4: I noted the same thing Elwyn did about the 4th paragraph.

Sec 2.4: r/There is a denial of service attack on the initiator of an 
IKE SA that can be avoided if the initiator takes the proper care./If 
the initiator takes proper care, then a denial of service attack on the 
initiator can be avoided.

Sec 2.4 (X2)/2.6/2.21.1/2.21.4/2.23/3.6/3.10.1/5: r/denial of service/DoS

Sec 2.5: r/notification message/Notify Message Type

Sec 2.2/2.6: In 2.2 it's (I)nitiator in 2.6 it's I(nitiator).  They 
ought to be consistent.

Sec 2.6: is state and CPU exhaustion one attack or two? r/An expected 
attack against IKE is state and CPU exhaustion/Expected attacks against 
IKE are state and CPU exhaustion

Sec 2.6: r/if an implementation of a responder /if a responder

Sec 2.6: r/DOS/DoS

Sec 2.6: r/this notification/this Notify Message Type

Sec 2.7: r/combined mode/combined-mode    X2

Sec 2.8.3: r/notify payload/Notify payload
Sec 2.8.3: r/notify payloads/Notify payloads

Sec 2.9: r/TS_UNACCEPTABLE/a Notify payload that contains TS_UNACCEPTABLE.*

Sec 2.9: r/SINGLE_PAIR_REQUIRED/a Notify payload that contains 
SINGLE_PAIR_REQUIRED.

Sec 2.11: Often times, I've seen DH qualified with 
ephemeral-ephemeral/ephemeral-static/static-static.  Should it just be 
"ephemeral DH"?

Sec 2.11: r/Since the computing of/Since computation of

Sec 1.2/2.16/App C: If AUTH is optional in message 3, shouldn't AUTH be 
included as [AUTH] in Section 1.2 message 3?

If you're not going to do the previous change:
Sec 2.16: r/from message 3/from message 3 (compared to message 3 in 
Section 1.2 that does include the AUTH payload).

Sec 2.18: Is it "DH transform" or "D-H transform"?

Sec 2.19: Which message 3, #3 in 1.2 is different than 2.16 or does it 
not matter?

Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 and 4 in Section 1.2?

Sec 2.21.2, last sentence: I have the same question Elwyn has.

Sec 2.23: Sometimes "traffic selectors" is "Traffic Selectors".

Sec 2.23.1: r/it may hve a/it may have a

Sec 2.23.1: r/normally looks the/normally looks at the

Sec 2.23.1: (I think Elwyn also noted this) spell out first instance of 
PAD/SAD

Sec 3.1: R(esponse) is (R)esponse in Sec 2.2; shouldn't it match 2.2?

Sec 3.1: Version isn't set by senders (is there some subtlety about it 
not be an initiator?) and is ignored by responders.  What good is this 
field?

Sec 3.3: Should "proposal" and "transform" always be capitalized?

Sec 3.3: Spell out ESN on first use.

Sec 3.5: r/component,the/component, the

Sec 3.5: Should [X.501] an [X.509] be replaced by [PKIX]?  PKIX profiles 
these and PKIX certificates are referenced in section 4.

Sec 3.10: Notification Data they're either status or error types: 
r/Notification Data (variable length) - Informational or error 
/Notification Data (variable length) - Status or error

Sec 4: "PKIX Certificates" is used in Section 4, but

Sec 8.1: Update reference for 3280 to 5280.

App B: I did not verify the DH groups.

App D: I did not verify all that was said that was done was.

spt