This is my first part of my review of ikev2bis document. This includes
changes based on going through section 1.
----------------------------------------------------------------------
Section 1 defines following terms: IKE SA, Child SA, message, request,
response, and exchange. The document uses sometimes "reply" instead of
"response", so I think it should be consistent in its use of terms.
This means that following uses of "reply" should be changed to
"response".
- Section 1.4.1 Deleting an SA with INFORMATIONAL Exchanges
change
"Normally, the reply in the INFORMATIONAL exchange will contain
delete payloads for the paired SAs going in the other direction"
with
"Normally, the response in the INFORMATIONAL exchange will contain
delete payloads for the paired SAs going in the other direction"
- Section 2.1. Use of Retransmission Timers
change
"IKE is a reliable protocol, in the sense that the initiator MUST
retransmit a request until either it receives a corresponding reply
OR it deems the IKE security association to have failed and it
discards all state associated with the IKE SA and any Child SAs
negotiated using that IKE SA. "
with
"IKE is a reliable protocol, in the sense that the initiator MUST
retransmit a request until either it receives a corresponding
response OR it deems the IKE security association to have failed
and it discards all state associated with the IKE SA and any Child
SAs negotiated using that IKE SA. "
- Section 2.6. IKE SA SPIs and Cookies
change
"An attacker can forge multiple cookie responses to the initiator's
IKE_SA_INIT message, and each of those forged cookie replies will
trigger two packets: one packet from the initiator to the responder
(which will reject those cookies), and one reply from responder to
initiator that includes the correct cookie."
with
"An attacker can forge multiple cookie responses to the initiator's
IKE_SA_INIT message, and each of those forged cookie replies will
trigger two packets: one packet from the initiator to the responder
(which will reject those cookies), and one response from responder
to initiator that includes the correct cookie."
- Section 2.23.1. Transport Mode NAT Traversal
change
"When the client receives the server's reply to the Child SA, it will
do similar processing."
with
"When the client receives the server's response to the Child SA, it
will do similar processing."
and change
"If transport mode for the SA was selected (that is, if the server
included USE_TRANSPORT_MODE notification in its reply):"
with
"If transport mode for the SA was selected (that is, if the server
included USE_TRANSPORT_MODE notification in its response):"
- Section 3.15.1. Configuration Attributes
change
"INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
netmask is allowed in the request and reply messages"
with
"INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
netmask is allowed in the request and response messages"
and change
"Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a
reply."
with
"Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a
response."
- Section 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
change
"A different possible reply would have been this:"
with
"A different possible response would have been this:"
and change
"That reply would mean that the client can send all its traffic
through the gateway, but the gateway does not mind if the client
sends traffic not included by INTERNAL_IP4_SUBNET directly to the
destination (without going through the gateway)."
with
"That response would mean that the client can send all its traffic
through the gateway, but the gateway does not mind if the client
sends traffic not included by INTERNAL_IP4_SUBNET directly to the
destination (without going through the gateway)."
and change
"then the gateway's reply might be:"
with
"then the gateway's response might be:"
- Section 4. Conformance Requirements
change
"Every implementation MUST be capable of responding to an
INFORMATIONAL exchange, but a minimal implementation MAY respond to
any INFORMATIONAL message with an empty INFORMATIONAL reply"
with
"Every implementation MUST be capable of responding to an
INFORMATIONAL exchange, but a minimal implementation MAY respond to
any INFORMATIONAL message with an empty INFORMATIONAL response"
In other cases the "reply" should be kept as it is now, as it does not
refer response message.
----------------------------------------------------------------------
The document also uses both "Child SA" and "IPsec SA" quite often, and
I think they are meant to mean same...
----------------------------------------------------------------------
In section 1.2 there is one instance of "IKE_INFORMATINAL exchange",
which should be "INFORMATIONAL exchange" instead.
----------------------------------------------------------------------
In section 1.3 at the end there is text talking about the
NO_ADDITIONAL_SAS. The current text is in the generic CREATE_CHILD_SA
section thus it covers all 3 use cases for CREATE_CHILD_SA (creating
new IPsec SAs, rekeying old IPsec SAs and rekeying IKE SA). The text
there is written to cover only new IPsec SAs, but I think it should
also cover rekeying IKE SA cases (section 4 conformance requirements
makes it quite clear you can return NO_ADDITIONAL_SAS to any
CREATE_CHILD_SA exchange including IKE SA rekey).
This means the text should be changed from
The responder sends a NO_ADDITIONAL_SAS notification to indicate that
a CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. Some minimal
implementations may only accept a single Child SA setup in the
context of an initial IKE exchange and reject any subsequent attempts
to add more.
To
The responder sends a NO_ADDITIONAL_SAS notification to indicate that
a CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. This notify can
also be used to reject IKE SA rekey. Some minimal implementations may
only accept a single Child SA setup in the context of an initial IKE
exchange and reject any subsequent attempts to add more.
----------------------------------------------------------------------
Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
and says they can be included, but the packet figure does not include
them. Adding them to the figure would be easy, but the problem is that we
currently say that you should follow the order of payloads from the
figures (altough we do refer to section 2 not section 1, but this is one
of the open issues).
So depending what we decided on the payload order and figures, it might
be better to add one extra ", [N]" to the figure before SA payload.
Also there is one more notify payload which can be included and which
affect negotiation, i.e. the IPCOMP_SUPPORTED notification which is
covered in the 2.22. Perhaps forward reference should be added to there.
Also the section 1.3.1 has text which perhaps should be removed:
Failure of an attempt to create a Child SA SHOULD NOT tear down the
IKE SA: there is no reason to lose the work done to set up the IKE
SA. When an IKE SA is not created, the error message return SHOULD
NOT be encrypted because the other party will not be able to
authenticate that message. See Section 2.21 for a list of error
messages that might occur if creating a Child SA fails.
This section 1.3.1 is talking about the CREATE_CHILD_SA not initial
IKE_AUTH, thus this section is not needed here. The section 1.2 already
has text about the Child SA failing during the initial exchange, so this
how paragaraph needs to be removed.
----------------------------------------------------------------------
Section 1.3.3 should make it clear that the first N payload in the figure
is the N(REKEY_SA), i.e the diagram should be changed to:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
TSi, TSr} -->
Also this section should say that other notifications explained in the
1.3.1 can also be included in this exchange, i.e. if transport mode SA
was rekeyed then this CREATE_CHILD_SA rekeying that SA needs to include
USE_TRANSPORT_MODE notification. Some kind of reference back to the 1.3.1
should be enough.
----------------------------------------------------------------------
Section 1.4 says that
INFORMATIONAL exchanges MUST ONLY occur
after the initial exchanges and are cryptographically protected with
the negotiated keys.
This does not match the 1.5 which says we can send INFORMATIONAL
exchanges also outside the IKE SA.
Perhaps this needs to be changed to:
Normally INFORMATIONAL exchanges MUST ONLY occur
after the initial exchanges and are cryptographically protected with
the negotiated keys (see Section 1.5 for exceptions).
----------------------------------------------------------------------
Section 1.5 needs some reordering and the text in section 1.5 vand 2.21.4
needs to be combined, now we have about the same text in two places.
The first paragraph of the 1.5 talks about the INVALID_IKE_SPI even
though it does not say it explictly, the second paragraph talks about
INVALID_SPI and then in third paragraph it says that "there are two cases
when one-way message is sent: INVALID_IKE_SPI and INVALID_SPI", just like
this would be new thing, but the previous paragraphs have already talked
about this. This is confusing, so I think this section requires bit of
reordering and rewording. Also it might be useful to actually move all
this text to section 2.21.4 and remove this whole section (remember
to update references).
Especially the fact that exchange type is copied from the request in
the INVALID_IKE_SPI case is missing from the 2.21.4 and should be
added there and also the last paragraph about INVALID_SPI text in the
1.5 is something that is not that clearly explained in the 2.21.4 so
that also needs to be kept (and/or moved).
----------------------------------------------------------------------
Section 1.6 is way too far from the beginning. We have already used
those terms 40 times before this section comes up, so it would be much
better that this section would be in the beginning of the document,
not at the page 20... Perhaps it should be moved to subsection 1.0.1
and move other defined terms there too.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
