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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
