eesp.org : add Security Considerations

Author: antonyantony

eesp.org

@@ -1820,7 +1820,51 @@ be supported.
 Security is central to the design of this protocol, and thus security
 considerations permeate the specification.  Additional security-
 relevant aspects of using the IPsec protocol are discussed in the
-Security Architecture document.
+Security Architecture document [[RFC4301]].
+
+** DDoS when using Sub-SAs
+Creation of excessive Sub-SAs may exhaust resources on constrained peers.
+Implementations using IKEv2 SHOULD negotiate a “Max Sub-SA IDs” limit and
+MUST enforce local limits on the number of active Sub-SAs.
+
+** Using Crypt Offset
+The Crypt Offset feature exposes portions of the next-header information in
+cleartext, reducing confidentiality and introducing inherent security risk.
+Its use is intended only within a single administrative domain where both
+peers are under common operational control.
+
+The following recommendations apply:
+
+This mechanism is not intended for use across administrative domains or
+on the open Internet.
+
+The receiver SHOULD validate the Crypt Offset against local policy and
+log any violations as auditable event. Even for stateless implementations
+(e.g., similar to [[PSP]]), local maximum Offset values SHOULD be enforced.
+
+** Optional Disabling of Replay Protection
+Disabling replay protection may allow an attacker to force unnecessary
+cryptographic processing, even if higher-layer protocols reject
+replayed data. This is a deployment-specific trade-off and SHOULD be
+enabled only when appropriate for the operational environment.
+Alternativey use localy synchronized clock to filter older packets, when
+the IV is current time.
+
+** Too Many Optional Headers
+EESP optional headers resemble IPv6 Extension Headers. Excessive use of
+optional headers may lead to resource exhaustion on intermediate
+routers or the receiving peer. Implementations SHOULD avoid attaching
+an excessive number of optional headers to a single packet.
+
+** New Sub SA Key Derivation Function
+
+This draft introduces a new key derivation procedure for Sub-SAs
+([[Key Derivation for Sub SAs]]). Any new cryptographic construction
+requires review to ensure that the Sub-SA Key Derivation Function (SSKDF)
+provides appropriate secrecy, independence between Sub-SAs, and resistance
+to key-recovery or cross-SA attacks. A dedicated cryptographic review of
+the SSKDF is therefore RECOMMENDED, and like requested by IETF
+cryptographic working groups or CFRG.
 
 * IANA Considerations