Make replay protection mandatory if SNs are negotiated

Author: tobiasbrunner

eesp-ikev2.org

@@ -51,8 +51,9 @@ prior to decryption. EESP also enables the establishment of Sub SAs
 with independent keys and sequence number spaces. Additionally, it
 supports the use of 64-bit sequence numbers transmitted in each
 packet or the omission of sequence numbers when the Replay Protection
-service is not needed. EESP packets carry a version number, enabling
-easier support for future extensions.
+service is not needed or cannot be achieved (e.g. in some multicast
+scenarios). EESP packets carry a version number, enabling easier
+support for future extensions.
 
 This document specifies the negotiation of EESP Security
 Associations (SAs) within the Internet Key Exchange Protocol
@@ -234,15 +235,15 @@ Use of Sub SAs is optional in EESP and can be negotiated using IKEv2.
 
 ** EESP Sequence Numbers
 
-Unlike ESP, EESPv0 header allows to transmit 64-bit sequence numbers.
-In addition, the Sequence Number field in the EESPv0 header is
-optional and can be omitted from the packet if replay protection
-service is not needed. Note that while possible, disabling the
-replay protection service is generally NOT RECOMMENDED and should
-only be done if the upper level protocol provides this service. See
-[[Security Considerations]] for details.
+Unlike ESP, the EESPv0 header transmits 64-bit sequence numbers if
+replay protection is used. In addition, the Sequence Number field in
+the EESPv0 header is optional and can be omitted from the packet if
+replay protection is not needed. Note that while possible, disabling
+replay protection is generally NOT RECOMMENDED and should only
+be done in case of multicast scenarios or if the upper level protocol
+provides this service. See [[Security Considerations]] for details.
 
-# [VS] I believe this is covered below in the discssion about
+# [VS] I believe this is covered below in the discussion about
 # [VS] restrictions on negotiated parameters
 
 #  ** Explicit Initialization Vector
@@ -345,19 +346,16 @@ The type of the Sub SA Key Derivation Function transform is <TBA2>.
 This document defines two new Transform IDs for the Sequence Numbers
 transform type: ~64-bit Sequential Numbers~ (<TBD4>) and ~None~ (<TBD5>).
 
-To enable presence of sequence numbers in the EESP header the
-initiator MUST propose SN = (64-bit Sequential Numbers) in the
-Proposal Substructure inside the Security Association (SA) payload.
-When the responder selects 64-bit Sequential Numbers, the Sequence Number
-field is included into the EESP header, that allows peers to
-achieve replay protection.
-
-# NOTE STK: I'd say MUST above as we want to negotiate Anti-Replay
-# service and not just the presense of the seq nr field.
+To enable the presence of sequence numbers in the EESP header and
+enabling replay protection, the initiator MUST propose SN = (64-bit
+Sequential Numbers) in the Proposal Substructure inside the Security
+Association (SA) payload. When the responder selects 64-bit Sequential
+Numbers, the Sequence Number field MUST be included into the EESP
+header and peers MUST perform replay protection.
 
 To disable sequence numbering, and thus replay protection based on
 sequence numbers, the initiator MUST propose SN=None (<TBD5>).
-When the responder selects None, Sequence Number field is omitted
+When the responder selects None, the Sequence Number field is omitted
 from the EESP header.
 
 ** Transforms Consistency
@@ -399,15 +397,15 @@ Sequence Numbers transform type (32-bit Sequential Numbers and
 Partially Transmitted 64-bit Sequential Numbers)
 are unspecified for EESPv0 and MUST NOT be used in EESPv0 proposals.
 
-Implemenattions MUST ignore transforms containing invalid
+Implementations MUST ignore transforms containing invalid
 values for the current proposal (as if they are unrecognized,
 in accordance with Section 3.3.6 of [[RFC7296]]).
 
-The use of the None Transform ID for the SN transform
+The use of the ~None~ Transform ID for the SN transform
 if further limited by the ENCR transform. In particular,
 if the selected ENCR transform defines use of implicit IV
-(as transforms defined in [[RFC8750]]), then the value None MUST NOT
-be selected for the SN transform.
+(as transforms defined in [[RFC8750]]), then the value ~None~ MUST
+NOT be selected for the SN transform.
 
 ** Example of SA Payload Negotiating EESP