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

[Benjamin Kaduk <[e-mail]>]

On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote:
>    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
>    <[e-mail]> 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.  

Thanks!

> 
>      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 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.
> 
>    """

Ah, it seems I was reading too quickly and missed the precondition.
Thanks for the attention to detail!

-Ben