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