Hi, I reviewed draft-ietf-ipsecme-ikev2-diet-esp.
Summary: I don't think that the document is ready. There are many issues (or various severity) that need to be fixed. Issues. 1. Section 4.3. The compression of the Inner IP Packet is based on the attributes that are derived from the negotiated Traffic Selectors TSi/TSr, as described in [RFC7296], Section 3.13. The Traffic Selectors may result in a quite complex expression, and this specification restricts that complexity. In particular, Diet-ESP restricts the Traffic Selector to a single type of IP address (i.e., IPv4 or IPv6), a single protocol (such as UDP, TCP, or not relevant), a single port range, and multiple DSCP numbers. Such simplification corresponds to the expression of an individual Traffic Selector Payload [RFC7296], Section 3.13.1. This text is problematic. Section 3.13.1 describes Traffic Selector (substructure) and not a Traffic Selector payload (which is defined in Section 3.13). In addition, traffic selectors, as defined in RFC 7296, cannot express DSCP, thus I don't know how to interpret the above requirement. I believe the text tries to say that there MUST be only one Traffic Selector (Section 3.13.1) in both TSi and TSr payloads (described in Section 3.13). The TS Type MUST be either TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. (I don't know what to do with DSCP. The protocol and the TS type are always single-valued in a Traffic Selector substructure). Perhaps my interpretation is not correct, but the current text needs to be revised anyway. 2. Section 4.3, Table 1. For ts_ip_version parameter possible values listed as "IPv4-only IPv6-only". Should they be "IPv4-only" "IPv6-only" instead? Also s/IP4/IPv4 (two cases) Why "64 bit" parameter denotes its own empty row? Should it be along with possible alignment values? The same question for ANY, ... and "generated", "zero" empty rows. Perhaps they should be merged with the above cells. 3. Section 4.3 This specification limits the expression of the Traffic Selector to be of the form (IP source range, IP destination range, Port source range, Port destination range, Protocol ID list, DSCP list). This limits the original flexibility of the expression of TS, but provides sufficient flexibility. This is not consistent with the text above, since the text above requires that there be only one protocol and not the list. And again, DSCP values cannot be expressed in IKEv2 Traffic Selectors. 4. Section 4.3. It is not very clear for me what iipc_profile is for. In other words, if the value is "diet-esp", then what it means? Does it mean that only those parameters, defined in Table 1 for IIPC must be used? Should the application verify this? Should all these parameters be supported or it is allowed to support only some of them? I'd like to see more discussion of this in the draft. Perhaps external reference to some SCHC document is needed. 5. Section 4.3. Please, expand the text for possible values for dscp_cda and ecn_cda instead of sending readers to flow_label_cda by "(See flow_label_cda)". The list of values is different, so it is better to repeat their meaning for each parameter. 6. Section 4.3. The explanations for dscp_cda and ecn_cda both start with the text "indicates how the DSCP values of the inner IP packet are generated.". Unless I'm badly missing something, this should be s/generated/compressed / decompressed 7. Section 4.3 ts_ip_dst_start, ts_ip_dst_end, ts_port_dst_start, ts_port_dst_end are not explained in the text. 8. Section 4.3 Please, expand LSB and MSB on first use (I presume Least /Most Significant Bits). 9. Section 4.3. In the text related to ts_proto - why RFC 5996 is referenced? It is obsoleted by RFC 7296. 10. Section 4.3. The text related to dscp_list parameter informally references the expired draft draft-mglt-ipsecme-dscp-np. In my reading of this text, it is impossible to implement this draft without reading draft-mglt-ipsecme-dscp-np (at least this is my impression). Thus, reference to draft-mglt-ipsecme-dscp-np should be normative, whichm in my understanding, makes impossible publication of this document unless draft-mglt-ipsecme-dscp-np becomes RFC. Alternatively, please rewrite the text so, that draft-mglt-ipsecme-dscp-np is not needed for implementing this document. 11. Section 4.3. The text related to alignment parameter is very problematic. I cannot figure out what it is all about. For example, "indicates the byte alignement supported by the OS for the ESP extension." What is "supported by OS"? What is "ESP extension"? What should be aligned? Why 32-bit alignment is for IPv6? As far as I remember, the IPv6 header should be 64-bit aligned, 32-bit alignment is used for IPv4. Am I missing something? Since AES-CCM is mentioned, I presume that alignment in fact means not a requirement for the start of payload alignment, but instead the requirement for the total size of the payload to be encrypted to be multiple of the encryption transform block size. If this is the case, then this should be spelled out more accurately. In addition, the block size can be different from 128 bits (for example, for GOST "Magma" it is 64 bits, there may also be defined encryption transforms with 256-bit block size in future), so this should be expressed more accurately, referencing the requirements imposed by encryption transform. By the way, possible values for alignment do not include "128 bits", so the text related to AES-CCM "a 128 bit alignment is overwritten by the block size" cannot be parsed by me. BTW, a typo: s/alignement/alignment 12. Section 4.3. Text related to tunnel_ip states that it "can be an IPv4 or IPv6 address". However, in the Table 1 only IPv6 address is allowed. 13. Section 4.3. Text related to esp_encr - I fail to understand why knowing the encryption algorithm is needed for compression. Perhaps this should be clarified. BTW, a typo: s/compresse/compress 14. Section 4.3. s/Security Policy Index/Security Parameter Index 15. Section 4.3. Text for esp_sn_lsb: "and is defined by this specification". Is this clarification needed for this parameter? I believe many parameters listed above are also defined by this specification, but it is only mentioned for esp_sn_lsb. In addition - why possible values for this parameter are 0-64? SN in the ESP header is always 32 bits in length, for 64-bit ESN the upper 32 bits are never transmitted. 16. Section 5.1.1 If you add some table similar to Table 1, with FL, MO, CDA values for each parameter, it will make reading easier. Alternatively, place description of compressing each field to its own paragraph. The current text is difficult to read. 17. Section 5.1.3. In the text "If the IP Header is an IPv6 Header" perhaps "tunnel" is missing before "IP"? 18. Section 5.1.3. Please expand "IHL" (Internet Header Length). 19. Section 5.3. SCHC Compression efficiently compresses the Next Header field, reducing overhead and aligning the packet to byte boundaries using SCHC Padding. After this, the SCHC Pad Length field is added. It is not clear for me what is the sequence of applying various actions. >From my understanding the SCHC Padding is applied before CTEC compression, but reading this text it seems that it is applied after it too. Is it applied twice? 20. Section 5.3. The ESP Padding and Pad Length fields are reduced by the SCHC compression rule. I fail to understand how this can be done. The padding is included into the ICV computation, I don't know how you are going to elide these bytes. 21. Section 5.3. Isn't IPv6 require 64-bit alignment and not 32? 22. Section 5.4. I fail to understand why there is a need to send SN uncompressed in case of implicit IV. In any case, you *must* be able to decompress SN to an original value *before* decrypting the packet. If there is a chance SN is decompressed incorrectly, then the packet will be dropped anyway (due to ICV verification failure). As a consequence - the esp_encr parameter is not needed. 23. Section 5.4. The IPv6 Next Header field or the IPv4 Protocol field that contains the "ESP" value is changed to "SCHC". What is the value for "SCHC"? I failed to find it in IANA registry https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 24. Section 7. Where the mentioned IANA registries are situated? I failed to find any "IIPC Profile" registry on IANA website. Regards, Valery. > This will start two week WGLC for the draft-ietf-ipsecme-diet-esp [1]. > This last call will end at 2025-01-23. If you have any comments about the > draft > send them to the WG list. > > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/ > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
