In section 1 Introduction: While this could be (partially) mitigated by setting up multiple narrowed Child SAs, for example using Populate From Packet (PFP) as specified in [RFC4301], this IPsec feature is not widely implemented.
I think it would be better to give better reason why PFP is not that useful, for example because it could cause way too many Child SAs, and/or way too few Child SAs as the number of Child SAs would be depending on the traffic flow patterns. I.e., if you have all traffic in one TCP/IP session (for example running backup), then you will get only one Child SA for all traffic. On the other hand if you have lots of separate short lived TCP connections (like web browser opening multiple connections to different web servers ect), you would have lots of Child SAs, which would be useless after short while. -- In section 1 change: "as specified in [RFC4301]" with "as specifeid in IPsec Architecture [RFC4301]" -- Add section 1.2 Terminology where you say you use terms Child SA, TSi, TSr, Notification Data, Traffic Selectors, CREATE_CHILD_SA, Configuration Payloads, etc defined in the RFC7296. Expand the list to include all terms used from RFC7296. -- Section 2 typo: s/Implementations/implementations/ -- Section 3 typo: s/multple/multiple/ Also you are using Notification Data (as specified n RFC7296), but then in the end of 1st paragraph you use "notify data payload". Changing those to be consistent would be good. -- In section 4 change twice: in [RFC7296] Section 2.9. with in IKEv2 [RFC7296] Section 2.9. also change As per RFC 7296, with As per IKEv2, (the IKEv2 rfc might not stay 7296 forever :) -- In section 5 say that the Notify Payload format is defined in IKEv2 [RFC7296] section 3.10, and are copied only here to make this document easier to read. -- In section 5.1 you say that Protocol id MUST contain either 2 for AH and 3 for ESP, but on the RFC7296 says that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt." and as this notify is sent with empty SPI field, then the Protocol ID field MUST be 0 also. -- In section 5.1 add text saying that SPI Size MUST be zero. -- In section 5.1 fix s/opague/opaque/ twice. -- In section 6 there is text saying: If the IKEv2 extension defined in this document is negotiated with the peer, an implementation which does not support receiving per-CPU packet trigger messages MAY initiate all its Child SAs immediately upon receiving the (only) packet trigger message it will receive from the IPsec stack. On the other hand there is no negotiation of the this extension. What is this text trying to say? Perhaps simply remove change to say "If an implementation does not support ... it MAY ..." -- Section 9 the correct heading for the IANA registries 2nd column are Notify Messages - Status Types and Notify Messages - Error Types Currently the figure 2 is using status type header and even that does not match iana registry. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec