Hi,
I reviewed the draft and I believe it is almost ready. However,
I think there still are few issues.
1. The last para of section 4 says:
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. As such, it is NOT RECOMMENDED to use
Implicit IV with Multicast.
I have three problems with this para. First, I think that this para
should be moved into the Security Considerations section.
Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat")
seems to be wrong here, since it is not an imperative, it's an explanation here
(because the preposition "As" is used; note that the draft has already stated
that the
nonce MUST NOT repeat in the beginning of Section 4). And last (but not least),
I have some trouble following this para, it seems to me that it is
self-contradicting.
First it says that IIV MUST NOT be used if there is a chance that SN repeats
(which I fully agree with), then it says that multicast is a prominent
example of this situation (i.e. the situation when SN may repeat, which
I fully agree with too) and finally it concludes that for multicast
IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used).
In other words it is allowed to use IIV for multicast in some circumstances,
which in my opinion contradicts with earlier MUST NOT.
Either remove the last sentence, or give more explanation
when it is possible to use IIV for multicast.
2. The draft defines IIV for ESP only and forbids to use it for IKEv2.
It was discussed and I believe it is right, but I'd like to see few
words (presumably in the Security Considerations) why IIV
in its current form cannot be used in IKEv2. Something along the lines:
This document defines three new encryption transforms that use implicit IV.
Unlike most encryption transforms defined to date, which can be used
for both ESP and IKEv2, these transforms are defined for ESP only and cannot
be used in IKEv2. The reason is that IKEv2 messages don't contain unique
per-message value, that can be used for IV generation. The Message-ID
field in IKEv2 header is somewhat counterpart of SN field in ESP header,
but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to repeat,
so there is no an easy way to derive unique IV from IKEv2 header fields.
Regards,
Valery.
> This message starts a working group last call (WGLC) on
> draft-ietf-ipsecme-implicit-iv-04, which will conclude
> on June 29, 2018 at UTC 23:59. Please review and provide feedback on the -04
> version
> (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). Please
> indicate if you believe this draft is
> ready for publication or if you have comments that must be addressed before
> the draft progresses.
>
> Regards,
> Dave
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
