While doing my IANA review on the document I found some small nits
about it. Here are my comments to the document:

--

Typo in abstract:

                                        This avoids
   sending the nonce itself, and savec in the case of AES-GCM, AES-CCM,
                                 ^^^^^

I assume it should be "saves".

--

In section 2 missing closing parenthesis and period:

                                ... The same applies for
   ChaCha20-Poly1305 ([RFC7634].  Currently this nonce is sent in each
                               ^

add missing ")".

--

In section 4, I think SA is better word than SPI to describe the IPsec
security association. SPI is just the number identifying the SA, SA is
the actual security association which includes sequence number, key,
direction, algorithms etc.

So change:

   As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
   used, Implicit IV as described in this document MUST NOT be used in
   setups with the chance that the Sequence Number overlaps for one SPI.
   Multicast as described in [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a prominent example, where many senders share
   one secret and thus one SPI.

with

   As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
   used, Implicit IV as described in this document MUST NOT be used in
   setups with the chance that the Sequence Number overlaps for one
   SA. Multicast as described in [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a prominent example, where many senders
   share one secret and thus one SA.

--

This text is bit misleading

   A similar mechanism could be used by associating the most
   significant byte of the Sequence Number to a sender, while the 3
   remaining bytes will be used to carry the counter value. Such
   mechanism prevents the use of Extended Sequence Number and limits
   the number of packet to be sent to 2** 24 = 16777216, that is 16 M.

To solve the issue you could of course move the sender byte as the
least significant byte in the sequence number, i.e., in that case the
system could use extended sequence numbers, and the limit of the
packet would not be that bad. Of course this still has the issue that
normal replay window processing does not work with cases where
sequence numbers are not used in numeric order (this same issue is in
the normal RFC6407 cases).

On the other hand, I think it might be better to just forbid the
implicit IV on multicast cases, and we do not need to explain all the
issues there. 

--

Section 5 and 6 need more text.

I.e., you do not actually describe how the Implicit IV is negotiated
in the IKE. You just tell that yes, it is negotiated, and there is no
issues.

So I suggest rewriting them as follows:

----------------------------------------------------------------------
5.  Initiator Behavior

   An initiator supporting this feature SHOULD propose implicit IV
   algorithms in the Transform Type 1 (Encryption Algorithm)
   Substructure of the Proposal Substructure inside the SA Payload. To
   facilitate backward compatibility with non-supporting peers the
   initiator SHOULD also include those same algorithms without
   Implicit IV (IIV) as separate transforms.

6.  Responder Behavior

   The rules of SA Payload processing require that responder picks its
   algorithms from the proposal sent by the initiator, thus this will
   ensure that the responder will never send an SA payload containing
   the IIV transform to an initiator that did not propose it.

--

In section 8 I do not understand what the first sentence is trying to
say. I think it should be better to rewrite the 1st paragraph in IANA
fConsiderations section as follows:

   This section assigns new code points to the recommended AEAD suites
   provided in [RFC8221], thus the new Transform Type 1 - Encryption
   Algorithm Transform IDs [IANA] are as defined below:
-- 
kivi...@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to