Hi, Daniel, The abstract clearly states a goal that is not achievable (of avoiding reassembly). The best way to avoid the impact of mid-tunnel fragmentation is to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. However, even so, the egress always needs to handle reasssembly as long as there is even source fragmentation.
I appreciate what you WANT to do - but again, it is not possible. You have two behaviors - either use inner fragmentation (which won’t work for transit traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU. But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S of the tunnel ingress. If you reduce the tunnel MTU, you’re just going to end up black-holing packets arriving at the tunnel ingress. Two important points: the tunnel ingress is NOT the one that should ever send PTB back; that’s the job of the router where/if that tunnel ingress resides; second, you cannot claim to get around an ICMP black hole situation by creating a new ICMP black hole situation. The rest of the document is rife with further errors, e.g.: The last sentence of the abstract is incomprehensible. In the intro, the claims about IPv4 ID are incorrect. As noted in RFC6864, speed is not the issue but rather the expected reordering. Additionally, there’s already a timeout, so there is no requirement for indefinitely kept state. Further, given source fragmentation, such issues are irrelevant. DF=1 leads to black holing ONLY in the absence of PLPMTUD, which is the appropriate solution for IPsec tunnels anyway. Note that even if DF=0, black-holing could still occur if the Tunnel Transit packet exceeds the tunnel egress EMTU_R. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jan 4, 2023, at 7:21 PM, Daniel Migault <mglt.i...@gmail.com> wrote: > > Hi Joe, > > We are waiting for your feedback, but I just want to check we have the same > understanding and that we will have a feed back. > > We would like to understand if the terminology used in the document is > aligned with the one of intarea-tunnels and if we agree that intarea-tunnels > and IPsec have different perspectives on handling fragmentation. I do not see > what we are proposing very different from what IPsec has been doing for > years. > > I also think that everything is explained in the introduction (2 text pages), > so you do not have to read the full document. The document is available here: > https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/ > > Yours, > Daniel > > On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault <mglt.i...@gmail.com > <mailto:mglt.i...@gmail.com>> wrote: >> Hi Joe, >> >> So we just published an update of our draft. We try to catch up the >> complete idea in the introduction - to avoid reading the complete draft. I >> think we partly aligned with the tunnel document. The current version only >> describe the security gateway as a node and does not split it between a >> outer and an interface. I think for the remaining of the document we are >> taking the exact terminology from the tunnel draft. >> >> We believe that IKEv2 and the tunnel document have different visions and >> tried to highlight this also. >> >> One big clarification in my point of view is that the previous version >> confused MTU with MAP. >> >> We are happy to get your feedback. >> >> Yours, >> Daniel >> >> On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com >> <mailto:to...@strayalpha.com> <to...@strayalpha.com >> <mailto:to...@strayalpha.com>> wrote: >>> On Oct 31, 2022, at 11:07 AM, Daniel Migault <mglt.i...@gmail.com >>> <mailto:mglt.i...@gmail.com>> wrote: >>>> >>>>> - the tunnel has two DIFFERENT relevant MTUs >>>>> the egress reassembly MTU (EMTU_R), which is the only thing >>>>> that should drive the “tunnel MTU” >>>>> >>>>> the tunnel MTU, which the ingress needs to know for source >>>>> fragmentation, but is NOT relevant to the >>>>> origin MTU upstream of the ingress >>>>> >>>> Will read the draft - but we believe that is better to generate one IPsec >>>> packet for every inner IP packet as opposed to two. This is why we are >>>> proposing to adjust the MTU so the outer packet matches the limit of the >>>> EMTU_R - and fragmentation be avoided. >>> >>> That doc explains why this is effort isn’t useful. As I noted to Tero, >>> there’s no ICMP message that says “bigger than I’d like”. PTB means >>> “packets larger than this will be dropped”. That’s not what’s going on >>> here, so it’s the wrong message to support. >>> >>> There is no message that supports what you’re trying to do - perhaps >>> because there can’t and shouldn’t be. >>> >>> Joe >> >> >> -- >> Daniel Migault >> Ericsson > > > -- > Daniel Migault > Ericsson > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
