Hi, I was extremely suprised that this draft claimed to have anything to do with mobile networks. 3GPP specifications has _always_ mandated replay protection for all 3GPP uses of IPsec, without exceptions. This has been a very clear choice by 3GPP. I have been actively (as a delegate or backoffice) taking part of almost all changes and discussion to the 3GPP use of IPsec for the last 20 years. I cannot remember anyone suggesting to relax the mandate on replay protection. And if anyone was to suggest such a thing, Ericsson would strongly object to such a change.
TS 33.210 "For NDS/IP-networks the IPsec security protocol shall always be ESP. For NDS/IP-networks it is further mandated that integrity protection/message authentication together with anti-replay protection shall always be used." https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2279 TS 33.501 If you look at the 5G security specification, you will find the sentence "shall be integrity, confidentiality and replay-protected" for every interface. Additionally the requirement in 33.210 apply to all uses of IPsec in 5G and 4G. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169 Upper layers in mobile networks are designed with the expectation that the security layer always provide replay protection. If you turn of replay protection in a 3GPP network you likely end up with a large number of nasty vulnerabilities. For a summary why you should not turn off replay protection except in very specific circumstances see the comments Ericsson recently send to NIST. https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-38b-initial-public-comments-2024.pdf "We think replay protection should be a strong requirement unless careful analysis of the whole system shows that replay protection is not needed in some specific part. Users and developers expect replay protection and higher layer protocols are often designed with the expectation that the security protocol provides replay protection. One example where no replay protection might be acceptable is 0-RTT in TLS 1.3 [22], but only after very careful analysis by the server on what kind of data to accept. Systems without replay protection often leads to surprising attacks and are hard to analyze. It is not a coincidence that Section 8 and E.5 in RFC 8446 [22] spends many pages analyzing security considerations for replayable 0-RTT data. If an upper layer was designed with the expectation of replay protection in a lower layer, using a security protocol without replay protection in the lower layers can compromise confidentiality, integrity, and availability in the higher layer, i.e., the whole infosec CIA triad. Practical and serious vulnerability due to the lack of replay protection has been common in both standardized and proprietary systems. It is sometimes argued that replay protection can be turned off in a lower layer as it is handled in a higher layer. This might be correct for the current configuration but often leads to security vulnerabilities when the higher layers are updated or changes. One recent example is DTLS 1.3 [23] where the post-handshake messages were designed with the expectation that replay protection is provided by the record layer and it was forgotten that DTLS allows turning of record layer replay protection. IETF is discussing updating DTLS 1.3 to forbid turning off replay protection. The revision should mandate replay protection unless careful analysis of the whole system shows that replay protection is not needed in some specific part." I would like to see IPsec forbid or making it harder to turn off replay protection, at a minimum it should be visible for both parties that one endpoint intends to turn off replay protection. A security vulnerability in one party typically affects both parties. If replay protection is a performance problem, IPSECME should work on making replay protection more efficient in implementations. Cheers, John Preuß Mattsson On 2024-03-05, 09:37, "Panwei (William)" <william.pan...@huawei.com> wrote: Hi folks, As a follow-up of the previous discussion about ESN and anti-replay entanglement problem, we've prepared a draft: https://datatracker.ietf.org/doc/draft-pan-ipsecme-anti-replay-notification/ The current draft mainly wants to highlight the problem. It also gives a preliminary solution of adding anti-replay status notification in IKEv2 to fulfill the requirement in RFC 4303 and RFC 4303. Whether to do unbinding ESN from anti-replay needs more discussion and feedback, and can be updated into the draft in the future if people want. Comments and reviews are more than welcome. Regards & Thanks！ Wei PAN (潘伟) -----Original Message----- From: I-D-Announce <i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org>> On Behalf Of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Sent: Monday, March 4, 2024 3:19 PM To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Subject: I-D Action: draft-pan-ipsecme-anti-replay-notification-00.txt Internet-Draft draft-pan-ipsecme-anti-replay-notification-00.txt is now available. Title: IKEv2 Support for Anti-Replay Status Notification Authors: Wei Pan Qi He Paul Wouters Name: draft-pan-ipsecme-anti-replay-notification-00.txt Pages: 7 Dates: 2024-03-03 Abstract: RFC 4302 and RFC 4303 specify that, during Security Association (SA) establishment, IPsec implementation should notify the peer if it will not provide anti-replay protection, to avoid having the peer do unnecessary sequence number monitoring and SA setup. This document defines the ANTI_REPLAY_STATUS Notify Message Status Type Payload in the Internet Key Exchange Protocol Version 2 (IKEv2) to inform the peers of their own anti-replay status when creating the IPsec SAs, to fulfill the above requirement. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-pan-ipsecme-anti-replay-notification/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-pan-ipsecme-anti-replay-notification-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ I-D-Announce mailing list i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
