Éric Vyncke via Datatracker writes: > ## 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). > > 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.
As I pointed out in my previous email that is not the case. The RFC4303 ESP has a Next Header field which contains indicates what type of packet is inside the ESP packet. It typically contains IP Protocol Numbers, but not always. Thats why the RFC4303 above says "chosen from the set of IP Protocol Numbers". The next paragraph in RFC4303 actually reuses one of the IP Protocol Number, i.e., 59 which means "no next header" for traffic flow confidentiality, i.e., for dummy packets: To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet. Actually only case where the Next Header values actually may match the IP Protocol Numbers is when transport mode is used, and even then they negotiated in the IKEv2, i.e., ESP does not care really what next header number means, it just passes them through along with the packet itself. If IKEv2 negotiates transport mode IPsec SA using ESP for IP Protocol number 233 (which is unassigned), then policy matching of the kernel will somehow find those packets matching that unknown IP Protocol Number and pass them to ESP, and ESP will simply store the IP Protocol Number in its header and encapsulate the packet without looking in to it. There are some special / magical numbers used in the ESP. One of them is 59, another is 4 for IPv4 tunnel mode and one is 41 for IPv6 tunnel mode. Note, that both IPv4 (4) and IPv6 tunnel (41) mode Next Header field values are also special cases which do not exactly match the IP Protocol Numbers. The tunnel mode processing is completely different from transport mode processing, and contains additional things like exit tunnel checks etc. They are even negotiated in the IKEv2 in completely different manner than transport mode protocol numbers. I.e., in IKEv2 when negotiating tunnel mode the fact it is going to be tunnel mode is negotiated separately and the protocol number in the traffic selectors will indicate what protocol numbers are passed inside the tunnel, i.e., what is going to be the IP protocol number of the inner packet, not what is going to be in the Next Header field of the ESP. The Next Header field of the tunnel mode ESP is taken by checking whether packet is IPv4 or IPv6 and mapping that to the IP Protocol Numbers having little bit same name or meaning, but reading those RFCs related to those IP Protocol Numbers will simply confuse you if you try to implement tunnel mode IPsec. So the Next Header field can only match the IP Protocol numbers for transport mode ESP. There is no IANA registry for the Next Header fields of the ESP. As the number of special cases for Next Header fields is raising it might be beneficial to generate one at one point, but currently there is no IANA Registry for it. Also as the use of IPTFS is negotiated in the IKEv2, so unless both peers agree to use it, Next Header value of 5 is never used. The reason why we need something there is that in some cases it might be beneficial for debugging etc purposes to know the inner packet type, just like in the IPv4 and IPv6 tunnel mode. The ESP could have been written so that IPv4 and IPv6 tunnel mode would use exactly one Next Header value, and after the ESP takes the inner packet from then outer packet, it could check out the IP header to see whether it is IPv4 or IPv6 packet and process it based on that. I also do not think that this updates to the RFC4303 in any way. This is extension that is negotiated in the IKEv2, and only implementations who actually implement IPTFS will ever see Next Header values of 5, and for them it is enough to read the this RFC describing the IPTFS. Implementors who do not care implementing IPTFS, but only implement ESP, does not need to know or care about this. None of the old ESP implementations are affected by this specification. > ### 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. ESP is already generic tunneling mechanism, this draft just adds another feature to that already existing generic tunneling mechanism, this draft does not specify new tunneling mechanism. Doing traffic flow confidentiality (i.e., sending fixed flow of fixed size packets) is not really meaningful unless you also encrypt the packets, so there is no point of trying to reuse this protocol for the intended use as general tunneling mechanism without security layer, and that security layer is ESP. I agree that paragraph you listed which says that there might be other uses is something that could be removed, as it does not really mean anything for IPTFS. > 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). As one of IPsecME Chairs I can comment that we did have quite a long discussion about the Next Header value in the working group and ended up using the number proposed in the draft. There was also some proposals in WG to make this more generic, but we tried to keep the protocol limited to the intended use, i.e., how to send constant flow of fixed size packets to hide traffic patterns, and not solve problems outside the IPsec framework, but we did not want to artificially limit the solution just in case someone wants to use it somewhere else. > ## COMMENTS > ### 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. I also checked this when you pointed it out, and parcels is missing lots of things that would have been required for this. The parcels only seems combine multiple packets inside the one packet, it misses the main point of this draft, which is to send fixed rate (for example 10 packets per second), fixed size packets (for example 1000 bytes) over the single ESP tunnel to hide whether there is traffic ongoing inside that ESP tunnel, and what type of traffic there is inside that ESP tunnel. The draft-templin-intarea-parcels could have been one building block for this, i.e., if that would have been already specified earlier, the aggregation from ther could have been reused. But this work started in March 2019, the first draft of draft-templin-intarea-parcels has been published in December 2021, i.e., after this document was already submitted to IESG for Publication (November 2021). It is bit hard to be aware of draft that is non-existing when submitting the document to IESG... > ### 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. If the receiver negotiates IPTFS and says it does not support receiving packet framents, then sender cannot fragment inner packets, and must instead add padding to the end of outer packet if the next packet does not fit to the space that is left in the outer packet. This is described in section 6.1.4, i.e., either end can send Don't Fragment bit on meaning that it does not support receiving packet fragments, and as the packets are always fixed size, the padding is needed to pad the outer packets to that fixed size.. Some implementors felt that 100% utilization of the constant rate fixed size flow of packet is not that important, and implementing fragmentation is extra code that they do not need. If you do not support fragmentation, then inner packet can never be split across multiple outer packets, making implemenations easier. When inner packet is split over multiple outer packets there are all kind of corner cases, like reordering of outer packets, lost outer packets (if any of the outer packets is lost the inner packet is lost, but you do not know that this was lost packet until later, when you can confirm that this not just packet reordering) etc. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
