Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)
OK thanks. Those changes would make the document clearer for me, at least. Regards, —John > On Mar 3, 2022, at 2:16 AM, Valery Smyslov wrote: > > > Hi John, > >> John Scudder 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!XGQjnyKG320X2cLxK9O8lUUdHDPAUAqktikCKjmq47JKLaRtoV4JBm_gnZUvhQ$ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/__;!!NEt6yMaO-gk!XGQjnyKG320X2cLxK9O8lUUdHDPAUAqktikCKjmq47JKLaRtoV4JBm-OaYI_mg$ >> >> >> >> -- >> COMMENT: >> -- >> >> Thanks for this. I have just a couple minor questions/suggestions. >> >> 1. Section 3.2, “these exchanges MUST follow each other”. I suppose what is >> meant is, “these exchanges MUST be sequential” (this hardly seems to need to >> be >> mandated, but OK). Or is something else intended, in which case, what is it? > > No, you got the point. If you think “these exchanges MUST be sequential” > is more natural English wording, I'll use it. As a non-native speaker > I probably don't feel the difference... > >> 2. In Section 3.4, there is: >> >> not all error notifications may ever appear in the IKE_INTERMEDIATE >> exchange (for example, errors concerning authentication are generally >> only applicable to the IKE_AUTH exchange). >> >> I can’t make sense of what the word “ever” is doing there. It makes sense to >> me >> if I remove “ever” to make it “not all error notifications may appear”. It’s >> OK >> if I change “ever” to “even”. But I don’t get it, as written. Am I missing >> something, or would one of my edits be appropriate? > > This is again an artefact of me being a non-native speaker. > By using this word I intended to stress that some error notifications > may _never_ appear in the IKE_INTERMEDIATE, but it's OK for me to drop this > word. > > Thank you! > > Regards, > Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)
Looks good to me. On Wed, Mar 2, 2022 at 10:40 PM Valery Smyslov wrote: > 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 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 pro
Re: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt
Paul, I think your following concern is meaningful by further consideration. After all, a larger MTU can increase transmission efficiency. I think it would be appropriate to add the following mechanisms to provide the ability to increase MTU, please kindly share your opinion. - As paths over the internet change, this draft can kick in to reduce the size, but I see no method to go back to a larger size once the path between the endpoints recovers again. 1 - After receiving the "ALLOWED_MTU" notify message, the sender device will do some special processing - ICMP or pre-fragmentation - as described in this draft if the sender finds the MTU of original packet after ESP encapsulation exceeds the "ALLOWED_MTU". 2- The specific actions on sender device after receiving "ALLOWED_MTU" should have a "time limit". When the "time limit" is exceeded, no special processing - like MTU check before ESP encapsulation - is performed on the original packet and the normal process is returned. 3 - This "time limit" ensures that the session reverts to its original state - process original packets normally - after a certain amount of time - equivalent to a redetection of the path MTU so that MTU changes can be handled. If the ESP packet's size exceeds path MTU again the ESP receiver device could detect new MTU and send " ALLOWED_MTU ". 4 - The recommendation at the implementation level is that this "time limit" should be flexible, in other words configurable. Because in theory, the path MTU does not change frequently, and redetection of the MTU may temporarily introduce packet loss (Or other problems) caused by ESP fragmented packets. Therefore, users should decide the "time limit" value based on actual network conditions. Paul, thank you very much for all of your suggestions, which are really of great help to improve the completeness and usability of this draft. Brs -Original Message- From: Harold Liu Sent: Thursday, February 24, 2022 3:51 PM To: ipsec@ietf.org; Paul Wouters Subject: RE: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt Paul, I further consider your concern below and I think I did not deep understand it before. You are right currently there is no mechanism to recover to a larger MTU, I will further think of it and update to you later. Again, really thank you for your valuable comments. - As paths over the internet change, this draft can kick in to reduce the size, but I see no method to go back to a larger size once the path between the endpoints recovers again. Brs -Original Message- From: IPsec On Behalf Of Harold Liu Sent: Thursday, February 24, 2022 11:21 AM To: ipsec@ietf.org; Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt Paul, thanks for your comments and I am really glad that you are interested in this topic. Please see my response inline. -Original Message- From: Paul Wouters Sent: Thursday, February 24, 2022 6:38 AM To: Harold Liu Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt On Wed, 23 Feb 2022, Harold Liu wrote: > Recently we ran into a real problem in some IPsec use case - In customer > application scenarios, ESP packets are fragmented, which causes many problems > - Including performance problems, device resource problems, and even traffic > loss (In customer use case, it is IPsec over NAT scenarios so ESP packets are > encapsulated by UDP. Therefore, except for the initial fragment that > contains complete UDP header, other fragments can only indicate UDP protocol > in the IP address, but do not have UDP header. Therefore, they may be > incorrectly identified by other applications and captured - The fragmented IP > payload is regarded as a UDP header. ESP cannot be reassembled and the > package is lost). When this happens, the application should be missing its packets, eg TCP or UDP and could reduce its MTU based on that as well. In other words, why would we want a second mechanism to do this, where these two mechanisms could end up fighting. The application cannot reduce its MTU when this happens because the packet lost, the application does not know the packet loss reason so as to cannot reduce the MTU and even cannot know what is appropriate to reduce to. For the TCP the standard action is retransmission according to sequence number received last time, but this could make trouble including but not limited to (I believe there are lots of description about TCP packets retransmission disadvantages) performance is significantly affected from an application level, and this continues to happen because the MTU of retransmitted TCP does not change. UDP is an unsolid transmission mechanism, UDP itself does not have any mechanism to detect packet loss. Some application/protocols over UDP (eg NTP/SNMP/IK
