Éric Vyncke via Datatracker <nore...@ietf.org> writes:
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-iptfs-13 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, alas the justification of the intended status is missing :-( Please note that Tatuya Jinmei is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well: https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section 6.1 ``` An AGGFRAG payload is identified by the ESP Next Header value AGGFRAG_PAYLOAD which has the value 0x5. The value 5 was chosen to not conflict with other used values. The first octet of this payload indicates the format of the remaining payload data. ``` This is in direct conflict with RFC 4303 (see below) IMHO as 5 is already allocated to ST (RFC 1819, which is still 'current' even if it was never used).
Not that this matters, but the author of RFC1819, Lou Berger, suggested we use this value very early in the documents life.
But ESP RFC 4303 section 2.6 says that this is an IP protocol number (and 5 is already allocated by the IANA): ``` The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP. ``` I.e., either this document needs to formally update RFC 4303 by allowing any number or another IP protocol number must be requested to the IANA.
The ipsecme chair (Tero) has already addressed this in a prior email. We aren't the first non-IP protocol number use of the ESP next header field. There is no need to allocate IP numbers for ESP use and we aren't the vanguard in this.
### Section 2.1, generic tunnel capability ``` Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such as increased performance through packet aggregation, as well as handling MTU issues using fragmentation. These uses are not defined here, but are also not restricted by this document. ``` Moreover, while IPSECme charter includes: ``` The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. ``` it says nothing about a generic tunnelling protocol, which is usually INTAREA topic, and I cannot refrain from thinking that this tunnelling mechanism could be used on any connection-less transport, e.g., UDP or IP. Hence, this DISCUSS point is only to initiate a discussion with IPSECME chairs and AD; Christian Hopps has already given some explanations when I deferred this I-D. I understand that I am in the rough here (no reaction on int-area and int-dir review is positive).
We did not write a generic tunneling protocol, as explained in prior email. The encapsulation makes direct use of ESP, as well as other choices such as how inner IP flags are mapped to outer packets being driven by the fact that the inner traffic is by definition being protected by an IPsec security association. Regarding the charter, the quoted charter item was specifically written for this work... Thanks, Chris.
### Section 2.2.6 Please also mention hop-limit and RFC 8200. ### Absence of ICMP considerations Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several unprotected packets can be bundled together, some guidance to the implementers will be welcome. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Yet another fragmentation above layer 3 No need to reply on this comment, but I cannot refrain from wondering how many fragmentation mechanisms above layer 3 have been specified by the IETF... We could end up running this specification over IPsec over TCP ;-) ### draft-templin-intarea-parcels Are the authors/WG aware of draft-templin-intarea-parcels ? This draft was not adopted by intarea (lack of interest mainly) but also aggregates packets into "parcels". Christian has already replied to this comment when I deferred the IESG evaluation. This is only kept for archiving. ### Section 1 s/(indicated using protocol 59)/(indicated using IP protocol 59)/ ? ### Section 2.1 ``` Padding is only added to the tunnel packets if there is no data available to be sent at the time of tunnel packet transmission, or if fragmentation has been disabled by the receiver. ``` The reader will welcome explanation about why a receiver disabling fragmentation is influencing padding at the sender side. ### Section 2.2 As ESP next header expects an IP protocol number and this one should probably be an IPv6 extension header, then the format proposed on figure 1 does not fit the usual extension header format. Did the authors analyze the potential use of the usual IPv6 extension header ? (at the expense of wasting bytes of course...) ### Section 2.2 dual-stack blocks ? Should there be a note about having a mix of IPv4 and IPv6 data blocks inside a single payload ? ### Section 2.2.5.1 Please add text about this section being IPv4-only as IPv6 header does not have a DF bit. Is there a recommended value for the DF bit for IPv4 outer headers ? ## NITS ### Section 1 ``` While directly obscuring the data with encryption [RFC4303], fully, the patterns in the message traffic may expose information due to variations in its shape and timing ([RFC8546], [AppCrypt]). ``` Possible wrong places for ',' around 'fully' ? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
