Re: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT)

Hi Benjamin,

Thanks you for the comments. Please see in line my responses.

Yours,
Daniel
On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker <
noreply@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ipsecme-implicit-iv-08: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for addressing my Discuss!
>
> A few new comments on the -08:
>
> Abstract
>
> If we're going to differentiate between nonce and IV, I think that
> the algorithms require a unique but not necessarily unpredictable *nonce*,
> rather than *IV*.
>
> I would preferred to have IV instead of nonce is that IPsec provides
constraints on the IV, not the nonce. I expected to have switched from
algorithms to their implementations by writing "when used with IPsec" in
the previous sentence. In order to flip-flop from algorithm to their
implementations with IPsec, I propose to clarify this as follows:

OLD:
These
algorithms require a unique IV but do not require an unpredictable IV.

NEW:
This IV must be unique but can be predictable.

> Section 2
>
> nit: s/Initialize/Initialization/
>
Fixed

>
> nit: s/similar mechanism/similar mechanisms/ plural
>
Fixed

> Section 7
>
> My previous ballot was trying to note that the sender/receiver counters
> MUST be reset (as noted here) even without this document, as part of
> the core ESP requirements.  So we don't need to use the "MUST" here as
> if it's a new requirement; we can just say that this behavior is already
> present due to the preexisting requirements
>
>
> Well, the reason I included it was that - at least my reading of ESP - ESP
seems to require key to be rekeyed when the SN reaches its limit only when
anti-replay is activated. In our case, we need to have this property even
without anti replay protection. Here is the text I considered rfc4303
section 2.2

"""

The sender's counter and the receiver's counter are initialized to 0
   when an SA is established.  (The first packet sent using a given SA
   will have a sequence number of 1; see Section 3.3.3
<https://tools.ietf.org/html/rfc4303#section-3.3.3> for more details
   on how the sequence number is generated.)  If anti-replay is enabled
   (the default), the transmitted sequence number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.

"""

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