Re: [IPsec] Disabling replay protection
Benjamin Schwartz writes: > On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson wrote: > > Tero Kivinen wrote: > > I mean what should other end do if the other end says he will not > > do anti-replay checks? > > Not send unique relay values in the ESP. > > Yes but mostly for AH. My goal is related to draft-xu-risav, which would > benefit from the ability to repeat sequence numbers in AH when replay > protection is not required. ESP and AH already allow that if you have multi sender situations, but IKE does not allow nogotiating such SAs. If you use g-ikev2 to negotiate multicast multi sender sa then I think the anti-replay is already disabled. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
Michael Richardson writes: > Tero Kivinen wrote: > > I mean what should other end do if the other end says he will not > > do anti-replay checks? > > Not send unique relay values in the ESP. You can already do that on multicast SAs, but for unicast SAs the RFC4303 mandates the unique sequence numbers regardless whether the recipient checks it or not: For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. and The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. Thus, the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section (3.4.3) below). Note, that the replay values might still not be unique, as if anti-replay is disabled then the sender can allow sequence number to cycle, thus using duplicate sequence numbers. This is not allowed if anti-replay is enabled. Only thing that could be allowed by telling the other end that anti-replay is disabled is that the sequence number is allowed to sycle: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter. However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) Is that feature so important that we should have separate notification for it? If you want to do something else by negotiating the fact that you do not do anti-replay protection then we need to modify the ESP and AH too, not just add notification to IKE. So I am saying that I do not see any real use case for just adding notification to IKE. There could be other features that people want to add that would also require telling the other end that replay protection checks are disabled, but those changes would require more things than just one notification to ike. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
On Thu, Feb 23, 2023 at 7:13 AM Steffen Klassert < steffen.klass...@secunet.com> wrote: > On Tue, Feb 21, 2023 at 12:45:27PM -0500, Benjamin Schwartz wrote: > ... > > Reusing sequence numbers is extremely unsafe in ESP. Most notably, > AES-GCM > > fails entirely and **leaks the shared secret** if a nonce is ever reused > > [1]. > > That depends on how you create your Nonce. If you use the sequence numbers > as the IV, then yes. But you are free to implement any other method as > long as the IV (and with that the Nonce) does not repeat (RFC 4106). > > So in theory, you can do that with ESP too. > Thanks for pointing this out! I didn't realize that RFC 4106 added a separate IV field. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
On Tue, Feb 21, 2023 at 12:45:27PM -0500, Benjamin Schwartz wrote: > On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson wrote: > > > Tero Kivinen wrote: > > > I mean what should other end do if the other end says he will not > > > do anti-replay checks? > > > > Not send unique relay values in the ESP. > > > > Yes but mostly for AH. My goal is related to draft-xu-risav, which would > benefit from the ability to repeat sequence numbers in AH when replay > protection is not required. > > Reusing sequence numbers is extremely unsafe in ESP. Most notably, AES-GCM > fails entirely and **leaks the shared secret** if a nonce is ever reused > [1]. That depends on how you create your Nonce. If you use the sequence numbers as the IV, then yes. But you are free to implement any other method as long as the IV (and with that the Nonce) does not repeat (RFC 4106). So in theory, you can do that with ESP too. Steffen ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson wrote: > Tero Kivinen wrote: > > I mean what should other end do if the other end says he will not > > do anti-replay checks? > > Not send unique relay values in the ESP. > Yes but mostly for AH. My goal is related to draft-xu-risav, which would benefit from the ability to repeat sequence numbers in AH when replay protection is not required. Reusing sequence numbers is extremely unsafe in ESP. Most notably, AES-GCM fails entirely and **leaks the shared secret** if a nonce is ever reused [1]. However, if the sender knows that the receiver is not enforcing replay protection, and ESN is disabled, then the sender can use sequence numbers out of order, which might be helpful for multi-sender situations. (This is a subset of draft-ponchon-ipsecme-anti-replay-subspaces, which I also think is worth pursuing in some fashion.) --Ben Schwartz [1] https://eprint.iacr.org/2016/475.pdf ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
Tero Kivinen wrote: > I mean what should other end do if the other end says he will not > do anti-replay checks? Not send unique relay values in the ESP. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Disabling replay protection
Benjamin Schwartz writes: > Hi IPSECME, > > RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is employed, > the receiver SHOULD notify the sender, during SA establishment, if the > receiver will not provide anti-replay protection". > > I haven't been able to find any mechanism for this in IKEv2 (or IKEv1). Is > there a way to do this? Or is this a mismatch between ESP and IKEv2? I think we discussed this during the development of the IKEv2, and it was decided that as the replay protection is completely local matter, there is not really reason to have that kind of notification in IKEv2. I mean what should other end do if the other end says he will not do anti-replay checks? I think it would be stupid to reject such connections just because of that, and that could cause the other end to claim to do it and still not do it just to get through the negotiation. In IKEv2 we tried to remove all of those parameters which are only local matter, so that any differences in those do not cause the negotiations to fail. In IKEv1 there was for example the lifetime parameters sent inside the IKEv1, and they caused lots of interoperability issues, when one send life time of 86400 and the other one had life configured to 86700, because there was 24h lifetime + 5 minute grace period. Or other end had one hour and other had 8 hours. Trying to get both ends to agree on the exact lifetimes was difficult, and thats why we removed those in IKEv2. I think the anti-replay protection is similar matter. What is the actual real life reason you would want to know about that, and what do you want to do when they do not match? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
> > Another approach would be to generalize the Transform Type 5 > > as the way to control the replay protection status > > (see draft-ietf-ipsecme-g-ikev2-07, Section 2.6.) > > I guess that depends on what implementations do when seeing a > Transform Type 5 value with bit 1 set. Would we really want > the Child SA to fail on such unknown value? > > In that sense, a NOTIFY seems more safe. Unknown status notify's > are ignored. And using notify shows more clearly it is a notification, > not a negotiation? Good point. In G-IKEv2 there is a provisioning instead of negotiation, so there is no such a problem. Regards, Valery. > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
On Fri, 17 Feb 2023, Valery Smyslov wrote: In IPsec the replay protection is a local matter of receiver, the sender must always increment the Sequence Number as if the replay protection is always on. Right. Another approach would be to generalize the Transform Type 5 as the way to control the replay protection status (see draft-ietf-ipsecme-g-ikev2-07, Section 2.6.) I guess that depends on what implementations do when seeing a Transform Type 5 value with bit 1 set. Would we really want the Child SA to fail on such unknown value? In that sense, a NOTIFY seems more safe. Unknown status notify's are ignored. And using notify shows more clearly it is a notification, not a negotiation? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
Hi, > > Hi IPSECME, > > > > RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is > > employed, the receiver SHOULD > notify the sender, during SA establishment, if the > > receiver will not provide anti-replay protection". > > > > I haven't been able to find any mechanism for this in IKEv2 (or IKEv1). Is > > there a way to do this? Or is > this a mismatch between ESP and IKEv2? In IPsec the replay protection is a local matter of receiver, the sender must always increment the Sequence Number as if the replay protection is always on. > Indeed, I don't see it for IKEv2 either. Funny enough there is > IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED for RFC 6311. That is for different purpose :-) > For IKEv1 I do see 24577 REPLAY-STATUS, referencing RFC 2407, > https://www.rfc-editor.org/rfc/rfc2407.html#section-4.6.3.2 > > So this was just never ported up to IKEv2 it seems. > > At $dayjob, we would call this an "easy onboarding task" :) > > Probably worth writing up a 3 page IKEv2 notification status payload for. Another approach would be to generalize the Transform Type 5 as the way to control the replay protection status (see draft-ietf-ipsecme-g-ikev2-07, Section 2.6.) Regards, Valery. > Paul > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
(Oops: ESP is RFC 4303, which contains exactly the same text except that it omits the words "such as IKE".) Thanks Paul; I hadn't found RFC 2407. I agree, we should port this forward to IKEv2. I'm happy to give that a try. On Thu, Feb 16, 2023 at 1:53 PM Paul Wouters wrote: > On Thu, 16 Feb 2023, Benjamin Schwartz wrote: > > > Subject: [IPsec] Disabling replay protection > > > > Hi IPSECME, > > > > RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is > employed, the receiver SHOULD notify the sender, during SA establishment, > if the > > receiver will not provide anti-replay protection". > > > > I haven't been able to find any mechanism for this in IKEv2 (or IKEv1). > Is there a way to do this? Or is this a mismatch between ESP and IKEv2? > > Indeed, I don't see it for IKEv2 either. Funny enough there is > IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED for RFC 6311. > > For IKEv1 I do see 24577 REPLAY-STATUS, referencing RFC 2407, > https://www.rfc-editor.org/rfc/rfc2407.html#section-4.6.3.2 > > So this was just never ported up to IKEv2 it seems. > > At $dayjob, we would call this an "easy onboarding task" :) > > Probably worth writing up a 3 page IKEv2 notification status payload for. > > Paul > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
On Thu, 16 Feb 2023, Benjamin Schwartz wrote: Subject: [IPsec] Disabling replay protection Hi IPSECME, RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection". I haven't been able to find any mechanism for this in IKEv2 (or IKEv1). Is there a way to do this? Or is this a mismatch between ESP and IKEv2? Indeed, I don't see it for IKEv2 either. Funny enough there is IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED for RFC 6311. For IKEv1 I do see 24577 REPLAY-STATUS, referencing RFC 2407, https://www.rfc-editor.org/rfc/rfc2407.html#section-4.6.3.2 So this was just never ported up to IKEv2 it seems. At $dayjob, we would call this an "easy onboarding task" :) Probably worth writing up a 3 page IKEv2 notification status payload for. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Disabling replay protection
Hi IPSECME, RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection". I haven't been able to find any mechanism for this in IKEv2 (or IKEv1). Is there a way to do this? Or is this a mismatch between ESP and IKEv2? Thanks, Ben Schwartz ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
