Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi Martin,

 

For the proposed text, I would prefer something normative but if you think that's unwise I'll accept your proposal.

 

          As Murray noticed, we can’t use normative language against future specifications :-)

 

          I combined text resulted from Lars’ comment and from yours into a list as follows

          (at the end of Introduction section):

 

                                                    ... It is expected that separate

   specifications will define for which purposes and how the

   IKE_INTERMEDIATE exchange is used in IKEv2.  Some considerations must

   be taken into account when designing such specifications.

 

   o  The IKE_INTERMEDIATE exchange is not intended for bulk transfer.

      This document doesn't set a hard cap on the amount of data that

      can be safely transferred using this mechanism, as it depends on

      its application.  But it is anticipated that in most cases the

      amount of data will be limited to tens of Kbytes (few hundred

      Kbytes in extreme cases), which is believed to cause no network

      problems (see [RFC6928] as an example of experiments with sending

      similar amounts of data in the first TCP flight).  See also

      Section 5 for the discussion of possible DoS attack vectors when

      amount of data sent in IKE_INTERMEDIATE is too large.

 

   o  It is expected that the IKE_INTERMEDIATE exchange will only be

      used for transferring data that is needed to establish IKE SA and

      not for data that can be send later when this SA is established.

 

          I think both wordings impose some recommendations/restrictions on using

          this exchange and thus it’s a good idea to put them together. Is it OK?

 

Otherwise, your responses look great!

 

          Thanks!

 

          Regards,

          Valery.

 

Thanks!

 

On Wed, Mar 2, 2022 at 1:26 PM Valery Smyslov <[e-mail]> wrote:

Hi Martin,

thank you for your comments.

> Martin Duke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-intermediate-09: 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/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (3.2) "Implementations MUST verify that Message IDs in the
> IKE_INTERMEDIATE
> messages [increment by 1]". Or what? In any case, isn't this fully enforced
> by
> the WINDOW_SIZE parameter in Sec 2.3 of RFC 7296? That is, if
> WINDOW_SIZE == 1,
> any message that doesn't increment by 1 will simply be ignored. If
> WINDOW_SIZE
> > 1, receiving an increment > 1 is in fact legal (due to packet loss) but the
> window will not advance until all IDs are received?

Your understanding is correct. These requirements are in RFC 7296
and may look redundant in this document. While it is not a good
practice to repeat requirements from another document, 
it is done here for the purpose of bringing readers' attention
to them, because for this particular exchange they are crucial 
for security. The way IKE_INTERMEDIATE exchanges 
are authenticated implies that chunks of data fed into the prf
be in the order these exchanges took place. 

Scott Fluhrer suggested to reinforce the requirement to check 
Message ID in the draft (quoting his private e-mail with his permission):

"... we need to be careful about Message ID handling; what we want to prevent is an attacker resending 
a previous encrypted IKE Intermediate message, and confusing things (which plausibly could happen 
if there were a large number of IKE intermediate exchanges, and the sides don't track all the message IDs 
that they've seen already).  I would suggest that the draft state that the responder MUST verify that 
the message IDs received are increasing (or is that inferable from the IKE RFC?)."

So, while it is basically repetition of what RFC 7296 says, it was decided
to reiterate these requirement due to their importance for security.

> (5) The security considerations hint at it with all the DoS talk, but it would
> be valuable to place some limits on the kind of information that can be
> contained in IKE_INTERMEDIATE and how it is processed. The document
> doesn't
> appear to explicitly restrict these messages to overflow from IKE_SA_INIT
> messages, so if an extension sends e.g. user data in these what are the
> implications? I'd suggest that applications not process such data until AUTH
> exchange is complete.

This document defines only the IKE_INTERMEDIATE exchange itself.
It is expected that other documents will define its application
and the types of data it contains.

That said, I agree that IKE_INTERMEDIATE must only be used 
in those cases, when the data transferred needs to be processed 
before (or in) IKE_AUTH. So, it's not for transferring user data 
(and I hope no specification will use it for this purpose).

I can add something like this:

  It is expected that the IKE_INTERMEDIATE exchange will 
  only be used for transferring data that is needed to establish IKE SA
  and not for data that can be send later when this SA is established.

Is it OK?

> While I am not particularly happy with solely using the WINDOW_SIZE
> mechanism
> to regulate the amount of data in flight, IMO that is an issue with RFC 7296
> and not this document.

Indeed.

Thank you!

Regards,
Valery.