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

[Martin Duke via Datatracker <[e-mail]>]

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?

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

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.