Internet DRAFT - draft-pan-ipsecme-anti-replay-notification

draft-pan-ipsecme-anti-replay-notification







IPSECME Working Group                                             W. Pan
Internet-Draft                                                     Q. He
Intended status: Standards Track                                  Huawei
Expires: 4 September 2024                                     P. Wouters
                                                                   Aiven
                                                            3 March 2024


           IKEv2 Support for Anti-Replay Status Notification
             draft-pan-ipsecme-anti-replay-notification-00

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.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-pan-ipsecme-anti-replay-
   notification/.

   Discussion of this document takes place on the ipsec Working Group
   mailing list (mailto:ipsec@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ipsec/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ipsec/.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.






Pan, et al.             Expires 4 September 2024                [Page 1]

Internet-Draft      Anti-Replay Notification in IKEv2         March 2024


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Notifying the Anti-replay Status  . . . . . . . . . . . . . .   4
   4.  ANTI_REPLAY_STATUS Notify Payload Format  . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
   Payload (ESP) [RFC4303] are used to provide security for IP
   communications.  Both AH and ESP support the anti-replay function to
   prevent an attacker from resending the packets received by the IPsec
   peer before.  Each IPsec packet is sent with a unique sequence
   number, which the IPsec receiver checks to see whether the sequence
   number is duplicated.






Pan, et al.             Expires 4 September 2024                [Page 2]

Internet-Draft      Anti-Replay Notification in IKEv2         March 2024


   RFC 4302 and RFC 4303 specify the details of sequence number
   generation and verification.  When anti-replay is enabled on the
   receiver, the sender must monitor the sequence number counter and
   increment the counter with every message sent.  The sender must
   ensure that the counter does not cycle, and trigger the creation and
   use of a new IPsec SA before the counter is about to cycle.  When
   anti-replay is disabled on the receiver, the sender does not need to
   monitor or reset the counter.  The sender only increments the counter
   and rolls it over back to zero when it reaches the maximum value.

   It is specified in both RFC 4302 and RFC 4303 that, during 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.  However,
   currently, IKEv2 [RFC7296] does not have the notification of anti-
   replay status when negotiating the creation of an IPsec SA.  As a
   result, IPsec implementations must always assume that the peer has
   anti-replay enabled.  Even though anti-replay is disabled on both
   ends, they still have to monitor the sequence numbers.

   This document adds a notification in IKEv2 to inform the peers of
   their own anti-replay status when creating the IPsec SAs, which can
   finally avoid unnecessary sequence number monitoring.

1.1.  Problem Statement

   When anti-replay is enabled on the peer, the IPsec implementation
   needs to monitor the sequence number of outbound packets, and trigger
   a rekey to generate and use a new Child SA when the sequence number
   counter is about to cycle.  In high-performance scenarios, high-speed
   traffic causes the 32-bit sequence number to be consumed quickly,
   resulting in frequent rekeying of Child SAs.  For this reason, IPsec
   defines the Extended Sequence Number (ESN) function, extending the
   available space for sequence numbers from 32 to 64 bits.  Although
   ESN is good to avoid the sequence number running out in a short
   period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303
   both require ESN to be used in conjunction with the anti-replay
   function.  That is, ESN can only be used if the anti-replay feature
   is enabled.












Pan, et al.             Expires 4 September 2024                [Page 3]

Internet-Draft      Anti-Replay Notification in IKEv2         March 2024


   In the high-performance scenario, operators may choose to disable the
   anti-replay function for the considerations of QoS, performance, and
   others.  For example, the high-level QoS packets arriving first may
   cause a large number of low-level QoS packets being dropped, when the
   disordered packets exceed the window size of anti-replay.  Disabling
   anti-replay brings a new problem: IPsec peers cannot successfully
   negotiate using ESN.  The final result is that neither peer of IPsec
   enables anti-replay, but neither can use ESN, leaving the Child SAs
   forced to rekey frequently due to the rapid exhaustion of the 32-bit
   sequence number.

   The solution to this problem can be approached in two ways.  One
   option is to support the continued use of the ESN when anti-replay is
   disabled.  Because IPsec packets carry only the low-order 32 bits of
   the sequence number, the ESN has a need for the receiver to manage
   the anti-replay window in order to determine the correct value for
   the high-order 32 bits.  To use ESN when anti-replay is disabled, the
   IPsec implementation needs to create and maintain a separate window
   for ESN as well.

   The other option is to add a notification of anti-replay status in
   IKEv2.  Section 3.4.3 of both RFC 4302 and RFC 4303 specify that the
   IPsec receiver should notify the sender during SA establishment that
   the receiver will not provide anti-replay protection.  Adding the
   anti-replay status notification in IKEv2 can fulfill this
   requirement.  When anti-replay is disabled on both peers, neither
   peer needs to monitor the sequence number counter, thus avoiding
   frequent rekey of Child SAs.

   Although the first option could support using ESN when anti-replay is
   enabled at one peer and disabled at the other, this would require an
   update to RFC 4302 and RFC 4303.  Therefore, this document considers
   the second option, given that it is only an extension of IKEv2 to
   fulfill a requirement already defined in RFC 4302 and RFC 4303.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Notifying the Anti-replay Status

   When creating a Child SA, the ANTI_REPLAY_STATUS notify payload can
   be used by the initiator and the responder to inform each other of
   their own anti-replay status (enabled or disabled) regarding this SA.



Pan, et al.             Expires 4 September 2024                [Page 4]

Internet-Draft      Anti-Replay Notification in IKEv2         March 2024


   The initiator includes the ANTI_REPLAY_STATUS notify payload in the
   IKE_AUTH exchange request for creating the initial Child SA or the
   CREATE_CHILD_SA exchange request for creating the subsequent Child
   SAs.

   A responder that does not support the anti-replay status notification
   processes the request as normal, and does not include the new Notify
   in the response.  As per regular IKEv2 processing, a responder that
   does not recognize this new Notify, MUST ignore the notify.  As
   required in RFC 4302 and RFC 4303, this responder should assume the
   anti-replay is enabled in the initiator.  The absence of the Notify
   in the response indicates to the initiator that the responder doesn't
   support the anti-replay status notification.  The initiator continues
   the IKEv2 negotiation as usual, and also assumes the anti-replay is
   enabled in the responder.

   A responder that supports the anti-replay status notification can
   understand whether the initiator provides the anti-replay protection
   for this Child SA, and includes the ANTI_REPLAY_STATUS notify payload
   in the response to inform its anti-replay status about this Child SA.

   The IKE_AUTH message exchange in this case is shown below:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2,
       TSi, TSr,
       N(ANTI_REPLAY_STATUS)}  -->
                                <--  HDR, SK {IDr, [CERT,] AUTH,
                                         SAr2, TSi, TSr,
                                         N(ANTI_REPLAY_STATUS)}

   The CREATE_CHILD_SA message exchange in this case is shown below:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, [KEi,]
       TSi, TSr,
       N(ANTI_REPLAY_STATUS)}  -->
                                <--  HDR, SK {SA, Nr, [KEr,]
                                         TSi, TSr,
                                         N(ANTI_REPLAY_STATUS)}

   After the Child SA is successfully established and the initiator and
   responder mutually notify each other of their own anti-replay status,
   the IPsec implementation can choose not to monitor the sequence
   number counter if the peer's anti-replay is disabled.



Pan, et al.             Expires 4 September 2024                [Page 5]

Internet-Draft      Anti-Replay Notification in IKEv2         March 2024


4.  ANTI_REPLAY_STATUS Notify Payload Format

   The ANTI_REPLAY_STATUS Notify Message type notification is used by
   the initiator and responder to indicate their own anti-replay status
   to each other when creating the Child SAs.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+-+-------------+-------------------------------+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +---------------+-+-------------+-------------------------------+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +---------------+---------------+-------------------------------+
   |                            Status                             |
   +---------------------------------------------------------------+

   *  Protocol ID (1 octet) - this field MUST contain either (2) to
      indicate AH or (3) to indicate ESP.

   *  SPI Size (1 octet) - MUST be 0.

   *  Notify Message Type (2 octets) - MUST be set to the value TBD1.

   *  Status (4 octets) - this field MUST be 0 to indicate the anti-
      replay is enabled or 1 to indicate the anti-replay is disabled.

   The Critical bit MUST be 0.  A non-zero value MUST be ignored.

5.  IANA Considerations

   This document defines a new Notify Message Type in the "IKEv2 Notify
   Message Types - Status Types" registry.  IANA is requested to assign
   the codepoint in this registry.

   NOTIFY messages: status types            Value
   ----------------------------------------------------------
   ANTI_REPLAY_STATUS                       TBD1

6.  Security Considerations

   TBD

7.  Acknowledgments

   TBD

8.  References




Pan, et al.             Expires 4 September 2024                [Page 6]

Internet-Draft      Anti-Replay Notification in IKEv2         March 2024


8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/rfc/rfc7296>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4303>.

Authors' Addresses

   Wei Pan
   Huawei Technologies
   Email: william.panwei@huawei.com


   Qi He
   Huawei Technologies
   Email: archibald.heqi@huawei.com


   Paul Wouters
   Aiven
   Email: paul.wouters@aiven.io










Pan, et al.             Expires 4 September 2024                [Page 7]