For the proposed text, I would prefer something normative but if you think that's unwise I'll accept your proposal.
Otherwise, your responses look great! Thanks! On Wed, Mar 2, 2022 at 1:26 PM Valery Smyslov <s...@elvis.ru> 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. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
